1 · Web viewCRIS Release Notes 2.09.10t1 specific D5.0.docx CRIS Version 2.09.10t1 Change History...

CRIS Release Notes 2.09.10t1 specific

Copyright© Healthcare Software Solutions 2014Registered Office: 3rd Floor i2 Mansfield, Hamilton Court, Oakham Business Park, Mansfield, NG18 5FB

These materials are or comprise restricted and proprietary confidential information of Healthcare Software Solutions. Disclosure to or use by the recipient shall not convey any intellectual property rights in these materials. The right to use these materials by the recipient is subject to restrictions and limitations contained in the Provision of Integrated Care Record System and Associated Services Agreement and related agreements.

ConfidentialityAll information in this document is provided in confidence for the sole purpose of adjudication of the document and shall not be used for any other purpose and shall not be published or disclosed wholly or in part to any other party without HSS prior permission in writing and shall be held in safe custody. These obligations shall not apply to information which is published or becomes known legitimately from some source other than HSS. Many of the product, service and company names referred to in this document are trademarks or registered trademarks. They are all hereby acknowledged.

Document Control

Title CRIS Release Notes 2.09.10t1 specificAuthor Gary Glover Date Created 25/08/2015File Ref. document.docxCRIS Version 2.09.10t1Change HistoryIssue Date Author / Editor Details of ChangeD1.0 21/08/2015 Gary Glover 2.09.10t1 initial draft.D2.0 25/08/2015 Gary Glover Removed references to development product names.D3.0 Bazil CaygillD4.0 14/09/2015 Gary Glover Corrected the new security setting outlined in issue CRIS-

1013.D5.0 24/09/2015 Gary Glover Issue CRIS-1163 completed

Review Date

© Healthcare Software Solutions 2014 All Rights Reserved Commercial In ConfidenceEffective Date – 10/07/2014HSS Doc ref: document.docx of 34

Contents

1. Introduction.............................................................................................................51.1. Purpose.............................................................................................................................. 51.2. Audience............................................................................................................................ 5

2. Authentication.........................................................................................................62.1. New Functionality.............................................................................................................. 6

3. Core.........................................................................................................................73.1. New Functionality.............................................................................................................. 73.2. Enhancements....................................................................................................................73.3. Resolved issues.................................................................................................................. 8

4. Database................................................................................................................104.1. Resolved Issue..................................................................................................................10

5. Date Formatting....................................................................................................115.1. Resolved Issues................................................................................................................11

6. Event Details..........................................................................................................136.1. Resolved Issue..................................................................................................................13

7. GUI........................................................................................................................ 157.1. Resolved issue..................................................................................................................15

8. Interfaces...............................................................................................................168.1. New Functionality............................................................................................................168.2. Resolved Issues................................................................................................................18

9. Post Processing......................................................................................................209.1. New Functionality............................................................................................................20

10. Printing...............................................................................................................2110.1. Resolved Issue..................................................................................................................21

11. Reporting............................................................................................................2211.1. New Functionality............................................................................................................2211.2. Resolved Issue..................................................................................................................25

12. Sessions...............................................................................................................2712.1. Resolved issue..................................................................................................................27

13. Setup Tables........................................................................................................2813.1. Resolved Issue..................................................................................................................28

14. Stats....................................................................................................................2914.1. Enhancement...................................................................................................................2914.2. Resolved Issue..................................................................................................................29

15. Vetting................................................................................................................30© Healthcare Software Solutions 2014 All Rights Reserved Commercial In ConfidenceEffective Date – 10/07/2014HSS Doc ref: document.docx of 34

15.1. Resolved issues................................................................................................................3016. Worklists.............................................................................................................32

16.1. New Functionality............................................................................................................3216.2. Resolved Issues................................................................................................................33


1. Introduction1.1. Purpose

This document will outline the functional changes made to this release. It will detail any new features, enhancements to existing functionality and list changes made due to existing functionality not working as expected.

1.2. AudienceThis document is primarily for the customer, so they have a clear understanding of what is included compared to previous releases. Internal stakeholders such as sales, product/client managers and Release Management personnel will also have visibility to this document and be involved in the review process.


2. Authentication2.1.New Functionality

CRIS-1057 Single Sign On implementation with ADDescription We need to provide the facility for automatic login using Single Sign On, which is validated against

the Active Directory domain. Shared workstation facilities are also needed to be implemented.Resolution Single Sign On is now implemented as required.Fixed in 2.09.10t1


3. Core3.1.New Functionality

CRIS-960 API for AVDATA for external systemsDescription Provide an API for external systems to retrieve AVDATA documents on request so that these are

available on request from external systems without relying on HL7 messagingResolution It is now possible to transfer AVData via HTTP instead of FTP. This is configured by the XR setting

AVDATAMANAGER.useHTTP. In addition, the following XR settings should be configured to point to the new AVData system: AVDATAMANAGER.HTTP.URL, AVDATAMANAGER.HTTP.User and AVDATAMANAGER.HTTP.Password.

Note that data migration is required before the HTTP solution can be implemented.Fixed in 2.09.10t1

3.2. EnhancementsCRIS-1076 Cannot close ‘role selection’ dialog box.Description If a user has a number of available roles, when the dialog appears so the required role can be

chosen, there is no way the user can cancel the login process and shut down the application.Resolution The user can now *shut down CRIS* during the login process by closing the role selection dialog

box.Fixed in 2.09.10t1

CRIS-845 Reduce the numbers loaded upon loginDescription When CRIS has been deployed as part of a large consortium, the login process is taking too long.

This is caused because it reads all of the users from the ‘staff’ table into memory as it starts up. Resolution Changes have been made to reduce the time taken to complete the visible startup process, by

processing old staff members in the background, whilst the current user maintains control of the application.

Fixed in 2.09.10t1

CRIS-1059 Printing delays in CRISDescription The introduction of saving the printed reports has significantly increased the time between

requesting one batch print and being able to change the filter to request the next one: CRIS is hanging at a point when users are expecting to be able to make changes.

Resolution An additional thread was added to handle storing items in an analogous way to printing them that was already present. Essentially, each item is placed in a queue and control is immediately passed back to the rest of CRIS. The background thread then handles the processing of the queue. This avoids the hanging, and ought to allow for the "type-ahead behaviour" that had been possible previously.

Fixed in 2.09.10t1


3.3. Resolved issuesCRIS-1074 Cannot select roles by using up and down arrow key in some cases.Description During startup process, Role selection dialog box in CRIS, is not working as expected in some cases.

(i.e. cannot select roles without pressing the TAB key)Resolution The ‘roles’ can now be selected using the ‘up’ and ‘down’ arrows as expected.Fixed in 2.09.10t1

CRIS-1075 When a role is selected by using keyboard, incorrect activities are shown in Role selection dialog box.

Description Where a user has multiple roles, selecting a specific role doesn’t display the associated activities of that role in the ‘Roles’ selection dialog box.

Resolution The associated ‘activities’ are now displayed correctly when a user selects a particular role.Fixed in 2.09.10t1


CRIS-1077 Patient event list datesDescription When undertaking the following sequence:

create a new event as a request; appoint it; cancel it; reappoint with different date and time; and then reload the patient event list

The time (onscreen) is correctly updated to the new time, but the onscreen date is not.

The underlying data in the database has been correctly updated.Resolution The correct date is now displayed onscreen alongside the correct time.Fixed in 2.09.10t1

CRIS-1116 Nuclear Med - Syringe info not insertingDescription It is not possible to attach syringe information against an event due to a

database error.The issue is that the time format is ‘hh:mm’, which is 5 characters in length but the database field only hold 4 characters – ‘hhmm’.

Resolution The GUI will always display the 5-character format. Before this is saved to the database, the ‘:’ is removed, so the time is saved without error.

Fixed in 2.09.10t1

3.4.


4. Database4.1.Resolved Issue

CRIS-1010 Error in ‘Batch verify’ due to time being stored incorrectlyDescription When adding a report to batch verify, the time is stored with a colon, e.g. 09:50. This leads

to an error when loading the batch from the batch verify screen.Resolution The GUI will always display the 5-character format. Before this is saved to the database, the ‘:’ is

removed, so the time is saved and retrieved without error.Fixed in 2.09.10t1


The GUI will always display the 5-character format. Before this is saved to the database, the ‘:’ is removed, so the time is saved without error.

5. Date Formatting5.1.Resolved Issues

CRIS-1005 DOB field no longer accepts certain date formatsDescription Since the changes to the date field layout, it is no longer possible to enter certain formats into the

DOB fields in CRIS.

For example, entering any of the following into the DOB field on the main CRIS screen in order to search for a patient brings back 16-Apr-0076 instead of 16-Apr-1976: 160476, 16 04 76, 16 4 76, 16/4/76 or 16/04/76

When entering into the DOB field on patient details the same date is calculated in the background and a warning message appear to say DOB cannot be more than 150 years in the past.

Note that the above formats work as expected in other date fields.Resolution Date of Birth / Date of death fields now calculate dates correctly and not from the year 0.Fixed in 2.09.10t1

CRIS-1006 Certain date formats return an incorrect dateDescription Recent changes to the formatting of dates and times have been implemented. In particular, dates

are now of the form dd-MMM-yyyy as opposed to dd/MM/yyyy. Since these changes, entering the following date formats no longer work as expected:(1) dd-M-yyyy(2) dd-M-yy(3) dd.M.yyyy(4) dd.M.yy, (5) dd.MM.yy(6) dd.MM.yyyy (date before 2000 only)

Resolution All expected date format entries are now supported.Fixed in 2.09.10t1

CRIS-1009 Validation no longer occurs in the date fields in CRISDescription Before the recent date/time formatting changes, if an invalid date was entered into a date field

then a warning message would be displayed to the user and the field would be blanked. This no longer occurs and an unexpected and often seemingly random date appears in the field instead.

E.g. Entering 31/04/2015 would evaluate to 01-May-2015.Resolution Changes have been made to better handle the entry of dates in the various formats now

supported, and to ensure that error messages are more coherent.Fixed in 2.09.10t1


CRIS-1217 Printed Letter arrival times different from DiaryDescription When an appointment letter is printed from a worklist, the resulting letter has prep time for the

examination taken into account. When printing an appointment letter directly from the diary, the prep time is not taken into account.

Resolution The ‘prep’ time is now being accounted for irrespective from where the letter is being printed.Fixed in 2.09.10t1

CRIS-1239 Diary number format exception.Description Errors are generated when resizing an event on the Diary. An error dialog is produced when

resizing an event on the diary, and the 'booked' field for the room is not incremented correctly.

Resolution Dragging and re-sizing events on the diary now work as expected.Fixed in 2.09.10t1

CRIS-1245 Date range not saving in Diary.Description When attempting to close a time range in a room in the diary, an error is thrown and the closure is

not saved. If a user right-clicks on a room header in the diary and selects 'Close time range', saving this range throws an error to say the value is too long.This is caused by colons not being removed before saving. E.g. if the time range is from 10:00 until 11:00, it attempts to save 10:0011:00 into the database, when it should actually be saving 10001100. It errors as the database field is only 8 characters long.

Resolution A date range can now be saved in the diary without error.Fixed in 2.09.10t1


6. Event Details6.1.Resolved Issue

CRIS-1086 Events showing an incorrect status after rollbackDescription When statuses are added in CRIS, the most recent status is normally set to be the current status.

However, certain statuses should never be set to current and, when one of these is added, the previous status remains the current one.

The statuses that should never be current are those with category V (vetted), P (printed), E (emailed) or D (document). So, for example, if a request is created and then vetted, the request status will remain the current status.

An issue occurs when doing Undo Attend, Not Performed. After the Not Performed status is added, it should add back the most recent current status. However, the usual check to ensure the previous status can be current is not done and so it is possible for one of the above four statuses to be added back as a current status.

Example: An event is requested, appointed, printed, attended, and then undo attend, not performed is selected.

This results in the following status list:

Status 1 = Request, not currentStatus 2 = Appointed, not currentStatus 3 = Printed, not currentStatus 4 = Attended, not currentStatus 5 = Not performed, not currentStatus 6 = Printed, current

This is incorrect as, although 'Printed' is the last status before 'Attended', it should not be set to current. The last status added should instead be:

Status 6 = Appointed, currentResolution The correct status is now inserted after Undo Attend, Not Performed has been selected. This

prevents the vetted, printed, and emailed or document statuses from being incorrectly set as the current status.

Fixed in 2.09.10t1


CRIS-1132 Error message displayed when changing event from daylistDescription An error message is displayed, ‘Request has been deleted’, when following Change workflow from

Day list.Resolution Fixed issue when updating the time an attendance is booked for.Fixed in 2.09.10t1


7. GUI7.1.Resolved issue

CRIS-1115 Author, License and notes information can be changed by userDescription Text in ‘Acknowledgements’ tab in ‘About CRIS’ dialog box can be manually changed by user.Resolution The text in this tab is no longer editable, therefore cannot be changed by the user.Fixed in 2.09.10t1


8. Interfaces8.1.New Functionality

CRIS-980 Create a DTI interface for the HSS DTI Hub application.Description There is a requirement to create an interface for the HSS DTI Hub application.Resolution Implemented HSS DTI Hub endpoint in CRISFixed in 2.09.10t1

CRIS-1011 Sending Reporting Groups as intended reporterDescription Where sites use reporting groups it can be useful to include the reporting group as part of the

outbound message for PACSResolution It is now possible to send out resource groups across the PACS interface in HL7 messages. These

are sent only when the attribute SendAdditionalNTEInfo is set to true (default false). In addition, the EJBSERVER user must have GENERAL.ResourceManagementModuleAvailable = 'Yes'.

The group information is sent out in NTE segments with the first repetition containing the code, the second repetition containing the description and NTE:4 containing 'RG' to identify this segment as a resource group.

E.g.

NTE|1||Resource group code 1~Group 1 description|RGNTE|2||Resource group code 2~Group 2 description|RG

As resource groups are stored at exam level, if an event contains multiple exams then the message for each individual exam will only contain groups assigned to that exam.

Note that a change has been made to the IEP interface to send out a set of NTE segments per exam whenever SendAdditionalNTEInfo = true. This is to ensure groups against all exams are sent. If the attribute is set to false then it works as it currently does and only sends NTE segments in the first exam section.

Fixed in 2.09.10t1

CRIS-1014 Protocol field to be included in messaging to PACSDescription Where vetting is done, it is useful to be able to message the protocol selected or created to the

outbound interface, both with PACS driven reporting and external tele radiology services. This component should be a configurable part of outbound messages.

Resolution It is now possible to send protocol information with any outbound OMG/ORU message to PACS or IEP. The information is sent in NTE segments, with the protocol text sent in NTE:3. This functionality is wrapped around the new attribute SendAdditionalNTEInfo. If this is set to 'false' then only clinical history is sent in NTE segments, which is how it worked before. If it is set to 'true' then it will send both clinical history and protocol information. In addition, if the attribute is set to true then NTE:4 is populated with 'CH' or 'PR' respectively, to show whether this text is clinical history or protocol info respectfully. The attribute is 'false' by default.


Fixed in 2.09.10t1

CRIS-1034 Event Comments required to pass to the PACS interfaceDescription Interface change required to ensure the event comments are sent, like the clinical history field,

with note type (NTE:4} populated with RE for remark . Likely to require an attribute for backward compatibility.

Resolution Event comments are now sent across the PACS interface whenever the attribute SendAdditionalNTEInfo is set to true (default false). The comments are sent in NTE:3 and NTE:4 is set to 'RE'.

Fixed in 2.09.10t1

CRIS-1163 Reason for exam and Clinical safety questions to be sent across interfaces in an NTE segmentDescription EMRAD requirement

Reason for exam and Clinical safety questions to be sent across interfaces in an NTE segment. This should be controlled by the attribute SendAdditionalNTEInfo.

Resolution Clinical safety questions will now be sent to PACS in NTE segments whenever the attribute SendAdditionalNTEInfo is set to true. NTE:4 will be set to 'QN' for these segments.

If the new attribute SendReasonForExam is set to true then OBR:31.2 will be populated with the Reason for exam. This field will be split into multiple repetitions whenever the text exceeds length 300, or whenever a line break appears in the text.

Note that this change will also affect the IEP interface.Fixed in 2.09.10t1

CRIS-1164 When a merge is done in CRIS it should create a trigger leading to an A08 message – EMRADDescription When a CRIS merge is performed, a MERGE interface trigger is create as expected. It should also

be possible for an UPDATE trigger for the main patient to be created, leading to an A08 message. This should be switchable via an XR setting.

Resolution It is now possible for an A08 message to be sent out following a patient merge in CRIS. The UPDATE trigger will be created as long as the new XR setting GENERAL.SendUpdateOnMerge is set to 'Yes' (default 'No'). The update message will be for the main patient.

Fixed in 2.09.10t1


8.2.Resolved IssuesCRIS-998 IEP Sends Wrong EventsDescription When sending events for reporting over the IEP interface, it is possible to configure the system to

send prior events. These should be previous attendances for the same patient. This works as expected when sending events from the patient's 'Events' page. However, if sending from a worklist that includes attendances for other patients, it is possible for these attendances to be erroneously sent over the IEP interface.

A change is required to ensure only priors for the selected event's patient are sent with the event that requires reporting.

Resolution The IEP interface now sends the same priors for an event, regardless of whether the event was sent from the patient's event list or from a worklist.

Fixed in 2.09.10t1

CRIS-1114 Partial Clinical History signature sent over the interfacesDescription When sending messages to PACS, the Clinical History is sent across in NTE segments. The signature

should be excluded from the message, i.e. the text that is automatically that displays the user, date and time.

Example:

Clinical History Line 1"(Entered By USER1 (Test User) on 22-Jun-2015 at 16:26)"

This sends out:NTE|1||Clinical History Line 1NTE|2||on 22-Jun-2015 at 16:26)

Only the first NTE segment should be sent.Resolution The signature is now fully removed from NTE segments as expected.Fixed in 2.09.10t1


CRIS-1167 Adding a delay to an interface trigger no longer worksDescription It is no longer possible to add a delay to an interface trigger in order to prevent it from being

processed straight away. Any interface trigger will be processed on the hour of the time due. So, for example, if the current time is 9:25 and a two minute delay is added so that the time due is 9:27, the trigger will actually be picked up at any time after 9:00, meaning it will be picked up straight away rather than waiting the required two minutes.

This will mean VERIFY triggers, which are delayed by two minutes as standard, will be sent out immediately. It also means that manual re-triggering, which should stagger the trigger processing to avoid too great a load, will no longer work, as the triggers will be processed in bulk on the hour.

Resolution Adding a delay to an interface trigger will now work as expected.Fixed in 2.09.10t1


9. Post Processing9.1.New Functionality

CRIS-959 Allow Auto Reporting when Report Editor is restrictedDescription Where restriction is enabled to stop the report editor being used, it must still be possible to allow

a user to create auto reports in post processing - there should be a security setting for the user to indicate which users are allowed to auto report.

Use the restrict report setting to implement the ability to auto report.Resolution Permission to Auto Reporting feature now only depends on the System Setting,

REPORT.AUTO_REPORT, regardless of other System Settings like GENERAL.CREATE_REPORT, GENERAL.CHANGE_REPORT and REPORT.PEER_REVIEW.

(Note: if REPORT.AUTO_REPORT is not set, it is regarded as N (i.e. No))Fixed in 2.09.10t1

CRIS-961 Post Processing to be read only once event is sent for external reportingDescription Post Processing should be locked so that changes can't be made once an event is being reported

externally to stop changes to exams, etc being made.Two new settings are required.An XR setting that ‘locks down’ the exam once it has been processed.A security setting to allow only ‘super users’ to override the ‘lockdown’.

Also need to add functionality for resending of post processing messageResolution Post processed data can now be locked down with XR setting

‘POSTEXAM.LockdownPostProcessing’ set to ‘Yes’ but can be overridden if the user has the ‘GENERAL.OVER_PPROC_LOC’ security setting.

Fixed in 2.09.10t1


10. Printing10.1. Resolved Issue

CRIS-1097 Printed Documents stored on the server results in NullPointer ErrorDescription It is possible that if a user attempts to print a document a null pointer exception will be generated,

this occurs when using HTTP not FTPResolution When storing printed documents, a previously closed data transaction is trying to be closed again,

leading to the error message seen. The error is no longer thrown and additional debug is added to inform the user when it is attempting to close an already closed transaction.

Fixed in 2.09.10t1


11. Reporting11.1. New Functionality

CRIS-958 Obstetrics reporting with external report interfaceDescription Where the report editor is restricted to read only, it must be possible to configure at

modality level which of the modalities this restriction applies to such that an event of modality 'O' is still reportable in CRIS.

Possible solutions:Using the CRISMODL table to include extra field to enable an override of report, if report is set to read only.XR Setting

If it's required to be site/trust specific then does it make more sense to add an XR setting? We could have it so that, for anything at all to be reported, the user must still have GENERAL.CREATE_REPORT/GENERAL.CHANGE_REPORT. But then, if they have an addition XR setting, e.g. Report.ModalitiesForReporting, set then only the modalities listed in this setting can be reported. E.g. Report.ModalitiesForReporting = O, M then only obs and MRI exams can be reported. If Report.ModalitiesForReporting is not set it could continue to work as it currently does. Would need to think about what to do for mixed modality events.

Resolution New XR Settings: REPORT.ModalitiesForReporting.Other Affecting Settings: System Settings: GENERAL.CREATE_REPORT, GENERAL.CHANGE_REPORT, REPORT.AUTO_REPORT and REPORT.PEER_REVIEW.

Any kind of modality including Obstetrics can be restricted.

Reporting facility is allowed mainly based on the modalities provided through the XR Setting, REPORT.ModalitiesForReporting, and if the settings is empty, it implies all the modalities are allowed in reporting. Reports with no allowed modalities are not displayed unless there is a requirement for adding addendum, changing acknowledgement fields and/or changing double reporting.

Main Areas where changes are mainly affected:XR Setting panel will pop up a multiple selection dialog box for modalities (Currently multiple selection dialog box is implemented for only modality even though underline API is also modified through this issue to compatible with other settings too. These enhancements will be addressed in future.)

While creating a new event under Reporting mode, allowability for report creation is restricted


mainly based on modalities and other relevant System Settings (these settings already are mentioned above).

While creating a new event under sonographer mode, allowability for report creation is restricted based on modalities and other relevant System Settings.

Reporting facility in Batch Verify List is restricted based on modalities and other relevant System Settings.

Reporting facility in Day List is restricted based on modalities and other relevant System Settings.

Reporting facility in Dictation List is restricted based on modalities and other relevant System Settings.

Reporting facility in Event Details is restricted based on modalities and other relevant System Settings.

Reporting facility in Event List is restricted based on modalities other relevant System Settings.

Reporting facility in Post Processing is restricted based on modalities other relevant System Settings.

Reporting facility in Report Info Lists is restricted based on modalities other relevant System Settings.

Reporting facility in OverrideConsentReason is restricted based on modalities other relevant System Settings.

CRIS Editor is restricted based on restricted based on modalities other relevant System Settings.

Reporting facility in Session Management is restricted based on modalities other relevant System Settings.

In a list, multiple selection of items may be enable or disable reporting button even though one event can only be reported.

Event with at least one exam with allowed modality will enable reporting facility depending on other relevant System Settings too.

Fixed in 2.09.10t1


CRIS-1013 Restrict report editor to read onlyDescription Where reporting is being done externally to CRIS, there needs to be a method for allowing

users of CRIS access to the report editor to review reports, but not to create them unless specific criteria are met. Add a setting that restricts the report editor to view only, in that the report can be viewed and the finished page can be access such that double reporting/museum codes etc can be added as well as communicator type functionality still works.Ensure reporting can be restricted to view only without affecting other workflows around the report editorNew security setting , default No, that enables:- Acknowledgement status popup and panel- Double reporting fieldsChange Report =Y should override this settingPrint Report should also be allowedSetting to be called restricted reporting mode

Restricted reporting mode to be able to be set independently of change report setting and still have the complete desired effect.

Resolution Changes made ensure that when GENERAL.CHANGE_REPORT and GENERAL.CREATE_REPORT (which are set in tandem) are set to "N" (No), then by setting REPORT.PEER_REVIEW to "Y" it is possible to edit both Acknowledgement and Double Reporting sections on the ‘FinishedPage’.Otherwise, behaviour is unaffected.

GENERAL. CREATE_REPORT/ CHANGE_REPORT

PEER REVIEW OUTCOME

Y N Ignore restricted reporting setting, allowed to do anything

Y Y Ignore restricted reporting setting, allowed to do anything

N N Works as it currently does, i.e. cannot do any kind of reporting

N Y Can change acknowledgement/double reporting sections

Fixed in 2.09.10t1


CRIS-1012 RCR Reporting Guideline Changes - Visibility of name/grade etcDescription Visibility of name, professional status, grade, position and registration number is required

when reporting. Identification of their name, professional status, grade, position and registration number is required when recording their interpretation of an imaging investigation. This can be achieved using a free text 'signature' field.

Add four free text fields to the Clinicians table: Primary Signature, Primary Signature Description, Alternative Signature, and Alternative Signature Description. They can then be included in interface messages/printed reports, although they will not be displayed in the CRIS report editor itself or saved in the database as part of the report text.

In terms of the interfaces, the signature should be included in an OBX segment following the report text. The signature used should relate to the clinician sent in OBX:16, which will be the person who reported, verified or addended the report. This should be the primary signature only and whether or not to send it should be switchable via a new attribute. This functionality should be added for all interfaces.

It should be possible to display both the primary and the secondary signature in a printed report.

Resolution Radiologist 'signature' is now appended to reports. There is a new attribute which controls this - 'IncludeClinicianSignature'.

Fixed in 2.09.10t1

11.2. Resolved IssueCRIS-962 Editing report text after removing clarificationDescription If a report has clarification markers, and a particular workflow is followed

to remove the mark and edit text, it causes the exception error below:2013-06-14 12:47:31,652 [AWT-EventQueue-1] DEBUG hss.digitaldictation.dragonapi.DragonAPI caretUpdate 260 - Caret changed2013-06-14 12:47:35,085 [AWT-EventQueue-1] DEBUG hss.digitaldictation.dragonapi.DragonAPI caretUpdate 260 - Caret changedUncaught exception in event thread for java.awt.event.KeyEvent[KEY_PRESSED,keyCode=8,keyText=Backspace,keyChar=Backspace,keyLocation=KEY_LOCATION_STANDARD] on hss.radiology.reports.CrisEditor[,0,0,1215x474,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.basic.BasicBorder


mailto:border%3Djavax.swing.plaf.basic.BasicBorders$MarginBorder@250cce,flags%3D360,maximumSize%3D,minimumSize%3D,preferredSize%3D,caretColor%3Dsun.swing.PrintColorUIResource

s$MarginBorder@250cce,flags=360,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=true,margin=javax.swing.plaf.InsetsUIResource[top=3,left=3,bottom=3,right=3],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],kit=hss.radiology.reports.ReportEditorKit@1fc719b,typeHandlers=]java.lang.ClassCastException: java.lang.Boolean at hss.radiology.reports.ReportDocument.remove(ReportDocument.java:604) at javax.swing.text.DefaultEditorKit$DeletePrevCharAction.actionPerformed(Unknown Source) at javax.swing.SwingUtilities.notifyAction(Unknown Source) at javax.swing.JComponent.processKeyBinding(Unknown Source) at javax.swing.JComponent.processKeyBindings(Unknown Source) at javax.swing.JComponent.processKeyEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at hss.app.WaitCursor.dispatchEvent(WaitCursor.java:47) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)

Resolution If the ‘clarification’ markers are removed, the remaining text can be edited without error.Fixed in 2.09.10t1




12. Sessions12.1. Resolved issue

CRIS-1220 Error message when saving comments in sessionsDescription An error message is thrown when saving a comment to a session event.Resolution The error was being thrown by the database due to an underlying ‘date/time’ formatting error.

The formatting has now been corrected and the session data can be saved as expected.Fixed in 2.09.10t1


13. Setup Tables13.1. Resolved Issue

CRIS-1058 Intended Clinician cannot be applied via Protocol TemplatesDescription When attempting to add the 'Intended Clinician' to an existing protocol template the value is not

saved. The problem also applies to new Protocols as well as existing protocols.

Resolution A change to the template is now correctly flagged when editing a protocol from the setup screen allowing ‘Intended Clinician’ field to be saved correctly.

Fixed in 2.09.10t1


14. Stats14.1. Enhancement

CRIS-1146 Stat date csv output formattingDescription It should be possible to configure whether stats outputs display dates in the new format (dd-Mon-

yyyy) or continues to use the old format (dd/MM/yyyy). Using the new format may affect sites who require the output to be used in downstream systems.

Add a new XR setting called STATS.UseCUIDateFormat. If set to 'Yes' it should use the new format and set to 'No' it should continue to use the old one. The default should be 'No'.

Resolution The stats output can now display dates in either the new or the old format, depending on whether the XR setting STATS.UseCUIDateFormat is set to 'Yes' or 'No' respectively. By default the old format will be used.

Fixed in 2.09.10t1

14.2. Resolved IssueCRIS-1107 Unable To Run Stats Where Date Fields Are RequiredDescription When running a stat with a 'Calculated' date field, an error is displayed indicating that the month is

invalid. This happens due to the formatting forced within CRIS conflicting with underlying code.

There is also an issue when running stats with DATE.TODAY in the Stat Start/End Date field, as this will also throw a formatting error.

Resolution Stats fields that return dates and are calculated from a Stats Method (e.g. Derived fields) were being run with the wrong date format. This caused the sql to error. The format has been updated to the new 'dd-MON-yyyy' format, which is compatible with both oracle and postgres, and so the error no longer occurs.

Adding DATE.TODAY to the Stat Start/End Date fields also now uses the new 'dd-MON-yyyy' format and so no longer errors.

In addition, existing stats with a date saved into Stat Start/End Date in the old format would also throw errors. A database script will be run on update to change all such dates to the new format.

Fixed in 2.09.10t1


15. Vetting15.1. Resolved issues

CRIS-1085 Radiologist widget Vetting list filtersDescription When using the Radiologist widget with the vetting list, the counts are incorrect when

clicking through to the list from the generated numbers.The issue appears to be with the Justify box on the vetting list being populated with ‘Y’ when clicking through from the widget. Changing the ‘Y’ to Blank will then show the same counts as on the widget.

A fix is required to ensure that the justify field is always defaulted to Blank when loading from the Radiologist Widget.

Resolution The vetting list now sets the ‘Show Justified’ field to Blank whenever it is loaded from the Radiologist Widget.

Fixed in 2.09.10t1

CRIS-1089 ‘Required within X number of days’ Protocol Template VettingDescription It has been noticed that the 'Required By' field via the Protocol screen does not

clear/update correctly.This occurs when a protocol template is selected with a ‘Required within X number of days’ defined via the Protocol Template. This populates the ‘Required By’ field in the event as expected. However, if the user then chooses a different Protocol Template which does not have a defined ‘Required within X number of days’ – i.e. a blank field via the template, then the date from the previous protocol is not updated.

The ‘Required within X number of days’ needs to update based on the template when the previous template had a positive value and the subsequent template had a blank value.

Resolution Selecting a protocol that is configured with a blank required number of days will now blank out the 'Required By' field when vetting.

Fixed in 2.09.10t1


CRIS-1227 Waiting status vetting issueDescription When vetting and rejecting a Waiting status event in CRIS it doesn't display the thumbs

down icon. If the event is vetted and rejected a second time the thumbs down icon then displays.

Resolution Changes were made to the ‘Vetting Status’ update process to ensure that if a Vetting Rejected action is requested this is correctly stored against the current event.

Fixed in 2.09.10t1


16. Worklists16.1. New Functionality

CRIS-1154 Vetting and Reporting Group development to enable use of the functionality.Description The new ‘Group’ fields in the [Vetting List] and [Report Info List] have two key limitations which

means it is difficult to implement or use the new functionality.The Groups make use of the already existing ‘Resource Group’ and ‘Resources’ tables in CRIS which are associated with the Resource Module. However unless both the Vetting Module and Resource Module are fully implemented the only method of applying ‘Groups’ either for Vetting or Reporting is manual per individual event details via event details or by right-clicking the event from the events list or a worklist. Both methods require 4 key presses to initiate and complete a pop up screen which is laborious and is not in line with other existing functionality which enables customer to easily assign vetting and reporting worklists via practitioner and intended clinician.It is also impossible to multi assign ‘Groups’ to events which do not require vetting, or attendances as the only place this function is available is via the [Vetting List] screen and exams not marked as vetting required, and attendances do not appear here. This is a significant retrograde step for sites who are used to managing Reporting list using intended Clinician via the Post Processing and using ‘multi-select’ via the [Report Info List] and using right click ‘Intended Clinician’ functions.

Resolution Added 'resource' group field to :

Event lists (via right-click, multple can be selected) Post Processing Event Entry

KNOWN ISSUE: When this new setting GENERAL.SingleResourceGroupPerEvent is set to 'Yes', an error is thrown when using batch verify with Order set to 'Batch'. This issue will be fixed in a patch against CRIS-1281.

Fixed in 2.09.10t1

CRIS-1198 Adding dates when report info list is loadedDescription Dates must be displayed under date fields when report info list is loaded in the very first time (i.e.

when no preferences for dates are available).Resolution Dates are displayed under date fields when report info list is loaded.Fixed in 2.09.10t1


16.2. Resolved IssuesCRIS-1052 Date fields in report info listDescription If date preferences for Report info list are deleted in the DB then the Start and End date fields in

the report info list will become unusable.Resolution When preferences are not available for start date and end date, the following default will be set:

Start date = a week before End date = current date (i.e. today).

Once this is changed, the changes will be stored to the user’s preferences.

Calendar control is working and F4 keystrokes are working as expected in all cases.Fixed in 2.09.10t1

CRIS-1069 Vetting List not working as expectedDescription When the Requested After field in Vetting List is not populated the list takes as its starting point

today's date rather than having no lower bound on the date.Resolution Functionality has been introduced to ensure that empty date fields occurring in specific WorkLists

pages were either returned as null values, or as today's date.Fixed in 2.09.10t1


1 · Web viewCRIS Release Notes 2.09.10t1 specific D5.0.docx CRIS Version 2.09.10t1 Change History...

Documents

Transcript of 1 · Web viewCRIS Release Notes 2.09.10t1 specific D5.0.docx CRIS Version 2.09.10t1 Change History...