Department of health and human services

§ 170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.

* * * * *

(a) * * *

(3) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, October 8, 2014.

* * * * *

9. In § 170.300, revise paragraph (d) to read as follows:

§ 170.300 Applicability.

* * * * *

(d) In §§ 170.314 and 170.315, all certification criteria and all capabilities specified within a certification criterion have general applicability (i.e., apply to any health care setting) unless designated as “inpatient setting only” or “ambulatory setting only.”

(1) Inpatient setting only means that the criterion or capability within the criterion is only required for certification of technology designed for use in an inpatient setting.

(2) Ambulatory setting only means that the criterion or capability within the criterion is only required for certification of technology designed for use in an ambulatory setting.

§ 170.314 [Amended]

10. In § 170.314:

a. In paragraph (a)(3)(i)(A), remove “§ 170.207(f)” and add in its place “§ 170.207(f)(1)”;

b. In paragraph (a)(3)(i)(B), remove “§ 170.207(g)” and add in its place “§ 170.207(g)(1)”;

c. In paragraph (a)(8)(iii)(B)(2), remove “paragraph (b)(1)(iii)” and add in its place “paragraph (b)(1)(iii)(B) or (b)(9)(ii)(D)”;

d. In paragraphs (b)(2)(i) introductory test, (b)(7) introductory text, (b)(8)(iii) introductory text, (e)(1)(i)(A)(1), and (e)(2)(iii)(A), remove the term “Common MU Data Set” and add in its place “Common Clinical Data Set”;

e. In paragraph (b)(5)(i)(A)(1), remove “§ 170.205(j)” and add in its place “§ 170.205(j)(1)”;

f. In paragraph (b)(6), remove “§ 170.205(j)” and add in its place “§ 170.205(j)(1)”;

g. In paragraph (e)(1)(i)(A) introductory text, remove “§ 170.204(a)” and add in its place “§ 170.204(a)(1)”;

h. In paragraph (f)(4)(i), remove “§ 170.205(g)” and add in its place “§ 170.205(g)(1)”; and

i. In paragraph (f)(6)(i), remove “§ 170.205(i)” and add in its place “ § 170.205(i)(1)”.

11. Add § 170.315 to read as follows:

§ 170.315 2015 Edition health IT certification criteria.

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:

(a) Clinical--(1) Computerized provider order entry – medications. Technology must enable a user to record, change, and access medication orders.

(2) Computerized provider order entry – laboratory. (i) Technology must enable a user to record, change, and access laboratory orders.

(ii) Technology must be able to receive and incorporate a new or updated laboratory order compendium in accordance with the standard specified in § 170.205(l)(2) and, at a minimum, the version of the standard in § 170.207(c)(3).

(iii) Ambulatory setting only. Technology must enable a user to create laboratory orders for electronic transmission in accordance with the standard specified in § 170.205(l)(1) and, at a minimum, the version of the standard in § 170.207(c)(3).

(3) Computerized provider order entry – diagnostic imaging. Technology must enable a user to record, change, and access diagnostic imaging orders.

(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 to an identified set of users or available as a system administrative function.

(iii) Interaction check response documentation. (A) Technology must be able to record at least one action taken and by whom in response to drug-drug or drug-allergy interaction checks.

(B) Technology must be able to generate either a human readable display or human readable report of actions taken and by whom in response to drug-drug or drug-allergy interaction checks.

(5) Demographics. (i) Enable a user to record, change, and access patient demographic data including preferred language, sex, race, ethnicity, 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)(2) 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)(2) 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) 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) Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1).

(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) Vital signs, body mass index, and growth charts--(i) Vital signs. Enable a user to record, change, and access, at a minimum, a patient's height, weight, diastolic blood pressure, systolic blood pressure, heart rate, respiratory rate, temperature, oxygen saturation in arterial blood by pulse oximetry, body mass index [ratio], and mean blood pressure in accordance with the following (The patient’s height/length, weight, diastolic blood pressure, systolic blood pressure, heart rate, respiratory rate, temperature, oxygen saturation in arterial blood by pulse oximetry, body mass index [ratio], and mean blood pressure must be recorded in numerical values only.):

(A) The standard specified in § 170.207(k)(1) and with the associated applicable unit of measure for the vital sign in the standard specified in § 170.207(m)(1);

(B) Metadata. For each vital sign in paragraph (a)(6)(i) of this section, the technology must also record the following:

(1) Date and time of vital sign measurement or end time of vital sign measurement;

(2) The measuring- or authoring-type source of the vital sign measurement; and

(3) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g); and

(C) Metadata for oxygen saturation in arterial blood by pulse oximetry. For the oxygen saturation in arterial blood by pulse oximetry, the technology must enable a user to record, change, and access the patient’s inhaled oxygen concentration identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with LOINC^® code 8478-0.

(ii) Optional – Body mass index percentile per age and sex. Enable a user to record, change, and access a patient’s body mass index [percentile] per age and sex for patients two to twenty years of age in accordance with the following (The patient’s body mass index [percentile] per age and sex must be recorded in numerical values only.):

(A) Identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with LOINC^® code 59576-9 and with the associated applicable unit of measure in the standard specified in § 170.207(m)(1); and

(B) Metadata. The technology must also record the following:

(1) Date and time of vital sign measurement or end time of vital sign measurement;

(2) The measuring- or authoring-type source of the vital sign measurement;

(3) The patient’s date of birth;

(4) The patient’s sex in accordance with the standard specified in § 170.207(n)(1); and

(5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g).

(iii) Optional – Weight for length per age and sex. Enable a user to record, change, and access a patient’s weight for length per age and sex for patients less than three years of age in accordance with the following (The patient’s weight for length per age and sex must be recorded in numerical values only.):

(A) Identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with the LOINC^® code and with the associated applicable unit of measure in the standard specified in § 170.207(m)(1); and

(B) Metadata. The technology must record the following:

(1) Date and time of vital sign measurement or end time of vital sign measurement;

(2) The measuring- or authoring-type source of the vital sign measurement;

(3) The patient’s date of birth;

(4) The patient’s sex in accordance with the standard specified in § 170.207(n)(1); and

(5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g).

(iv) Optional – Head occipital-frontal circumference. Enable a user to record, change, and access a patient’s head occipital-frontal circumference for patients less than three years of age in accordance with the following (The patient’s head occipital-frontal circumference must be recorded in numerical values only.):

(A) Identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with LOINC^® code 8287-5 and with the associated applicable unit of measure in the standard specified in § 170.207(m)(1); and

(B) Metadata. The technology must also record the following:

(1) Date and time of vital sign measurement or end time of vital sign measurement;

(2) The measuring- or authoring-type source of the vital sign measurement;

(3) The patient’s date of birth;

(4) The patient’s age in accordance with the standard specified in § 170.207(n)(1); and

(5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g).

(v) Optional – Calculate body mass index. Automatically calculate and display body mass index based on a patient's height and weight.

(vi) Optional – Plot and display growth charts. Plot and display, upon request, growth charts for patients.

(7) Problem list. Enable a user to record, change, and access a patient's active problem list:

(i) Ambulatory setting. Over multiple encounters in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4); or

(ii) Inpatient setting. For the duration of an entire hospitalization in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4).

(8) Medication list. Enable a user to record, change, and access a patient's active medication list as well as medication history:

(i) Ambulatory setting. Over multiple encounters; or

(ii) Inpatient setting. For the duration of an entire hospitalization.

(9) Medication allergy list. Enable a user to record, change, and access a patient's active medication allergy list as well as medication allergy history:

(i) Ambulatory setting. Over multiple encounters; or

(ii) Inpatient setting. For the duration of an entire hospitalization.

(10) Clinical decision support--(i) Evidence-based decision support interventions. Enable a limited set of identified users to select (i.e., activate) one or more electronic clinical decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the following data:

(A) Problem list;

(B) Medication list;

(C) Medication allergy list;

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

(E) Laboratory tests; and

(F) Vital signs.

(ii) Linked referential clinical decision support. (A) Technology must be able to identify for a user diagnostic and therapeutic reference information in accordance with the standard and implementation specifications at § 170.204(b)(3) or (4).

(B) For paragraph (a)(10)(ii)(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)(10)(i)(A), (B), and (D) of this section.

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

(B) Technology must enable interventions to be:

(1) Based on the data referenced in paragraphs (a)(10)(i)(A) through (F) of this section.

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

(3) Ambulatory setting only. When a patient's laboratory tests and values/results are incorporated pursuant to paragraph (b)(4) of this section.

(iv) CDS intervention interaction. Interventions provided to a user in paragraphs (a)(10)(i) through (iii) of this section must occur when a user is interacting with technology.

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

(A) For evidence-based decision support interventions under paragraph (a)(10)(i) 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 clinical decision support in paragraph (a)(10)(ii) 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) Intervention response documentation. (A) Technology must be able to record at least one action taken and by whom in response to clinical decision support interventions.

(B) Technology must be able to generate either a human readable display or human readable report of actions taken and by whom in response to clinical decision support interventions.

(11) Drug-formulary and preferred drug list checks. Technology must either meet paragraph (a)(11)(i) or (ii) of this section.

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

(B) Indicate for a user the last update of the drug formulary; and

(C) Receive and incorporate a formulary and benefit file in accordance with the standard specified in § 170.205(n)(1).

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

(B) Indicate for a user the last update of the preferred drug list.

(12) Smoking status. Enable a user to record, change, and access the smoking status of a patient in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4).

(13) Image results. Indicate to a user the availability of a patient's images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations.

(14) 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)(4).

(15) Family health history – pedigree. Technology must be able to create and incorporate a patient's family health history in accordance with the standard and implementation specification specified in § 170.205(m)(1).

(16) Patient list creation. Enable a user to dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data:

(i) Problems;

(ii) Medications;

(iii) Medication allergies;

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

(v) Laboratory tests and values/results; and

(vi) Ambulatory setting only. Patient communication preferences.

(17) Patient-specific education resources. Technology must be able to:

(i) Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with the standard (and implementation specifications) specified in § 170.204(b)(3) or (4); and

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

(18) Electronic medication administration record. (i) In combination with an assistive technology that provides automated information on the “rights” specified in paragraphs (a)(18)(i)(A) through (E) of this section, enable a user to verify the following before administering medication(s):

(A) Right patient. The patient to whom the medication is to be administered matches the medication to be administered.

(B) Right medication. The medication to be administered matches the medication ordered for the patient.

(C) Right dose. The dose of the medication to be administered matches the dose of the medication ordered for the patient.

(D) Right route. The route of medication delivery matches the route specified in the medication order.

(E) Right time. The time that the medication was ordered to be administered compared to the current time.

(ii) Right documentation. Record the time and date in accordance with the standard specified in § 170.210(g), and user identification when a medication is administered.

(19) Patient health information capture. Technology must be able to enable a user to:

(i) Identify, record, and access patient health information documents;

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

(iii) Record and access information directly shared by a patient.

(20) Implantable device list. (i) Enable a user to record, change, and access, a list of Unique Device Identifiers associated with a patient’s Implantable Device(s).

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

(A) Device Identifier;

(B) Batch/lot number;

(C) Expiration date;

(D) Production date; and

(E) Serial number.

(iii) Retrieve the “Device Description” attribute associated with a Unique Device Identifier in the Global Unique Device Identification Database.

(iv) For each Unique Device Identifier in a patient’s list of implantable devices, enable a user to access the following:

(A) The parsed data elements specified under paragraph (a)(20)(ii) of this section that are associated with the UDI; and

(B) The retrieved data element specified under paragraph (a)(20)(iii) of this section.

(21) Social, psychological, and behavioral data. Enable a user to record, change, and access, at a minimum, one of the following patient social, psychological, and behavioral data.

(i) Sexual orientation. Enable sexual orientation to be recorded in accordance with the standard specified in § 170.207(o)(1) and whether a patient declines to specify sexual orientation.

(ii) Gender identity. Enable gender identity to be recorded in accordance with the standard specified in § 170.207(o)(2) and whether a patient declines to specify gender identity.

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

(iv) Education. Enable education to be recorded in accordance with the standard specified in § 170.207(o)(4) and whether a patient declines to specify education.

(v) Stress. Enable stress to be recorded in accordance with the standard specified in § 170.207(o)(5) and whether a patient declines to specify stress.

(vi) Depression. Enable depression to be recorded in accordance with the standard specified in § 170.207(o)(6) and whether a patient declines to specify stress.

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

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

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

(x) 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(o)(10) and whether a patient declines to specify exposure to violence (intimate partner violence).

(22) Decision support – knowledge artifact. Enable a user to send and receive clinical decision support knowledge artifacts in accordance with the standard specified in § 170.204(d)(1).

(23) Decision support – service. Enable a user to send and receive electronic clinical guidance in accordance with the standard specified in § 170.204(e)(1).

(b) Care coordination--(1) Transitions of care--(i) Send and receive via edge protocol. Technology must be able to:

(A) Send transitions of care/referral summaries through a method that conforms to the standard specified in § 170.202(d); and

(B) Receive transitions 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).

(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) if the technology is also being certified using an SMTP-based edge protocol.

(ii) Validate and display--(A) Validate C-CDA conformance – system performance. Technology must demonstrate its ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with both of the standards specified in § 170.205(a)(3) and (4). This includes the ability to:

(1) Parse each of the document types formatted according to the following document templates: CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; Referral Note, and Discharge Summary.

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

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

(4) Correctly interpret empty sections and null combinations; and

(5) Record errors encountered and allow for a user to be notified of or review the errors produced.

(B) Technology must be able to 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) and (4).

(C) Section views. Allow for individual display each additional section or sections (and the accompanying document header information) that were included in a transition of care/referral summary received and formatted in accordance with either of the standards adopted in § 170.205(a)(3) and (4).

(iii) Create. (A) Enable a user to create a transition of care/referral summary:

(1) Formatted according to the standards adopted in § 170.205(a)(3);

(2) Formatted according to the standards adopted in § 170.205(a)(4); and

(3) Includes, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s):

(i) Encounter diagnoses. The standard specified in § 170.207(i) or, at a minimum, the version of the standard specified in § 170.207(a)(4);

(ii) Cognitive status;

(iii) Functional status;

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

(v) Inpatient setting only. Discharge instructions.

(B) Patient matching data quality. Technology must be capable of creating a transition of care/referral summary that includes the following data and, where applicable, represent such data according to the additional constraints specified below:

(1) Data. first name, last name, maiden name, middle name (including middle initial), suffix, date of birth, place of birth, current address, historical address, phone number, and sex.

(2) Constraint. Represent last/family name according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0.

(3) Constraint. Represent suffix according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, PHD, ESQ). If no suffix exists, the field should be entered as null.

(4) Constraint. Represent the year, month and date of birth are required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in latter local time is assumed. If date of birth is unknown, the field should be marked as null.

(5) Constraint. Represent phone number (home, business, cell) in the ITU format specified in ITU-T E.123 and ITU-T E.164. If multiple phone numbers are present, all should be included.

(6) Constraint. Represent sex in accordance with the standard adopted at § 170.207(n)(1).

(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 standard adopted in § 170.205(a)(3) as well as separately to the standard adopted in § 170.205(a)(4) using the Continuity of Care Document, Discharge Summary Document and Referral Summary document templates.

(ii) Correct patient. Upon receipt of a transition of care/referral summary formatted according to either of the standards adopted at § 170.205(a)(3) or (4), technology must be able to demonstrate that the transition of care/referral summary received is or 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, medication allergy 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 medications, medication allergies, or problems;

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

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

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

(2) Medication allergies. At a minimum, the version of the standard specified in § 170.207(d)(3); and

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

(iv) System verification. Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard adopted at § 170.205(a)(4) using the Continuity of Care Document document template.

(3) Electronic prescribing. (i) Enable a user to prescribe, send, and respond to prescription-related transactions for electronic transmission in accordance with the standard specified at § 170.205(b)(2), and, at a minimum, the version of the standard specified in § 170.207(d)(3), as follows:

(A) Create new prescriptions (NEWRX);

(B) Change prescriptions (RXCHG, CHGRES);

(C) Cancel prescriptions (CANRX, CANRES);

(D) Refill prescriptions (REFREQ, REFRES);

(E) Receive fill status notifications (RXFILL); and

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

(ii) Enable a user to enter, receive, and transmit structured and codified prescribing instructions for the transactions listed in paragraph (b)(3)(i) of this section for electronic transmission in accordance with the standard specified at § 170.205(b)(2) and, at a minimum, for at least the following component composites:

(A) Repeating Sig;

(B) Code System;

(C) Sig Free Text String;

(D) Dose;

(E) Dose Calculation;

(F) Vehicle;

(G) Route of Administration;

(H) Site of Administration;

(I) Sig Timing;

(J) Duration;

(K) Maximum Dose Restriction;

(L) Indication; and

(M) Stop.

(iii) Technology must limit a user’s ability to prescribe all medications in only the metric standard.

(iv) Technology must 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) Incorporate laboratory tests and values/results--(i) Receive results--(A) Ambulatory setting only. (1) Receive and incorporate clinical laboratory tests and values/results in accordance with the standard specified in § 170.205(j)(2); and, at a minimum, the version of the standard specified in § 170.207(c)(3).

(2) Display the tests and values/results received in human readable format.

(B) Inpatient setting only. Receive clinical laboratory tests and values/results in a structured format and display such tests and values/results in human readable format.

(ii) Display the test report information:

(A) Specified in 42 CFR 493.1291(a)(1) through (3) and (c)(1) through (7);

(B) Related to reference intervals or normal values as specified in 42 CFR 493.1291(d);

(C) For alerts and delays as specified in 42 CFR 493.1291(g) and (h); and

(D) For corrected reports as specified in 42 CFR 493.1291(k)(2).

(iii) Attribute, associate, or link a laboratory test and value/result with a laboratory order or patient record.

(5) Transmission of laboratory test reports. Technology must be able to electronically create laboratory test reports for electronic transmission in accordance with the standard specified in in § 170.205(j)(2) and, at a minimum, the version of the standard specified in § 170.207(c)(3).

(6) Data portability--(i) General requirements for export summary configuration. A user must be able to set the following configuration options when using technology to create an export summary or 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.

(ii) Document creation configuration--(A) Document-template types. A user must be able to configure the technology to create an export summary or export summaries formatted according to the standard adopted at § 170.205(a)(4) for any of the following document-template types.

(1) Generally applicable. CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; and Referral Note.

(2) Inpatient setting only. Discharge Summary.

(B) For any document-template selected the technology must be able to include, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s):

(1) Encounter diagnoses. The standard specified in § 170.207(i) or, at a minimum, the version of the standard at § 170.207(a)(4);

(2) Cognitive status;

(3) Functional status;

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

(5) Inpatient setting only. Discharge instructions.

(C) Use of the “unstructured document” document-level template is prohibited for compliance with the standard adopted at § 170.205(a)(4)).

(iii) Timeframe configuration. A user must be able to configure the technology to set the time period within which data would be used to create the export summary or summaries. This must include the ability to enter in a start and end date range as well as the ability to set a date at least three years into the past from the current date.

(iv) Event configuration. A user must be able to configure the technology to create an export summary or summaries based on the following user selected events:

(A) A relative date or time (e.g., the first of every month);

(B) A specific date or time (e.g., on 10/24/2015); and

(C) When a user signs a note or an order.

(v) Location configuration. A user must be able to configure and set the storage location to which the export summary or export summaries are intended to be saved.

(7) Data segmentation for privacy – send. Technology must enable a user to create a summary record formatted in accordance with each of the standards adopted in § 170.205(a)(3) and (4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1).

(8) Data segmentation for privacy – receive. Technology must enable a user to:

(i) Receive a summary record that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1);

(ii) Apply document-level tagging and sequester the document from other documents received; and

(iii) View the restricted document (or data), without incorporating the document (or data).

(9) Care plan. Technology must enable a user to record, change, access, create, and receive care plan information in accordance with the Care Plan document template in the standard adopted in § 170.205(a)(4).

(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 formatted in accordance with the standard specified at § 170.205(h) for one or multiple patients 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. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.

(2) Clinical quality measures – import and calculate--(i) Import. Enable a user to import a data file in accordance with the standard specified at § 170.205(h) 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) Technology must be able to calculate each and every clinical quality measure for which it is presented for certification.

(3) [Reserved]

(4) Clinical quality measures – filter. (i) Technology must be able to record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.

(ii) Technology must be able to 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.

(iii) Data. (A) TIN;

(B) NPI;

(C) Provider type;

(D) Patient insurance;

(E) Patient age;

(F) Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(1);

(G) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2);

(H) Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4); and

(I) Practice site address.

(d) Privacy and security--(1) Authentication, access control, and authorization. (i) Verify against a unique identifier(s) (e.g., username or number) that a person 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, paragraph (d)(2)(i)(B) or (C) of this section, or both paragraphs (d)(2)(i)(B) and (C).

(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 to the affected record or 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. Paragraph (d)(7)(i) or (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)(3).

(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).

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

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

(e) Patient engagement--(1) View, download, and transmit to 3rd party. (i) Patients (and their authorized representatives) must be able to use technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Access to these capabilities must be online and through a secure channel that ensures all content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).

(A) View. Patients (and their authorized representatives) must be able to use health IT to view in accordance with the standard adopted at § 170.204(a)(1), at a minimum, the following data:

(1) The Common Clinical Data Set (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set).

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

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

(4) 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).

(5) 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 only human readable format, in only the format specified in accordance to the standard adopted at § 170.205(a)(4), or in both formats. The use of the “unstructured document” document-level template is prohibited for compliance with the standard adopted at § 170.205(a)(4).

(2) When downloaded according to the standard adopted at § 170.205(a)(4), 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 adopted at 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 at least one of the following:

(i) The standard specified in § 170.202(a).

(ii) Through a method that conforms to the standard specified at § 170.202(d) and leads to such summary being processed by a service that has implemented the standard specified in § 170.202(a).

(2) Inpatient setting only. Transmit transition of care/referral summaries (as a result of a transition of care/referral) selected by the patient (or their authorized representative) in accordance with at least one of the following:

(i) The standard specified in § 170.202(a).

(ii) Through a method that conforms to the standard specified at § 170.202(d) and leads to such summary being processed by a service that has implemented the standard specified in § 170.202(a).

(ii) Activity history log. (A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section or when an application requests electronic health information using the capability specified at paragraph (e)(1)(iii) of this section, the following information must be recorded and made accessible to the patient:

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

(2) The date and time each action occurred in accordance with the standard specified at § 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) Technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion adopted at §170.315(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient.

(iii) Application access. Patients (and their authorized representatives) must be able to use an application that can interact with the following capabilities. Additionally, the following technical outcomes and conditions must be met through the demonstration of an application programming interface (API) that can respond to requests from other applications for data specified within the Common Clinical Data Set. 

(A) Security. The API must include a means to establish a trusted connection with the application requesting patient data, including a means for the requesting application to register with the data source, be authorized to request data, and log all interactions between the application and the data source.

(B) Patient selection. The API must include a means for the application to query for an ID or other token of a patient’s record in order to subsequently execute data requests for that record in accordance with (e)(1)(iii)(C) of this section.

(C) Data requests, response scope, and return format. The API must enable and support both of the following data request interactions:

(1) Data-category request. The API must support syntax that allows it to respond to requests 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 either XML or JSON.

(2) All-request. The API must support syntax that allows it to respond to a request for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted according to the standard adopted at §170.205(a)(4).

(D) Documentation. 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).

(E) Terms of use. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements.

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

(i) Both the patient (or authorized representative) and technology user are authenticated; and

(ii) The message content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).

(f) Public health--(1) Transmission to immunization registries. (i) Technology must be able to 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)(3) for historical vaccines; and

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

(ii) Technology must 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--(i) Ambulatory setting only. (A) Technology must be able to create syndrome-based public health surveillance information for electronic transmission.

(B) Optional. Technology must be able to create syndrome-based public health surveillance information for electronic transmission that contains the following data:

(1) Patient demographics;

(2) Provider specialty;

(3) Provider address;

(4) Problem list;

(5) Vital signs;

(6) Laboratory test values/results;

(7) Procedures;

(8) Medication list; and

(9) Insurance.

(ii) Inpatient setting only. Technology must be able to 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. Technology must be able to 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)(2); and

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

(4) Transmission to cancer registries. Technology must be able to create cancer case information for electronic transmission in accordance with:

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

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

(5) Transmission to public health agencies – case reporting. Technology must be able to create case reporting information for electronic transmission in accordance with the standard specified in § 170.205(q)(1).

(6) Transmission to public health agencies – antimicrobial use and resistance reporting. Technology must be able to 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. Technology must be able to 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 meaningful use objective with a 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 meaningful use objective with a 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 meaningful use 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 (a)(1) through (10) and (18), (20), (22), (23), and (b)(2) through (4) of this section.

(ii) The following information must be submitted on the user-centered design processed used:

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

(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.

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

(A) Name and version of the product; 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) List of the specific metrics captured during the testing, including; 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);

(E) Test results for each task using metrics listed above in paragraphs (g)(3)(ii)(A) through (D) of this section;

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

(iv) 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 is:

(A) Compliant with a QMS established by the Federal government or a standards developing organization; or

(B) Mapped to one or more QMS established by the Federal government or standards developing organization(s).

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

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

(5) Accessibility technology compatibility. For each capability technology includes that is specified in the certification criteria at paragraphs (a), (b), and (e) of this section, the capability must be compatible with at least one accessibility technology that includes text-to-speech functionality.

(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 (iii) of this section can be demonstrated in tandem and do not need to be individually addressed in isolation or sequentially.

(i) Reference C-CDA match. Upon the entry of clinical data consistent with the Common Clinical Data Set, the technology must be able to create a data file formatted in accordance with each of the standards adopted in § 170.205(a)(3) and (4) that matches a gold-standard, reference data file.

(ii) Document-template conformance. Upon the entry of clinical data consistent with the Common Clinical Data Set, the technology must be able to create a data file formatted in accordance with each of the standards adopted in § 170.205(a)(3) and (4) that demonstrates a valid implementation of each of the following document templates (as applicable to the adopted standard):

(A) Generally applicable. CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; and Referral Note.

(B) Inpatient setting only. Discharge Summary.

(iii) Vocabulary conformance. Upon the entry of clinical data consistent with the Common Clinical Data Set, the technology must be able to create a data file formatted in accordance with each of the standards adopted in § 170.205(a)(3) and (4) that demonstrates the required vocabulary standards (and value sets) are properly implemented.

(7) Application access to Common Clinical Data Set. The following technical outcomes and conditions must be met through the demonstration of an application programming interface (API) that can respond to requests from other applications for data specified within the Common Clinical Data Set. 

(i) Security. The API must include a means to establish a trusted connection with the application requesting patient data, including a means for the requesting application to register with the data source, be authorized to request data, and log all interactions between the application and the data source. 

(ii) Patient selection. The API must include a means for the application to query for an ID or other token of a patient’s record in order to subsequently execute data requests for that record in accordance with paragraph (g)(7)(iii) of this section.

(iii) Data requests, response scope, and return format.  The API must enable and support both of the following data request interactions:

(A) Data-category request. The API must support syntax that allows it to respond to requests 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 either XML or JSON.

(B) All-request. The API must support syntax that allows it to respond to a request for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted according to the standard adopted at § 170.205(a)(4).

(iv) Documentation. The API must include accompanying documentation that contains, at a minimum:

(A) 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.

(B) 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).

(v) Terms of use. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements.

(8) 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) If a single accessibility-centered design standard or law was used for applicable capabilities, it would only need to be identified once.

(ii) If 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) If no accessibility-centered design standard or law was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion.

(h) Transport methods and other protocols--(1) Direct Project--(i) Applicability Statement for Secure Health Transport. Technology must be able to send and receive health information in accordance with the standards specified in § 170.202(a).

(ii) Optional – Applicability Statement for Secure Health Transport and Delivery Notification in Direct. Technology must be 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. Technology must be able to send and receive health information in accordance with:

(i) The standards specified in § 170.202(a);

(ii) The standard specified in § 170.202(b); and

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

(3) SOAP Transport and Security Specification and XDR/XDM for Direct Messaging. Technology must be able to send and receive health information in accordance with the standards specified in § 170.202(b) and (c).

(4) Healthcare provider directory – query request. In accordance with the standard specified in § 170.202(f)(1), technology must be able to make, at a minimum, the following queries to a directory and subsequently process the response returned:

(i) Query for an individual provider;

(ii) Query for an organizational provider;

(iii) Query for both individual and organizational providers in a single query; and

(iv) Query for relationships between individual and organizational providers.

(v) Optional- federation. In accordance with the standard specified in § 170.202(f)(1), technology must be able to process federated responses.

(5) Healthcare provider directory – query response. In accordance with the standard specified in § 170.202(f)(1), technology must be able to, at a minimum, respond to the following queries to a directory:

(i) Query for an individual provider;

(ii) Query for an organizational provider;

(iii) Query for both individual and organizational providers in a single query; and

(iv) Query for relationships between individual and organizational providers.

(v) Optional- federation. In accordance with the standard specified in § 170.202(f)(1), technology must be able to federate queries to other directories.

(i) Administrative--(1) Electronic submission of medical documentation--(i) Document templates. Health IT must be able to create electronic documents for transmission formatted according to the following standard and applicable implementation specifications adopted at § 170.205(a)(4) and (a)(5)(i). With respect to § 170.205(a)(5)(i):

(A) Health IT must be able to create the following document types regardless of the setting for which it is designed: Diagnostic Imaging Report; Unstructured Document; Enhanced Operative Note Document; Enhanced Procedure Note Document; and Interval Document.

(B) Ambulatory setting only. Health IT must be able to create an Enhanced Encounter Document.

(C) Inpatient setting only. Health IT must be able to create an Enhanced Hospitalization Document.

(ii) Digital signature. (A) Applying a digital signature. Technology must be able to apply a digital signature in accordance with the implementation specification adopted at § 170.205(a)(5)(ii) to a document formatted according to the following standard and applicable implementation specifications adopted at § 170.205(a)(4) and (a)(5)(i). It must also be able to demonstrate that it can support the method for delegation of right assertions.

(1) The cryptographic module used as part of the technology must: be validated to meet or exceed FIPS 140-2 Level 1; include a digital signature system and hashing that are compliant with FIPS 186-2 and FIPS 180-2; and store the private key in a FIPS-140-2 Level 1 validated cryptographic module using a FIPS-approved encryption algorithm. This requirement may be satisfied through documentation only.

(2) Technology must support multi-factor authentication that meets or exceeds Level 3 assurance as defined in NIST Special Publication 800-63-2.

(3) After ten minutes of inactivity, technology must require the certificate holder to re-authenticate to access the private key.

(4) If implemented as a software function, the system must clear the plain text private key from the system memory to prevent the unauthorized access to, or use of, the private key when the signing module is deactivated.

(5) Technology must record time and date consistent with the standard adopted at § 170.210(g).

(B) Validating a digital signature. Technology must be able validate a digital signature that has been applied to a document according to the implementation specification adopted at § 170.205(a)(5)(ii).

(iii) Author of record level 1. Using the same system capabilities expressed in paragraph (i)(1)(ii), technology must be able to apply a digital signature according to the implementation specification adopted at § 170.205(a)(5)(iii) to sign single or bundles of documents a document formatted according to the following standard and applicable implementation specifications adopted at § 170.205(a)(4) and (a)(5)(i).

(iv) Transactions. Using the same system capabilities expressed in paragraph (i)(1)(ii) of this section, technology must be able to apply a digital signature according to the implementation specification adopted at § 170.205(a)(5)(iv) to a transaction and include the signature as accompanying metadata in the signed transaction.

(2) [Reserved]