§ 170.315 - ONC certification criteria for Health IT.

§ 170.315 2015 Edition health IT ONC certification criteria .

Cross Reference

Link to an amendment published at 89 FR 1429, Jan. 9, 2024.

Cross Reference

The effective date of this amendment was corrected to read Mar. 11, 2024, at 89 FR 8548, Feb. 8, 2024.

Cross Reference

Link to a correction published at 89 FR 8548, Feb. 8, 2024.

Cross Reference

Link to a correction published at 89 FR 16470, Mar. 7, 2024.

The

for Health IT.

The Secretary adopts the following certification criteria for health IT. Health IT must be able to electronically perform the following capabilities in accordance with all applicable standards and implementation specifications adopted in this part: . For all criteria in this section, a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, shall update the Health IT Module and shall provide such update to their customers in accordance with the dates identified for each revised certification criterion and for each applicable standard in 45 CFR part 170 subpart B.

(a) Clinical —

(1) Computerized provider order entry—medications.

(i) Enable a user to record, change, and access medication orders.

(ii) Optional. Include a “reason for order” field.

(2) Computerized provider order entry—laboratory.

(i) Enable a user to record, change, and access laboratory orders.

(ii) Optional. Include a “reason for order” field.

(3) Computerized provider order entry—diagnostic imaging.

(i) Enable a user to record, change, and access diagnostic imaging orders.

(ii) Optional. Include a “reason for order” field.

(4) Drug-drug, drug-allergy interaction checks for CPOE —

(i) Interventions. Before a medication order is completed and acted upon during computerized provider order entry (CPOE), interventions must automatically indicate to a user drug-drug and drug-allergy contraindications based on a patient's medication list and medication allergy list.

(ii) Adjustments.

(A) Enable the severity level of interventions provided for drug-drug interaction checks to be adjusted.

(B) Limit the ability to adjust severity levels in at least one of these two ways:

(1) To a specific set of identified users.

(2) As a system administrative function.

(5) DemographicsPatient demographics and observations.

(i) Enable a user to record, change, and access patient demographic and observations data including race, ethnicity, preferred language, sex, sex parameter for clinical use, sexual orientation, gender identity, name to use, pronouns, and date of birth.

(A) Race and ethnicity.

(1) Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(23) and whether a patient declines to specify race.

(2) Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(23) and whether a patient declines to specify ethnicity.

(3) Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this section to the categories in the standard specified in § 170.207(f)(1).

(B) Preferred language. Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.

(C) Sex. Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2).

(D) Sexual orientation. Enable sexual orientation to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(1) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation.

(E) Gender identity. Enable gender identity to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(2) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify gender identity.

(F) Sex Parameter for Clinical Use. Enable at least one sex parameter for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026.

(G) Name to Use. Enable at least one preferred name to use to be recorded. Conformance with this paragraph is required by January 1, 2026.

(H) Pronouns. Enable at least one pronoun to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(4). Conformance with this paragraph is required by January 1, 2026.

(ii) Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.

(6)–(8) [Reserved]

(9) Clinical decision support (CDS) —

(i) CDS intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.

(ii) CDS configuration.

(A) Enable interventions and reference resources specified in paragraphs (a)(9)(iii) and (iv) of this section to be configured by a limited set of identified users (e.g., system administrator) based on a user's role.

(B) Enable interventions:

(1) Based on the following data:

(i) Problem list;

(ii) Medication list;

(iii) Allergy and intolerance list;

(iv) At least one demographic specified in paragraph (a)(5)(i) of this section;

(v) Laboratory tests; and

(vi) Vital signs.

(2) When a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care/referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.

(iii) Evidence-based decision support interventions. Enable a limited set of identified users to select (i.e., activate) electronic CDS interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the data referenced in paragraphs (a)(9)(ii)(B)(1)(i) through (vi) of this section.

(iv) Linked referential CDS.

(A) Identify for a user diagnostic and therapeutic reference information in accordance at least one of the following standards and implementation specifications:

(1) The standard and implementation specifications specified in § 170.204(b)(3).

(2) The standard and implementation specifications specified in § 170.204(b)(4).

(B) For paragraph (a)(9)(iv)(A) of this section, technology must be able to identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the data referenced in paragraphs (a)(9)(ii)(B)(1)(i), (ii), and (iv) of this section.

(v) Source attributes. Enable a user to review the attributes as indicated for all CDS resources:

(A) For evidence-based decision support interventions under paragraph (a)(9)(iii) of this section:

(1) Bibliographic citation of the intervention (clinical research/guideline);

(2) Developer of the intervention (translation from clinical research/guideline);

(3) Funding source of the intervention development technical implementation; and

(4) Release and, if applicable, revision date(s) of the intervention or reference source.

(B) For linked referential CDS in paragraph (a)(9)(iv) of this section and drug-drug, drug-allergy interaction checks in paragraph (a)(4) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).

(vi) Expiration of criterion. The adoption of this criterion for purposes of the ONC Health IT Certification Program expires on January 1, 2025.

(10) Drug-formulary and preferred drug list checks. The requirements specified in one of the following paragraphs (that is, paragraphs (a)(10)(i) and (a)(10)(ii) of this section) must be met to satisfy this certification criterion:

(i) Drug formulary checks. Automatically check whether a drug formulary exists for a given patient and medication.

(ii) Preferred drug list checks. Automatically check whether a preferred drug list exists for a given patient and medication.

(11) [Reserved]

(12) Family health history. Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(41).

(13) Patient-specific education resources.

(i) Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:

(A) The standard and implementation specifications specified in § 170.204(b)(3).

(B) The standard and implementation specifications specified in § 170.204(b)(4).

(ii) Optional. Request that patient-specific education resources be identified in accordance with the standard in § 170.207(g)(2).

(14) Implantable device list.

(i) Record Unique Device Identifiers associated with a patient's Implantable Devices.

(ii) Parse the following identifiers from a Unique Device Identifier:

(A) Device Identifier; and

(B) The following identifiers that compose the Production Identifier:

(1) The lot or batch within which a device was manufactured;

(2) The serial number of a specific device;

(3) The expiration date of a specific device;

(4) The date a specific device was manufactured; and

(5) For an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).

(iii) Obtain and associate with each Unique Device Identifier:

(A) A description of the implantable device referenced by at least one of the following:

(1) The “GMDN PT Name” attribute associated with the Device Identifier in the Global Unique Device Identification Database.

(2) The “SNOMED CT® Description” mapped to the attribute referenced in in paragraph (a)(14)(iii)(A)(1) of this section.

(B) The following Global Unique Device Identification Database attributes:

(1) “Brand Name”;

(2) “Version or Model”;

(3) “Company Name”;

(4) “What MRI safety information does the labeling contain?”; and

(5) “Device required to be labeled as containing natural rubber latex or dry natural rubber (21 CFR 801.437).”

(iv) Display to a user an implantable device list consisting of:

(A) The active Unique Device Identifiers recorded for the patient;

(B) For each active Unique Device Identifier recorded for a patient, the description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section; and

(C) A method to access all Unique Device Identifiers recorded for a patient.

(v) For each Unique Device Identifier recorded for a patient, enable a user to access:

(A) The Unique Device Identifier;

(B) The description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section;

(C) The identifiers associated with the Unique Device Identifier, as specified by paragraph (a)(14)(ii) of this section; and

(D) The attributes associated with the Unique Device Identifier, as specified by paragraph (a)(14)(iii)(B) of this section.

(vi) Enable a user to change the status of a Unique Device Identifier recorded for a patient.

(15) Social, psychological, and behavioral data. Enable a user to record, change, and access the following patient social, psychological, and behavioral data:

(i) Financial resource strain. Enable financial resource strain to be recorded in accordance with the standard specified in § 170.207(p)(1) and whether a patient declines to specify financial resource strain.

(ii) Education. Enable education to be recorded in accordance with the standard specified in § 170.207(p)(2) and whether a patient declines to specify education.

(iii) Stress. Enable stress to be recorded in accordance with the standard specified in § 170.207(p)(3) and whether a patient declines to specify stress.

(iv) Depression. Enable depression to be recorded in accordance with the standard specified in § 170.207(p)(4) and whether a patient declines to specify depression.

(v) Physical activity. Enable physical activity to be recorded in accordance with the standard specified in § 170.207(p)(5) and whether a patient declines to specify physical activity.

(vi) Alcohol use. Enable alcohol use to be recorded in accordance with the standard specified in § 170.207(p)(6) and whether a patient declines to specify alcohol use.

(vii) Social connection and isolation. Enable social connection and isolation to be recorded in accordance the standard specified in § 170.207(p)(7) and whether a patient declines to specify social connection and isolation.

(viii) Exposure to violence (intimate partner violence). Enable exposure to violence (intimate partner violence) to be recorded in accordance with the standard specified in § 170.207(p)(8) and whether a patient declines to specify exposure to violence (intimate partner violence).

(b) Care coordination —

(1) Transitions of care —

(i) Send and receive via edge protocol.

(A) Send transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in § 170.202(a)(2); and

(B) Receive transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) from a service that has implemented the standard specified in § 170.202(a)(2).

(C) XDM processing. Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in § 170.205(p)(1) when the technology is also being certified using an SMTP-based edge protocol.

(ii) Validate and display —

(A) Validate C–CDA conformance—system performance. Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in § 170.205(a)(3), (4), and (5) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:

(1) Parse each of the document types.

(2) Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3), (4), and (5).

(3) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3), (4), and (5).

(4) Correctly interpret empty sections and null combinations.

(5) Record errors encountered and allow a user through at least one of the following ways to:

(i) Be notified of the errors produced.

(ii) Review the errors produced.

(B) Display. Display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in § 170.205(a)(3), (4), and (5).

(C) Display section views. Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in § 170.205(a)(3), (4), and (5) in a manner that enables the user to:

(1) Directly display only the data within a particular section;

(2) Set a preference for the display order of specific sections; and

(3) Set the initial quantity of sections to be displayed.

(iii) Create. Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(3), (4), and (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:

(A)

(1) The data classes expressed in the standard standards in § 170.213 and in accordance with § 170.205(a)(4), (5), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section for the time period up to and including December 31, 2025, or

(2) The Common Clinical Data Set in data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4), (6), and paragraph paragraphs (b)(1)(iii)(A)(3)(i) through (iviii) of this section for the period before December 31, 2022, and

(3) The following data classes:

(i) Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).

(ii) Goals. In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).

(iii) Health concerns. In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).

(iv) Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).

(B) Encounter diagnoses. Formatted according to at least one of the following standards:

(1) The standard specified in § 170.207(i).

(2) At a minimum, the version of the standard specified in § 170.207(a)(41).

(C) Cognitive status.

(D) Functional status.

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(F) Inpatient setting only. Discharge instructions.

(G) Patient matching data. First name, last name, previous name, middle name (including middle initial), suffix, date of birth, current address, phone number, and sex. The following constraints apply:

(1) Date of birth constraint.

(i) The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.

(ii) Optional. When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.

(2) Phone number constraint. Represent phone number (home, business, cell) in accordance with the standards adopted in § 170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.

(3) Sex constraint.Constraint: Represent sex in accordance with the standard adopted in § 170.207(n)(1) up to and including December 31, 2025; or with the standard adopted in § 170.207(n)(2).

(2) Clinical information reconciliation and incorporation —

(i) General requirements. Paragraphs (b)(2)(ii) and (iii) of this section must be completed based on the receipt of a transition of care/referral summary formatted in accordance with the standards adopted in § 170.205(a)(3) through (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates on and after , for time period up to and including December 31, 2022.

(

2025; or in accordance with the standards adopted in § 170.205(a)(3), (4), (6).

(ii) Correct patient. Upon receipt of a transition of care/referral summary formatted according to the standards adopted § 170.205(a)(3) through (5) for the period up to and including December 31, 2025; or according to the standards adopted § 170.205(a)(3), (4), and (6), technology must be able to demonstrate that the transition of care/referral summary received can be properly matched to the correct patient.

(iii) Reconciliation. Enable a user to reconcile the data that represent a patient's active medication list, allergies and intolerance list, and problem list as follows. For each list type:

(A) Simultaneously display (i.e., in a single view) the data from at least two sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date.

(B) Enable a user to create a single reconciled list of each of the following: Medications; Allergies and Intolerances; and problems.

(C) Enable a user to review and validate the accuracy of a final set of data.

(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standard(s) on and after December 31, 2022standards:

(1) Medications. At a minimum, the version of the standard specified in § 170.213;

(2) Allergies and intolerance. At a minimum, the version of the standard specified in § 170.213; and

(3) Problems. At a minimum, the version of the standard specified in § 170.213.

(iv) System verification. Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in § 170.205(a)(5) on and after December 31, 2022.

(iv) System verification. Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in paragraph (a)(5) of this section for the time period up to and including December 31, 2025; or according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in paragraph (a)(6) of this section.

(3) Electronic prescribing.

(i) For technology certified prior to June 30, 2020, subject to the real world testing provisions at § 170.405(b)(5),

(A) Enable a user to perform the following prescription-related electronic transactions in accordance with, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:

(1) Create new prescriptions (NEWRX).

(2) Change prescriptions (RXCHG, CHGRES).

(3) Cancel prescriptions (CANRX, CANRES).

(4) Refill prescriptions (REFREQ, REFRES).

(5) Receive fill status notifications (RXFILL).

(6) Request and receive medication history information (RXHREQ, RXHRES).

(B) For each transaction listed in paragraph (b)(3)(i)(A) of this section, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements in the DRU Segment.

(C) Optional: For each transaction listed in paragraph (b)(3)(i)(A) of this section, the technology must be able to receive and transmit the reason for prescription using the indication elements in the SIG Segment.

(D) Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).

(E) Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.

(ii) For technology certified subsequent to June 30, 2020:

(A) Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(31) as follows:

(1) Create new prescriptions (NewRx).

(2) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).

(3) Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).

(4) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).

(5) Receive fill status notifications (RxFill).

(6) Request and receive medication history (RxHistoryRequest, RxHistoryResponse).

(7) Relay acceptance of a transaction back to the sender (Status).

(8) Respond that there was a problem with the transaction (Error).

(9) Respond that a transaction requesting a return receipt has been received (Verify).

(B) Optionally, enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:

(1) Create and respond to new prescriptions (NewRxRequest, NewRxResponseDenied).

(2) Send fill status notifications (RxFillIndicatorChange).

(3) Ask the Mailbox if there are any transactions (GetMessage).

(4) Request to send an additional supply of medication (Resupply).

(5) Communicate drug administration events (DrugAdministration).

(6) Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm).

(7) Recertify the continued administration of a medication order (Recertification).

(8) Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).

(9) Electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse).

(C) For the following prescription-related transactions, the technology must be able to receive and transmit the reason for prescription using the diagnosis elements: <Diagnosis> <Primary> or <Secondary>:

(1) Required transactions:

(i) Create new prescriptions (NewRx).

(ii) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).

(iii) Cancel prescriptions (CancelRx).

(iv) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).

(v) Receive fill status notifications (RxFill).

(vi) Receive medication history (RxHistoryResponse).

(2) Optional transactions:

(i) Request to send an additional supply of medication (Resupply)

(ii) Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse)

(iii) Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).

(iv) Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse).

(D) Optional: For each transaction listed in paragraph (b)(3)(ii)(C) of this section, the technology must be able to receive and transmit reason for prescription using the <IndicationforUse> element in the SIG segment.

(E) Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).

(F) Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.

(4)–(5) [Reserved]

(6) Data export —

(i) General requirements for export summary configuration.

(A) Enable a user to set the configuration options specified in paragraphs (b)(6)(iii) and (iv) of this section when creating an export summary as well as a set of export summaries for patients whose information is stored in the technology. A user must be able to execute these capabilities at any time the user chooses and without subsequent developer assistance to operate.

(B) Limit the ability of users who can create export summaries in at least one of these two ways:

(1) To a specific set of identified users.

(2) As a system administrative function.

(ii) Creation. Enable a user to create export summaries formatted in accordance with the standard specified in § 170.205(a)(4) using the Continuity of Care Document document template that includes, at a minimum:

(A) The Common Clinical Data Set.

(B) Encounter diagnoses. Formatted according to at least one of the following standards:

(1) The standard specified in § 170.207(i).

(2) At a minimum, the version of the standard specified in § 170.207(a)(41).

(C) Cognitive status.

(D) Functional status.

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(F) Inpatient setting only. Discharge instructions.

(iii) Timeframe configuration.

(A) Enable a user to set the date and time period within which data would be used to create the export summaries. This must include the ability to enter in a start and end date and time range.

(B) Consistent with the date and time period specified in paragraph (b)(6)(iii)(A) of this section, enable a user to do each of the following:

(1) Create export summaries in real-time;

(2) Create export summaries based on a relative date and time (e.g., the first of every month at 1:00 a.m.); and

(3) Create export summaries based on a specific date and time (e.g., on 10/24/2015 at 1:00 a.m.).

(iv) Location configuration. Enable a user to set the storage location to which the export summary or export summaries are intended to be saved.

(7) Security tags—summary of care—send. Enable a user to create a summary record formatted in accordance with the standard adopted in § 170.205(a)(4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1) at the:

(i) Document, section, and entry (data element) level; or

(ii) Document level for the period before December 31, 2022.

(8) Security tags—summary of care—receive.

(i) Enable a user to receive a summary record that is formatted in accordance with the standard adopted in § 170.205(a)(4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1) at the:

(A) Document, section, and entry (data element) level; or

(B) Document level for the period before December 31, 2022; and

(ii) Preserve privacy markings to ensure fidelity to the tagging based on consent and with respect to sharing and re-disclosure restrictions.

(9) Care plan. Enable a user to record, change, access, create, and receive care plan information in accordance with:

(i) The Care Plan document template, including the Health Status Evaluations and Outcomes Section and Interventions Section (V2), in the standard specified in § 170.205(a)(4); and

(ii) The standard in § 170.205(a)(5) on and after for the time period up to and including December 31, 20222025; or § 170.205(a)(6).

(10) Electronic Health Information export —

(i) Single patient electronic health information export.

(A) Enable a user to timely create an export file(s) with all of a single patient's electronic health information that can be stored at the time of certification by the product, of which the Health IT Module is a part.

(B) A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.

(C) Limit the ability of users who can create export file(s) in at least one of these two ways:

(1) To a specific set of identified users

(2) As a system administrative function.

(D) The export file(s) created must be electronic and in a computable format.

(E) The publicly accessible hyperlink of the export's format must be included with the exported file(s).

(ii) Patient population electronic health information export. Create an export of all the electronic health information that can be stored at the time of certification by the product, of which the Health IT Module is a part.

(A) The export created must be electronic and in a computable format.

(B) The publicly accessible hyperlink of the export's format must be included with the exported file(s).

(iii) Documentation. The export format(s) used to support paragraphs (b)(10)(i) and (ii) of this section must be kept up-to-date.

(11) Decision support interventions—

(i) Decision support intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.

(ii) Decision support configuration.

(A) Enable interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.

(B) Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.

(C) Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.

(iii) Decision support intervention selection. Enable a limited set of identified users to select (i.e., activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:

(A) Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213:

(1) Problems;

(2) Medications;

(3) Allergies and Intolerances;

(4) At least one demographic specified in paragraph (a)(5)(i) of this section;

(5) Laboratory;

(6) Vital Signs;

(7) Unique Device Identifier(s) for a Patient's Implantable Device(s); and

(8) Procedures.

(B) Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213.

(iv) Source attributes. Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.

(A) For evidence-based decision support interventions:

(1) Bibliographic citation of the intervention (clinical research or guideline);

(2) Developer of the intervention (translation from clinical research or guideline);

(3) Funding source of the technical implementation for the intervention(s) development;

(4) Release and, if applicable, revision dates of the intervention or reference source;

(5) Use of race as expressed in the standards in § 170.213;

(6) Use of ethnicity as expressed in the standards in § 170.213;

(7) Use of language as expressed in the standards in § 170.213;

(8) Use of sexual orientation as expressed in the standards in § 170.213;

(9) Use of gender identity as expressed in the standards in § 170.213;

(10) Use of sex as expressed in the standards in § 170.213;

(11) Use of date of birth as expressed in the standards in § 170.213;

(12) Use of social determinants of health data as expressed in the standards in § 170.213; and

(13) Use of health status assessments data as expressed in the standards in § 170.213.

(B) For Predictive Decision Support Interventions:

(1) Details and output of the intervention, including:

(i) Name and contact information for the intervention developer;

(ii) Funding source of the technical implementation for the intervention(s) development;

(iii) Description of value that the intervention produces as an output; and

(iv) Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.

(2) Purpose of the intervention, including:

(i) Intended use of the intervention;

(ii) Intended patient population(s) for the intervention's use;

(iii) Intended user(s); and

(iv) Intended decision-making role for which the intervention was designed to be used/for (e.g., informs, augments, replaces clinical management).

(3) Cautioned out-of-scope use of the intervention, including:

(i) Description of tasks, situations, or populations where a user is cautioned against applying the intervention; and

(ii) Known risks, inappropriate settings, inappropriate uses, or known limitations.

(4) Intervention development details and input features, including at a minimum:

(i) Exclusion and inclusion criteria that influenced the training data set;

(ii) Use of variables in paragraphs (b)(11)(iv)(A)(5) through (13) of this section as input features;

(iii) Description of demographic representativeness according to variables in paragraphs (b)(11)(iv)(A)(5) through (13) of this section including, at a minimum, those used as input features in the intervention;

(iv) Description of relevance of training data to intended deployed setting; and

(5) Process used to ensure fairness in development of the intervention, including:

(i) Description of the approach the intervention developer has taken to ensure that the intervention's output is fair; and

(ii) Description of approaches to manage, reduce, or eliminate bias.

(6) External validation process, including:

(i) Description of the data source, clinical setting, or environment where an intervention's validity and fairness has been assessed, other than the source of training and testing data

(ii) Party that conducted the external testing;

(iii) Description of demographic representativeness of external data according to variables in paragraph (b)(11)(iv)(A)(5)–(13) including, at a minimum, those used as input features in the intervention; and

(iv) Description of external validation process.

(7) Quantitative measures of performance, including:

(i) Validity of intervention in test data derived from the same source as the initial training data;

(ii) Fairness of intervention in test data derived from the same source as the initial training data;

(iii) Validity of intervention in data external to or from a different source than the initial training data;

(iv) Fairness of intervention in data external to or from a different source than the initial training data;

(v) References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes;

(8) Ongoing maintenance of intervention implementation and use, including:

(i) Description of process and frequency by which the intervention's validity is monitored over time;

(ii) Validity of intervention in local data;

(iii) Description of the process and frequency by which the intervention's fairness is monitored over time;

(iv) Fairness of intervention in local data; and

(9) Update and continued validation or fairness assessment schedule, including:

(i) Description of process and frequency by which the intervention is updated; and

(ii) Description of frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified.

(v) Source attribute access and modification —

(A) Access.

(1) For evidence-based decision support interventions and Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section.

(2) For Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9) of this section.

(B) Modify.

(1) For evidence-based decision support interventions and Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.

(2) For Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in paragraph (b)(11)(iv)(B) of this section.

(vi) Intervention risk management. Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.

(A) Risk analysis. The Predictive Decision Support Intervention(s) must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.

(B) Risk mitigation. The Predictive Decision Support Intervention (s) must be subject to practices to mitigate risks, identified in accordance with paragraph (b)(11)(vi)(A) of this section; and

(C) Governance. The Predictive Decision Support Intervention(s) must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used.

(c) Clinical quality measures —

(1) Clinical quality measures—record and export —

(i) Record. For each and every CQM for which the technology is presented for certification, the technology must be able to record all of the data that would be necessary to calculate each CQM. Data required for CQM exclusions or exceptions must be codified entries, which may include specific terms as defined by each CQM, or may include codified expressions of “patient reason,” “system reason,” or “medical reason.”

(ii) Export. A user must be able to export a data file at any time the user chooses and without subsequent developer assistance to operate:

(A) Formatted in accordance with the standard specified in § 170.205(h)(2);

(B) Ranging from one to multiple patients; and

(C) That includes all of the data captured for each and every CQM to which technology was certified under paragraph (c)(1)(i) of this section.

(2) Clinical quality measures—import and calculate —

(i) Import. Enable a user to import a data file in accordance with the standard specified in § 170.205(h)(2) for one or multiple patients and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.

(ii) Calculate each and every clinical quality measure for which it is presented for certification.

(3) Clinical quality measures—report. Enable a user to electronically create a data file for transmission of clinical quality measurement data:

(i) In accordance with the applicable implementation specifications specified by the CMS implementation guides for Quality Reporting Document Architecture (QRDA), category I, for inpatient measures in § 170.205(h)(3) and CMS implementation guide for QRDA, category III for ambulatory measures in § 170.205 (k)(3); or

(ii) In accordance with the standards specified in § 170.205(h)(2) and § 170.205(k)(1) and (2) for the period before December 31, 2022.

(4) Clinical quality measures—filter.

(i) Record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.

(ii) Filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in paragraph (c)(4)(iii) of this section and be able to:

(A) Create a data file of the filtered data in accordance with the standards adopted in § 170.205(h)(2) and § 170.205(k)(1) and (2); and

(B) Display the filtered data results in human readable format.

(iii) Data.

(A) Taxpayer Identification Number.

(B) National Provider Identifier.

(C) Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(12).

(D) Practice site address.

(E) Patient insurance in accordance with the standard specified in § 170.207(s)(12).

(F) Patient age.

(G) Patient sex in accordance with the version of the standard specified in § 170.207(n)(12).

(H) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(23).

(I) Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(41).

(d) Privacy and security —

(1) Authentication, access control, and authorization.

(i) Verify against a unique identifier(s) (e.g., username or number) that a user seeking access to electronic health information is the one claimed; and

(ii) Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the technology.

(2) Auditable events and tamper-resistance —

(i) Record actions. Technology must be able to:

(A) Record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1);

(B) Record the audit log status (enabled or disabled) in accordance with the standard specified in § 170.210(e)(2) unless it cannot be disabled by any user; and

(C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by technology in accordance with the standard specified in § 170.210(e)(3) unless the technology prevents electronic health information from being locally stored on end-user devices (see paragraph (d)(7) of this section).

(ii) Default setting. Technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) and (d)(2)(i)(C) of this section.

(iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that technology permits to be disabled, the ability to do so must be restricted to a limited set of users.

(iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the technology.

(v) Detection. Technology must be able to detect whether the audit log has been altered.

(3) Audit report(s). Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data specified in the standards in § 170.210(e).

(4) Amendments. Enable a user to select the record affected by a patient's request for amendment and perform the capabilities specified in paragraph (d)(4)(i) or (ii) of this section.

(i) Accepted amendment. For an accepted amendment, append the amendment to the affected record or include a link that indicates the amendment's location.

(ii) Denied amendment. For a denied amendment, at a minimum, append the request and denial of the request in at least one of the following ways:

(A) To the affected record.

(B) Include a link that indicates this information's location.

(5) Automatic access time-out.

(i) Automatically stop user access to health information after a predetermined period of inactivity.

(ii) Require user authentication in order to resume or regain the access that was stopped.

(6) Emergency access. Permit an identified set of users to access electronic health information during an emergency.

(7) End-user device encryption. The requirements specified in one of the following paragraphs (that is, paragraphs (d)(7)(i) and (d)(7)(ii) of this section) must be met to satisfy this certification criterion.

(i) Technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of the technology on those devices stops.

(A) Electronic health information that is stored must be encrypted in accordance with the standard specified in § 170.210(a)(2).

(B) Default setting. Technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users.

(ii) Technology is designed to prevent electronic health information from being locally stored on end-user devices after use of the technology on those devices stops.

(8) Integrity.

(i) Create a message digest in accordance with the standard specified in § 170.210(c)(2).

(ii) Verify in accordance with the standard specified in § 170.210(c)(2) upon receipt of electronically exchanged health information that such information has not been altered.

(9) Trusted connection. Establish a trusted connection using one of the following methods:

(i) Message-level. Encrypt and integrity protect message contents in accordance with the standards specified in § 170.210(a)(2) and (c)(2).

(ii) Transport-level. Use a trusted connection in accordance with the standards specified in § 170.210(a)(2) and (c)(2).

(10) Auditing actions on health information.

(i) By default, be set to record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1).

(ii) If technology permits auditing to be disabled, the ability to do so must be restricted to a limited set of users.

(iii) Actions recorded related to electronic health information must not be capable of being changed, overwritten, or deleted by the technology.

(iv) Technology must be able to detect whether the audit log has been altered.

(11) Accounting of disclosures. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in § 170.210(d).

(12) Encrypt authentication credentials. Health IT developers must make one of the following attestations and may provide the specified accompanying information, where applicable:

(i) Yes—the Health IT Module encrypts stored authentication credentials in accordance with standards adopted in § 170.210(a)(2).

(ii) No—the Health IT Module does not encrypt stored authentication credentials. When attesting “no,” the health IT developer may explain why the Health IT Module does not support encrypting stored authentication credentials.

(13) Multi-factor authentication. Health IT developers must make one of the following attestations and, as applicable, provide the specified accompanying information:

(i) Yes—the Health IT Module supports the authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “yes,” the health IT developer must describe the use cases supported.

(ii) No—the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “no,” the health IT developer may explain why the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards.

(e) Patient engagement —

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

(i) Patients (and their authorized representatives) must be able to use internet-based technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Such access must be consistent and in accordance with the standard adopted in § 170.204(a)(1) and may alternatively be demonstrated in accordance with the standard specified in § 170.204(a)(2).

(A) View. Patients (and their authorized representatives) must be able to use health IT to view, at a minimum, the following data:

(1) The data classes expressed in the standards in § 170.213 (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set), and in accordance with § 170.205(a)(4) and (a)(5), and paragraphs (e)(1)(i)(A)(3)(i) through (iii) of this section for the time period up to and including December 31, 2025, or

(2) The Common Clinical Data Set in data classes expressed in the standards in § 170.213 (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set), and in accordance with § 170.205(a)(4) and (a)(6), and paragraphs (e)(1)(i)(A)(3)(i) through (iviii) of this section for the period before December 31, 2022.

(3) The following data classes:

(i) Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).

(ii) Goals. In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).

(iii) Health concerns. In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).

(iv) Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standards specified in § 170.205(a)(4).

(4) Ambulatory setting only. Provider's name and office contact information.

(5) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization.

(6) Laboratory test report(s). Laboratory test report(s), including:

(i) The information for a test report as specified all the data specified in 42 CFR 493.1291(c)(1) through (7);

(ii) The information related to reference intervals or normal values as specified in 42 CFR 493.1291(d); and

(iii) The information for corrected reports as specified in 42 CFR 493.1291(k)(2).

(7) Diagnostic image report(s).

(B) Download.

(1) Patients (and their authorized representatives) must be able to use technology to download an ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) in the following formats:

(i) Human readable format; and

(ii) The format specified in accordance to with the standard specified in § 170.205(a)(4) and (5) for the time period up to and including December 31, 2025, or § 170.205(a)(4) and (6), and following the CCD document template.

(2) When downloaded according to the standard specified in § 170.205(a)(4) and through (56) following the CCD document template, the ambulatory summary or inpatient summary must include, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set):

(i) Ambulatory setting only. All of the data specified in paragraph (e)(1)(i)(A)(1), (2), (4), and (5) of this section.

(ii) Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(1), and (3) through (5) of this section.

(3) Inpatient setting only. Patients (and their authorized representatives) must be able to download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion specified in paragraph (b)(1) of this section).

(C) Transmit to third party. Patients (and their authorized representatives) must be able to:

(1) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in paragraph (e)(1)(i)(B)(2) of this section in accordance with both of the following ways:

(i) Email transmission to any email address; and

(ii) An encrypted method of electronic transmission.

(2) Inpatient setting only. Transmit transition of care/referral summaries (as a result of a transition of care/referral as referenced by (e)(1)(i)(B)(3)) of this section selected by the patient (or their authorized representative) in both of the ways referenced (e)(1)(i)(C)(1)(i) and (ii) of this section).

(D) Timeframe selection. With respect to the data available to view, download, and transmit as referenced paragraphs (e)(1)(i)(A), (B), and (C) of this section, patients (and their authorized representatives) must be able to:

(1) Select data associated with a specific date (to be viewed, downloaded, or transmitted); and

(2) Select data within an identified date range (to be viewed, downloaded, or transmitted).

(ii) Activity history log.

(A) When any of the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section are used, the following information must be recorded and made accessible to the patient (or his/her authorized representative):

(1) The action(s) (i.e., view, download, transmission) that occurred;

(2) The date and time each action occurred in accordance with the standard specified in § 170.210(g);

(3) The user who took the action; and

(4) Where applicable, the addressee to whom an ambulatory summary or inpatient summary was transmitted.

(B) [Reserved]

(iii) Request for restrictions. Patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. Conformance with this paragraph is required by January 1, 2026.

(2) Secure messaging. Enable a user to send messages to, and receive messages from, a patient in a secure manner.

(3) Patient health information capture. Enable a user to:

(i) Identify, record, and access information directly and electronically shared by a patient (or authorized representative).

(ii) Reference and link to patient health information documents.

(f) Public health —

(1) Transmission to immunization registries.

(i) Create immunization information for electronic transmission in accordance with:

(A) The standard and applicable implementation specifications specified in § 170.205(e)(4).

(B) At a minimum, the version of the standard specified in § 170.207(e)(31) for historical vaccines.

(C) At a minimum, the version of the standard specified in § 170.207(e)(42) for administered vaccines.

(ii) Enable a user to request, access, and display a patient's evaluated immunization history and the immunization forecast from an immunization registry in accordance with the standard at § 170.205(e)(4).

(2) Transmission to public health agencies—syndromic surveillance. Create syndrome-based public health surveillance information for electronic transmission in accordance with the standard (and applicable implementation specifications) specified in § 170.205(d)(4).

(3) Transmission to public health agencies—reportable laboratory tests and values/results. Create reportable laboratory tests and values/results for electronic transmission in accordance with:

(i) The standard (and applicable implementation specifications) specified in § 170.205(g).

(ii) At a minimum, the versions of the standards specified in § 170.207(a)(31) and (c)(21).

(4) Transmission to cancer registries. Create cancer case information for electronic transmission in accordance with:

(i) The standard (and applicable implementation specifications) specified in § 170.205(i)(2).

(ii) At a minimum, the versions of the standards specified in § 170.207(a)(41) and (c)(31).

(5) Transmission to public health agencies—electronic agencies —electronic case reporting. Enable a user to create a case report for electronic transmission meeting the requirements described in paragraphs (f)(5)(i) of this section for the time period up to and including December 31, 2025; or the requirements described in paragraph (f)(5)(ii) of this section.

(i) Functional electronic case reporting. A Health IT Module must enable a user to create a case report for electronic transmission in accordance with the following:

(A) Consume and maintain a table of trigger codes to determine which encounters may be reportable.

(

ii

B) Match a patient visit or encounter to the trigger code based on the parameters of the trigger code table.

(

iii

C) Case report creation. Create a case report for electronic transmission:

(

A

1) Based on a matched trigger from paragraph (f)(5)(

ii

i)

.

(B).

(2) That includes, at a minimum:

(

1

i) The data classes expressed in the

standard

standards in § 170.213

, or (2) The Common Clinical Data Set for the period before December 31, 2022

.

(

3

ii) Encounter diagnoses

. Formatted

formatted according to at least one of the

following

standards

: (i) The standard

specified in § 170.207(i)

. (ii) At a minimum, the version of the standard specified in

or § 170.207(a)(

4

1).

(

4

iii) The provider's name, office contact information, and reason for visit.

(

5

iv) An identifier representing the row and version of the trigger table that triggered the case report.

(ii) Standards-based electronic case reporting. A Health IT Module must enable a user to create a case report for electronic transmission in accordance with the following:

(A) Consume and process case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set in § 170.205(t)(4).

(B) Create a case report consistent with at least one of the following standards:

(1) The eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1); or

(2) The HL7 CDA eICR IG in § 170.205(t)(2).

(C) Receive, consume, and process a case report response that is formatted to either the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3) as determined by the standard used in (f)(5)(ii)(B) of this section.

(D) Transmit a case report electronically to a system capable of receiving a case report.

(6) Transmission to public health agencies—antimicrobial use and resistance reporting. Create antimicrobial use and resistance reporting information for electronic transmission in accordance with the standard specified in § 170.205(r)(1).

(7) Transmission to public health agencies—health care surveys. Create health care survey information for electronic transmission in accordance with the standard specified in § 170.205(s)(1).

(g) Design and performance —

(1) Automated numerator recording. For each Promoting Interoperability Programs percentage-based measure, technology must be able to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure's numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage.

(2) Automated measure calculation. For each Promoting Interoperability Programs percentage-based measure that is supported by a capability included in a technology, record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable measure.

(3) Safety-enhanced design.

(i) User-centered design processes must be applied to each capability technology includes that is specified in the following certification criteria: Paragraphs paragraphs (a)(1) through (5), (9) (until the criterion's expiration date), and (14) , and (b)(2) and , (3), and (11) of this section.

(ii) Number of test participants. A minimum of 10 test participants must be used for the testing of each capability identified in paragraph (g)(3)(i) of this section.

(iii) One of the following must be submitted on the user-centered design processed used:

(A) Name, description and citation (URL and/or publication citation) for an industry or federal government standard.

(B) Name the process(es), provide an outline of the process(es), a short description of the process(es), and an explanation of the reason(s) why use of any of the existing user-centered design standards was impractical.

(iv) The following information/sections from NISTIR 7742 must be submitted for each capability to which user-centered design processes were applied:

(A) Name and product version; date and location of the test; test environment; description of the intended users; and total number of participants;

(B) Description of participants, including: Sex; age; education; occupation/role; professional experience; computer experience; and product experience;

(C) Description of the user tasks that were tested and association of each task to corresponding certification criteria;

(D) The specific metrics captured during the testing of each user task performed in (g)(3)(iv)(C) of this section, which must include: Task success (%); task failures (%); task standard deviations (%); task performance time; and user satisfaction rating (based on a scale with 1 as very difficult and 5 as very easy) or an alternative acceptable user satisfaction measure;

(E) Test results for each task using the metrics identified above in paragraph (g)(3)(iv)(D) of this section; and

(F) Results and data analysis narrative, including: Major test finding; effectiveness; efficiency; satisfaction; and areas for improvement.

(v) Submit test scenarios used in summative usability testing.

(4) Quality management system.

(i) For each capability that a technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation, and maintenance of that capability must be identified that satisfies one of the following ways:

(A) The QMS used is established by the Federal government or a standards developing organization.

(B) The QMS used is mapped to one or more QMS established by the Federal government or standards developing organization(s).

(ii) When a single QMS was used for applicable capabilities, it would only need to be identified once.

(iii) When different QMS were applied to specific capabilities, each QMS applied would need to be identified.

(5) Accessibility-centered design. For each capability that a Health IT Module includes and for which that capability's certification is sought, the use of a health IT accessibility-centered design standard or law in the development, testing, implementation and maintenance of that capability must be identified.

(i) When a single accessibility-centered design standard or law was used for applicable capabilities, it would only need to be identified once.

(ii) When different accessibility-centered design standards and laws were applied to specific capabilities, each accessibility-centered design standard or law applied would need to be identified. This would include the application of an accessibility-centered design standard or law to some capabilities and none to others.

(iii) When no accessibility-centered design standard or law was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion.

(6) Consolidated CDA creation performance. The following technical and performance outcomes must be demonstrated related to Consolidated CDA creation. The capabilities required under paragraphs (g)(6)(i) through (v) of this section can be demonstrated in tandem and do not need to be individually addressed in isolation or sequentially.

(i) This certification criterion's scope includes:

(A) The data classes expressed in the standard standards in § 170.213, and in accordance with § 170.205(a)(4) and (a)(5) and paragraphs (g)(6)(i)(C)(1) through (34) of this section for the time period up to and including December 31, 2025; or

(B) The Common Clinical Data Set in data classes expressed in the standards in § 170.213, and in accordance with § 170.205(a)(4) and (6) and paragraphs (g)(6)(i)(C)(1) through (43) of this section for the period before December 31, 2022.

(C) The following data classes:

(1) Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).

(2) Goals. In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).

(3) Health concerns. In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).

(4) Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).

(ii) Reference C–CDA match.

(A) For health IT certified to (g)(6)(i)(A) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) and (5) that matches a gold-standard, reference data file.

(B) For health IT certified to (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that matches a gold-standard, reference data file.

(iii) Document-template conformance.

(A) For health IT certified to (g)(6)(i)(A) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) and (5) that demonstrates a valid implementation of each document template applicable to the certification criterion or criteria within the scope of the certificate sought.

(B) For health IT certified to (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that demonstrates a valid implementation of each document template applicable to the certification criterion or criteria within the scope of the certificate sought.

(iv) Vocabulary conformance.

(A) For health IT certified to (g)(6)(i)(A) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) and (5) that demonstrates the required vocabulary standards (and value sets) are properly implemented.

(B) For health IT certified to (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that demonstrates the required vocabulary standards (and value sets) are properly implemented.

(v) Completeness verification. Create a data file for each of the applicable document templates referenced in paragraph (g)(6)(iii) of this section without the omission of any of the data included in either paragraph (g)(6)(i)(A) or (B) of this section, as applicable.

(7) Application access—patient selection. The following technical outcome and conditions must be met through the demonstration of an application programming interface (API).

(i) Functional requirement. The technology must be able 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.

(ii) Documentation.

(A) The API must include accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.

(2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

(B) The documentation used to meet paragraph (g)(7)(ii)(A) of this section must be available via a publicly accessible hyperlink.

(8) Application access—data category request. The following technical outcome and conditions must be met through the demonstration of an application programming interface.

(i) Functional requirements.

(A) Respond to requests for patient data (based on an ID or other token) for each of the individual data categories specified in the Common Clinical Data Set and return the full set of data for that data category (according to the specified standards, where applicable) in a computable format.

(B) Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.

(ii) Documentation —

(A) The API must include accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.

(2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

(B) The documentation used to meet paragraph (g)(8)(ii)(A) of this section must be available via a publicly accessible hyperlink.

(9) Application access—all data request. The following technical outcome and conditions must be met through the demonstration of an application programming interface.

(i) Functional requirements.

(A)

(1) Respond to requests for patient data (based on an ID or other token) for all of the data classes expressed in the standards in § 170.213 at one time and return such data (according to the specified standards, where applicable) in a summary record formatted in accordance with § 170.205(a)(4) and (5) following the CCD document template, and as specified in paragraphs (g)(9)(i)(A)(3)(i) through (iiiiv) of this section for the time period up to and including December 31, 2025; or

(2) The Common Clinical Data Set in accordance with Respond to requests for patient data (based on an ID or other token) for all of the data classes expressed in the standards in § 170.213 at one time and return such data (according to the specified standards, where applicable) in a summary record formatted in accordance with § 170.205(a)(4) and (6) following the CCD document template, and as specified in paragraphs (g)(9)(i)(A)(3)(i) through (iv) of this section for the period before December 31, 2022, and .

(3) The following data classes:

(i) Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standards specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standards specified in § 170.205(a)(4).

(ii) Goals. In accordance with the “Goals Section” of the standards specified in § 170.205(a)(4).

(iii) Health concerns. In accordance with the “Health Concerns Section” of the standards specified in § 170.205(a)(4).

(iv) Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standards specified in § 170.205(a)(4).

(B) Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.

(ii) Documentation —

(A) The API must include accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.

(2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

(B) The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink.

(10) Standardized API for patient and population services. The following technical outcomes and conditions must be met through the demonstration of application programming interface technology.

(i) Data response.

(A) Respond to requests for a single patient's data according to the standard standards and implementation specifications adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(ab)(21), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.

(B) Respond to requests for multiple patients' data as a group according to the standard adopted in § 170.215(a)(1), standards and implementation specifications adopted in § 170.215(a), (2b)(1), and (4d), for each of the data included in the standard standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.

(ii) Supported search operations.

(A) Respond to search requests for a single patient's data consistent with the search criteria included in the implementation specification specifications adopted in § 170.215(ab)(21), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.”

(B) Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(ad)(4).

(iii) Application registration. Enable an application to register with the Health IT Module's “authorization server.”

(iv) Secure connection.

(A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(ab)(21) and (3c).

(B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(ad)(4).

(v) Authentication and authorization —

(A) Authentication and authorization for patient and user scopes —

(1) First time connections.

(i) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(ac)(3) and standard adopted in § 170.215(be).

(ii) A Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret.

(

using the “confidential app” profile according to an implementation specification adopted in § 170.215(c).

(iii) A Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token

(2) Subsequent connections.

(i) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(ac)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application.

(ii) A Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret.

(

using the “confidential app” profile according to an implementation specification adopted in § 170.215(c).

(B) Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(ad)(4) and the application must be issued a valid access token.

(vi) Patient authorization revocation. A Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request.

(vii) Token introspection. A Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c).

(viii) Documentation.

(A) The API(s) must include complete accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.

(2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

(3) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server.

(B) The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps.

(h) Transport methods and other protocols —

(1) Direct Project —

(i) Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.

(ii) Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).

(2) Direct Project, Edge Protocol, and XDR/XDM.

(i) Able to send and receive health information in accordance with:

(A) The standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message;

(B) The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles; and

(C) Both edge protocol methods specified by the standard in § 170.202(d).

(ii) Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).

[80 FR 62747, Oct. 16, 2015, as amended at 80 FR 76871, Dec. 11, 2015; 85 FR 25941, May 1, 2020; 85 FR 47099, Aug. 4, 2020; 85 FR 70083, Nov. 4, 2020; 85 FR 78236, Dec. 4, 2020; 89 FR 1429, Jan. 9, 2024; 89 FR 8548, Feb. 8, 2024; 89 FR 16470, Mar. 7, 2024]