• Developer Name : MedAZ.Net, LLC
• Product Name : Med A-Z
• Version : 202001
• Certification number : 15.05.05.3150.MDAZ.01.00.1.230616
• Plan ID : 20241114maz
• Developer Real World Testing Plan Page URL: https://www.medaz.net/RWT.html
• Certified Criteria:

  170.315 (b)(3) Electronic prescribing
  170.315 (b)(10) Electronic health information export
  170.315 (c)(1) Clinical Quality Measures – Record and Export
  170.315 (c)(2) Clinical Quality Measures – Import and Calculate
  170.315 (c)(3) Clinical Quality Measures – Report
  170.315 (f)(1) Transmission to immunization registries
  170.315 (f)(2) Transmission to PHA – syndromic surveillance
  170.315 (g)(7) Application access – patient selection
  170.315 (g)(10) Standardized API for patient and population services
  

This plan was formulated to collect a holistic image of how the system is used over about one calendar year. Due to a smaller than expected data volume and sample size, we will be largely carrying forward last year’s testing methodology.

Med A-Z has contacted customers and is setting up mirrored production environments. Data from the end of the previous business day will be used for test scenario evaluations, conducted by internal testing staff. This approach will enable simulation of actual volumes specifically for low-usage scenarios within the mirrored environment.

Over the course of the year, we intend to count the number of gross successes and failures, as defined in the measures section below, to establish baseline reliability scores (successes/ (successes + failures)) to each measure. The reliability score will be on a scale of 0 to 1. At each quarterly review, the running reliability scores will be tabulated, and systems with lower scores will be reviewed and revised. Using this framework will allow us to view all data trends globally and target any potential weaknesses in a systematic manner.

Measurement Methodology:

Metric Name:

Measures:

Associated Criteria:170.315 (b)(3) Electronic Prescribing

• NewRx - New prescriptions
• RxChangeRequest and RxChangeResponse - Requests and responses to change prescriptions
• CancelRx and CancelRxResponse - Requests and responses to cancel prescriptions
• RxRenewalRequest and RxRenewalResponse - Requests and responses to renew prescriptions
• RxFill - Responses with fill status notifications, when fill status is requested by client
• RxHistoryRequest and RxHistoryResponse - Requests and responses to medication histories

1. Gross Successes – The count of Surescripts confirmation or waiting responses in server logs.
2. Gross Failures – The count of error messages in the server logs

Associated Criteria:170.315 (b)(10) Electronic Health Information Export

There are two workflows to export EHI. They are:

• Single patient EHI export: An administrator can export EHI for a single patient.
• Patient population EHI export. An administrator can select any of the information stored in authorized patients’ records to use as criteria for a population and then export the population of patients who meet those criteria.

We recognize that not all customers use the full functionality of the certification criteria made available in the EHR. If Med A-Z is unable to identify customers that use the (b)(10) criterion as defined in the regulation, then testing will be done using the mirrored client databases and reflected in the results report.

1. Gross Successes – The count of “Export files created” success messages in server logs.
2. Gross Failures – The count of “file creation failure” error messages in the server logs

Associated Criteria:170.315 (c)(1) Clinical Quality Measures – Record and Export

There are two steps for recording and exporting CQMs in Med A-Z:

1. Record. Providers discreetly document clinical data elements as part of their existing clinical documentation. In some cases, data elements are automatically mapped to discrete standard terminologies, and in other cases, organizations have the flexibility to map their workflows to standard terminology.
2. Export. Users generate and export documents containing data elements that are discretely mapped to standard terminologies in QRDA 1. Administrative users can generate documents for all eligible patients or for individually identified patients.

1. Gross Successes – The manual count of successful QRDA1 file creation.
2. Gross Failures – The manual count of QRDA1 file rejections

Associated Criteria:170.315 (c)(2) Clinical Quality Measures – Import and Calculate

There are two steps for importing and calculating CQMs in Med A-Z:

1. Import. Users can import quality reporting patient data files in QRDA 1 format to use for subsequent quality reporting. Users import externally created files through an incoming interface, permitting the organization to report on data from within their own system as well as from external sources.
2. Calculate. Both imported data and data entered in Med A-Z are used in measure calculation when evaluating patient outcomes.

1. Gross Successes – The manual count of times where data is read and imported correctly into Med A-Z System.
2. Gross Failures – The manual count of “file read failure” error messages in the server logs.

Associated Criteria: 170.315 (c)(3) Clinical Quality Measures – Report

Eligible Clinician QRDA Category III Documents, which are aggregated documents, are required to be generated and exported. Administrative users can generate documents for all eligible patients or for individually identified patients.

Exported data files support the electronic clinical quality data submission requirements specified under CMS rules. Organizations upload these files to CMS web portals to report on quality programs.

1. Gross Successes – The manual count of successful file submissions to CMS.
2. Gross Failures – The manual count of QRDA3 file rejections

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

Med A-Z provides bi-directional interfaces (VXU/QBP) for transmitting and receiving historical immunization information to immunization registries, where available. The scenarios include:

• Administer: When a provider administers a new immunization, an electronic message (VXU) is automatically sent to any immunization registry with which the organization has a connection.
• Document historical administration: An electronic message is automatically sent to immunization registries configured to receive information on historical administrations.

1. Gross Successes – The count of “transmission successful” success messages in server logs.
2. Gross Failures – The count of “transmission failure” error messages in the server logs

Associated Criteria: 170.315 (f)(2) Transmission to Public Health Agencies – Syndromic Surveillance

If the public health agency supports reporting from ambulatory settings, the ADT Syndromic Surveillance information is automatically sent for qualified patients.

1. Gross Successes – The manual count of confirmation messages from CDC.
2. Gross Failures – The manual count of non-responses from CDC.

Associated Criteria: 170.315 (g)(7) Application Access – Patient Selection

Med A-Z facilitates the provision of patient identifiers and USCDI data through APIs:

1. Authorization. Patients can authorize third-party applications to access their health information using APIs. The app requests information for the patient, and the system identifies the patient and responds with a unique patient identifier, an access token, and a refresh token that the app can use to access the patient’s information.
2. Data retrieval. After a patient grants access to a third-party application, the app can access and retrieve the patient’s data within the USCDI using standard APIs.
3. Revocation. Patients can revoke an authorized app’s access by removing app access within the patient portal.
4. Data sharing for providers and backend systems. Med A-Z’s FHIR and OAuth 2.0 APIs enable several different use cases for securely sharing USCDI data with third-party applications. Sample use cases are described below.
   • SMART on FHIR EHR launch. Providers use third-party apps with contextual EHR integration and FHIR APIs using the SMART on FHIR EHR Launch workflow. This launches a third-party app from within the software, making it available for the provider to use without needing to re-enter credentials. The app can then use FHIR APIs to query for data as necessary for the provider’s workflows. This allows providers to use FHIR applications that are integrated directly into their workflows.
   • Bulk FHIR APIs. Third-party systems can access USCDI data for a population of patients using Bulk FHIR APIs.

1. Gross Successes – The count of “Connection Successful” success messages in server logs.
2. Gross Failures – The count of “Connection Failure” error messages in the server logs.

Associated Criteria: 170.315 (g)(10) Standardized API for Patient and Population Services

Med A-Z facilitates the provision of patient identifiers and USCDI data through APIs:

1. Authorization. Patients can authorize third-party applications to access their health information using APIs. The app requests information for the patient, and the system identifies the patient and responds with a unique patient identifier, an access token, and a refresh token that the app can use to access the patient’s information.
2. Data retrieval. After a patient grants access to a third-party application, the app can access and retrieve the patient’s data within the USCDI using standard APIs.
3. Revocation. Patients can revoke an authorized app’s access by removing app access within the patient portal.
4. Data sharing for providers and backend systems. Med A-Z’s FHIR and OAuth 2.0 APIs enable several different use cases for securely sharing USCDI data with third-party applications. Sample use cases are described below.
   • SMART on FHIR EHR launch. Providers use third-party apps with contextual EHR integration and FHIR APIs using the SMART on FHIR EHR Launch workflow. This launches a third-party app from within the software, making it available for the provider to use without needing to re-enter credentials. The app can then use FHIR APIs to query for data as necessary for the provider’s workflows. This allows providers to use FHIR applications that are integrated directly into their workflows.
   • Bulk FHIR APIs. Third-party systems can access USCDI data for a population of patients using Bulk FHIR APIs.

1. Gross Successes – The count of “Connection Successful” success messages in server logs.
2. Gross Failures – The count of “Connection Failure” error messages in the server logs.