45 C.F.R. § 170.315
The Secretary adopts the following certification criteria for health IT. Health IT must be able to electronically perform the following capabilities in accordance with 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.
(2) Computerized provider order entry—laboratory.
(3) Computerized provider order entry—diagnostic imaging.
(ii) Adjustments.
(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) Patient 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)(3) 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)(3) 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).
(ii) CDS configuration.
(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.
(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).
(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.
(14) Implantable device list.
(ii) Parse the following identifiers from a Unique Device Identifier:
(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:
(v) For each Unique Device Identifier recorded for a patient, enable a user to access:
(15) Social, psychological, and behavioral data. Enable a user to record, change, and access the following patient social, psychological, and behavioral data:
(b) Care coordination—(1) Transitions of care—(i) Send and receive via 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.
(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 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 data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4), (6), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section, 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)(1).
(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: Represent sex 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).
(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:
(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standards:
(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.
(3) Electronic prescribing.
(ii) For technology certified subsequent to June 30, 2020:
(A) (1) For the time period up to and including December 31, 2027, enable a user to perform the prescription-related electronic transactions specified in paragraph (b)(3)(ii)(A)(3) of this section in accordance with the standards specified in § 170.205(b)(1) or (2).
(i) At a minimum, at least one of the versions of the standard adopted in § 170.207(d)(1).
(ii) The standard in § 170.207(d)(2) if using the standard in § 170.205(b)(2).
(2) On and after January 1, 2028, enable a user to perform the prescription-related electronic transactions specified in paragraph (b)(3)(ii)(A)(3) of this section in accordance with the standard specified in § 170.205(b)(2).
(i) At a minimum, at least one of the versions of the standard adopted in § 170.207(d)(1).
(ii) The standard in § 170.207(d)(2).
(3) The prescription-related electronic transactions are as follows:
(i) New prescriptions (NewRx).
(ii) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
(iii) Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
(iv) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
(v) Receive fill status notifications (RxFill).
(vi) Request and receive medication history (RxHistoryRequest, RxHistoryResponse).
(vii) Relay acceptance of a transaction back to the sender (Status).
(viii) Respond that there was a problem with the transaction (Error).
(ix) Respond that a transaction requesting a return receipt has been received (Verify).
(x) Electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification). These transactions are required if using the standard in § 170.205(b)(2).
(B) Enable a user to exchange race and ethnicity information when performing the following prescription-related electronic transactions, if using the standard in § 170.205(b)(2):
(1) Receive fill status notifications (RxFill).
(2) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
(3) Request to cancel prescriptions (CancelRx).
(4) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
(C) For the following prescription-related transactions, the technology must be able to receive and transmit the diagnosis or diagnoses that are the reason for prescription:
(1) Required transactions:
(i) 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) [Reserved]
(vii) Electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse, PANotification). These transactions are required if using the standard in § 170.205(b)(2).
(2) [Reserved]
(4) Real-time prescription benefit—(i) Send and receive information. Enable a user to perform the following transactions using the XML format in accordance with at least one of the versions of the standards adopted in § 170.205(c); at a minimum, a standard adopted in § 170.207(d)(1); and the standard in § 170.207(d)(2), as follows:
(8) Security tags—summary of care—receive.
(9) Care plan. Enable a user to record, change, access, create, and receive care plan information in accordance with:
(10) Electronic Health Information export—(i) Single patient electronic health information export.
(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.
(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.
(11) Decision support interventions—
(ii) Decision support configuration.
(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.
(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.
(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:
(3) Clinical quality measures—report. Enable a user to electronically create a data file for transmission of clinical quality measurement data:
(4) Clinical quality measures—filter.
(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:
(iii) Data.
(2) Auditable events and tamper-resistance—(i) Record actions. Technology must be able to:
(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.
(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:
(5) Automatic access time-out.
(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.
(8) Integrity.
(9) Trusted connection. Establish a trusted connection using one of the following methods:
(10) Auditing actions on health information.
(12) Encrypt authentication credentials. Health IT developers must make one of the following attestations and may provide the specified accompanying information, where applicable:
(13) Multi-factor authentication. Health IT developers must make one of the following attestations and, as applicable, provide the specified accompanying information:
(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 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 (iii) of this section.
(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 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) through (6) 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.
(3) Patient health information capture. Enable a user to:
(f) Public health—(1) Transmission to immunization registries.
(i) Create immunization information for electronic transmission in accordance with:
(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:
(4) Transmission to cancer registries. Create cancer case information for electronic transmission in accordance with:
(5) Transmission to public health 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:
(C) Case report creation. Create a case report for electronic transmission:
(1) Based on a matched trigger from paragraph (f)(5)(i)(B).
(2) That includes, at a minimum:
(i) The data classes expressed in the standards in § 170.213.
(ii) Encounter diagnoses formatted according to at least one of the standards specified in § 170.207(i) or § 170.207(a)(1).
(iii) The provider's name, office contact information, and reason for visit.
(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:
(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).
(3) Safety-enhanced design.
(iii) One of the following must be submitted on the user-centered design processed used:
(iv) The following information/sections from NISTIR 7742 must be submitted for each capability to which user-centered design processes were applied:
(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:
(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.
(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:
(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.
(iii) Document-template conformance.
(iv) Vocabulary conformance.
(7) Application access—patient selection. The following technical outcome and conditions must be met through the demonstration of an application programming interface (API).
(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).
(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 (iv) of this section for the time period up to and including December 31, 2025; or
(2) 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.
(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).
(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).
(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.
(ii) Supported search operations.
(iv) Secure connection.
(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(c) and standard adopted in § 170.215(e).
(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 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(c) 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 using the “confidential app” profile according to an implementation specification adopted 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.
(31) Provider prior authorization API—coverage requirements discovery. Support the following capabilities to enable users to request and receive coverage requirements.
(i) Coverage discovery. Support the capability to initiate and exchange information as a “CRD Client” to enable the identification of coverage requirements according to at least one of the versions of the implementation specification adopted in § 170.215(j)(1), including the following:
(32) Provider prior authorization API—documentation templates and rules. Support the capability for users to request and populate prior authorization documentation using templates and rules as a “Full DTR EHR” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2), including:
(33) Provider prior authorization API—prior authorization support. Support the following capabilities to enable users to submit prior authorization requests.
(i) Prior authorization submission. Support submitting a prior authorization request as a client in accordance with at least one of the versions of the implementation specification adopted in § 170.215(j)(3) including the following:
(C) Prior authorization transactions. Support the ability to submit a prior authorization request as a client system including the following:
(1) Support the capabilities in the “EHR PAS Capabilities” Capability Statement.
(2) Support the ability to consume and process a “ClaimResponse.”
(3) Support subscriptions as a client according to the requirements in paragraph (j)(21) of this section in order to support “pended authorization responses.”
(2) Direct Project, Edge Protocol, and XDR/XDM.
(i) Able to send and receive health information in accordance with:
(j) Modular API capabilities. The following technical outcomes and conditions must be met through the demonstration of application programming interface technology.
(20) Workflow triggers for decision support interventions—clients. Support the requirements applicable to a “CDS Client” according to at least one of the implementation specifications in § 170.215(f) including the following:
(ii) Authentication and authorization. Support authentication and authorization, including the following:
(iv) Information exchange. Send a decision support request to a “CDS Service,” including support for the following:
(21) Subscriptions—client. Support subscriptions as a client according to at least one of the implementation specifications in § 170.215(h), including the following:
[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; 89 FR 101809, Dec. 16, 2024; 90 FR 37210, Aug. 4, 2025]