General Information
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
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) |
|
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:
Date: 01-17-24