General Information

Performance Year: 2023 

Developer Name: NaphCare, Inc.

Product Name(s): TechCare EHR

Version Number(s): 5.0

Certified Health IT Product List (CHPL) Product Number(s): 15.04.04.2813.Tech.05.00.0.191208

Developer Real World Testing Plan & Results Page URL: https://devportal.techcareehr.com/RWTP

Changes to Original Plan

Summary of Change

Reason

Impact

Use Case 1: NaphCare currently maintains 2015 CEHRT status for TechCare v5.0. Application updates within v5.0 which enable functionality identified in Use Case 1 (Care Coordination and Direct Project) were implemented in April of 2023. The application update was deployed to an EHR partner, but unexpected technical limitations were discovered with their chosen HISP during pilot testing.

NaphCare’s EHR partner utilized a HISP that was unable to accept messages greater than a specific file size. In our use case, 100% of the chosen patient files exceeded this file size limitation. This technical limitation with the chosen HISP, discovered during testing, resulted in our EHR partner being unable to utilize the functionality of Care Coordination and Direct Project.

This previously unknown technical limitation caused NaphCare to be unable to perform the testing described in this use case. 

Use Case 2: Data export via C-CDAs maintained limited deployment in practice given the lack of partners where the information sharing was requested. We maintained some success with real world deployment to HIEs in select states, however those HIEs continued to request  now retired versions of the C-CDA standards. 

NaphCare’s corrections specific care setting limits prospective partners in the real-world use of Data Export via C-CDA. Where partnerships did exist, it was with HIEs that had not fully adopted the revised standards for C-CDAs and NaphCare was required to use older versions not meeting the criteria of the latest revision/certification.

This prevented NaphCare from being able to document and measure the success of this measure in a real-world use case.

Use Case 3 & 4: The corrections-specific industry that is our care setting did not see direct correlation with this use case and we were unable to identify participating partners to complete this study. 

Although functionality exists for Record and Export, Application Access and is available in production environments, we were not able to find willing participants.

This prevented NaphCare from being able to document and measure the success of this functionality as defined in Use Case 3 and Use Case 4.

 

Summary of Testing Methods and Key Findings

It was NaphCare’s intent to use TechCare’s Reporting/Logging features to examine functionality performed in the system and the success/failure with the tested measures within each use case defined.  This would, in turn:

·         Demonstrate real worked interoperability and conformance to criterion requirements

·         Include patient care scenario and use case focused testing

 

Specifically, NaphCare planned to use the following data sources to collect and confirm testing approaches:

·         TechCare Application Logging reflecting end user actions in the system

·         TechCare Interface Logging reflecting automated action within the system

·         Interface Partner Results (i.e. partner Hospitals to validate information requested/received

·         End-User Sample Sets (i.e. subset of patients meeting criteria for information transfer.

 

For the reasons outlined above, the only key finding from our experience related to this effort is that adoption rate of certified technology and it use in real-world scenarios has been limited.  Although available, improved information sharing tools have not motivated adoption by customers, or intermediaries (i.e. HIEs, HISPs, etc.).

 

As a point of reference, the below Use Cases are associated with the following measures

Use Case #1: Care Coordination and Direct Project 

•             § 170.315(b)(1) Transitions of care

•             § 170.315(h)(1) Direct Project

 

Use Case #2: Data Export

•             § 170.315(b)(6) Data export

 

Use Case # 3: CQM 

•             § 170.315(c)(1) record and export

 

Use Case #4: Application Programming Interfaces (APIs)

•             § 170.315(g)(7) Application access— patient selection

•             § 170.315(g)(8) Application access— data category request

•             § 170.315(g)(9) Application access— all data request

 

 

Care Setting

The TechCare EHR product is deployed to correctional healthcare settings within county, state, and federal correctional facilities. These are the only care settings where TechCare EHR is utilized, and partners in this industry would represent testing subjects. 

Metrics and Outcomes

Use Case 1: Care Coordination and Direct Project: 

Criterion §170.315(b)(1) Transitions of Care

Criterion §170.315(h)(1) Direct Project

 

Measurement/

Metric

 

 

The intended goal was to capture the total number of offsite patient visits created during the test period and correlate that to the number of C-CDAs created and transmitted via Direct Edge Protocol Transmission using our selected HISP.

Expected

Outcome(s)

 

 

The expected outcome was an 80% match between offsite visits and transmitted C-CDA for those patients going to a partner hospital which accepted the C-CDAs via Direct Edge Protocol Transmission.

Outcomes

 

 

See additional information under Changes to Original Plan section above. Otherwise, TechCare's Unit and Regression Testing plans allowed for predictive metrics that met or exceeded the Plan. Use Case 1 Test 1 was expected to meet 80% but in fact would have met over 95%. Only approximately 2 out of every 50 expected patients would have had too little information on their profiles cause a non-CDA pathway to be chosen to exchange records. Use Case 1 Test 2 was expected to meet 50% and was predicted in Unit Testing to meet that number. Approximately 1 out of every 2 patients would be properly registered in the receiving EHR system in order to allow users to benefit from the C-CDA transfer. Use Case 1 Test 3 was expected to meet 50% and was predicted in Unit Testing to meet that number. Users of TechCare would receive C-CDAs upon a patients return 1 out of every 2 times, due to patient processing factors. Returning to custody escorted by an officer puts a time-component to the process. If the C-CDA was ready very soon after a patients departure from the hospital, the procedural opportunity in TechCare to view the summary is was successful (as expected) about 50% of the time.

Challenges

Encountered (if Applicable)

 

 

Challenges experienced are documented above. NaphCare established a partner for this specific Use Case and completed pilot deployment in April of 2023. Due to technical limitations by the chosen HISP, we were unable to complete this test as a part of CY23 testing. Our intent is to complete this test with a new EHR partner and HISP as a part of CY24 testing. 

 

Use Case 2: Data Export

 

Criterion §170.315(b)(6) Data Export

 

Measurement/

Metric

 

 

The intended goal was to capture the rate of utilization for data export to centralized repositories (i.e. HIEs) for all patients released from  correctional institutions.

Expected

Outcome(s)

 

 

We expected to see at least 1 C-CDA (release/discharge) created and successfully submitted for every patient within a region supported by an integrated HIE. 

Outcomes

 

 

 

See additional information under Changes to Original Plan section above. While we do maintain integration with HIEs in the same region as partner facilities using TechCare, the technology used for creation of the C-CDAs is a retired version of the standard. The HIE has not fully adopted the latest CCDA format standards based on the CURES update. That said, we were able to validate submission of 1 C-CDA per released patient during the test period. The ambitious 100% C-CDA batch process expected outcome, however, was proven time and time again in the regression testing process. Without any relied upon software, TechCare is able to produce and verify output of C-CDA creation and availability on a 1 to 1 ratio whether a small handful of patients are released from custody (1 - 20) or large groups (200 - 300) nightly. The EHR knows the number of patients released in a given window (the numerator) and the EHR knows how many batch exported C-CDAs it produced to match.

 

Challenges

Encountered (if Applicable)

 

 

Despite optimism that an existing HIE partner would adopt the latest standard in CY2023, they did not, therefore we intend to update this integration to utilize the latest version of C-CDA standards in CY2024. This effort will ensure that this test/use case is made a valid metric for real world testing.  

Use Case 3: CQM 

Criterion §170.315(c)(1) Record and Export

 

Measurement/

Metric

 

 

The intended goal was to capture successful exports of CQM data which would have been entered in the TechCare system during the course of care of a patient.

Expected

Outcome(s)

 

 

We expect all CQM data elements entered into the system directly correlate with the export of that data across the same time period.

Outcomes

 

 

See additional information under Changes to Original Plan section above. While the ability to enter the specific CQM data is available in the system and its ability to be exported is validated by Live Testing as a part of CEHRT processes, its utilization real world was very limited. No viable outcomes could be measured in Production Care settings. The beta testing usage within the period, though, did result in useful knowledge. Less than 20% (9 out of 50) of CQM exported data would have had the required data elements. Correctional Healthcare setting is vastly different and results oftentimes in more frequent yet hurried patient encounters. This is the likely largest contributing factor to the lower than initially predicted 30%. Optimism remains for future reporting periods, though, given the industry's evolution.

Challenges

Encountered (if Applicable)

 

 

Given the unique correctional care setting, not all typical CQM data elements are captured through the course of care.  Further, other data elements that might not be considered “standard” in other care settings, are captured in the correctional care setting. To complicate the focus of collection, there are specific auditing bodies (i.e. National Commission on Correctional Healthcare and American Correctional Association) which drive CQM data in jails and prisons and their standards do not always overlap with CQM data elements.  As a result, clinical care teams tend to focus collection on the elements specific to corrections.

 

Use Case 4:  Application Programming Interfaces (API)

Criterion §170.315(g)(7) Application Access – Patient Selection

Criterion §170.315(g)(8) Application Access – Data Category Request

Criterion §170.315(g)(9) Application Access – all Data Request

 

Measurement/

Metric

 

 

The intended goal with this Use case was to confirm that those who attempted to access the API were granted such access securely assuming they were authorized to do so.  Then, for those who validated and successfully queried for patient data, that appropriate patient data was returned in the right format.

Expected

Outcome(s)

 

 

It was expected that 50% of API access attempts were successful, considering that ill intent actors attempted to access the API without proper authorization.  And that 80% of successful connections properly returned C-CDAs

Outcomes

 

 

See additional information under Changes to Original Plan section above. We were not able to achieve Production Use outcomes as the technology was not requested by or adopted by any customers as a means of sharing patient data. Unit and Regression testing of the APIs, though, allowed for expected outcomes to be met within a negligible margin of error. Correctional healthcare like most EHR settings requires high API security standards. The API requests would only be initiated from trusted sources with partners directly with the City or County jail, or State or Federal Prison. Since those outside sources are limited and known, coupled with their patient population being very high in non-incarcerated individuals, unit testing resulted in 50% of Use Case 4 Test 1 API requests resulting in positive validation (positive defined as trusted source and patient found). Relatedly once validation became a non-factor (Test 2s numerator assumes valid requests only) 80% of Use Case 4 Test 2 API requests were shown in unit testing to result in a patient having sufficient unique identification match and thus C-CDA generation and delivery. The 20% is explained by an expected Medical Record Number mismatch.

Challenges

Encountered (if Applicable)

 

 

This method of data exchange was viewed as overly complex by partners. Based on our care setting of corrections, our partners requested HIE integration or direct connections using the Direct Edge Protocol technologies.

 

 

Key Milestones

Milestone

Care Setting

Date

Finalization of all Application Functionality/Modules including data collection mechanisms for Use Case 2, 3.

 

Correctional Healthcare (Jails, Prisons)

December 2023 (TechCare v5.0 2023/R6)  

Finalization of all Application Functionality/Modules including data collection mechanisms for Use Case 4.

 

Correctional Healthcare (Jails, Prisons)

December 2023 (TechCare v5.0 2023/R6) 

Finalization of all Application Functionality/Modules including data collection mechanisms for

Use Case 1.

 

Correctional Healthcare (Jails, Prisons)

April 2023(TechCare v5.0 2023/R2) 

Attempted engagement with partners across all Use Cases

 

Correctional Healthcare (Jails, Prisons)

February 2023 – December 2023

 

Attestation

The Real World Testing Results above are complete with all required elements including measures that address all certification criteria and care settings.  All information in this plan is up to date and fully addresses the health IT developer’s Read-World Testing requirements.

Authorized Representative Name: Mr. Jason Douglas, Chief Development Officer

Authorized Representative Email: jdouglas@naphcare.com  

Authorized Representative Phone: 205-536-8445

Authorized Representative Signature:Jason Douglas

Date: 01-17-24