2025-rwt-results

REAL WORLD TESTING RESULTS REPORT 2025

GENERAL INFORMATION

Plan Report ID Number: 20241108all
Developer Name: AllegianceMD Software, Inc
Product Name(s): Veracity
Version Number(s): 9.1
Product List (CHPL) ID(s): 15.02.05.2672.ALLE.01.01.1.220117
Developer Real World Testing Plan Page URL: https://allegiancemd.com/real-world-testing
Developer Real World Testing Results Report URL: https://allegiancemd.com/real-world-testing

CHANGES TO ORIGINAL PLAN

Summary of Change	Reason		Impact
Changes to the original dates	Due to the low number of utilization, we had to change date range to accomodate the low number of transactions, each change is noted.		No impact.
Change of Care settings	Due to the the unpredictability of usage by certain care settings and the small user base available. We had to change the care settings to reflect the actual usage at the time of testings. There should be no impact as all care settings get the same copy of the software.		No impact.
170.315(g)(10)	No adoption by any customer.	Manual testing	No impact.

STANDARDS UPDATES

None of the products include voluntary SVAP standards

SUMMARY OF TESTING METHODS AND KEY FINDINGS

Test Plan:
The test cases that were included actions by various user types to capture the required data and workflows. In most scenarios, real world patient data was used to confirm compliance with the things such as successful transmission statuses for some certification criteria requirements. Some standards were tested via manual inspection and/or with ONC-recommended test tools.

Test Methods:
User actions are sent to an event distributed event streaming platform. User events are recorded. This method is superior to picking certain clients for testing as it provides real time data across all clients and in case of error, it provides error logs to help us trouble shoot any issue with the system.

Key Milestones

Crieteria ID	Description	Dates to capture the Data logs for Monitoring	Duration
170.315(g)(9)	Application access – all data request	07/01/2025 to 07/14/2025	14 days
§170.315(g)(7)	Application access — patient selection	07/01/2025 to 07/14/2025	14 days
§170.315(g)(10)	Standardized API for patient and population services	12/16/2025 to 12/16/2025	Manual

Challenges faced during testing

Revisions to the test plans were driven by several challenges, most notably the limited user population and the reality that many Veracity 9.1 customers either did not engage with government payers, qualified for the MIPS/QPP low-volume exemption, or opted to absorb Medicare payment penalties instead of incurring the labor cost required.

RWT Measure #11. Application access – patient selection

Associated Criteria: 315(g)(7)
Application Programming Interfaces: 170.315(g)(7) Application access— patient selection

Testing Methodology: Reporting/Logging

Measurement Description
The data required for the measure is collected for the duration of 14 days as mentioned in the schedule. Using the data logs we collect information as mentioned below to calculate the accuracy and successful responses percentage. Using these logs we can monitor if Veracity is able to accept the API key and secret. When the API receives a request from another software component or service containing sufficient patient information to identify the patient, the API returns a patient ID

Care Settings:
Family Medicine, Neurology

Testing Results:
Number of Clinics With Records: 2
Reporting Interval: 07/01/2025 – 07/14/2025
Number Of Clinics : 2
Total no. of API requests received for the patients: 6
Total no. of invalid API requests for the patients: 0
Total no. of successful of valid API requests for the patients: 6
Total no. of successful API responses from Veracity: 100%

Analysis and Key Findings
Very few facilities are using this feature.

Non-Conformities or Errors Discovered
During our testing, we did not discover any errors or criteria non-conformities. We did not make any changes to this measure from our original test plan except for the care settings.

Relied Upon Software
None

RWT Measure #12. Application access – all data request

Associated Criteria: 315(g)(9)
Application Programming Interfaces: 170.315(g)(9) Application access— all data request

Testing Methodology: Reporting/Logging

Measurement Description
The data required for the Measure is collected for the duration of 14 days as mentioned in the schedule. Using the data logs we will collect below (a – c) mentioned data to calculate the accuracy and successful transmission percentage. This Criterion required Veracity to give the functionality to users for requesting All patient Data as mentioned in §170.315(g)(9)(i)(A). The API data requests are considered valid and response is given only if the combination of User name, password and API Toke key are correct.

Care Settings:
Family Medicine

Testing Results:
Number of Clinics With Records: 1
Reporting Interval: 07/01/2025 – 07/14/2025
Number Of Queries : 6725
Denominator = (Total no. of requests for All Patient Data – Total no. of Invalid API requests)
Denominator = 6725
Numerator = Total no. of successful responses given to requests in Denominator
Numerator = 6725
Total % of Successful Transmissions = (Numerator/Denominator) X 100
Total % of Successful Transmissions = 100%

Analysis and Key Findings
Very few facilities are using this feature. Only two were found.

Relied Upon Software
None

RWT Measure #14. FHIR

Associated Criteria: 315(g)(10)
Standardized API for patient and population services: 170.315(g)(10)
Testing Methodology: Manual using inferno

Measurement Description
The data logs of API requests and responses are collected during the data logging schedule of 60 days. This data will prove that EHR has the real time working modules to receive and respond to API requests in FHIR format.

Care Settings:
Test family practice with non-real patient data using inferno.

Testing Results:
Number of Clinics With Records: 1
Reporting Interval: 12/16/2025 – 12/16/2025
Denominator: 1
Numerator: 1
Tests passed with inferno testing
Analysis and Key Findings
We don’t have any client that implemented FHIR API. We had to resort to manual testing.

Reason for Manual Testing:
With our limited client base, no clients had implemented the FHIR API as of the end of May. As a result, we had to pivot to manual testing, which carries significant labor cost and requires substantial preparation time. This change was unavoidable because we could not identify any third-party, FHIR-compatible client systems capable of consuming FHIR messages from our client FHIR server.

Our outreach to clients and external vendors consistently surfaced the same issue: a lack of FHIR-capable applications. While some third-party providers expressed interest in integrating with clinics, most depended on non-FHIR REST APIs. Despite extensive follow-up conversations, the FHIR capability gap remained, preventing us from proceeding with production testing.

We recommend that the ONC fund the development of a patient-friendly mobile application to accelerate FHIR adoption for accessing health data across multiple vendors. Such an app would enable patients to manage their health information more easily and could be recommended by our clients for patient use. It would also incentivize third-party developers to build FHIR-compatible solutions, strengthening the overall interoperability ecosystem.

Relied Upon Software
none