Real World Testing 2024

menu close

Real World Testing 2024 (RWT)

Care Coordination
Passed Passed
§ 170.315(b)(1) Transitions of care § 170.315(b)(6) Data export
§ 170.315(b)(2) Clinical information reconciliation and incorporation
           
           
           
Clinical Quality Measures Application Programming Interfaces
Passed Passed
§ 170.315(c)(1) — record and export § 170.315(g)(7) Application access— patient selection
§ 170.315(c)(2) — import and calculate § 170.315(g)(9) Application access— all data request
§ 170.315(c)(3) — report
           
           
Public Health
Passed
§ 170.315(f)(1) Transmission to immunization registries
§ 170.315(f)(5) Transmission to public health agencies — electronic case reporting
§ 170.315(f)(7) Transmission to public health agencies — health care surveys
     
     
Electronic Exchange
Passed
§ 170.315(h)(1) Direct Project
Criteria Care Setting Measurement Period Date Key Milestones
Care Coordination
§ 170.315(b)(1) Transitions of care
§ 170.315(b)(2) Clinical information reconciliation and incorporation
§ 170.315(h)(1) Direct Project: from the Electronic Exchange Category
 Ambulatory
5/1/2024-9/30/2024
 May, 2024
  • Confirm Trading Partner
  • Confirm ability to send and receive clinical documents
  • Confirm with TP that production data will be used, whether in an actual live environment or a copy of a live environment
June, 2024
  • SUT links to the correct Direct addresses and initiates sending of Clinical Document.
  • C-CDA Care Referral or Referral Note is triggered to send via Direct Protocol
  • Referral Dept. checks Direct Status screen (under Direct Outgoing menu choice) to ensure Clinical Document was successfully transmitted.
July, 2024 Recipient uses scorecard to grade C-CDA
August, 2024
  • Tester uses Document Center to locate Clinical Document.
  • Care provider reviews the Direct Status screen
    (under Direct Outgoing menu choice).
September, 2024
  • The care provider reviews the record, and the patient's problems, medications, and medication allergies are reviewed and optionally merged into the system under test with no duplicates.
  • The data from the TP becomes part of the patients permanent record.
  • The main dashboard is updated to accurately reflect for the provider all 3rd party visits to be reconciled
September, 2024 Calculate and compile metrics
§ 170.315(b)(6) Data export Ambulatory
7/1/2024 -7/31/2024
 July, 2024
  • Date and time ranges can be configurable via the UI
  • Targeted Practices can be configurable via the UI
  • Patients exported can be configurable via the UI
July, 2024 Use the Edge Test Tool to check validity of output file(s)
July, 2024 Calculate and compile metrics
Clinical Quality Measures
§ 170.315(c)(1)—record and export
§ 170.315(c)(2)—import and calculate
§ 170.315(c)(3)—report
 Ambulatory
8/1/2024-8/31/2024
 August, 2024
  • Confirm Trading Partner
  • Confirm ability to calculate and report eCQMs
  • Confirm with TP that production data will be used, whether in an actual live environment or a copy of a live environment
August, 2024 The file should upload and be accepted by the environment without error.
August, 2024 All populations of all measures should match.
August, 2024 Calculate and compile metrics
Public Health
§ 170.315(f)(1) Transmission to immunization registries Ambulatory
7/1/2024-7/31/2024
 July, 2024
  • Has a state immunization registry that is enabled for bi-directional send/receive of immunization data.
  • Already has a functional bi-directional immunization interface or would like to implement one to their registry.
July, 2024 Validate that immunization interface is functioning as expected
July, 2024 Verify immunization data was received in registry.
July, 2024 Verify immunization data was received in HIE Portal
July, 2024 Calculate and compile metrics
§ 170.315(f)(5) Transmission to public health agencies — electronic case reporting Ambulatory
7/1/2024-7/31/2024
 July, 2024 eCR messages are successfully received and processed by public health agency
July, 2024 Functioning eCR interface to public health agency
July, 2024 Calculate and compile metrics
§ 170.315(f)(7) Transmission to public health agencies — health care surveys Ambulatory
7/1/2024-7/31/2024
 July, 2024
  • The identified testing location is able to select a subset of survey questions that are relevant to its activities
  • Location confirms availability of survey option in patient portal.
July, 2024 Responses are converted to HL7 CDA documents for transmission.
July, 2024 Calculate and compile metrics
Application Programming Interfaces
§ 170.315(g)(7) Application access— patient selection
§ 170.315(g)(9) Application access— all data request
 Ambulatory
8/1/2024 -8/31/2024
 August, 2024
  • Partner with PHR or identify existing PHR that can receive patient clinical data as described in this RWT plan.
  • Ensure that PHR has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API and Patient Portal modules of ConnectEHR.
August, 2024 Encounter is created and visually confirmed
August, 2024
  • Dynamic FHIR API has transformed C-CDA into FHIR resources.
  • PHR app consumes FHIR resources to populate EHR data
August, 2024 Visually validate Assessment, Plan of Treatment and Health Concerns narrative text
August, 2024 Calculate and compile metrics
§ 170.315(g)(10) Standardized API for patient and population services Ambulatory & Inpatient
3/1/2022 -6/1/2022
 May, 2024
  • Partner with PHR or identify existing PHR that can receive patient clinical data as described in this RWT plan. We recommend MyLinks (https://www.mylinks.com/)
  • Ensure that PHR has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API and Patient Portal modules of ConnectEHR.
June, 2024 Encounter is created and visually confirmed
July, 2024
  • Dynamic FHIR API has transformed C-CDA into FHIR resources.
  • PHR app consumes FHIR resources to populate EHR data
May, 2024
  • Partner with a provider-centric app for improved patient care (e.g. growth charts, clinical decision support, patient charting).
  • Ensure that app has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API module of ConnectEHR.
June, 2024 Data is rendered correctly: Provider compares patient data in app to patient data in EHR and notes any discrepancies.
May, 2024
  • Partner with a provider-centric app that requires periodic bulk data downloads.
  • Ensure that app has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API module of ConnectEHR.
June, 2024 Data is rendered correctly: Provider compares patient data in app to patient data in EHR and notes any discrepancies.
August, 2024
Electronic Exchange
§ 170.315(h)(1) Direct Project
(Included with (b)(1),(b)(2) in the CareCoordination Category) 		Ambulatory
5/1/2024-8/31/2024
 SEE CARE COORDINATION SEE CARE COORDINATION
Table of Contents Link Associated Certification Criteria:
§ 170.315(b)(1) Transition of Care (Cures Update)
§ 170.315(b)(2) Clinical information reconciliation and incorporation
§ 170.315(h)(1) Direct Project
Measure Description: Send and receive Transition of Care (TOC) messages with other providers to close the referral loop. The patient's ePHI will be exchanged using a C-CDA 2.1 Care Referral or Referral Note and DIRECT secure messaging for data transport. Justification: We chose to concentrate on the aspects of this criterion that would:
  1. Showcase a streamlined approach to provider-to-provider patient referrals, for those organizations that have opted into a HISP. Using transitions of care, the goal is to target shorter lead times and higher quality patient care.
  2. Eliminate as much risk of data entry errors as possible by transmitting patient data securely and electronically rather than relying on manual data entry for referrals.
  3. Reduce the overall time burden of managing referral status changes and tracking.
  4. Reduce fax document handling and the inaccuracy of matching referral documents to patient charts.
  5. Ensure private and secure transmission of patients' PHI
  6. Result in increased interoperability between disparate HIT systems.
Metric Description:
  1. 100 percent outbound TOC's successfully received by HIE for in-State Patients with discharges
  2. 100 percent or more of trading partner's TOC C-CDAs are successfully incorporated by SUT.
  3. Work towards 10% of patients where a referral is initiated and complete the referral loop using DIRECT.
 Standards Implemented: (SVAP)
  • USCDIv1 July 2020 Errata
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 Relied upon software: Product Name: Dynamic Health IT, Inc., ConnectEHR +BulkFHIR
Product Version: FHIR4-B
Product Name: MaxMD Direct mdEmail
Product Version: Version 3.0 SOAP 		Methods Use to Demonstrate Interoperability:
  1. HISP via Direct Protocol (SMTP)
  2. HIE exchange
  3. HTTPS via secure provider portal
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
       
1
 Identify Trading Partner (TP) and coordinate with TP for sending/receiving clinical documents using production data as described in this RWT plan.
  • Confirm Trading Partner
  • Confirm ability to send and receive clinical documents
  • Confirm with TP that production data will be used, whether in an actual live environment or a copy of a live environment
 May, 2024
2
 Patient A has encounter with care provider and data is captured in EHR. Care provider initiates TOC Care Referral to the TP EHR via DIRECT and to the HIE
  • USCDIv1 data elements captured in EHR (system under test)
  • Care provider selects Clinical Document to be transmitted.
  • Care provider is able to create a C-CDA Release 2.1 that also includes the reason for referral, and the referring or transitioning provider's name and office contact information.
  • Care provider chooses the CPT for the referral and then chooses the provider he wants the patient to see
3
 * Referral Dept. choses the appropriate provider to refer the patient to based off of scheduling & tracking
  • SUT links to the correct Direct addresses and initiates sending of Clinical Document
  • C-CDA Care Referral or Referral Note is triggered to send via Direct Protocol
  • Referral Dept. checks Direct Status screen (under Direct Outgoing menu choice) to ensure Clinical Document was successfully transmitted.
 June, 2024
*
 Next steps take place in trading partner's EHR.
4
 Validate that C-CDA for Patient A contains USCDIv1 data elements. Recipient uses scorecard to grade C-CDA July, 2024
5
 Trading partner refers Patient A from TP EHR to system under test by generating C- CDA Clinical Document.
  • Care provider selects recipient from directory of Direct addresses and initiates sending of Clinical Document.
6
 In system under test, tester acknowledges receipt of valid Clinical Document.
  • Tester uses Document Center to locate Clinical Document.
  • Care provider reviews the Direct Status screen (under Direct Outgoing menu choice).
August, 2024
7
 In system under test, the incoming data is incorporated via reconciliation into Patient A's existing medical record.
  • The care provider reviews the record, and the patient's problems, medications, and medication allergies are reviewed and optionally merged into the system under test with no duplicates.
  • The data from the TP becomes part of the patients permanent record.
  • The main dashboard is updated to accurately reflect for the provider all 3rd party visits to be reconciled
September, 2024
8
 Calculate and compile metrics September, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023
Table of Contents Associated Certification Criteria:
§ 170.315(b)(6) Data export
Measure Description: Export all available data elements from the United States Core Data for Interoperability (USCDIv1) for a population of patients for use in a different health information technology product or a third party system. This export can be used for many purposes, including data portability when a physician practice switches to a new EHR platform. Justification: We chose to concentrate on the aspects of this criterion that would:
  1. Demonstrate CloudCraft's ability to export batches of patient data easily for the user.
  2. facilitate interoperability by providing the exported data in the form of valid CCD files that conform to the HL7 standards as described in the HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm).
Metric Description:
  1. 100 percent of Exports ran timely, or a user friendly error will be provided.
  2. C-CDA count matches actual patient count for requested selection criteria.
 Standards Implemented: N/A
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 		Methods Use to Demonstrate Interoperability:
  1. Visual validation/counting
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
1
 Using production data in an actual live environment or copy of live environment, demonstrate the ability to configure data export for all patients, specific patients, or by location, for a specified time frame
  • Date and time ranges can be configurable via the UI
  • Targeted Practices can be configurable via the UI
  • Patients exported can be be configurable via the UI
 July, 2024
2
 Demonstrate the ability to limit the set of users who can create export summaries Batch export is only available in Admin Console. Only users with admin role in HR can access Admin Console.
3
 Confirm users roles that do not have admin role in HR cannot create export summaries Users without admin role cannot access Admin Console and thus cannot create batch export.
4
 Create and validate a batch export for a single patient Use the Edge Test Tool to check validity of output file(s) July, 2024
5
 Create an on-demand batch export for data within a entered date and time range for a specific location.
  • Data was available for the entered date and time range
  • The batch export contained data only within that date and time range, only for the specified location.
6
 Schedule a recurring batch export for a set of specified patients (Ex. Every first of every month @ 7 AM) The scheduled batch export would be display and be visually validated
7
 Schedule a single batch export for a future date/time for any criteria (Ex. 07/16/2024 @ 3.30 PM)
  • The scheduled batch export was created successfully
  • The specific date/time would be in the near future so the export could be confirmed
8
 Save the export summary to a preferred location at the time of export.
  • Saving to a preferred location is allowed
  • Visually confirming the export after save is performed and successful
9
 Calculate and compile metrics. July, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023
Table of Contents Associated Certification Criteria:
§ 170.315(c)(1) - Clinical quality measures (CQMS) — record and export
§ 170.315(c)(2) - Clinical quality measures (CQMS) — import and calculate
§ 170.315(c)(3) - Clinical quality measures (CQMS) — report
Measure Description:
  • Capture and record electronic clinical quality measure (eCQM) data in EHR (or trading partner's EHR) for calculating eCQMs.
  • Electronically create a data file for transmission of CQM data in accordance with the CMS QRDA Category I IG for inpatient measures as adopted in § 170.205(h)(3) and CMS QRDA Category III IG for ambulatory measures as adopted in § 170.205(k)(3).
Justification: We chose to concentrate on the aspects of this criterion that would closely follow the actual activities of Cloud Craft users with respect to eCQM calculatlon and output:
  1. 1) Run quality measure reports and display results on Dashboard to compare with industry-standard benchmarks and with prior/expected performance.
  2. 2a) Generate eCQM output for PI/IQR (universal eCQM reporting program for hospitals) and ensure that it can be successfully uploaded to the PI/IQR website.
  3. 2b) Generate eCQM output for MIPS (the most widety-used eCQM reporting program for ambulatory) and ensure that it can be successfully uploaded to the Quality Payment Program (QPP) website.
  4. 3a) Verify that CQMsolutlon is a product that can support hospital quality reporting needs.
  5. 3b) Verify that CQMsolutlon is a product that can support MIPS participants in achieving an end-to-end reporting bonus.
Metric Description:
  1. 1. 100 percent matching data clements In CQMsolutlon vs EHR. This will be confirmed by visual validation of the following data:
    • Demographics
    • Problems/Diagnosis
    • Medications
    • Allergies
    • Vitals
    • Results
    • Procedures
  1. 2. 100% discrepancy will be identified thru Quarterly Reconciliation of measures calculation between ACO calculations and SUT calculations
Standards Implemented:
  • HL7 CDA® R2 lmplementation Guide: Quality Reporting Document Architecture - Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1 - Introductory Material, June 2015
  • HL7 CDA R2 Implementation Guide: Quality Reporting Document Architecture - Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 2 - Templates and Supporting Material, June 2015
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 Relied upon Software: Product Name: Dynamic Health IT, CQMsolution
Product Version: 23 		Methods Use to Demonstrate Interoperability:
  • Visual Inspection and matching of QRDA I data to EHR data
  • Matching of calculation results from CQMsolutlon to CMS
  • API Sandbox testing with CMS for file acceptance
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
1
 Identify Trading Partner (TP) and coordinate with TP for calculating and reporting electronic clinical quality measures (eCQMs) using production data as described in this RWT plan
  • Confirm Trading Partner
  • Confirm ability to calculate and report eCQMs
  • Confirm with TP that production data will be used, whether in an actual live environment or a copy of a live environment
 August, 2024
2
 Identify six EP (Eligible Professional) eCQMs for RWT Based on historical data, select the most popular eCQMs.
3
 Identify a one calendar year reporting period with adequate patient data for reporting Admins with sufficient familiarity with the physician practice's clinical activities should be able to choose a period with an appropriate amount of quality data.
4
 Capture and record clinical quality measure (CQM) data in Trading Partner's (TP) EHR. Since manual data entry for an adequate quantity of data would be onerous, we will use actual patient data.
  • a. If TP is Integrated with CQMsolution, CQMsolution will capture data through a SQL query, so that when a user runs a CQM report, CQMsolution pulls data directly from the TP's database
  • b. Alternative approach. Pull in data through QRDA I files in a .zip folder
Data ready for report generation
5
 Correctly calculate numerator, denominator, exclusion and exception values for selected eCQMs. The CQMsolution report should complete with no errors.
6
 Spot-check 10 patients for each measure, ensuring that some are in the denominator only, some are in the numerator and denominator and, if possible, some are exclusions or exceptions. Use Patient List to check which categories Initial Patient Population (IPP), Denominator (Den), Exclusions (Excl), Numerator (Num) or Exceptions (Excp) each patient falls into.

For each spot-check patient, use the drill-down to confirm that the patient data in CQMsolution (encounters, codes, demographics) matches the patient data in the EHR and that the patient is correctly categorized in CQMsolution.
7
 Upload the generated MIPS QRDA III file to QPP. The file should upload and be accepted by the environment without error. August, 2024
8
 Check the submission environment's measure calculation results and compare them to CQMsolution's calculation results. All populations of all measures should match. August, 2024
9
 Calculate and compile metrics. August, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023
Table of Contents Associated Certification Criteria:
§ 170.315(f)(1) - Transmission to immunization registries
Measure Description: Create and transmit Immunization information. Enable a user to request, access, and display, a patient's evaluated immunization history and the immunization forecast from an immunization registry Justification: We chose to concentrate on the aspects of this criterion that would provide the most patient care value in an actual setting. lmmunization registries can be very helpful in directing and informing patient care and in cost control through identification of needed immunizations and elimination of redundant immunizations. In our experience, there is a wide variation in immunization registry capabilities and some do not yet have the ability to handle a bi-directional query/response type of interface. That's why we offered the Alternate Test Approach.
Metric Description:
  1. 100 percent correct immunization records successfully posted to registry confirmed by logging into the HIE portal for visual validation.
  2. 100 percent correct immunization history records successfully received in EHR confirmed by visual validation.
  3. Successful Transmission to Public Health Registry, verifying error logs and spot checking the NCHIE portal.
 Standards Implemented: N/A
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 		Methods Use to Demonstrate Interoperability:
  1. TCP/IP
  2. Webservice
  3. HL7 Standard Code Set CVX -Vaccine AdministeredOID: 2.16.840.1.113883.12.292
  4. National Drug Code Directory OID: 2.16.840.1.113883.6.69
  5. SOAP-based standard for transport of immunization data
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
1
 Identify Trading Partner (TP) and coordinate with TP for transmitting immunization records using production data as described in this RWT plan
  • Has a state immunization registry that is enabled for bi-directional send/receive of immunization data.
  • Already has a functional bi-directional immunization interface or would like to implement one to their registry.
July, 2024
2
 Implement bi-directional immunization interface (if interface not already in place) Validate that immunization interface is functioning as expected July, 2024
3
 Production data is requested for all patients on the schedule. Once received, the data is structured and staged. If production, determine whether an actual patient or a test patient will be used.
4
 User Verifies the Immunization Received and Reconciles with EHR Data
  • Select a specific patient that may need immunization record updates
  • User navigates to staged data within the encounter
  • Provider reviews and confirms immunization records
5
 Create a new immunization record For one of the patients in step 4, record an immunization in Client EHR.
6
 Run immunization process to send all updated immuniation for all patients seen in a batch registry process. Record send functionality and verify logs for successful transmission
7
 Access registry to verify that immunization data was received. Verify immunization data was received in registry. July, 2024
8
 Access HIE Portal to verify that immunization data was received Verify immunization data was received in HIE Portal July, 2024
9
 Calculate and compile metrics. Using Log Data calculate the Metrics and presents to User Admin specifics statuses July, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023
Table of Contents Associated Certification Criteria:
§ 170.315(f)(5) Transmission to public health agencies-electronic case reporting
Measure Description: Create Electronic Case Reports (eCR) for transmission to public health agency based on a specific LOINC, ICD-10 and SNOMED codes entered in patient's encounter. eCR functionality looks up the patient's codes in the table and, if appropriate, sends an eCR message to the health agency. Justification: We chose to focus on aspects of this criterion that would provide the most patient care value in an actual setting. Public health registries can be very helpful to patient care, epidemiologists and government for identifying disease outbreaks, epidemics and even pandemics.
Metric Description:
  1. 100 percent of eCR messages successfully received and processed by public health agency based on either:
    • a) Logging into agency web site and validating, or
    • b) Using a report provided by agency
Standards Implemented: N/A
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 		Methods Use to Demonstrate Interoperability:
  1. Table of Trigger Events based on LOINC, ICD-10 and SNOMED codes.
  2. Use of USCDIv1 (Common Clinical Data Set)
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
1
 Identify Cloudcraft Client who either:
  • Has a public health agency that can receive eCR data
  • Already has a functional eCR interface or would like to implement one to their public health agency and the agency willing to share metrics of eCR messages successfully received.
eCR messages are successfully received and processed by public health agency. July, 2024
2
 Implement send-only public health interface (if interface not already in place).
  • Determine whether test or production interface will be used
  • If production, determine whether an actual patient or a test patient will be used.
 Functioning eCR interface to public health agency July, 2024
3
 Create a patient encounters.
  • Register patients or create new patients in Client EHR and create a current patient encounter
  • Enter one or more SNOMED Codes or ICD-10 diagnosis codes present in the Trigger Events table that lists reportable eCR diagnoses.
 Patient registered queued for interface
4
 Enter lab results through EHR or Lab interface. Make sure LOINC codes correspond to codes present in the Trigger Events table that lists reportable LOINC codes. Patient queued for interface
5
 Run eCR process to send to public health agency (assuming process in batch, rather than real-time). Messages sent to public health agency
6
 Query agency to verify that public health data was received for patients from step 3 and 4. Public health successfully processed by agency.
7
 Calculate and compile metrics. July, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023
Table of Contents Associated Certification Criteria:
§ 170.315(f)(7) Transmission to public health agencies-health care surveys
Measure Description: Create health care survey information for electronic transmission. Justification: We chose to focus on aspects of this criterion that would provide insight into patient experience and feedback. And, provide supervisory board oversight through analytics, providing customer feedback for each board meeting.
Metric Description: 100% of providers configuring a survey will have the ability to configure in the EHR.
100% of the survey questions shall be available for management analytics.
100% of all non-aggregated survey data shall be aggregated on a supervisory board portal, for board oversight.
Standards Implemented: N/A
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 		Methods Use to Demonstrate Interoperability: HL7 Standard for CDA
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
1
 Participation in National Hospital Medical Care Survey is voluntary.
  • Create master bank of question from which locations can select a subset for patient surveys based on location need.
  • Select one location who has opted to participate in NHAMCS to monitor for testing.
  • The identified testing location is able to select a subset of survey questions that are relevent to its activities.
  • Location confirms availability of survey option in patient portal.
 July, 2024
2
 For a period of time, monitor the system as the below steps(3-5) take place continuously. Many patient visits will occur during the period of time, generating a sufficient amount of data for calculating the metrics at the end of testing.
3
 Front desk notifies patients of survey availability
  • Patients are made aware of option to send feedback, positive or negative, and that their feedback will be routed accordingly.
  • One survey per patient visit is allowed to be submitted.
4
 Aggregate and anonymize survey responses. Responses are deidentified then compiled by location and provider.
5
 Survey responses are transmitted to CDC via bulk upload for review. Responses are converted to HL7 CDA documents for transmission. July, 2024
6
 Calculate and compile metrics. July, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/1/2023
Table of Contents Associated Certification Criteria:
§ 170.315(g)(7) Application access— patient selection
§ 170.315(g)(9) Application access— all data request
Measure Description: Enable a patient's to access their electronic health data through a Personal Health Record (PHR) app on their smartphone. They have had a healthcare encounter with a provider using an EHR that is integrated with the Dynamic FHIR API and Patient Portal modules of ConnectEHR. They would like to view the results from that encounter along with the rest of their electronic health record. Justification: CMS has a focus on empowering patients by providing them with an electronic copy of their health record. We agree that this is very important for patient satisfaction and improving population health in general.
Metric Description:
  1. Patient is able to retrieve FHIR API data from PHR app for 100 percent of encounters.
  2. In 100 percent of encounters from Step #1, PHR data matches data from EHR. This will be confirmed by visual validation of USCDIv1.
 Standards Implemented:
  • HL7 implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 1 - Introductory Material, Release 2.1, August 2015
  • HL7 implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 2 - Templates and Supporting Material, Release 2.1, August 2015
  • FHIR STU3
  • FHIR R4
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 		Methods Use to Demonstrate Interoperability:
  1. HTTPS via secure portal
  2. FHIR
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
1
 Identify Trading Partner (TP) and coordinate with TP tor providing patients timely access to their ePHI using production data as described in this RWT plan
  • Partner with PHR or identify existing PHR that can receive patient clinical data as described in this RWT plan.
  • Ensure that PHR has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API and Patient Portal modules of ConnectEHR.
August, 2024
2
 Patient A has encounter with care provider who uses EHR described above Encounter is created and visually confirmed August, 2024
3
 Provider captures USCDIv1 data elements in EHR USCDIv1 data elements are validated in the system
4
 Provider manually generates Care/Referral Summary C-CDA post-visit or ensures that the EHR generates one automatically C-CDA is confirmed for the specified patient
5
 Patient A uses Dynamic Patient Portal login to view clinical information
  • Patient Portal automatically sends email reminder that Patient A has a new clinical document available.
  • Email reminder has a URL/hyperlink to the patient portal
  • If patient hasn't already activated their portal account, portal account can be activated via Welcome Email or by an Administrator user
6
 Patient A uses portal login credentials to log into PHR app Specific patient ID and token are returned for authentication and data requests
7
 PHR app displays full set of data for all data categories
  • Dynamic FHIR API has transformed C-­CDA into FHIR resources.
  • PHR app consumes FHIR resources to populate EHR data
August, 2024
8
 PHR app returns full set of data for a given category PHR app will display and all data to be displayed for each data category
9
 PHR app returns data in a computable format using specified standards Data is confirmed to be in XML or JSON format
10
 PHR app returns full and accurate data for a specific date and specific date range
  • Step 10 is optional, if PHR app has the capability to filter by date range
  • Filtering data by a specffic date returns data accurately and as expected
  • Filtering data by a specffic date range returns data accurately and as expected
11
 Via visual inspection of PHR app, the data is verified to include Assessment, Plan of Treatment and Health concerns are specified as narrative text Visually validate Assessment Plan of Treatment and Health Concerns narrative text August, 2024
12
 Calculate and compile metrics. August, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023
Table of Contents Associated Certification Criteria:
§ 170.315(g)(10) Standardized API for patient and population services
Measure Description: Provide a standardized FHIR-based API that supports bulk data requests to provide patients, providers and niche specialty applications to consume patient data enabling improved interoperability, improved patient care and better overall population health. Justification: We chose to concentrate on the aspects of this criterion that would empower clinicians with flexibility in choosing new and innovative healthcare technology. Historically, it has been difficult for builders of niche applications to access necessary patient demographic and clinical data for smooth, seamless use of their applications. Likewise, clinicians have often felt forced to stick with cumbersome, difficult-to-use EHR technology because of the cost and complexity of migrating their patient data.
Metric Description:
  1. 100 percent of encounters where Patient is able to retrieve FHIR API data from PHR app.
  2. 100 percent of encounters from Step #1 where Patient’s PHR data matches data from EHR. This will be done by visual validation of the following FHIR resources:
    • Demographics
    • Problems
    • Medications
    • Allergies
  3. 100 percent of encounters where Provider is able to retrieve FHIR API data from app.
  4. 100 percent of encounters from Step #3 where data for randomly-selected patients as presented in app matches data from EHR. This will be done by visual validation of the following FHIR resources:
    • Demographics
    • Problems
    • Medications
    • Allergies
 Standards Implemented: (SVAP)
  • United States Core Data for Interoperability (USCDI), Version 1, July 2020 Errata
  • HL7 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, Version 4.0.1: R4, October 30, 2019, including Technical Correction #1, November 1, 2019
  • HL7 FHIR® US Core Implementation Guide STU 3.1.1, August 8, 2020
  • HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 1.0.0, November 13, 2018
  • HL7 FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1), August 22, 2019
  • OpenID Connect Core 1.0 Incorporating errata set 1, November 8, 2014, IBR approved for § 170.215(b)
Developer Info: CloudCraft, LLC
175 Eddice Taylor Road
Faison, NC 28341
Care Setting: Ambulatory 		Product Info: Product Name: CloudCraft Software
Product Version: 9
CHPL ID: 15.04.04.3071.Clou.09.01.1.221227 		Methods Use to Demonstrate Interoperability:
  1. USCore FHIR resources
  2. SMART Patient Launch
  3. SMART EHR Launch
  4. Backend Services Authorization
  5. Visual validation
 
Test Step Testing Procedure Expected Outcomes Key Milestone Date Key Milestone Outcomes Comment(s)
These Test Steps Cover Single Patient API Access
1
 Identify Trading Partner (TP) and coordinate with TP for providing patients timely access to their ePHI using production data as described in this RWT plan.
  • Partner with PHR or identify existing PHR that can receive patient clinical data as described in this RWT plan. We recommend MyLinks (https://www. mylinks.com/)
  • Ensure that PHR has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API and Patient Portal modules of ConnectEHR.
 May, 2024
2
 Patient A has encounter with care provider who uses EHR described above. Encounter is created and visually confirmed June, 2024
3
 Provider captures USCDIv1 data elements in EHR USCDIv1 data elements are validated in the system
4
 Provider manually generates Care/Referral Summary C-CDA post-visit or ensures that the EHR generates one automatically. C-CDA is confirmed for the specified patient
5
 Patient A uses Dynamic Patient Portal login to view clinical information
  • Patient Portal automatically sends email reminder that Patient A has a new clinical document available.
  • • Email reminder has a URL/hyperlink to the patient portal.
  • If patient hasn’t already activated their portal account, portal account can be activated via Welcome Email or by an Administrator user
6
 Patient A uses portal login credentials to log into PHR app Specific patient ID and token are returned for authentication and data requests
7
 PHR app displays full set of data for each data category
  • Dynamic FHIR API has transformed C- CDA into FHIR resources.
  • PHR app consumes FHIR resources to populate EHR data
 July, 2024
8
 PHR app returns full set of data for a given category PHR app will display and all data to be displayed for each data category
9
 PHR app returns data in a computable format using specified standards. Data is confirmed to be in XML or JSON format
10
 PHR app returns full and accurate data for a specific date and specific date range
  • Step 10 is optional, if PHR app has the capability to filter by date range
  • Filtering data by a specific date returns data accurately and as expected
  • Filtering data by a specific date range returns data accurately and as expected
11
 Via visual inspection, the data is verified to include Assessment, Plan of Treatment and Health concerns are specified as narrative text Visually validate Assessment, Plan of Treatment and Health Concerns narrative text
These Test Steps Cover Care Coordination via 3rd Part App
1a
 Identify Trading Partner (TP) and coordinate with TP for providing patients timely access to their ePHI using production data as described in this RWT plan.
  • Partner with a provider-centric app for improved patient care (e.g. growth charts, clinical decision support, patient charting).
  • Ensure that app has functionality to access the Dynamic FHIR API, as described here
  • Partner with EHR that is integrated with the Dynamic FHIR API module of ConnectEHR.
May, 2024
2a
 Provider logs into app and triggers FHIR API data retrieval
  • The app connects to the FHIR API server and pulls down the specific FHIR resources from the EHR
3a
 Provider views and validates data in app
  • Data is rendered correctly: Provider compares patient data in app to patient data in EHR and notes any discrepancies.
June, 2024
These Test Steps Cover Bulk Data for Care Coordination
1b
 Identify Trading Partner (TP) and coordinate with TP for providing patients timely access to their ePHI using production data as described in this RWT plan.
  • Partner with a provider-centric app that requires periodic bulk data downloads
  • Ensure that app has functionality to access the Dynamic FHIR API, as described here.
  • Partner with EHR that is integrated with the Dynamic FHIR API module of ConnectEHR.
May, 2024
2b
 Provider logs into app and views patient data
  • The app connects to the FHIR API server and pulls down the specific FHIR resources from the EHR
3b
 Provider validates data in app
  • Data is rendered correctly: Provider compares patient data in app to patient data in EHR and notes any discrepancies.
June, 2024
12
 Calculate and compile metrics August, 2024
Attestation This Real World Testing plan is 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 Real World Testing requirements.

Authorized Representative Name:
Terry Lee

Authorized Representative Email:
tlee@naiacorp.net

Authorized Representative Phone:
205.369.0854

Authorized Representative Signature:

Date:
11/15/2023