CRIS Release Notes 2.09.10q2 specific
Copyright
© Healthcare Software Solutions2014
Registered 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.
Confidentiality
All 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.10q2 specificAuthor / Gary Glover / Date Created / 13/05/2014
File Ref. / CRIS Release Notes 2.09.10q2 specific D5.0.docx
CRIS Version / 2.09.10q2
Change History
Issue / Date / Author / Editor / Details of Change
D1.0 / 13/05/2014 / Gary Glover / 2.09.10q2 changes only.
D2.0 / 21/05/2014 / Gary Glover / 2.09.10q2 additions
D3.0 / 10/07/2014 / Gary Glover / Further changes to Q2 release.
D4.0 / 10/07/2014 / Emma Savage-Mady / Minor formatting amendments
D5.0 / 10/07/2014 / Gary Glover / Changes made after internal review
Review Date
Contents
1.Introduction
1.1.Purpose
1.2.Audience
2.DTIs
2.1.New Functionality
3.Event Details
3.1.New Functionality
3.2.Resolved Issues
4.GUI
4.1.New Functionality
4.2.Enhancements
5.Patient
5.1.Issues Resolved
6.Reporting
6.1.Issues Resolved
7.Scanning
7.1.Issues resolved
8.Vetting
8.1.New functionality
8.2.Enhancements
8.3.Issues Resolved
1.Introduction
1.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.Audience
This 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.DTIs
2.1.New Functionality
CRIS-280 / Siemens 3D desktop integrationDescription / Siemens have a 3D reconstruction product which runs alongside an existing PACS workstation. We require an integration to this, however it cannot be done as a traditional desktop integration as we cannot run two simultaneously on the same workstation.
Resolution / Added Syngo 3D integration. This installs as a plugin rather than a desktop integration and adds an additional icon to the toolbar which allows the user to invoke the 3D application and also to control whether it is automatically closed when the report is cleared from CRIS. The syngo 3D plugin can be activated by adding the class name "hss.interfaces.syngo3d.Syngo3DPlugin" to the "GENERAL.Plugins" XR Setting.
Fixed in / 2.09.10q2
CRIS-305 / Port Merge HALO DTI to the latest release of CRIS
Description / The Merge Halo (which has been rebranded as MergePACS) needs to be implemented in this release of the CRIS application.
Resolution / The "Merge PACS" DTI is now part of the CRIS package.
Fixed in / 2.09.10q2
2.2.Resolved issues
CRIS-360 / SAS iSite 2DTI – unable to load 2nd studyDescription / If you have an event with two exams, you are unable to load the 2nd study on
the report without clearing the report text for the 1st study.
Resolution / The DTI worked on the erroneous (but undocumented in the API documentation) belief that an iSite Canvas equates to a patient, whereas it actually equates to exam.
Fixed in / 2.09.10q2
3.Event Details
3.1.Resolved Issues
CRIS-109 / Hover help vetting information not aligned with actual vetting pageDescription / Hover help text is showing 'Preparation'. In fact, the 'Preparation' box in Vetting has been renamed to 'Protocol'. The hover help text is not aligned with vetting page.
Hover help text is showing 'Resources'. In fact, there are 'Resources Required' and 'Personnel Resources'. Currently, hover help text only show detail from 'Resources Required'.
Resolution / The vetting information displayed on the popups now shows 'Protocol' instead of 'Preparation'. This is reflected in the popup on the diary scratch pad and the popup on the event details page.
Fixed in / 2.09.10q2
CRIS-326 / Entered by text is sometimes editable
Description / The ‘Entered By’ text in event details fields should always be un-editable. However, it is possible for it to become editable if a higher up comment has been modified by a different user.
Resolution / The Entered by text now remains un-editable in this scenario.
Fixed in / 2.09.10q2
CRIS-330 / It is still possible to overwrite another user's text in the Reason For Exam field
Description / When attempting to save an event text field that has been changed by another user since the event was loaded, a warning popup appears to say another user has changed the event. It displays the changes and shows how the current user and the other user's text will be combined if saved. This works for the Event Comments, Clinical History and Clinical Safety Questions. If the user changes the Reason for Exam field, changes by another user are not checked and it is still possible to overwrite another user's changes.
Resolution / Reason For Exam now works the same as the other text fields when text has been changed by another user. A dialog appears showing the two sets of text combined and the user has the option to save this or to close the dialog and remove their text/clear down the screen.
Fixed in / 2.09.10q2
4.GUI
4.1.New Functionality
CRIS-7 / Multiple Rooms in Day list, Appointments and Unprocessed ListDescription / Ability for the ‘Day List’, ‘Unprocessed List’ and ‘Appointments List’ to accept more than one room as filter criteria.i.e. we have 4 MRI rooms, but work 2 of them on single lists, so need to see the 2 together
Resolution / In order to display multiple rooms, the user can right-click, select the Configure Table Filters tab and add 'ROOM1,ROOM2' to the 'Rooms' field. On saving, the list will display events from both of these rooms. The configuration can then be saved to a filter profile in order for the filter to be reloaded easily.
Fixed in / 2.09.10q2
4.2.Enhancements
CRIS-8 / Rejecting Events via Vetting not consistent with Rejecting via other methodsDescription / Rejecting Events is not consistent – Rejecting a Request via [Request] is a status of RJ with comment, Rejecting an Order is also a Status of RJ but when using the Vetting Module to Reject request not originating from an order, it is a Cancellation – i.e. VJ , which means you cannot view all rejected requested at the same time. It would be nice to see this rationalized, as it makes finding all Rejections a more time consuming process using the front end of the system – this process currently requires a Statistical Report, and use of Sessions to process this information
Resolution / When rejecting via vetting, the following statuses will now be added.
(a) Event is currently an order or has a request or waiting status - adds vetting rejected and request rejected.
(b) All other events, e.g. appointment, attendance - adds vetting rejected and a cancel status.
Fixed in / 2.09.10q2
CRIS-43 / Display Name rather than user id
Description / Expansion of User id to Name via the Vetting Screen
Resolution / Both the user ID and the username are now displayed in the event details fields. The text will be of the form: (Entered/Modified By user id (user name) on date at time)
Fixed in / 2.09.10q2
5.Patient
5.1.Issues Resolved
CRIS-113 / Default ethnicity code is not added to new patient recordsDescription / When creating a new patient without an 'Ethnic Origin' value, if a new event is created prior to saving the patient for the first time, the 'Ethnic Origin' value is not populated with the default.
If the patient is saved prior to creating the event, the default 'Ethnic Origin' value is populated.
Resolution / The 'Ethnic Origin' value of a new patient is saved when creating a new event prior to saving the patient for the first time. If this field is empty, the default is populated.
Fixed in / 2.09.10q2
6.Reporting
6.1.Issues Resolved
CRIS-158 / ‘REPORT.AllowBlank’ doesn't work from unreported list.Description / The XR setting ‘REPORT.AllowBlank’ does not seem to have the correct effect when reports are loaded via the ‘ReportInfoList – Unreported’. The verify button is not greyed out as it is in the standard report editor screen, therefore the user is able to press verify and the report will save and verify with no text. ‘Finish’ does produce the warning of a blank report and will not save.
Resolution / There are a couple of XR settings that apply to both reports simultaneously.
'REPORT.AutoText' and 'REPORT.AutoTextProtect'.
The 'REPORT.AutoTextProtect' only comes into effect if 'REPORT.AutoText' is set to 'Yes'.
So if 'REPORT.AutoText' is set to 'Yes' and 'REPORT.AutoTextProtect' set to 'No' or blank, when the unreported event is loaded from the 'Report Info List', summary and exam text gets inserted automatically. This causes both reports to be set to 'changed' and as such enables the 'Verify' button. Therefore selecting this button now will verify both reports.
Now if 'REPORT.AutoText' is set to 'Yes' and 'REPORT.AutoTextProtect' is set to 'Yes' also, when the unreported event is loaded from the 'Report Info List', summary and exam text gets inserted automatically but into the report headers. This is done to preserve this text, the trouble is, and once again, both reports have been flagged as 'changed' even though it appears that there is no text in the report section. So, again, the verify button is enabled and both reports can be verified.
Setting these two settings to 'No' or blank allows each report section to be verify independently and also the appropriate warning is displayed if both reports are empty.
Fixed in / 2.09.10q2
CRIS-329 / Locked behaviour using VR/"Next Exam"
Description / "Locking behaviour" when using Dragon "Next exam" VR command in the Report page.
Wherever the cursor was positioned it would move to the top left-hand corner
Resolution / The cursor is now placed (where possible) at the beginning of the first clear line (only containing whitespace) at the bottom of the relevant section within the report. If there was no such clear line available, the cursor would appear at the end of the section.
Both the ‘Next/Previous exam’ VR commands and their equivalent keyboard short-cuts (F7/F8) now process the same section of code within the application for consistency and robustness.
Fixed in / 2.09.10q2
7.Scanning
7.1.Issues resolved
CRIS-254 / 'Scan new image' tick box - not working correctlyDescription / When an event is loaded with an existing image, the 'scan new image' check box is 'unticked', therefore the 'scan new' preference is set to 'No'.
Then, within the same user session, if a new event is loaded with no image, the 'scan new image' check box remains 'unchecked'. Ideally, if the preference is set to 'Yes' at the start of a user session, this should never by overridden automatically.
Therefore, the presence of an existing image should 'un-check' the 'scan new image' check box, but not alter the underlying preference.
Resolution / With an event with an existing image, the 'scan new image' checkbox is 'unchecked' but the underlying preference is not changed.
Fixed in / 2.09.10q2
8.Vetting
8.1.New functionality
CRIS-30 / Vetting List Changes to Allow GroupsDescription / Add functionality to the CRIS Vetting List module to allow consultants who vet to be added to a vetting group rather than the whole process being carried out by individuals.
Resolution / Vetting Groups on the Vetting List page
1. Assignments (at the bottom of the right-hand panel) have been generalized to offer the possibility of setting the practitioner or including this record in a particular resource group, in addition to any other groups it may already be part of.
2. The list of events can now be filtered using the Group field values at the bottom right of the main Vetting List page panel.
Highlighting particular records (orders or events) in the vetting list page creates a selection.
If the selection consists of purely events, then assignment simply updates the appropriate fields for each record in the selection.
If the selection consists of orders, and they are all for the same patient, then it is possible to merge those orders as separate exams to construct an individual requested event.
There are 2 types of assignment action:
Selection created +
A. {Simple Assignment}
i. Right-clicking selection + referred to -> practitioner/group value entered + Save Clicked
or
ii. AssignTo practitioner/group value entered + Assign Clicked
B. {Combination Assignment}
Vet button clicked -> Protocol button clicked -> Referred button clicked
practitioner/group value entered + Save Clicked
For A.ii no checks are performed on any selection in advance of the Assign button being available. So for orders, it is possible to select a list of them (for the same or different patients) and for all the conversions to be performed individually, resulting in multiple request events.
A.i can only be used for selections consisting of orders for the same patient or a group of events.
When using B on a selection of orders for same patient, an attempt will be made to combine them, as separate exams, and then the practitioner/group value can be added to the resulting single event.
Slight change made to the security setting that controls the visibility of the 'Practitioner/Group' fieldsand the 'Assign' button.
Now controlled by the GENERAL.CHANGE_EVENT security setting.
Fixed in / 2.09.10q2
8.2.Enhancements
CRIS-26 / Vetting Module filteringDescription / We need to be able to display both A&E patients and inpatients on the same list. The CT radiographers currently have to swap between the two codes to ensure that they are seeing all of the patients who require scans. Alternatively, have a single letter code which would map to both A&E and inpatient patient types
Resolution / In order to display multiple patient types, the user can right-click, select the Configure Table Filters tab and add 'TYPE1,TYPE2' to the 'PatType' field. On saving, the list will display events for both of these patient types. The configuration can then be saved to a filter profile in order for the filter to be reloaded easily.
Fixed in / 2.09.10q2
CRIS-35 / Vetting Protocol Ownership & Filtering
Description / Protocols will be owned by the user that created them (which needs to be stored too).
Protocols may only be edited by the user who created them or by someone else who has specific permission to (which will be "GENERAL.MANAGE_OTHERS_VETTING").
A protocol can also be linked to Users, Resource (Vetting) Groups, and Sites and, as currently, Trusts.
When protocols are listed they should be listed in this order (or some other way to distinguish between match levels).
Some form of cascade is deemed appropriate:
TRUST, SITE, GROUP and USER levels will be restricted to trust-local protocols.
SYSTEM level overrides all other levels and "cascades".
5 levels of settings for both change and ownership, with NO hierarchical cascade for management - System, Trust, Site, Resource Group or User.
The current MANAGE_VETTING setting will be used for USER permission, extra permissions of MANAGE_SYSTEM, MANAGE_TRUST, MANAGE_SITE, and MANAGE_GROUP will be added.
The ownership will be the default determinant of applicability when assigning protocols to an event.
The default ownership (when creating a protocol) will be the highest level at which the user has permission (see below) to manage.
A user may change ownership of a protocol, or category, (for which they have "manage" permission) to any of the levels at which that user also has permission to manage, with categories subject to system or trust ownership, only.
Categories can only created/deleted at Trust or System level, lower levels can assign/remove protocols to the categories but not manage the categories themselves.
Resolution / Protocol templates can now have owners (at one of various levels) and shared to multiple entities (as per issue description).
The levels concerned are:
* System
* Trust
* Site
* Resource (Vetting) Group
* User
Security settings required to manage the levels are (in the same order):
* MANAGE_VET_SYS
* MANAGE_VET_TR
* MANAGE_VET_STE
* MANAGE_VET_GRP
* MANAGE_VETTING
As per the description, MANAGE_VET_SYS will override all others, giving access to all levels.
When vetting an event, only those protocol templates which are in the Event's trust, site & logged in user's hierarchy will be available to be assigned.
Fixed in / 2.09.10q2
8.3.Issues Resolved
CRIS-75 / Vetting Protocol Database and relationship changesDescription / Currently, Vetting protocols are related only to a trust. New ‘Vetting’ functionality requires that Protocols be linked also to Trusts, Sites, Resource Groups and Individuals, to aid filtering when assigning protocols.
In a nutshell:
A protocol can have 1, and only 1, owner. That owner is one of System, Trust, Site, Resource Group or User.
DBA input required as to whether, for CRIS, the best solution for this is a separate "Owner" table or simply adding extra columns to ‘vettingprotocol’.
A protocol can also be linked (or shared) to many Trusts, Sites, Resource Groups or Users.
DBA input required as the "best practice" way to do this is probably with association tables but may not be so in a CRIS context.
Resolution / All relevant update scripts for both the Oracle and Postgresql databases have been updated.
Fixed in / 2.09.10q2
CRIS-116 / Multi-user warning/overwriting of fields does not work as expected in vetting
Description / (1) When vetting it is possible to overwrite another user's text
If amending event details fields through the Event Info tab, if another user has changed the text since the page was loaded, saving overwrites the other user's changes.
(2) Warning message appears when saving event fields through vetting
When adding text to the event fields from within the Event Info tab, if you then go through the workflow and press [Save] on the Event Details page, a warning message appears saying "Another user has changed this event". It then asks you to check the text and save or not. However, the text was not added by a different user and so this warning should not appear.
Resolution / It is no longer possible to overwrite another user's text via vetting. The fields are now checked before they are saved in the same way as on the event details page.
In addition, the text changed warning no longer always appears towards the end of the workflow when adding text via vetting.
Fixed in / 2.09.10q2
CRIS-145 / Change 'Vet' button on Event Info to 'Protocol'
Description / Add Protocol function button – The [Vet] function button in the Event Info screen makes no sense as it actually means [Add Protocol]. This button is hard coded and not a status so needs to be amended asap to make the Vetting Module logical / intuitive.
Change 'Vet' button on Event Info to 'Add Protocol' Once protocol has been assigned, button should state 'View Protocol'
Resolution / On Event Info page:
The "Vet" button has been re-named to "Protocol".
The title of the tab shown as a result has also been changed to "Protocol".
Fixed in / 2.09.10q2
CRIS-159 / Protocol updated is not refreshed properly
Description / When amending an existing protocol, the changes cannot be seen until the amended protocol is re-selected and the Description, Exams, Areas, Modalities and Document fields are not saved.
After creating a new protocol and saving the changes, the new protocol can be seen in the protocol tree. Trying to leave the ‘setup’ screen by selecting the ‘X’ symbol displays a warning ‘Table not saved, Do you wish to quit without saving table(s) (ProtocolSetup)’.
Resolution / The detail view now properly updates after an edit.
The warning message about unsaved protocols when attempting to exit the setup application is no longer displayed.
Fixed in / 2.09.10q2
CRIS-160 / Cannot view protocol in Vetting screen
Description / When logged in as a ‘radiographer’ with the following settings
GENERAL.CHANGE_VETTING=Y
VIEWS.VETTING=Y
GENERAL.MANAGE_VETTING=N
Selecting a protocol with a document should allow the user to view the protocol. This option is currently not available.
Resolution / "View Protocol" is back, available in the right-click context menu.
Fixed in / 2.09.10q2
CRIS-162 / The protocols are not sorted by the alphabetic name order
Description / If there is only 1 sub category, the protocols are not sorted in:
Setup table, the protocol under 'All Protocols' categories
In vetting screen:
the protocol under 'All Protocols' category
the protocol under 'Relevant Protocols' category
Resolution / The sort now properly cascades down the tree. All nodes should be sorted, regardless of how many there are.
Fixed in / 2.09.10q2
CRIS-328 / Intended clinician saving error
Description / Changing the ‘Intended Clinician’ on a ‘vetted’ event, then when the changes are saved an error is produced suggesting the changes haven’t been saved.Doing the same thing on an ‘un-vetted’ event saves without error.
Resolution / When anything is changed on an event, a flag is raised to indicate the change. Once the event has been saved, these flags are reset. Here the flag was raised twice, once in the 'Event Details' screen and then again in the 'Protocol' (Vetting) screen, but the flag was only being reset in the 'Event Details' screen, it wasn't being reset within the 'Protocol' screen, hence the warning message appeared.
Fixed in / 2.09.10q2
CRIS-379 / Vetting Protocol Tree creates "Assigned Protocols" node when vetting an order for the first time
Description / When vetting an order (which doesn't have an event saved against it) the protocol tree adds an "Assigned protocols" node every time a node is clicked.
Resolution / Only one "Assigned Protocols" node will exist in the tree at any point in time after an order has had protocols assigned to it and saved.
Fixed in / 2.09.10q2
CRIS-382 / Orders cannot be vetted unless saved as an event first
Description / An order cannot be vetted (have protocols assigned) unless it has been saved as an event first.
Resolution / Orders can now be vetted and have protocols assigned.
Fixed in / 2.09.10q2
9.Worklists