Real World Test Plan 2025

Standard (and version)

a) 170.202(a)(2) Applicability Statement for Secure Health Transport Version 1.3, May 2021 (Direct) for b1
b) 170.205(a)(5) HL7® CDA R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3-US Realm, May 2022 for b1, b2, b9, e1, g9
c) 170.204(a)(1) Web Content Accessibility Guidelines (WCAG) 2.1, June 05, 2018 (Level A Conformance) for e1

Updated certification criteria and associated product

b1, b2, b9, e1, g9

Health IT Module CHPL ID

15.05.05.3098.MAGE.01.00.1.220127

Method used for standard update

SVAP

Date of ONC-ACB notification

11/16/2022

Date of customer notification (SVAP only)

12/25/2022

Conformance measure

Measures 1,2,3,4,5,14

Standard (and version)

a) 170.215(c)(2) HL7® FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0, November 26, 2021.

Updated certification criteria and associated product

G10

Health IT Module CHPL ID

15.05.05.3098.MAGE.01.00.1.220127

Method used for standard update

SVAP

Date of ONC-ACB notification

11/21/2022

Date of customer notification (SVAP only)

NA

Conformance measure

Measures 15

Measurement /Metric

Description

Measure 1: 170.315(b)(1) Transitions of care - Receive Clinician logs into QSmartCare and receives a C-CDA from a referring provider via Edge Protocol with no Tech Support and no errors Successful receipt of C-CDA is achieved and observed.

Clinician logs into QSmartCare and receives a C-CDA from a referring provider via Edge Protocol with no Tech Support and no errors Successful receipt of C-CDA is achieved and observed.

Clinician begins a new patient encounter in the QSmartCare certified software with a patient referred by another clinician. With a Direct Address and unique credentials, the clinician can have a seamless login and secure receipt of C-CDA from the referring clinician using the Edge Protocol. The USCDI standard will be demonstrated in these transactions through screenshots collected. Log files are also captured. These will all show the successful receipt of the C-CDA with all fields completed and arranged per provider preference. This will meet § 170.315(b)(1) (Receive).

Measure 2: 170.315(b)(1) Transitions of care - Send

Updated C-CDA is sent back to referring partner. Successful sending of CCDA is achieved and observed

Clinician sends updated C-CDA with minimal delay back to referring clinician via Direct Protocol. Updated C-CDA is also sent to the patient portal. Confirmation of sent C-CDA is captured along with log files. This will meet § 170.315(b)(1) (Send)

Measure 3: 170.315(b)(2) Clinical information reconciliation and incorporation:

The C-CDA is validated, and Clinical Information Reconciliation is performed. No errors are expected.

After successful receipt of the C-CDA, the clinician validates the C-CDA within QSmartCare. Clinical information reconciliation for medication, medication allergy, and current problem list is performed using QSmartCare software.USCDI standards will be demonstrated in these transactions through screenshots collected. Log files demonstrate the reconciliation. This will meet § 170.315(b)(2).

Measure 4: 170.315(e)(1) View, download, and transmit to 3rd party:

Access via the patient portal - Observation of the View, Download & Transmit functions are performed. This will demonstrate the portal as a key tool for the clinician to share the patient’s most current health information with the patient.

A patient will have access to the patient portal to view encounter summaries of their choice as human readable C-CDAs and download the C-CDA without assistance. Transmission of patient data will be sent to a provider (Edge Protocol) and or a non-clinician via a standard email address. This will meet § 170.315 (e)(1).

Measure 5: 170.315(g)(7, 9) API

Additionally, the patient will have the ability to access (by authentication) either partial or full encounter summaries by way of an API call from a 3rd-party application running on a patient-owned device to the API of the QSmartCare.

The same patient will be enabled to present their authenticated credentials to use a 3rd-party application running on a patient-owned device to access either partial encounter summary data or a full encounter summary. They will have the ability to view and or transmit their information as they see fit. This will meet § 170.315 (g)(7,9)

Measure 6: 170.315(b)(10) Electronic Health Information Export

This will demonstrate the portal as a key tool for the clinician to export electronic health information (EHI) for a single and multiple patients at any time the user chooses without developer assistance.

i)       Can Create patient EHI data.

ii)      Export the patient EHI data for single and multiple patients without developer assistance.

iii)       EHI exported data are available in both computable and human readable format

Measure 7: 170.315(c)(1) Clinical quality measures (CQMs) Record and Export

(C)(1)(i) Record all necessary data to calculate CQMs

(C)(1)(ii) Export CQM data file in QRDA I format for one or more patients that include all necessary data recorded for report calculation.

Measure 8: 170.315(c)(2) Clinical quality measures (CQMs) Import and calculate

(C)(2)(i) Import a CQM data file in QRDA I format for one or more patients that includes all necessary data for calculating an aggregate report

(C)(2)(ii) Calculates aggregate report for each CQM’s based on the data recorded and received on the system

Measure 9: 170.315(c)(3) Clinical quality measures (CQMs) Report

(C)(3)(i) Electronically create a CQM data file for transmission of clinical quality measurement data in QRDA III format.

Measure 10: 170.315(f)(1) Transmission to Immunization Registries:

This measure will catalog the use of HL7 V2 standard document conformant, and the ability of the system to transmit to state immunization registry.

(i) Create immunization information according to the IG) IM Release 1.5, and the July 2015 Addendum, using CVX codes for historical vaccines and NDC codes for newly administered vaccines

(ii) Transmit the immunization message to the connected organization.

Measure 11: 170.315(f)(2) Public Health - Syndromic Surveillance:  This measure will assess the conformance of the certified syndromic surveillance transmission using the QSM Application to any of the public agencies

(i) Create syndrome-based public health surveillance information for electronic transmission according to the HL7 2.5.1 standard.

(ii) Transmit the syndrome-based public health surveillance message to the connected agencies.

Measure 12: 170.315(b)(3) Electronic prescribing: This measure will demonstrate the electronic transmission of all prescription related transactions.

(i) Send and Receive prescription transactions electronically per the NCPD SCRIPT Standard and using RxNorm codes.

(ii) Send the reason for the prescription using diagnosis elements along with prescription.

Measure 13: 170.315(h)(1) Direct Project:

This measure will track various measurements associated with Direct messaging successfully sent and received with the QSmartCare Module and the 3rd party throughout a given interval.

(i) Send and receive health information using direct.

Measure 14: 170 315(b)(9) Care Plan:

This measure will demonstrate to Record, Change, Access, Create, and Receive Care Plan

(i) Can change and access the care plan details.

(ii) Generates C-CDA care plan document.

(iii) Creates human readable format of the care plan document.

(iv) Receive care plan document formatted in accordance with the standard specified at § 170.205(a)(4)

Measure 15: 170 315(g)(10) Standardized_API_for_Patient_and_Population_Services:

Additionally, the patient will have the ability to access (by authentication) either partial or full encounter summaries by way of an API call from a 3rd-party application running on a patient-owned device to the API of the QSmartCare.

The same patient will be enabled to present their authenticated credentials to use a 3rd-party application running on a patient-owned device to access either partial encounter summary data or a full encounter summary. They will have the ability to view and or transmit their information as they see fit. This will meet § 170.315 (g)(7,9,10)

Measurement /Metric

Associated Certification Criteria

Relied upon Software

Measure 1

170.315(b)(1) Transitions of care - receive

Data Motion

Measure 2

170.315(b)(1) Transitions of care - Send

Data Motion

Measure 3

170.315(b)(2) Clinical information reconciliation and incorporation

170.315(b)(1) Transitions of care - receive

Data Motion (only applies for b1)

Measure 4

170.315(e)(1) View, download, and transmit to 3rd party

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

Measure 5

170.315(g)(7, 9) API

Measure 6

170.315(b)(10) Electronic Health Information Export

170.315(b)(1) Transitions of care

Measure 7

170.315(c)(1) Clinical quality measures (CQMs) Record and Export

Measure 8

170.315(c)(2) Clinical quality measures (CQMs) Import and calculate

Measure 9

170.315(c)(3) Clinical quality measures (CQMs) Report

Measure 10

170.315(f)(1) Transmission to Immunization Registries:

Measure 11

170.315(f)(2) Public Health - Syndromic Surveillance

Measure 12

170.315(b)(3) Electronic prescribing:

New Corp

Measure 13

170.315(h)(1) Direct Project

Data Motion

Measure 14

170 315(b)(9) Care Plan

170.315(b)(1) Transitions of care - receive

Data Motion(only applies for b1)

Measure 15

170 315(g)(10) Standardized API for Patient and Population Services

Measurement /Metric

Justification

Measure 1: 170.315(b)(1) Transitions of care - Receive: Clinician logs into QSmartCare and receives a C-CDA from a referring provider via Direct Protocol with no Tech Support and no errors.

Successful receipt of C-CDA is achieved and observed.

The ability to electronically receive a C-CDA, without developer assistance, from another provider and or point of service by using the Edge Protocol is integral to the exchange of data and interoperability and inherent in a certified QSmartCare. The C-CDA will use the USCDI standard.

Measure 2: 170.315(b)(1) Transitions of care - Send: Updated C-CDA is sent back to referring provider. Successful sending of the CCDA is achieved and observed.

To complete the ability to bi-directionally participate in the interoperability of patient information the certified QSmartCare technology must be able to allow providers to send a C-CDA using the Edge Protocol,and the USCDI standard.

Measure 3: 170.315(b)(2) Clinical Information Reconciliation and Incorporation: The C-CDA is validated, and Clinical Information reconciliation is performed. No errors are expected.

A clinician must be able to perform clinical information reconciliation and incorporation for medication, medication allergy and the problems effectively, without developer assistance. As a result, a revised C-CDA using the Common Clinical Data Set standard will be created which can then be shared with additional clinicians and sent to the patient portal for patient access. The ability to do this as part of the test plan will show how clinicians can complete this task efficiently and without error. The most current information will be available to both clinicians and the patient as required by a certified QSmartCare.

Measure 4: 170.315(e)(1) View, download, and transmit to 3rd party: Observation of the View, Download & Transmit functions are performed. This will demonstrate the portal as a key tool for the clinician to share the patient’s most current health information with the patient. Additionally, the ability to access (authenticate) either partial or full encounter summaries by way of an API call.

The patient portal is vital to all patients. Patients will be able to login at any time and view their most current information as well as share it with any other clinicians they might choose to visit. This allows the exchange of information by the patients themselves which is key to giving control of their health information. This is an essential part of certified QSmartCare technology

Measure 5: 170.315(g)(7,9) API: Additionally, the patient will have the ability to access (by authentication) either partial or full encounter summaries by way of an API call from a 3rd-party application running on a patient-owned device to the API of the QSmartCare.

The certified QSmartCare technology must provide the patient with an additional ability to obtain their medical information via a request from an application of their own, outside of the domain of QSmartCare. This functionality will supplement the capabilities that are achieved with a patient portal.

Measure 6: 170.315(b)(10) Electronic Health Information Export:

This will demonstrate the portal as a key tool for the clinician to export electronic health information (EHI) for a single and multiple patients at any time the user chooses without developer assistance.

Exporting data on demand is an essential requirement for clinical practice with a certified QSmartCare. This measure will generate a EHI export for single and multiple patients at any time the user chooses without developer assistance. Exported files are available in both computable and human readable format.

Measure 7: 170.315(c)(1) Clinical quality measures (CQMs) – record and export: This measure will demonstrate the Clinical Quality Measure Reporting system that calculates and generate the aggregate report in both human readable and QRDA III file format for each CQM’s based on the deduplicated clinical data that recorded in the QSmartCare system and that imported to the system in QRDA I format. Also, the system allows to export of the CQM data in QRDA I file format.

QSmartCare management logs, system logs, and activity logs, sample QRDA collected will be reviewed to determine the frequency used by providers for generating reports and sending/receiving CQM data files. Log files obtained during Real World Testing will be de-identified and used for analysis in several areas to validate the proper operation of CQM and input for the calculation of the metric.

Measure 8:  170.315(c)(2) CQMs – import and calculate: Ensure the functionality exists for CQM recording for patient data import and calculation capability.

Demonstrate the system can import a data file and calculate the measures CMS pre-validation and test tool.

Measure 9:  170.315(c)(3) CQMs – report: Ensure the functionality exists for CQM export capability

Demonstrate the CQM measure capture and calculations and test export CMS pre-validation and test tool.

Measure 10:  170.315(f)(1) Transmission to Immunization Registries: This measure will catalogue the use of HL7 V2 standard document conformant, and the ability of the system to transmit to the state immunization registry.

QSmartCare developed criteria to meet certification requirements for the wound care speciality. However, penetration into the wound care market is low and most of them are Adult wound care.  We are only documenting immunization. Though our wound care physician does not directly provide immunization we do document the status of immunization.

Measure 11:  170.315(f)(2) Public Health - Syndromic Surveillance: This measure is tracking how many syndromic surveillance messages are created and successfully sent from the QSmartCare Module to a syndromic registry throughout a given interval

This measure will provide a value to indicate if the exchange is enabled and working between QSmartCare and the syndromic surveillance registry. QSmartCare is not using this feature because all of our client base are wound care specific so they are not required to report to public health agencies.

Measure 12: 170.315(b)(3) Electronic prescribing: This measure will demonstrate the electronic transmission of all prescription related transactions.

QSmartCare developed criteria to meet certification requirements for the wound care speciality. However, it is not possible to demonstrate the correct standards used because as wound care physician we do not receipt other facility. So reporting is not something they have needed to do so we are not using this functionality.

Measure 13: 170.315(h)(1) Direct Project: This use case is tracking various measurements associated with Direct messaging successfully sent and received with the QSmartCare Module.

This criterion requires the ability of a certified Health IT module to record the frequency that direct messages are sent and received by providers. We cannot reliably use that metric to define success. Furthermore, it is not feasible to obtain copies of Direct Messages from “outside” developers or providers who have no incentive to participate in this exercise

Measure 14: 170 315(b)(9) Care Plan: This measure will demonstrate to Record, Change, Access, Create, and Receive Care Plan

Create - This measure will generate a C CDA care plan document.

Receive - Creates a human readable version of the care plan document and can receive a care plan document formatted in accordance with the standard specified at § 170.205(a)(4) and includes the Health Status Evaluations

and Outcomes Section and Interventions Section (V2) using visual inspection.

Measure 15: 170 315(g)(10) Standardized_API_for_Patient_and_Population_Services: Additionally, the patient will have the ability to access (by authentication) either partial or full encounter summaries by way of an API call from a 3rd-party application running on a patient-owned device to the API of the QSmartCare.

A patient should be able to share their health information upon request with third-party vendors that have elected to integrate with QSmartCare publicly available FHIR API. Additionally, third-party vendors should be able to perform an EMR based launch of a FHIR application as part of this new program.

Care Setting

Justification

Facility

·         In Patient

o   EH

Speciality

·         Wound Care

QSmartCare is currently used by providers in the Wound Care specialty. This test plan will demonstrate that the overall functionality is the same regardless of the number of providers that are using it at a given time.

However, we will confirm that QSmartCare accommodates the specific workflow under each condition with multiple simultaneous users of QSmartCare.

Real World Testing will be conducted with clinicians involving 1 to 3 clinicians, which represents the most common use case for the QSmartCare EHR. Real patient data will be deidentified and the testing will be using a mirrored production environment. The ability to complete all measures successfully with these practices will be documented through observation of the completed tasks. Deviations from the designed process, if any, will be noted and addressed.

The ability to complete all measures successfully with these practices will be documented through observation of the completed tasks. Deviations from the designed process, if any, will be noted and addressed.

Measurement / Metric

Expected Outcomes

Measure 1: 170.315(b)(1) Transitions of care (Receive)

We will utilize the measure Automated Measure (315.g.2), to determine the measure count. It will show that QSmartcare can receive a C-CDA patient summary record.

Both Referral Notes and Discharge Summaries will be evaluated.

The received document will be evaluated for the ability to:

• Receive and validate and display any recorded errors if not valid C CDA documents.

• Parse and present a pre-configured human readable display of all USCDI data from the relevant C-CDA formatted to the USCDI standard.

QSmartCare is compliant with standards for these criteria and vocabulary code sets in all of these measures.

We expect the outcome to meet or exceed 75% successful validation.
We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 2: 170.315(b)(1) Transitions of care (Send)

We will utilize the measure Automated Measure (315.g.2), to determine the measure count. It will show that the QSmartcare can send a C-CDA patient summary record.

The Real World Testing will demonstrate that the clinician can send R2.1 C CDA Referral Notes and Discharge Summaries compliant with the USCDI standard using the SMTP Edge Protocol. We will successfully validate the receipt of the sent documents. We expect the outcome to meet or exceed 75% successful validation.We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 3: 170.315(b)(2) Clinical information reconciliation and incorporation

We will utilize the measure Automated Measure (315.g.2), to determine the measure count. The Real World Testing will demonstrate that the receiving clinician will be able to validate the C-CDA, compliant with the USCDI, perform reconciliation successfully for medication, medication allergies and problems at any time without delay and create an updated C-CDA, compliant to the USCDI, as required to demonstrateQSmartCare exchange of information and interoperability.

We expect that the CCDA Reconciliation rate will exceed 75%.
We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 4: 170.315(e)(1) View, download, and transmit to 3rd party

The Real World Testing will demonstrate that the clinician can enable patients (and their authorized representatives) to view, at a minimum, the USCDI standard; laboratory test report(s); and diagnostic image reports. Enable patients (and their authorized representative) to view health information filtered by a specific date and date range. Enable patients (and their authorized representatives) to download inpatient summaries in the following formats:

• Human readable format

• Format C-CDA document summary will include, at a minimum, the USCDI standard; laboratory test report(s); diagnostic image reports.

For all settings, patients (and their authorized representatives) will be able to transmit the C-CDA summary through both:

o Email transmission to any email address

• When transmitted, the inpatient summary will be compliant with with the USCDI standard; laboratory test report(s); diagnostic image reports; and:

• Enable patients (and their authorized representative) to download health information filtered by a specific date and date range.

For all view, download, and transmit capabilities, the following information will be recorded and made accessible to the patient (and authorized representative):

o The action that occurred

o The date and time each action occurred

o The user who took the action; and the addressee to whom

the summary was transmitted.

We will utilize reports such as audit logs, including Automated Measure (315.g.2) reports, to determine our measure count. We will show that patients can log into their patient portal to access their patient data and transmitting their health data to a 3rd party. Our expectation is there will be moderate utilization by patients for view and lower utilization for download and transmit with a high success rate for all certified capabilities.
with a high success rate for all certified capabilities. We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 5: 170.315(g)(7,9) API

The Real World Testing will demonstrate that the clinician has the functionality within QSmartCare to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient’s data.

The QSmartCare will demonstrate the functionality to respond to requests for patient data for partial or all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified

standards, where applicable) in a summary record formatted according to the standard adopted C-CDS standard. The requests will respond to requests for patient data associated with a specific date as well as requests for patient

data within a specified date range.

We will use audit logs and Automated Measure (315.g.2) reports to identify the API request access and can generate a report from reports menu for API access request within the specified time interval. Our expectation is there will be moderate utilization by patients for the XML API.
We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 6: 170.315(b)(10) Electronic Health Information Export

The Real World Testing will demonstrate that limited set of clinicians are enabled to export patients EHI data. They can:

a)       a) Create patient EHI data

b)      b) Export EHI data for both single and multiple patients at any time without developer assistance

c)       c) EHI exported data are available in both computable and human readable format

Our expectation is there will be very medium utilization by providers with a high success rate.
We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 7: 170.315(c)(1) Clinical quality measures (CQMs) - record and export

This measure is tracking and counting how many eCQM quality measures were successfully reported on by the QSmartCare Module to CMS during their submission period for MIPS Quality reporting.

This measure will provide a count and list of electronic clinical quality measures (eCQMs) which are calculated and submitted to CMS for a given program, like MIPS. Clinical quality measures are only used for the respective CMS programs and any production measures should utilize submission to CMS. Because CQM criteria, 315(c)(1) - (c)(3), all work collectively together in the eCQM functionality of the QSmartCare Module.

The measurement will count and list of eCQMs submitted to CMS over a given interval. A successful measure submission indicates compliance with the underlying ONC criteria. It will show that QSmartCare can do calculations on the eCQM and that they are accepted by CMS. We will abstract counts of exported QRDA CAT I files and compare that to the number of files generated to calculate what percentage of generated files are being exported to calculate a utilization rate. The expectation is that 80-90% of generated files are exported.
We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 8: 170.315(c)(2) CQMs – import and calculate

We will count the number of imported QRDA CAT I files and expect that it will validate that the functionality is being used successfully in production by our providers. We will abstract counts of imported QRDA CAT I files and compare that to the number of files uploaded for import to validate what percentage of uploaded files are being successfully imported and calculate a utilization rate.

We expect that 85% or more uploaded files are successfully imported and that 5% or less of patient files uploaded will be unsuccessful due to no data being present in the file.

We will visually inspect each patient record selected in the random sample to validate that the expected imported data is present in the patient record. We expect to find an 85-95% success rate with data import.
We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 9: 170.315(c)(3) CQMs – report:

C3 requires a certified Health IT module must be able to create a QRDA Category 1 formatted file and a QRDA Category 3 report to be used for transmitting CQM data to CMS. The CQM files are imported and/or exported by providers to demonstrate the certified capability is available and effective, regardless of the frequency it is used. Our expectation is there will be moderate utilization by providers with a high success rate. We expect that 90% of submitted files generated will be successful.We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 10: 170.315(f)(1) Transmission to Immunization Registries

The measurement will record if the immunization interface is active and working between the QSmartcare and public health registry. A successful measurement status indicates compliance to the underlying ONC criteria. We will show that the QSmartcare is creating and exchange the HL7 immunization record, including ability to record the required clinical data elements. In sending the immunization message, the QSmartcare will demonstrate ability to confirm successful interoperability of patient’s immunization data to an IIS/immunization registry. We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.  

Measure 11: 170.315(f)(2) Public Health - Syndromic Surveillance

The measurement will record if the syndromic surveillance interface is active and working between the QSmartcare and public health registry. A successful measure status indicates compliance to the underlying ONC criteria. We will show that the QSmartcare can create the HL7 syndromic surveillance message, including ability to record the required clinical data elements. In sending the syndromic surveillance message, QSmartcare will demonstrate ability to confirm successful interoperability of patient’s syndromic data to public health registry. There will likely not be a high volume of reports generated due to this criterion not applying to the whole inpatient care setting. We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it

Measure 12: 170.315(b)(3) Electronic prescribing

This criterion requires the ability of a certified Health IT module to perform prescription-related electronic transactions (eRx) using required standards. However, it is not possible to demonstrate the correct standards used because as wound care physician we do not receipt other facility and have no incentive to participate. Therefore, we intend to demonstrate the required certified capabilities are effective by demonstrating how often eRx transactions are performed by examining reports from our eRx partner. This will demonstrate that not only are the eRx transactions sent from the certified Health IT module, but that the transactions are successfully received by the eRx clearinghouse.We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 13: 170.315(h)(1) Direct Project

Therefore, we intend to demonstrate the required certified capabilities by demonstrating how often Direct Messages are exchanged with other systems to demonstrate the certified capability is available and effective, regardless of the frequency it is used. Our expectation is there will be zero adoption of this certified capability by our users. We have a testing methodology for these capabilities to test the plan below to demonstrate the feature is available and functions as expected should any users elect to begin using this feature.

Measure 14: 170 315(b)(9) Care Plan

The Real World Testing will demonstrate that a User can Record, Change, Access, Create, and Receive a Care Plan.

Create - This measure will generate a C CDA care plan document and executes the upload of the submitted file to the ETT: Message Validators and verify the validation report indicates passing without error. We do not anticipate a high volume of this specific CDA document type being used by our care settings yet.

Receive - Creates a human readable version of the care plan document and can receive a care plan document

formatted in accordance with the standard specified at § 170.205(a)(4) and includes the Health Status Evaluations

and Outcomes Section and Interventions Section (V2) using visual inspection. We are not aware of many organizations generating this specific type of document, so we do not anticipate a large number of organizations that are receiving the Care Plan.

We can demonstrate the Care plan documentation, Create and Receive in C-CDA format and will use audit logs to identify the Care plan capture information, Create and receive information and can generate a report for total number of care plan documented in a specified time frame. We do not anticipate a high volume of this specific CDA document type is being used by our care settings yet.We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Measure 15: 170 315(g)(10) Standardized API for Patient and Population Services:

a) Real world testing (RWT) will allow QSmartCare to verify utilization of our publicly available FHIR API by both third-party vendors and patients who have elected to share their health information with a third-party app.

b) RWT will demonstrate the ability to respond to a request for patient data and return said patient data utilizing a shared patient ID via our secure FHIR-based API.

c) RWT will demonstrate the ability to respond to a request for all USCDI data categories in a summary record format in accordance with § 170.315(g)(9).

d) RWT will demonstrate the ability to respond to requests for a single patient’s data or for multiple patients’ data as a group according to the standard adopted consistent with the FHIR Resource search criteria include adopted in §170.315(g)(10).

We make sure that the feature is tested in our mirror environment and demonstrated to be functioning without any problems if we don't have any users using it.

Key Milestone

Care Setting

Date / Timeframe

Release of documentation for the Real-World Testing to be provided to authorized representatives and providers.

Facilities:  Inpatient

Specialties: Wound Care

November 2024

Identify the user practices that will participate in the test plan

Facilities:  Inpatient

Specialties: Wound Care

December 2024

Confirm that the Real World Test Plan participants can log into their accounts and are ready to start the RWT plan documentation

Facilities:  Inpatient

Specialties: Wound Care

February 2025

Follow-up with providers and authorized representatives regularly to understand any issues arising with the data collection.

Facilities:  Inpatient

Specialties: Wound Care

March 2025

End of Real-World Testing period/final collection of all data for analysis.

Facilities:  Inpatient

Specialties: Wound Care

June 2025

Analysis and report creation.

Facilities:  Inpatient

Specialties: Wound Care

August 2025

Submit Real World Testing report to ACB (per their instructions)

Facilities:  Inpatient

Specialties: Wound Care

January 2026