Background

Some customers have all patient IDs padded with spaces to 9 characters and prefixed with both a character (e.g. Z) and the issuer of the patient id. This means that all interfaces need to be able to support formatting the patient ids in this manner. HL7 being sent out through Mirth are easily modified, but the DICOM send part of a CD import currently has no opportunity for enhancement.

Feature

To allow RIS to be able to prefix, modify, and format the patient id field in a DICOM send, the UI Plugin framework has been enhanced to allow the values passed to the DICOM toolkit to be customized. A new plugin can then be added that formats the patient id appropriately.

The RIS now raises an event prior to sending the DICOM message to PACS, allowing a plugin to subscribe to this event to modify the data used to generate the DICOM. The CDImportLib library was also updated to include the issuer of patient id int the data passed to the event.

AZMA Plugin Changes

The AZMA HIS plugin can now subscribe to this event and modify the patient ID to be a concatenation of ‘Z’, the issuer of patient id, and the 9-character space-padded patient id.

Background

RIS currently has the ability to send a scanned document over an interface (for example, to Ensemble). These messages currently only contain the scan_document_key related to action that took place.

Feature

This feature adds support for outbound message attachments to include the full Scan Doc Dataset, including the document type, notes, external id, etc. when the Scan Document Key is provided.

Background

HL7 defines an ADT transaction that corresponds to the change of an identifier to a patient. In other words, the patient previously identified as 123 should now be identified as 456 and the 123 identifier will no longer be used.

Feature

RIS now supports incoming ADT ChangePatientIdentifier messages indicating a patient id has been changed and will update the patient id and issuer fields.

Feature

RIS supports Master File Notification (MFN) inbound messages via HL7 to perform dataset updates via webservices. This allows a remote system to ‘own’ certain lookup tables, and when they are updated in the remote system, an HL7 MFN message will be sent to eRAD RIS, and RIS will update its copy of this table accordingly.

This will be configured by the eRAD Professional Services Team if necessary in your installation.

Feature

EIS business logic has been updated to allow for updating unique rows of c_patient_extra_info based on the combination of patient_key and patient_extra_info_code. EIS will completely replace existing rows for this patient_key when this message is received. In other words, repeatedly sending an incoming message with different values for c_patient_extra_info.value will result in a single row in RIS with the most recent value, rather than multiple rows with distinct values in them. The sending system should re-transmit any values it wishes the RIS to maintain.

Background

Currently when RIS accepts a HTML report from an external system via the EIS interface, it will convert it to a PDF and store it in the RIS database using the legacy report functionality and a 3rd party HTML to PDF conversion utility. However, this approach limits the ‘legacy report’ to one report per study as the external interface will delete any existing legacy reports when receiving a new report.

Feature

The support team can now send a c_interpretation row in via the external interface and may now include an element called <html_report>. This element will contain the base64 encoded HTML report. When received, EIS will convert the report to a PDF and store it in the c_legacy_report table. The reports are then viewable via the View Study screen and Report nugget on the worklists.

Background

Currently, messages received from PACS that indicate an accession number has been PACS corrected only marks the primary study as corrected. For some messages this behavior is appropriate, but there are cases where it should apply to all studies in the linked set.

Feature

With this (order level accession number) enhancement, each message may specify how the PACS Corrected flag should be handled:

·         Default (current) behavior of applying to primary study only.

·         Allow a message to specify that values for the c_study node of a message should apply to ALL studies.

·         Allow a message to specify that values for the c_study node should apply to ALL Non-Cancelled studies.

Background

The current portal interface implementation uses a single user account no matter who is using it. Credentials are obtained from the Browser (portals) config window. However, some sites require that some interfaced systems be accessed with a unique user and password per user. We therefore need to support this information down at the user level.

Feature

The browser (portals) interface has been updated to allow a user to access their configured portal systems using their own user account and credentials, rather than relying on a shared account.

Portal support for multiple accounts per user

When accessing external portals, RIS retrieves authentication details from the BrowserConfig.Password and BrowserConfig.UserName settings.

A new button has been added to the portals window to allow users to enter different credentials for the currently selected portal tab.

Protocol worklist menu option and flags.

Submitting user account information via the Credentials dialog will reload the browser using the new authorization details.

Summary

This enhancement adds the ability for RIS outbound messages to include person extra info values.

Previously, values from the l_person_extra_info_x_person table representing person extra info values added within RIS were not exported with the other l_person related tables. This table is now retrieved from the database and expanded when exprting person_key nodes.

This sample a Mirth message shows how the requested_by_person_key node will now contain the l_person_extra_info_x_person values:

Summary

The ModifyLookupDataset (MFN) method has been updated to support inbound messages that include 'insert' and 'update' attributes that control how the interface handles rows that are sent in the message.

·         Explicitly specifying that updates are not allowed will insert new rows but NOT update existing rows.

·         Explicitly specifying that inserts are not allowed will update existing rows and raise an exception if no existing row is found.   

Background

In many cases inbound messages include 'insert' and 'update' attributes that control how the interface handles rows that are sent in the message, with 'insert' adding rows only if they are not found so existing values are not overwritten. Only when the 'update' attribute is specified will a found row be updated.

This change was requested as procedure codes received via an MFN message would always overwrite existing values with each new MFN message received.

Resolution

Messages may now specify if a found row should be allowed to be added, updated, or both. Default behavior when no attributes are specified remains as if both insert and update were specified, so new rows will be added, and existing rows updated.

Note: When unspecified, insert and update attributes default to Y.

Attributes for "insert" and "update" have been added to the schemas for any lookup row node in the containers for the lookup specific methods ModifyBillingCodeData, ModifyCarrierData, ModifyCarrierTypeData, ModifyModalityData, ModifyOrderingOrganizationData, ModifyPersonnelData, and ModifyProcedureCodeData.

This enhancement <verb> the <object> to <action> from <location> when <condition> because <reasons>.

Update[d] the Conditional Tab editor's Display Criteria to include the Confirmation screen on the list of available Screens. This allows Digital Forms to be configured to display during the confirmation workflow.