CURES

Summary

This enhancement to the eRAD RIS suite of workflow solutions updates the product’s UDI and version number to signify a substantive change to our Certified Health Record Technology (CEHRT) certified code base.

Specifically, a new Universal Device Identifier (UDI) of 00866994000262422 has been generated and the Certification prefix digit has been incremented from 3 to 4 to reflect completion of updates to our CURES certification for the eRAD RIS Client, the eRAD RIS CONNECT Provider Portal, the eRAD RIS CONNECT Patient Portal, and the eRAD RIS Utilization Management Portal modules.

Background

Target Version Numbering

Version numbering for eRAD RIS follows the following format:

v[Certification].[Y.M.D][.Patch][.Revision]

·         The Certification component of the version number identifies the Certified Health Record Technology (CEHRT) certified code base from which releases are derived.

o    RIS is recognized as a medical device, and as such it must pass a formal MU/CEHRT certification process. Our CEHRT number is incremented only after a complete re-certification cycle is completed, which is only necessary when substantial architectural or functional changes are made to the product.

·         The Y.M.D component is incremented with each Scheduled Build.

·         The Patch component is added or incremented when releasing a Hotfix or Rapid Release to a Scheduled Build.

·         The Revision component is added or incremented when releasing a Hotfix or Rapid Release to a previous Hotfix or Rapid Release.

Feature Description

The UDI and version of a RIS UI client may be viewed on the Help » About screen.

In addition to the full version number, a build number of the commercialized version is also displayed. This internal number is assigned by our build process and is displayed for support purposes.

Configuration Instructions

No System Administrator actions are necessary to enable this feature.

Summary

This enhancement to CURES introduces an eRAD RIS module that provides a FHIR-based API for patients to access their data through third party system such as Apple Health etc.

This new functionality integrates eRAD RIS with a third-party company (Darena Solutions) to provide sharing services and a FHIR API via their Blue Button Pro solution and fulfills the requirement for patient access to the FHIR based (g)(10) API via Darena.

Background

Previously, RIS had no way to provide electronic on-demand access to PHI by other systems.

With this change, RIS introduces functionality to support the required ability to export the electronic health information stored in and by certified health IT to support patient EHI access requests as well as to support a health care provider wishing to export an entire patient population to transition to another health IT system.

Note that this CURES - 170.315(g)(10) requirement has a compliance date of Dec 31,2023:

https://www.healthit.gov/curesrule/final-rule-policy/2015-edition-cures-update

Feature Description

With this change, patients may request to be enrolled for API access to their exams, and eRAD RIS will begin sending completed C-CDAs to Darena.

The general workflow for this feature is:

·         The patient will directly call the eRAD RIS customer to request access to their study information.

·         The eRAD PSR will locate the correct patient in eRAD RIS and enter their email via their RIS patient folder.

·         eRAD RIS will initiate a message to Darena via the Darena interface - who in turn will send a “Patient Invite” email to the patient

·         eRAD RIS will generate and send the C-CDA’s to Darena via the Darena interface - for all signed studies for that patient along with customer identifying information

·         eRAD RIS will generate and send all future C-CDA’s for signed studies for that patient to Darena along with customer identifying information

·         The patient uses that email to sign up with Darena’s Blue Button Pro, by which they can access their data and FHIR API.

Patients are enrolled when they contact RadNet to request access to their study information, e.g., wanting to share their study information for a CT performed Jan 1 at RadNet with a specialist via the (g)(10) API).

To enroll the patient, RadNet’s Patient Service Representative (PSR) will:

1.       Locate the correct patient in eRAD RIS.

2.       From their Edit Patient screen, access the Extra Data tab.

3.       Add a new External Access Email value with an authorized email address.

The following are examples of what could occur between the patient, Darena, and the Doctor.

·         Within the Darena Blue Button Pro application, the patient can view and manage their RadNet health information. They will see all their RadNet studies sent from eRAD to Darena.

·         Within the Darena Blue Button Pro application, the patient can select an exam (e.g., their Jan 1 CT) and share it with their specialist Doctor.

·         The patient can connect their Blue Button Pro account to a third-party healthcare system (e.g., Apple Health, Google, Microsoft) and export their report to these external systems.

Behavior Notes

·         When the patient data is first saved with the ExternalAccessEmail patient extra info item populated, a c_action row will be created with the db_action ExternalAccessPatientEnrolled. If this row is deleted and re-added, the action will also be created.

·         For every report signed for an enrolled patient, a c_action row with a db_action set to ExternalAccessReportSigned will be created.

·         The Wedge will process the ExternalAccessPatientEnrolled action by sending a C-CDA for the patient’s entire record and will only send the C-CDA for the related study when processing the ExternalAccessReportSigned action.

Failure Monitoring

If Darena fails to process the job, the Darena plugin will throw an exception with the errors retrieved from Darena. This will cause it to go on the _Error queue (ex. If the queue_name is Darena, the c_action_queue row will be updated to have Darena_Error as the queue_name).

Known Limitations

The following significant limitations have been identified and should be communicated to affected users:

·         Bug #32922 - OutboundMessagerResolver erroneously expanding table level nodes

o    Issue: The OutboundMessageResolver class used to send messages to Mirth (per Feature #29393) expands certain columns so more information is available in Mirth. However, this logic is incorrectly being applied to any xml node that contains 'billing_code' in the name.

o    Impact: This causes table-level nodes such as c_financial_group_x_procedure_billing_code to be expanded, resulting in an error.

o    Workaround: Create a temporary rule in the l_queue_container_pruning lookup table to prune these table nodes from the message prior to this expansion taking place (Refer to Configuration Instructions in Feature #29393).

Additional functionality is planned for a future release:

·         Currently, individual patient enrolment is configured via the Extra Data tab. In a future release, Feature #33265 is planned to deliver an enhanced configuration approach that will provide more flexibility, control, and an improved user experience.

Configuration Instructions

Service Team assistance is required to enable this feature.

Summary

This enhancement to CURES updates the QRDA Import Tool and related XSL templates to support import and export of new data elements required for the CMS125 measure.

Background

RIS needs to be able to function with CURES behavior 170.315(c)(1,2,3). This includes importing QRDA’s using the QRDA Import Tool as well as exporting QRDA I and III measure reports. These actions must be possible without developer intervention.

RIS currently reports on the following Clinical Quality Measures (CQMs):

·         CMS125 - Breast Cancer Screening, which is now at v10 (2022).

Both the revised QRDA I (individual eMeasures) and QRDA III (aggregate quality reports) Implementation Guides indicate there are updates related to this measure:

CMS QRDA Reference and Implementation Guides:

https://ecqi.healthit.gov/qrda

o    The QRDA I Implementation Guide identifies these changes in Chapter 12.

o    The QRDA III Implementation Guide identifies these changes in Chapter 13.

Feature Description

With this change, the existing QRDA of functionality for exporting (which lives in the RIS) and importing (which lives in a separate utility which can be provided to a service user) have been updated to match the 2022 CMS specifications.

·         The XSL templates for both versions of the QRDA have been updated to conform to the new template specifications. This included updating template version attributes and adding template IDs to validate against CMS vs the old CEHRT version of the measure.

·         The denominator exclusion rules were also updated for the CMS125v10 measure, adding a number of additional data points which needed to be both importable and exportable. Refer to the CMS125v10 definition at https://ecqi.healthit.gov/ecqm/ec/2022/cms125v10?sort_order=2021vs2022#quicktabs-tab-tabs_measure-2 to see the full details of what was implemented.

Configuration Instructions

Service Team assistance is required to enable this feature.

Summary

This enhancement to CURES adds the logging required in order to generate metrics required for compliance with Real World Testing measures via the RIS Client, API, and Patient Portal.

This functionality was delivered via the Redmine tickets:

·         Feature #32998 - CURES - Collect metrics required to audit CURES Real World Testing - RIS Client Changes

·         Feature #32999 - CURES - Collect metrics required to audit CURES Real World Testing - Patient Portal Changes

·         Feature #33000 - CURES - Collect metrics required to audit CURES Real World Testing - API Client Changes

Previously, several of these user activity measures were not tracked, or were tracked but not specifically enough (for example, exported and transmitted were not differentiated), or were only tracked via the audit log (which is not suitable for querying/reporting).

With this change, the identified metrics will populate a centralized counter table (c_counters), which can be directly queried for reporting purposes:

Note that the client_application_code in c_counters is has a code of RISService when CCDA is exported via RIS, but is Null for activity logged from the external web API.

Known Limitations

While there are no Known Limitations for this feature, additional functionality is planned for a future release that will query and report on these metrics via a Management Report:

·         Feature #33002 - CURES - Collect metrics required to audit CURES Real World Testing - Management Report

Configuration Instructions

No System Administrator actions are necessary to enable this feature.