Long-Term Care-Nursing Homes EHR-Systems Functional Profile: Release 1

Direct Care Functions

PDF Version: http://aspe.hhs.gov/daltcp/reports/2008/LNEHRSFP1-dcf.pdf (87 PDF pages)


HL7 LTC-Nursing Home EHR-S Functional Profile (based on the HL7 EHR-S Functional Model, February 2007) -- Direct Care Functions

Priority Column: EN = Essential Now; EF = Essential Future; O = Optional

Functional Model (FM) Source Column -- Criteria Status is either: N/C = no change; A=added; M=modified; D = deleted. For new children functions, the FM Source columns is blank.

Blue, Underscored text = addition to text from the HL7 EHR-S Functional Model; Strikethrough text = HL7 EHR-S Functional Model text deleted for the LTC Functional Profile

ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1 H EN Care Management Description: Care Management functions (i.e., DC.1.x functions) are those directly used by providers as they deliver patient care and create an electronic health record. DC.1.1.x functions address the mechanics of creating a health record and concepts such as a single logical health record, managing patient demographics, and managing externally generated (including patient originated) health data. Thereafter, functions DC.1.2.x through DC.1.9.x follow a fairly typical flow of patient care activities and corresponding data, starting with managing the patient history and progressing through consents, assessments, care plans, orders, results, etc.

Integral to these care management activities is an underlying system foundation that maintains the privacy, security, and integrity of the captured health information -- the information infrastructure of the EHR-S. Throughout the DC functions, conformance criteria formalize the relationships to Information Infrastructure functions. Criteria that apply to all DC.1 functions are listed in this header (see Conformance Clause page six for discussion of “inherited” conformance criteria).

In the Direct Care functions there are times when actions/activities related to "patients" are also applicable to the patient representative. Therefore, in this section, the term “patient” could refer to the patient and/or the patient’s personal representative (e.g., guardian, surrogate). 		  1. The system SHALL conform to function IN.1.1 (Entity Authentication). 1 DC.1 1 N/C
2. The system SHALL conform to function IN.1.2 (Entity Authorization). 2 DC.1 2 N/C
3. The system SHALL conform to function IN.1.3 (Entity Access Control). 3 DC.1 3 N/C
4. IF the system is used to enter, modify or exchange data, THEN the system SHALL conform to function IN.1.5 (Non-Repudiation), to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data. 4 DC.1 4 N/C
5. IF the system exchanges data outside of a secure network, THEN the system SHALL conform to Function IN.1.6 (Secure Data Exchange), to ensure that the data are protected. 5 DC.1 5 N/C
6. IF the system exchanges data outside of a secure network, THEN the system SHALL conform to Function IN.1.7 10 (Secure Data Routing -LTC), to ensure that the exchange occurs only among authorized senders and receivers. 6 DC.1 6 M
7. IF the system is used to enter or modify data in the health record, THEN the system SHALL conform to function IN.1.8 (Information Attestation), to show authorship and responsibility for the data. 7 DC.1 7 N/C
8. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality). 8 DC.1 8 N/C
9. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction). 9 DC.1 9 N/C
10. The system SHOULD conform to function IN.2.3 (Synchronization). 10 DC.1 10 N/C
11. IF the system is used to extract data for analysis and reporting, THEN the system SHALL conform to function IN.2.4 (Extraction of Health Record Information), to support data extraction across the complete health record of an individual. 11 DC.1 11 N/C
12. IF the system stores unstructured data, THEN the system SHALL conform to function IN.2.5.1 (Manage Unstructured Health Record Information), to ensure data integrity through all changes. 12 DC.1 12 N/C
13. IF the system stores structured data, THEN the system SHALL conform to function IN.2.5.2 (Manage Structured Health Record Information), to ensure data integrity through all changes. 13 DC.1 13 N/C
14. The system SHOULD conform to function IN.3 (Registry and Directory Services). 14 DC.1 14 N/C
15. IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.1 (Standard Terminologies and Terminology Models), to support semantic interoperability. 15 DC.1 15 N/C
16. IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.2 (Maintenance and Versioning of Standard Terminologies), to preserve the semantics of coded data over time. 16 DC.1 16 N/C
17. The system SHOULD conform to function IN.4.3 (Terminology Mapping). 17 DC.1 17 N/C
18. IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.1 (Interchange Standards), to support interoperability. 18 DC.1 18 N/C
19. IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.2 (Interchange Standards Versioning and Maintenance), to accommodate the inevitable evolution of interchange standards. 19 DC.1 19 N/C
20. The system SHOULD conform to function IN.5.3 (Standards-based Application Integration). 20 DC.1 20 N/C
21. IF the system exchanges data with other systems outside itself, THEN the system SHALL conform to function IN.5.4 (Interchange Agreements), to define how the sender and receiver will exchange data. 21 DC.1 21 N/C
22. The system SHOULD conform to function IN.6 (Business Rules Management). 22 DC.1 22 N/C
23. The system SHOULD conform to function IN.7 (Workflow Management). 23 DC.1 23 N/C
24. The system SHALL conform to function S.2.2.1 (Health Record Output). 24 DC.1 24 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1 H EN Record Management Statement:

Description: For those functions related to data capture, data may be captured using standardized code sets or nomenclature, depending on the nature of the data, or captured as unstructured data. Care-setting dependent Data is entered by a variety of caregivers. Details of who entered data and when it was captured should be tracked. Data may also be captured from devices or other tele-health applications. 		S.3.1.4   25 DC.1.1   M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.1 F EN Identify and Maintain a Patient Record Statement: Identify and maintain a single patient record for each patient.

Description: A single record is needed for legal purposes, as well as to organize it unambiguously for the provider. Health information is captured and linked to the patient record. Static data elements as well as data elements that will change over time are maintained. The patient is uniquely identified, after which the record is tied to that patient. Combining information on the same patient, or separating information where it was inadvertently captured for the wrong patient, helps maintains health information for a single patient. In the process of creating a patient record, it is at times advantageous to replicate identical information across multiple records, so that such data does not have to be re-entered. For example, when a parent registers children as new patients, the address, guarantor, and insurance data may be propagated in the children's records without having to re-enter them. For example, when a couple (i.e., husband and wife) are registered as new patients, the address, guarantor, and insurance data may be propagated from the record of one spouse to the other without having to re-enter the data.		 S.1.4.1
S.2.2.1
S.3.1.2
S.3.1.5
IN.2.1
IN.2.3 		1. The system SHALL create a single logical record for each patient. 26 DC.1.1.1 1 N/C
2. The system SHALL provide the ability to create a record for a patient when the identity of the patient is unknown. 27 DC.1.1.1 2 N/C
3. The system SHALL provide the ability to store more than one identifier for each patient record. 28 DC.1.1.1 3 N/C
4. The system SHALL associate key identifier information (e.g., system ID, medical record number) with each patient record. 29 DC.1.1.1 4 N/C
5. The system SHALL provide the ability to uniquely identify a patient and tie the record to a single patient. 30 DC.1.1.1 5 N/C
6. The system SHALL provide the ability, through a controlled method, to merge or link dispersed information for an individual patient upon recognizing the identity of the patient. 31 DC.1.1.1 6 N/C
7. IF health information has been mistakenly associated with a patient, THEN the system SHALL provide the ability to mark the information as erroneous in the record of the patient in which it was mistakenly associated and represent that information as erroneous in all outputs containing that information. 32 DC.1.1.1 7 N/C
8. IF health information has been mistakenly associated with a patient, THEN the system SHALL provide the ability to associate it with the correct patient. 33 DC.1.1.1 8 N/C
9. The system SHALL provide the ability to retrieve parts of a patient record using a primary identifier, secondary identifiers, or other information which are not identifiers, but could be used to help identify the patient. 34 DC.1.1.1 9 N/C
10. The system SHOULD SHALL provide the ability to obsolete, inactivate, nullify, destroy and archive a patient's record in accordance with local policies and procedures, as well as applicable laws and regulations. 35 DC.1.1.1 10 M
11. IF related patients register with any identical data, THEN the system SHOULD MAY provide the ability to propagate that data to all their records. 36 DC.1.1.1 11 M
12. The system SHALL conform to function IN.2.2 (Auditable Records). 37 DC.1.1.1 12 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.2 F EN Manage Patient Demographics Statement: Capture and maintain demographic information. Where appropriate, the data should be clinically relevant and reportable.

Description: Contact information including addresses and phone numbers, as well as key demographic information such as date of birth, time of birth, gestation, gender, and other information is stored and maintained for unique patient identification, reporting purposes and for the provision of care. Patient demographics are captured and maintained as discrete fields (e.g., patient names and addresses) and may be enumerated, numeric or codified. Key patient identifiers are shown on all patient information output (such as name and ID# on each screen of a patient's record). The system will track who updates demographic information, and when the demographic information is updated. 		S.1.4.1
S.2.2.2
IN.2.2
IN.2.4 		1. The system SHALL capture demographic information as part of the patient record. 38 DC.1.1.2 1 N/C
2. The system SHALL store and retrieve demographic information as discrete data. 39 DC.1.1.2 2 N/C
3. The system SHALL provide the ability to retrieve demographic data as part of the patient record. 40 DC.1.1.2 3 N/C
4. The system SHALL provide the ability to update demographic data. 41 DC.1.1.2 4 N/C
5. The system SHOULD SHALL provide the ability to report demographic data. 42 DC.1.1.2 5 M
6. The system SHOULD SHALL store historical values of demographic data over time. 43 DC.1.1.2 6 M
7. The system SHALL present a set of patient identifying information at each interaction with the patient record. 44 DC.1.1.2 7 N/C
8. The system SHOULD conform to function IN.1.4 (Patient Access Management). 45 DC.1.1.2 8 N/C
9. The system SHALL conform to function IN.2.2 (Auditable Records). 46 DC.1.1.2 9 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.3 H EN Data and Documentation from External Sources Description: External sources are those outside the EHR system, including clinical, administrative, and financial information systems, other EHR systems, PHR systems, and data received through health information exchange networks.   1. The system SHOULD conform to function IN.1.4 (Patient Access Management). 47 DC.1.1.3 1 N/C
2. The system SHALL conform to function IN.2.2 (Auditable Records). 48 DC.1.1.3 2 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.3.1 F EN Capture Data and Documentation from External Clinical Sources Statement: Incorporate clinical data and documentation from external sources.

Description: Mechanisms are available for capturing and incorporating external clinical data and documentation (including identification of source) such as image documents and other clinically relevant data are available. This covers all types of data and documents received by the nursing facility that would typically be incorporated into a medical record, including but not limited to faxes, referral authorizations, consultant reports, and patient/resident correspondence of a clinical nature. (cc#1)

Intrinsic to the concept of electronic health records is the ability to exchange health information with other providers of health care services. Health information from these external sources needs to be received, stored in the patient record, and displayed upon request. External data and documents addressed in the function include:
  1. Lab results received through an electronic interface -- This information is to be received and stored in the resident record as discrete data, which means that each separate element of the data needs to be stored in is own field. Therefore, if lab results are received through an electronic interface, the results are received in the EHR and the lab test name, result (value), and unit of measure are correctly displayed as discrete data (vs. report format). (cc#2 & #3)
  2. Scanned documents received and stored as images (i.e. power of attorney forms, Living wills, etc.) -- These scanned documents are indexed and can be retrieved based on the document type, date of the original document, and the date of scanning. (cc#4 & cc#4a)
  3. Text-based outside reports (i.e., x-ray reports, hospital discharge summaries, history & physicals) -- Any mechanism for capturing these reports is acceptable: OCR, PDF, image file of report, etc. (cc#6)
  4. Clinical images from an external source (i.e., radiographic images, digital images from a diagnostic scan or graphical images) -- These images may be stored within the system or be provided through direct linkage to an external source such as a hospital PACS system. (cc#7)
  5. Other forms of clinical results, such as wave files of EKG tracings (cc#8)
  6. Medication detail (i.e., a medication history) from an external source such as a retail pharmacy, the patient, or another provider -- While the medication detail includes the medication name, strength, and SIG, this does not imply that the data will populate the medication module. (cc#9)
  7. Structured, text-based reports (such as medical summary text in a structured format) (cc#10)
  8. Standards-based structured, codified data (such as a Continuity of Care Record with SNOMED CT) (cc#11)
Data incorporated through these mechanisms is presented alongside locally captured documentation and notes wherever appropriate. 		IN.1.5
IN.1.6
IN.1.7
IN.1.8
IN.2.1
IN.2.2
IN.4.2
IN.4.3
IN.5.1
IN.5.2 		1. The system SHALL provide the ability to capture external data and documentation. 49 DC.1.1.3.1 1 N/C
2. IF lab results are received through an electronic interface, THEN the system SHALL receive and store the data elements into the patient record. 50 DC.1.1.3.1 2 N/C
3. IF lab results are received through an electronic interface, THEN the system SHALL display them upon request. 51 DC.1.1.3.1 3 N/C
4. The system SHOULD SHALL provide the ability to receive, store and display scanned documents as images. 52 DC.1.1.3.1 4 M
4a. The system SHALL provide the ability to index and retrieve scanned documents as images based on the document type, the date of the original document and the date of scanning 53 DC.1.1.3.1   A
5. The system MAY provide the ability to store imaged documents or reference the imaged documents via links to imaging systems. 54 DC.1.1.3.1 5 N/C
6. The system SHOULD provide the ability to receive, store and present text-based externally-sourced documents and reports. 55 DC.1.1.3.1 6 N/C
7. The system SHOULD provide the ability to receive, store and display clinical result images (such as radiologic images) received from an external source. 56 DC.1.1.3.1 7 N/C
8. The system SHOULD provide the ability to receive, store and display other forms of clinical results (such as wave files of EKG tracings) received from an external source. 57 DC.1.1.3.1 8 N/C
9. The system SHOULD SHALL provide the ability to receive, store and present medication details from an external source. 58 DC.1.1.3.1 9 M
10. The system SHOULD provide the ability to receive, store and present structured text-based reports received from an external source. 59 DC.1.1.3.1 10 N/C
11. The system SHOULD provide the ability to receive, store and present standards-based structured, codified data received from an external source. 60 DC.1.1.3.1 11 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.3.2 F EF 2010 Capture Patient-Originated Data Statement: Capture and explicitly label patient originated data, link the data source with the data, and support provider authentication for inclusion in patient health record.

Description: It is critically important to be able to distinguish clinically authored and authenticated data from patient-originated data that is either provided by the patient for inclusion in the EHR or entered directly into the EHR by the patient from clinically authenticated data. Patients may provide data for entry into the health record or be given a mechanism for entering this data directly. Patient-originated data intended for use by providers will be available for their use.

Data about the patient may be appropriately provided by:
  1. the patient
  2. a surrogate (parent, spouse, guardian) or
  3. an informant (teacher, lawyer, case worker).
An electronic health record may provide the ability for direct data entry by any of these.

Patient-originated data may also be captured by devices and transmitted for inclusion into the electronic health record.

Data entered by any of these must be stored with source information. A provider must authenticate patient-originated data included in the patient's legal health record. A provider must be able to indicate they have verified the accuracy of patient-originated data (when appropriate and when a verification source is available) for inclusion in the patient record. Such verification does not have to occur at each individual data field and can be at a higher level of the data. 		IN.1.4
IN.2.5.1
IN.2.5.2 		1. The system SHALL capture and explicitly label patient- originated data. 61 DC.1.1.3.2 1 N/C
1a. The system SHALL provide the ability to capture patient originated data including, but not limited to, demographics, past medical history, medications, and allergies. 62     A
2. IF the system provides the ability for direct entry by the patient, THEN the system SHALL explicitly label the data as patient entered. 63 DC.1.1.3.2 2 N/C
3. The system SHALL capture and label the source of clinical data provided on behalf of the patient. 64 DC.1.1.3.2 3 N/C
4. The system SHALL present patient-originated data for use by care providers. 65 DC.1.1.3.2 4 N/C
5. The system SHALL provide the ability for a provider to verify indicate they have verified the accuracy of patient-originated data (when appropriate and when a verification source is available) for inclusion in the patient record. 66 DC.1.1.3.2 5 M
6. The system SHOULD SHALL provide the ability to view or and comment, but not alter patient-originated data. 67 DC.1.1.3.2 6 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.3.3 F EN Capture Patient Health Data Derived from Administrative and Financial Data and Documentation Statement: Capture and explicitly label patient health data derived from administrative or financial data; and link the data source with that data.

Description: It is critically important to be able to distinguish patient health data derived from administrative or financial data from clinically authenticated data. Sources of administrative and financial data relating to a patient's health may provide this data for entry into the health record or be given a mechanism for entering this data directly. The data must be explicitly labeled as derived from administrative or financial data, and information about the source must be linked with that data.

Patient health data that is derived from administrative or financial data may be provided by:
  1. the patient
  2. a provider
  3. a payer, or
  4. entities that transmit or process administrative or financial data.
Since this data is non-clinical, it may not be authenticated for inclusion in the patient's legal health record. Registration data, which may contain demographic data and pertinent positive and negative histories, is an example of administrative and financial data that may be captured. 		DC.1.1.2
DC.1.2
S.1.4.1 		1. The system SHALL provide the ability to capture and label patient health data derived from administrative or financial data. 68 DC.1.1.3.3 1 N/C
2. The system SHALL provide the ability to capture and link data about the source of patient health data derived from administrative and financial data with that patient data. 69 DC.1.1.3.3 2 N/C
3. The system SHALL provide the ability to present labeled patient health information derived from administrative or financial data and the source of that data for use by authorized users. 70 DC.1.1.3.3 3 N/C
4. The system SHOULD provide the ability to view health information data and or comment on patient health information records or documents derived from administrative or financial data. 71 DC.1.1.3.3 4 M
4a. The system SHALL provide the ability to correct administrative and financial data. 72     A
5. The system SHOULD provide the ability to request correction from the external source of the administrative or financial data. 73 DC.1.1.3.3 5 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.4 F EN Produce a Summary Record of Care Statement: Present a summarized review of a patient's comprehensive EHR, subject to jurisdictional laws and organizational policies related to privacy and confidentiality.

Description: Create summary views and reports at the conclusion of an episode of care. Summarized views and reports of the episode of care must support requirements in the CMS State Operations Manual for a discharge summary and should support other secondary uses of information such as public health reporting. In addition, summarized health information must be produced as an HL7 compliant Continuity of Care Document (CCD) in order to support interoperable exchange of health information with other care providers. Output of the CCD should be supported in electronic and paper formats. At a minimum, the CCD must contain content for the Advance Directives, Problems, Alerts, and Medications sections.
  • The Advance Directives section of the CCD contains data defining the patient's advance directives and any reference to supporting documentation. The most recent and up-to-date directives are required, if known, and should be listed in as much detail as possible. This section contains data such as the existence of living wills, healthcare proxies, and CPR and resuscitation status. If referenced documents are available, they can be included in the CCD exchange package.
  • The "Problems" section of the CCD lists and describes all relevant clinical problems at the time the summary is generated. At a minimum, all pertinent current and historical problems should be listed.
  • The "Alerts" section of the CCD is used to list and describe any allergies, adverse reactions, and alerts that are pertinent to the patient's current or past medical history. At a minimum, currently active and any relevant historical allergies and adverse reactions should be listed.
  • The "Medications" section of the CCD defines a patient's current medications and pertinent medication history. At a minimum, the currently active medications should be listed, with an entire medication history as an option, particularly when the summary document is used for comprehensive data export. The section may also include a patient's prescription history, and enables the determination of the source of a medication list (e.g., from a pharmacy system vs. from the patient).
It is strongly recommended that the CCD contain content for the Functional Status, Immunizations, Medical Equipment, and Plan of Care sections.

Create Service reports created at the completion of an episode of care such as, but not limited to, discharge summaries and public health reports, should be compiled without requiring additional input from clinicians. 		S.2.2.1
IN.1.9
IN.2.4
IN.2.5.1
IN.2.5.2 		1. The system SHALL present summarized views and reports of the patient's comprehensive EHR, including, but not limited to, discharge summary requirements as stated in the CMS State Operations Manual. 74 DC.1.1.4 1 M
2. The system SHOULD include at least the following in the summary: problem list, medication list, allergy and adverse reaction list. 75 DC.1.1.4 2 D
2a. The system SHALL create an HL7 compliant Continuity of Care Document (CCD). 76     A
2b. The system SHALL provide the ability to produce a CCD that includes at least the following sections: Advance Directives, Problems, Alerts, and Medications. 77     A
2c. The system SHOULD provide the ability to produce a CCD that includes the following sections: Functional Status, Immunizations, Medical Equipment and Plan of Care. 78     A
2d. The system SHOULD provide the ability to populate the following sections of an HL7 compliant CCD without requiring additional input from clinicians: Advance Directives, Problems, Alerts, and Medications. 79     A
2e. IF federally mandated assessments are included in the Functional Status section of the CCD, THEN those assessments SHOULD comply with NCVHS/CHI endorsed standards for the representation of the assessment and vocabulary content. 80     A
3. The system SHOULD conform to function S.3.3.6 (Health Service Reports at the Conclusion of an Episode of Care). 81 DC.1.1.4 3 N/C
4. The system SHOULD conform to function IN.1.4 (Patient Access Management). 82 DC.1.1.4 4 N/C
5. The system SHALL conform to function IN.2.2 (Auditable Records). 83 DC.1.1.4 5 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.1.5 F EN Present Ad Hoc Views of the Health Record Statement: Subject to jurisdictional laws and organizational policies related to privacy and confidentiality, present customized views and summarized information from a patient's comprehensive EHR. The view may be arranged chronologically, by problem, or other parameters, and may be filtered or sorted.

Description: A key feature of an electronic health record is its ability to support the delivery of care by enabling prior information to be found and meaningfully displayed. EHR systems should facilitate search, filtering, summarization, and presentation of available data needed for patient care. Systems should enable views to be customized, for example, specific data may be organized chronologically, by clinical category, or by consultant, or by discipline, depending on need. Jurisdictional laws and organizational policies that prohibit certain users from accessing certain patient information must be supported.		 S.1.8
S.2.2.3
S.3.1.1
IN.1.3
IN.1.6
IN.1.7
IN.1.9
IN.2.4
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.5.4
IN.6 		1. The system SHALL provide the ability to create views that prohibit patients from accessing certain information according to organizational policy, scope of practice, and jurisdictional law. 84 DC.1.1.5 1 N/C
2. The system SHOULD SHALL provide the ability to create customized views of summarized information based on sort and filter controls for date or date range, problem, or other clinical parameters. 85 DC.1.1.5 2 M
3. The system SHOULD SHALL provide the ability to access summarized information through customized views based on prioritization of chronology, problem, or other pertinent clinical parameters. 86 DC.1.1.5 3 M
4. The system SHOULD conform to function IN.1.4 (Patient Access Management). 87 DC.1.1.5 4 N/C
5. The system SHALL conform to function IN.2.2 (Auditable Records). 88 DC.1.1.5 5 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.2 F EN Manage Patient History Statement: Capture and maintain medical, procedural/surgical, social and family history including the capture of pertinent positive and negative histories, patient-reported or externally available patient clinical history.

Description: The history of the current illness and patient historical data related to previous medical diagnoses, surgeries and other procedures performed on the patient, and relevant health conditions of family members is captured through such methods as patient reporting (for example interview, medical alert band) or electronic or non-electronic historical data. This data may take the form of a pertinent positive such as: "The patient/family member has had..." or a pertinent negative such as "The patient/family member has not had..." When first seen by a health care provider, patients typically bring with them clinical information from past encounters. This and similar information is captured and presented alongside locally captured documentation and notes wherever appropriate.		 S.2.2.1
S.3.5
IN.1.7
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.5.4 		1. The system SHALL provide the ability to capture, update and present current patient history including pertinent positive and negative elements. 89 DC.1.2 1 N/C
1a. The system SHALL provide the ability to capture structured data in the patient history. 90     A
2. The system SHOULD SHALL provide the ability to capture and present previous external patient histories in compliance with Function DC.1.3.1.1 (Capture Data and Documentation from External Clinical Sources). 91 DC.1.2 2 M
3. The system MAY provide the ability to capture the relationship between patient and others. 92 DC.1.2 3 N/C
4. The system SHALL capture the complaint, presenting problem or other reason(s) for the visit or encounter. 93 DC.1.2 4 N/C
5. The system SHOULD SHALL provide the ability to capture the reason for visit/encounter from the patient's perspective. 94 DC.1.2 5 M
6. The system SHOULD conform to function IN.1.4 (Patient Access Management). 95 DC.1.2 6 N/C
7. The system SHALL conform to function IN.2.2 (Auditable Records). 96 DC.1.2 7 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.3 H EN Preferences, Directives, Consents and Authorizations Description: In the Preferences, Directives, Consents and Authorizations functions there are times when actions/activities related to "patients" are also applicable to the patient representative. Therefore, in this section, the term "patient" could refer to the patient and/or the patient's personal representative (i.e., guardian, surrogate, proxy, health care agent).   1. The system SHOULD conform to function IN.1.4 (Patient Access Management). 97 DC.1.3 1 N/C
2. The system SHALL conform to function IN.2.2 (Auditable Records). 98 DC.1.3 2 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.3.1 F EN Manage Patient and Family Preferences Statement: Capture and maintain patient and family preferences.

Description: Patient and family preferences regarding issues such as language, religion, spiritual practices and culture -- may be important to the delivery of care. It is important to capture these so that they will be available to the provider at the point of care. 		DC.2.1.4
S.3.7.1
IN.2.5.1
IN.2.5.2
IN.6 		1. The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions patient preferences such as language, religion, spiritual practices and cultural practices. 99 DC.1.3.1 1 M
2. The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions family preferences such as language, religion, spiritual practices and cultural practices. 100 DC.1.3.1 2 M
3. The system SHOULD conform to function DC.2.1.4 (Support for Patient and Family Preferences), and incorporate patient and family preferences into decision support systems. 101 DC.1.3.1 3 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.3.2 F EN Manage Patient Advance Directives Statement: Capture and maintain patient advance directives.

Description: Patient advance directives and provider DNR orders are captured as well as the date and circumstances under which the directives were received, and the location of any paper records or legal documentation (e.g., the original) of advance directives as appropriate.		 S.3.5.1
S.3.5.3
S.3.5.4
IN.1.5
IN.1.8
IN.1.9
IN.2.2
IN.2.5.1
IN.2.5.2
IN.6 		1. The system SHALL provide the ability to indicate that advance directives exist for the patient. 102 DC.1.3.2 1 N/C
2. The system SHALL provide the ability to indicate the type of advance directives completed for the patient such as living will, durable power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order". 103 DC.1.3.2 2 N/C
3. The system SHOULD SHALL provide the ability to capture, present, maintain and make available for clinical decisions patient advance directives documents and "Do Not Resuscitate" orders. 104 DC.1.3.2 3 M
4. The system SHOULD SHALL conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and capture scanned patient advance directive documents and "Do Not Resuscitate" orders. 105 DC.1.3.2 4 M
5. The system SHOULD SHALL provide the ability to indicate when advanced directives were last reviewed. 106 DC.1.3.2 5 M
6. The system SHOULD SHALL provide the ability to indicate the name and relationship of the party completing the advance directive for the patient. 107 DC.1.3.2 6 M
7. The system SHALL time and date stamp the entry of advance directives information. 108 DC.1.3.2 7 M
7a. The system SHOULD provide the ability to capture the date and/or time a paper advance directives document was signed/completed. 109     A
7b. The system SHOULD provide the ability to capture the date and/or time advance directive information was received by the provider. 110     A
8. The system SHOULD SHALL provide the ability to document the location and or source of any legal documentation regarding advance directives. 111 DC.1.3.2 8 M
9. The system SHOULD conform to function DC.2.1.4 (Support for Patient and Family Preferences). 112 DC.1.3.2 9 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.3.3 F EN Manage Consents and Authorizations Statement: Create, maintain, and verify patient decisions such as informed consent for treatment and authorization/consent for disclosure when required.

Description: Decisions are documented and include the extent of information, verification levels and exposition of treatment options. This documentation helps ensure that decisions made at the discretion of the patient, family, or other responsible party, govern the actual care that is delivered or withheld.

There may be several documents active at any one time that may govern a patient's care. Both clinical and administrative consents and authorizations are considered part of this function. A consent or authorization includes patient authorization for re-disclosure of sensitive information to third parties.

Consents/Authorizations for printing should include appropriate standardized forms for patients, guardians, foster parents. The system must appropriately present forms for adolescents according to privacy rules.

Some states may mandate assent. Assent is agreement by the patient to participate in services when they are legally unable to consent (e.g., an adolescent, an adult with early dementia). 		DC.1.1.3
S.2.2.2
S.3.5.1
S.3.5.4
IN.1.5
IN.1.8
IN.1.9
IN.2.2
IN.2.4
IN.2.5.1
IN.2.5.2
IN.6 		1. The system SHALL provide the ability to indicate that a patient has completed applicable consents and authorizations. 113 DC.1.3.3 1 N/C
2. The system SHALL provide the ability to indicate that a patient has withdrawn applicable consents and authorizations. 114 DC.1.3.3 2 N/C
3. The system SHOULD SHALL conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and capture scanned paper consent and authorization documents. 115 DC.1.3.3 3 M
4. The system SHOULD provide the ability to view and complete consent and authorization forms on-line electronically. 116 DC.1.3.3 4 M
4a. IF the system provides the ability to complete consents and authorizations electronically, THEN the system SHALL provide the ability for patients to electronically sign consent and authorization forms in conformance with IN.1.8 (Information Attestation). 117     A
5. The system MAY provide the ability to generate printable consent and authorization forms form templates. 118 DC.1.3.3 5 M
5a. IF the system allows completion of electronic authorizations and consents, THEN the system SHALL provide the ability to generate printable consent and authorization form templates. 119     A
6. The system MAY display the consents and authorizations associated with a specific clinical activity, such as treatment (e.g., immunizations) or surgery (e.g., wound debridement), along with that event in the patient's electronic chart. 120 DC.1.3.3 6 M
7. The system MAY SHALL provide the ability to sort and display consents and authorizations chronologically, reverse chronologically, and by type. 121 DC.1.3.3 7 M
8. The system SHOULD MAY provide the ability to document an assent for patients legally unable to consent. 122 DC.1.3.3 8 M
9. IF the system provides the ability to complete consents and authorizations electronically, THEN the system SHALL provide the ability to document the source of each consent and authorization, such as the patient or the patient's personal representative if the patient is legally unable to provide it. 123 DC.1.3.3 9 M
10. IF the system provides the ability to complete consents and authorizations electronically, THEN the system SHOULD SHALL provide the ability to document the patient's personal representative's level of authority to make decisions on behalf of the patient. 124 DC.1.3.3 10 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.4 H EN Summary Lists Summary lists are used to present succinct "snapshots" of critical health information such as allergy, medication, problem, and immunization lists. S.2.2.2
IN.2.4
IN.2.5.1
IN.2.5.2 		1. The system SHOULD conform to function IN.1.4 (Patient Access Management). 125 DC.1.4 1 N/C
2. The system SHALL conform to function IN.2.2 (Auditable Records). 126 DC.1.4 2 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.4.1 F EN Manage Allergy, Intolerance and Adverse Reaction List Statement: Create and maintain patient-specific allergy, intolerance and adverse reaction lists.

Description: Allergens, including immunizations, and substances are identified and coded (whenever possible) and the list is captured and maintained over time. All pertinent dates, including patient-reported events, are stored and the description of the patient allergy and adverse reaction is modifiable over time. The entire allergy history, including reaction, for any allergen is viewable. The list(s) includes all reactions including those that are classifiable as a true allergy, intolerance, side effect or other adverse reaction to drug, dietary or environmental triggers. Notations indicating whether item is patient reported and/or provider verified are maintained. 		DC.2.3.1.1
S.2.2.1
S.2.2.3
S.3.7.1
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.6 		1. The system SHALL provide the ability to capture true allergy, intolerance, and adverse reaction to drug, dietary or environmental triggers as unique, discrete entries. 127 DC.1.4.1 1 N/C
2. The system SHOULD provide the ability to capture the reason for entry of the allergy, intolerance or adverse reaction. 128 DC.1.4.1 2 N/C
3. The system SHALL provide the ability to capture the reaction type. 129 DC.1.4.1 3 N/C
4. The system SHOULD provide the ability to capture the severity of a reaction. 130 DC.1.4.1 4 N/C
5. The system SHALL provide the ability to capture a report of No Known Allergies (NKA) for the patient. 131 DC.1.4.1 5 N/C
6. The system SHOULD SHALL provide the ability to capture a report of No Known Drug Allergies (NKDA) for the patient. 132 DC.1.4.1 6 M
7. The system SHOULD provide the ability to capture the source of allergy, intolerance, and adverse reaction information. 133 DC.1.4.1 7 N/C
8. The system SHALL provide the ability to deactivate an item on the list. 134 DC.1.4.1 8 N/C
9. The system SHALL provide the ability to capture the reason for deactivation of an item on the list. 135 DC.1.4.1 9 N/C
10. The system may SHALL provide the ability to present allergies, intolerances and adverse reactions that have been deactivated as well as the reason for deactivation. 136 DC.1.4.1 10 M
10a. The system SHALL provide the ability to record the identity of the user who added, modified, inactivated, or removed items from the allergy list, including attributes of the changed items. 137     A
11. The system MAY SHOULD provide the ability to display user defined sort order of list. 138 DC.1.4.1 11 M
12. The system SHOULD provide the ability to indicate that the list of allergies to medications and other agents has been reviewed. 139 DC.1.4.1 12 M
13. They system SHALL provide the ability to capture and display the date on which allergy information was entered. 140 DC.1.4.1 13 N/C
14. The system SHOULD provide the ability to capture and display the approximate date of the allergy occurrence. 141 DC.1.4.1 14 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.4.2 F EN Manage Medication List Statement: Create and maintain patient-specific medication lists.

Description: Medication lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. All pertinent dates, including medication start, modification, and end dates are stored. The entire medication history for any medication, including alternative supplements and herbal medications, is viewable. Medication lists are not limited to medication orders recorded by providers, but may include, for example, pharmacy dispense/supply records, patient-reported medications and additional information such as age specific dosage.		 S.2.2.1
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.5.4
IN.6 		1. The system SHALL provide the ability to capture patient-specific medication lists. 142 DC.1.4.2 1 N/C
2. The system SHALL display and report patient-specific medication lists. 143 DC.1.4.2 2 N/C
3. The system SHALL provide the ability to capture the details of the medication such as ordering date, dose, route, and SIG (description of the prescription, such as the quantity) when known. 144 DC.1.4.2 3 N/C
4. The system SHOULD SHALL provide the ability to capture other dates associated with medications such as start and end dates. 145 DC.1.4.2 4 M
5. The system SHALL provide the ability to capture medications not reported on existing medication lists or medication histories. 146 DC.1.4.2 5 N/C
6. The system SHALL provide the ability to capture non-prescription medications including over the counter and complementary medications such as vitamins, herbs and supplements. 147 DC.1.4.2 6 N/C
7. The system SHALL present the current medication lists associated with a patient. 148 DC.1.4.2 7 N/C
8. The system SHOULD SHALL have the ability to present the medication history associated with a patient. 149 DC.1.4.2 8 M
9. The system SHALL present the medication, prescriber, and medication ordering dates when known. 150 DC.1.4.2 9 N/C
10. The system SHALL provide the ability to mark a medication as erroneously captured and exclude should be excluded from the presentation of current medications. 151 DC.1.4.2 10 M
11. The system SHALL provide the ability to print a current medication list for patient use. 152 DC.1.4.2 11 N/C
12. The system MAY provide the ability to capture information regarding the filling of prescriptions (dispensation of medications by pharmacies or other providers). 153 DC.1.4.2 12 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.4.3 F EN Manage Problem List Statement: Create and maintain patient-specific problem lists.

Description: A problem list includes at a minimum the patient's active and historical diagnoses, and any problems/needs identified on the care plan. A problem list. It may also include, but is not limited to: other chronic conditions, diagnoses, or symptoms, functional limitations, visit or stay-specific conditions, diagnoses, or symptoms or family and situational conditions adversely impacting the patient. Problem lists are managed over time, whether over the course of a visit or stay or the life of a patient, allowing documentation of historical information and tracking the changing character of problem(s) and their priority. The source (e.g., the provider, the system ID, or the patient) of the updates should be documented. In addition all pertinent dates are stored All pertinent dates are stored, including date noted or diagnosed, dates of any changes in problem specification or prioritization, and date of resolution. This might include time stamps, where useful and appropriate. The entire problem history for any problem in the list is viewable. 		DC.2.1.3
S.2.2.1
S.3.3.5
IN.2.4
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.6 		1. The system SHALL capture, display and report all active problems associated with a patient. 154 DC.1.4.3 1 N/C
2. The system SHALL capture, display and report a history of all problems associated with a patient. 155 DC.1.4.3 2 N/C
3. The system SHALL provide the ability to capture onset date of problem when known. 156 DC.1.4.3 3 M
4. The system SHOULD provide the ability to capture the chronicity (chronic, acute/self-limiting, etc.) of a problem. 157 DC.1.4.3 4 N/C
5. The system SHALL provide the ability to capture the source, date and time of all updates to the problem list. 158 DC.1.4.3 5 N/C
6. The system SHALL provide the ability to deactivate a problem. 159 DC.1.4.3 6 N/C
7. The system MAY provide the ability to re-activate a previously deactivated problem. 160 DC.1.4.3 7 N/C
8. The system SHOULD SHALL provide the ability to display inactive and/or resolved problems. 161 DC.1.4.3 8 M
9. The system SHOULD SHALL provide the ability to manually order/sort the problem list. 162 DC.1.4.3 9 M
10. The system MAY SHOULD provide the ability to associate problems with other clinical items or events (for example: encounters, orders, medications and notes). with one or more problems 163 DC.1.4.3 10 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.4.4 F EN Manage Immunization List Statement: Create and maintain patient-specific immunization lists.

Description: Immunization lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. Details of immunizations administered are captured as discrete data elements including date, type, manufacturer and lot number. The entire immunization history is viewable. 		  1. The system SHALL capture, display and report all immunizations associated with a patient 164 DC.1.4.4 1 N/C
2. The system SHALL record as discrete data elements data associated with any immunization given including date, type, lot number and manufacturer 165 DC.1.4.4 2 N/C
3. The system SHOULD provide the ability to prepare a report of a patient's immunization history upon request for appropriate authorities such as schools or day-care centers. 166 DC.1.4.4 3 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.5 F EN Manage Assessments Statement: Create and maintain assessments.

Description: During an encounter with a patient, the provider will conduct an assessment that is germane to the age, gender, developmental or functional state, medical and behavioral condition of the patient, such as growth charts, developmental profiles, and disease specific assessments. Wherever possible, this assessment should follow industry standard protocols although, for example, an assessment for an infant will have different content than one for an elderly patient. When a specific standard assessment does not exist, a unique assessment can be created, using the format and data elements of similar standard assessments whenever possible.

The EHR-S must be able to provide users with the clinically appropriate and regulatory mandated assessments required to be completed during a patient stay. To support this, the system must allow providers to create, maintain, and make available for clinician use:
  • user-defined assessments reflecting assessment content and protocols as per facility policy (such as Nursing Admission assessments, Dietary admission assessments, Physical Therapy evaluations, etc.), and
  • standard assessments reflecting assessment content and protocols as per industry and professional standards of practice (such as the Geriatric Depression Scale, AIMS, Mini-Mental, Falls Risk Assessment, etc.)
In addition, the EHR-S must maintain and make available for clinician use any standardized assessment instruments (such as the MDS) that are required by jurisdictional regulation.

The EHR-S must provide the ability for clinicians to complete these assessments (user-defined assessments, standard assessments, and standardized assessment instruments) and maintain them as part of the electronic patient record. The EHR-S should provide the ability to capture additional data to augment an assessment as necessary, and should link data from the assessment to the patient's problem list and care plan.		 DC.1.5
DC.1.6.2
DC.1.10.1
DC.2.1.1
DC.2.1.2
DC.2.2.1
S.2.2.1
IN.1.6
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.6 		1. The system SHALL provide the ability to create "user-defined" and standard assessments for clinician use in assessing patient condition. 167 DC.1.5 1 M
2. The system SHOULD SHALL provide the ability to use complete, maintain and transmit standardized assessment instruments (such as the Minimum Data Set) where they exist as mandated by jurisdictional regulations. 168 DC.1.5 2 M
3. The system SHOULD SHALL provide the ability to document using complete and maintain "user-defined" and standard assessments germane to the age, gender, developmental state, and health condition as appropriate to the EHR user's scope of practice of resident condition as required by:
  1. the Conditions of Participation for Medicare and Medicaid (i.e., assessments related to resident risk of dehydration, unintended weight loss, or pressure ulcers),
  2. jurisdictional regulations,
  3. professional standards of practice, and
  4. facility policy.
 169 DC.1.5 3 M
4. The system SHOULD provide the ability to capture data relevant to standard assessment . 170 DC.1.5 4 D
5. The system SHOULD provide the ability to capture additional data to augment the standard assessments relative to variances in medical conditions. 171 DC.1.5 5 M
6. The system SHOULD provide the ability to link data from an standard assessment to a problem list. 172 DC.1.5 6 M
7. The system SHOULD provide the ability to link data from an standard assessment to an individual care plan. 173 DC.1.5 7 M
8. The system MAY provide the ability to link data from external sources, laboratory results, and radiographic results to the standard an assessment. 174 DC.1.5 8 M
9. The system SHOULD MAY provide the ability to compare documented data against standardized curves and display the trends. 175 DC.1.5 9 M
9a. The system SHOULD conform to function DC.2.1.1 (Support for Standard Assessments). 176     A
9b. The system SHOULD conform to function DC.2.1.2 (Support for Patient Context-Driven Assessments). 177     A
9c. The system SHALL provide the ability to retrieve prior versions of completed user-defined and standard assessments. 178     A
10. The system SHOULD conform to function IN.1.4 (Patient Access Management). 179 DC.1.5 10 N/C
11. The system SHALL conform to function IN.2.2 (Auditable Records). 180 DC.1.5 11 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.5.1 F EN Capture and Manage the CMS Resident Assessment Instrument Statement: Capture and manage the Minimum Data Set as per CMS regulations

Description: The resident assessment process mandated by the Centers for Medicare & Medicaid Services (CMS) includes a standardized assessment instrument (the MDS), triggers and protocols for further assessment (Resident Assessment Protocols), and utilization guidelines that define the frequency, timeliness, error correction process, and data submission requirements for the Minimum Data Set. In addition, some state agencies impose further, more stringent requirements on MDS processes. The EHR-S must provide the ability to comply with all federal requirements related to the MDS, as well as the additional state level requirements imposed by the jurisdiction in which the system is implemented.

Note: References to "version" in this function are referring to prior iterations of the mandated assessment instrument. 		  1. The system SHALL provide the ability to capture all data elements as defined in the most recent MDS data specification. 181     A
2. The system SHALL perform Medicare payment calculations from MDS data items in accordance with the most recent algorithms provided by CMS and populate the payment calculation value to the appropriate MDS data element. 182     A
3. The system SHALL perform State Medicaid payment calculations from MDS data items in accordance with the most recent algorithms provided by the state agency of the jurisdiction in which the system is implemented, and populate the payment calculation value to the appropriate data element as required by jurisdictional law or regulation. 183     A
4. The system SHALL perform data consistency edits as defined in the most recent MDS data specification. 184     A
5. The system SHALL calculate triggered Resident Assessment Protocols (RAPs) in accordance with the most recent MDS data specification. 185     A
6. The system SHALL provide the ability to capture the clinician assessment process for triggered Resident Assessment Protocols (RAPs). 186     A
7. The system SHALL create MDS data submission files in accordance with the most recent MDS data specifications. 187     A
8. The system SHALL implement MDS data correction and assessment locking processes as defined in the most recent version of the CMS MDS Correction Policy. 188     A
9. The system SHOULD calculate and report quality calculations such as Quality Indicators and Quality Measures in compliance with function S.2.1.2 (Performance and Accountability Measures). 189     A
10. The system SHALL report Medicare payment calculations in compliance with function S.3.1.3 (Automatic Generation of Administrative and Financial Data from Clinical Record). 190     A
11. The system SHOULD provide the ability to link data from the MDS to a problem list. 191     A
12. The system SHOULD provide the ability to link data from the MDS to an individual care plan. 192     A
13. The system SHOULD provide the ability to exchange MDS assessment data in conformance with HL7 CDA release 2 or higher. 193     A
14. The system SHALL provide the ability to export MDS data in formats as required by jurisdictional authority. 194     A
15. The system SHALL provide the ability to access, view, report and display all previously completed MDS assessments. 195     A
16. The system MAY provide the ability to capture all data elements as defined in previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 196     A
17. The system MAY create MDS data submission files in accordance with previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 197     A
18. The system MAY implement MDS data correction and assessment locking processes as defined in prior versions of the CMS MDS Correction Policy for purposes of transitioning paper documentation to electronic format. 198     A
19. The system MAY calculate triggered Resident Assessment Protocols (RAPs) in accordance with previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 199     A
20. The system MAY perform data consistency edits as defined in previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 200     A
21. The system SHOULD comply with IN 5.1 (Interchange Standards) Criteria #9 (The system SHOULD provide the ability to exchange federally mandated assessment instrument data in conformance with Consolidated Health Informatics (CHI) format and content standards.) 201     A


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.6 H EN Care Plans, Treatment Plans, Guidelines, and Protocols       202 DC.1.6   N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.6.1 F EN Present Guidelines and Protocols for Planning Care Statement: Present organizational guidelines for patient care as appropriate to support planning of care, including order entry and clinical documentation.

Description: Guidelines, and protocols presented for planning care may be site specific, community or industry-wide standards. It is not the intent of this function to suggest that guidelines and protocols are presented for all entries in the care plan. Unlike the medical model used in acute care settings, the social model of care used in LTC does not lend itself as easily to the use of standard guidelines and protocols. LTC care planning incorporates the MDS and RAP process (as well as other assessments/orders) to identify social as well as physical strengths and deficits. There may be no "standard protocol" for how to measure or further assess "strength in faith". However where relevant guidelines and protocols do exist, they are presented to the user.		 DC.1.1.2
DC.2.2.1.1
DC.2.2.1.2
DC.2.2.2
DC.2.2.3
DC.2.7.1
S.3.7.1
IN.6 		1. The system SHALL provide the ability to present current guidelines and protocols to clinicians who are creating plans for treatment and care. 203 DC.1.6.1 1 N/C
2. The system SHOULD provide the ability to search for a guideline or protocol based on appropriate criteria (such as problem). 204 DC.1.6.1 2 N/C
3. The system SHOULD provide the ability to present previously used versions of guidelines and protocols available to clinicians for historical or legal purposes. 205 DC.1.6.1 3 M
4. IF decision support prompts are used to support a specific clinical guideline or protocol, THEN the system SHALL conform to function DC.1.8.6 (Manage Documentation of Clinician Response to Decision Support Prompts). 206 DC.1.6.1 4 N/C
5. The system SHALL conform to function DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols). 207 DC.1.6.1 5 N/C
6. The system SHOULD conform to function IN.2.2 (Auditable Records). 208 DC.1.6.1 6 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.6.2 F EN Manage Patient-Specific Care and Treatment Plans Statement: Provide administrative tools for healthcare organizations to build care plans, guidelines and protocols for use during patient care planning and care.

Description: Care plans, guidelines or protocols may contain goals or targets for the patient, specific guidance to the providers, suggested orders, and nursing interventions, among other items. Tracking of implementation or approval dates, modifications and relevancy to specific domains or context is provided. Transfer of treatment and care plans may be implemented electronically using, for example, templates, or by printing plans to paper. 		DC.3.1.1
DC.3.1.2
DC.3.1.3
IN.2.2
IN.2.5.1
IN.2.5.2
IN.6 		1. The system SHALL provide the ability to capture patient-specific plans of care and treatment. 209 DC.1.6.2 1 N/C
2. The system SHALL conform to DC.1.6.1 (Present Guidelines and Protocols for Planning Care) and provide the ability to use locally or non-locally developed templates, guidelines, and protocols for the creation of patient-specific plans of care and treatment 210 DC.1.6.2 2 N/C
3. The system SHALL provide the ability to use a patient's previously developed care plans as a basis for the creation of new plans of care and treatment. 211 DC.1.6.2 3 M
4. The system SHALL provide the ability to track updates to a patient's plan of care and treatment including authors, creation date, version history, references, local sources and non-local sources in accordance with scope of practice, organizational policy and jurisdictional law. 212 DC.1.6.2 4 N/C
5. The system SHOULD provide the ability to coordinate order sets with care plans. 213 DC.1.6.2 5 N/C
6. The system SHOULD MAY provide the ability to derive suggest possible order sets from care plans. 214 DC.1.6.2 6 M
7. The system SHOULD provide the ability to derive suggest care plans from order sets. 215 DC.1.6.2 7 M
8. The system SHALL provide the ability to transfer plans of care and treatment to other care providers. 216 DC.1.6.2 8 N/C
9. The system SHOULD conform to function DC.3.1.1 (Clinical Task Assignment and Routing) and incorporate care plan items in the tasks assigned and routed. 217 DC.1.6.2 9 N/C
10. The system SHOULD conform to function DC.3.1.2 (Clinical Task Linking) and incorporate care plan items in the tasks linked. 218 DC.1.6.2 10 N/C
11. The system SHOULD conform to function DC.3.1.3 (Clinical Task Tracking) and incorporate care plan items in the tasks tracked. 219 DC.1.6.2 11 N/C
12. The system SHALL conform to function IN.2.2 (Auditable Records). 220 DC.1.6.2 12 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7 H EN Orders and Referrals Management     1. The system SHALL conform to function IN.2.2 (Auditable Records). 221 DC.1.7   N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.1 F EN Manage Medication Orders Statement: Create prescriptions or other medication orders with detail adequate for correct filling and administration. Provide information regarding compliance of medication orders with formularies.

Description: Different medication orders, including discontinue, refill, and renew, require different levels and kinds of detail, as do medication orders placed in different situations. The correct details are recorded for each situation. Administration or patient instructions are available for selection by the ordering clinicians, or the ordering clinician is facilitated in creating such instructions. The system may allow for the creation of common content for prescription details, including content required in the NCPDP Codified SIG standard. Appropriate time stamps for all medication related activity are generated. This includes series of orders that are part of a therapeutic regimen (e.g., Renal Dialysis, Oncology).

When a clinician places an order for a medication, that order may or may not comply with a formulary specific to the patient's location or insurance coverage, if applicable. Whether the order complies with the formulary should be communicated to the ordering clinician at an appropriate point to allow the ordering clinician to decide whether to continue with the order. Formulary-compliant alternatives to the medication being ordered may also be presented. In addition, the system should present the clinician with clinical decision support (such as allergies, drug-drug- interactions, etc.) during the medication ordering process.

Finally, the EHR-S must support the unique medication ordering processes required in the LTC nursing home environment, including the need to support:
  • Communication of orders between the physician, nursing facility and pharmacy provider)
  • Existing practices for monthly signature of renewal orders by physicians (see criterion 1a)
  • The facility nurse acting as an agent of the physician.
 DC.2.3.1.1
DC.2.3.1.2
DC.2.3.1.3
DC.2.4.2
DC.3.2.2
S.2.2.1
S.3.3.2
S.3.7.2
IN.2.4
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.5.4
IN.6 		1. The system SHALL provide the ability to create prescription or other medication orders, such as over the counter (OTC), with the details adequate for correct filling and administration captured as discrete data. 222 DC.1.7.1 1 M
1a. The system SHALL provide the ability to indicate that an existing order has been renewed by the prescriber including prescriber name, and the date and time of renewal. 223     A
2. The system SHALL capture user and date stamp for all prescription related events. 224 DC.1.7.1 2 N/C
3. The system SHALL conform to function DC.1.4.2 (Manage Medication List) and update the appropriate medication list with the prescribed medications (in case of multiple medication lists). 225 DC.1.7.1 3 N/C
4. The system SHALL provide a list of medications to search, including searchable selection list for ordering medications that includes both generic and brand names. 226 DC.1.7.1 4 M
5. The system SHALL provide the ability to maintain a discrete list of orderable medications selection list for ordering medications with components in discrete fields (such as medication name, strength, form). 227 DC.1.7.1 5 M
6. The system SHALL conform to function DC.1.7.2.1 (Manage Non-Medication Patient Care Orders) and provide the ability to order supplies associated with medication orders in accordance with scope of practice, organizational policy or jurisdictional law. 228 DC.1.7.1 6 N/C
7. The system MAY SHOULD make common content (such as drug, dose, route and SIG) available for prescription details to be selected by the ordering clinician. 229 DC.1.7.1 7 M
8. The system MAY SHALL provide the ability for the ordering clinician to create enter prescription details (e.g., free text) as needed. 230 DC.1.7.1 8 M
9. The system MAY make available common patient medication instruction content to be selected by the ordering clinician. 231 DC.1.7.1 9 N/C
10. The system MAY provide the ability to include prescriptions medication orders in order sets. 232 DC.1.7.1 10 M
11. The system MAY provide a list of frequently-ordered medications by diagnosis by provider which could include the full details of the medication, including SIG, quantity, refills, DAW, etc. 233 DC.1.7.1 11 N/C
12. The system MAY provide the ability to select drugs by therapeutic class and/or indication. 234 DC.1.7.1 12 N/C
13. The system MAY SHOULD conform to function S.3.3.2 (Eligibility Verification and Determination of Coverage) and display the results of electronic prescription eligibility and health plan/payer formulary checking. 235 DC.1.7.1 13 M
14. The system MAY provide the ability to re-prescribe create a medication order by using data from a prior medication order allowing a prior prescription to be reordered (e.g., without re-entering previous data (e.g. such as administration schedule, quantity). 236 DC.1.7.1 14 M
15. IF the system SHOULD provides the ability to create a medication order by using data from a prior medication order re-prescribe a medication from a prior prescription, using the same dosage but THEN the system SHALL allow for editing of details adequate for correct filling and administration of medication (e.g. dose, frequency, body weight). 237 DC.1.7.1 15 M
16. The system SHOULD conform to function DC.2.3.1.1 (Support for Drug Interaction Checking) and check and report allergies, drug-drug interactions, and other potential adverse reactions, when new ordering medications. are ordered. 238 DC.1.7.1 16 M
17. The system SHOULD conform to function DC.2.3.1.2 (Support for Patient Specific Dosing and Warnings) and check and report other potential adverse reactions, when new medications are ordered. 239 DC.1.7.1 17 N/C
18. The system SHOULD provide the ability to create prescriptions in which the weight-specific dose is suggested suggest a weight-specific dose during the order entry process. 240 DC.1.7.1 18 M
19. The system SHOULD conform to function DC.2.3.1.3 (Support for Medication Recommendations). 241 DC.1.7.1 19 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.2 H EN Non-Medication Orders and Referrals Management       242 DC.1.7.2   N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.2.1 F EN Manage Non-Medication Patient Care Orders Statement: Capture and track patient care orders. Enable the origination, documentation, and tracking of non-medication patient care orders.

Description: Non-medication orders that request actions or items can be captured and tracked including new, renewal and discontinue orders. Examples include orders to transfer a patient between units, orders for DNR, to ambulate or reposition a patient, for medical supplies, durable medical equipment, home IVs, and diet or therapy orders.

Each item ordered includes the appropriate detail, such as order identification and instructions. Orders should be communicated to the correct service provider for completion. 		DC.2.4.1
DC.2.4.2
S.2.2.1
S.3.3.3
S.3.7.1
IN.1.6
IN.1.7
IN.2.5.1
IN.2.5.2
IN.6 		1.  The system SHALL provide the ability to capture non-medication patient care orders for an action or item 243 DC.1.7.2.1 1 N/C
2.  The system SHALL provide the ability to capture adequate order detail for correct order fulfillment 244 DC.1.7.2.1 2 N/C
3.  The system SHALL provide the ability to track the status (such as active, discontinued, requisitioned, completed) of the ordered action or item. 245 DC.1.7.2.1 3 M
4.  The system SHOULD provide the ability to capture patient or caregiver instructions necessary for correct order fulfillment and associate the instructions with the order. 246 DC.1.7.2.1 4 M
5.  The system SHOULD provide the ability to present patient and caregiver instructions necessary for correct order fulfillment. 247 DC.1.7.2.1 5 M
6.  The system SHOULD provide the ability to communicate the order to the correct recipient(s) for order fulfillment 248 DC.1.7.2.1 6 N/C
7.  The system SHALL conform to DC.2.4.2 (Support for Non-Medication Ordering) 249 DC.1.7.2.1 7 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.2.2 F EN Manage Orders for Diagnostic Tests   Statement: Enable the origination, documentation, and tracking of orders for diagnostic tests.   Description: Orders for diagnostic tests (e.g., diagnostic radiology, blood test) are captured and tracked including new, renewal and discontinue orders. Each order includes appropriate detail, such as order identification, instructions and clinical information necessary to perform the test. Orders and supporting detailed documentation shall be communicated to the service provider for completion of the diagnostic test(s). This communication should occur through electronic exchange of data using HITSP endorsed standards of interoperability, although other methods of data exchange, including by methods such as automated fax, may be used in the absence of recognized standards. 

Some systems may contain instructions, but in some settings, instructions may be provided from external sources (e.g., handouts).		 DC.2.4.5.2
S.2.2.1
S.3.7.1
IN.1.6
IN.1.7
IN.2.5.1
IN.2.5.2
IN.6		 1.  The system SHALLprovide the ability to capture orders for diagnostic tests. 250 DC.1.7.2.2 1 N/C
2.  The system SHALLprovide the ability to capture adequate order detail for correct diagnostic test fulfillment. 251 DC.1.7.2.2 2 N/C
3.  The system SHALLprovide the ability to track the status (such as requisitioned, completed, in process)of diagnostic test(s). 252 DC.1.7.2.2 3 M
4.  The system SHOULDprovide the ability to capture and present patientand caregiverinstructions relevant to the diagnostic test ordered. 253 DC.1.7.2.2 4 M
5.  The system SHALLprovide the ability tocommunicate orders to the service provider of the diagnostic test. 254 DC.1.7.2.2 5 M
6.  The system SHOULDcommunicate supporting detailed documentation to the correct service provider of the diagnostic test. 255 DC.1.7.2.2 6 N/C
7.  The system SHALLconform to DC.2.4.2 (Support for Non-Medication Ordering). 256 DC.1.7.2.2 7 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.2.3 F O Manage Orders for Blood Products and Other Biologics  Statement: Communicate with appropriate sources or registries to manage orders for blood products or other biologics.

Description: Interact with a blood bank system or other source to support orders for blood products or other biologics including discontinuance orders. Use of such products in the provision of care is captured. Blood bank or other functionality that may come under jurisdictional law or other regulation (e.g., by the FDA in the United States) is not required; functional communication with such a system is required.		 DC.2.4.5.1
S.1.1
S.1.2 		1.  The system SHALLprovide the ability to interface with systems of blood banks or other sources to manage orders for blood products or other biologics. 257 DC.1.7.2.3 1 N/C
2.  The system SHALLprovide the ability to capture use of such products in the provision of care. 258 DC.1.7.2.3 2 N/C
3.  The system SHOULDSHALL conform to function S.1.1 (Registry Notification). 259 DC.1.7.2.3 3 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.2.4 F EF 2010 Manage Referrals    Statement: Enable the origination, documentation and tracking of referrals between care providers or health care organizations, including clinical and administrative details of the referral, and consents and authorizations for disclosures as required.

Description: Documentation and tracking of a referral from one care provider to another is supported, whether the referred to or referring providers are internal or external to the healthcare organization. The EHR-S provides the ability to capture completion of the referral appointment. This capture functionality can be accomplished via:
  • external input such as receiving, accepting, downloading or importing a file(s)
  • internally creating the information by means such as entering, computing or recording information regarding the referral)
Guidelines for whether a particular referral for a particular patient is appropriate in a clinical context and with regard to administrative factors such as insurance may be provided to the care provider at the time the referral is created.		 DC.1.9.3
DC.2.4.4.1
DC.2.4.4.2
S.1.3.1a
S.1.3.5
S.3.3.2
S.3.3.3
IN.1.6
IN.1.7
IN.2.5.1
IN.2.5.2		 1.  The system SHALLprovide the ability to capture and communicate referral(s) to other care provider (s), whether internal or external to the organization. 260 DC.1.7.2.4 1 N/C
2.  The system SHALLprovide the ability to capture clinical details as necessary for the referral. 261 DC.1.7.2.4 2 N/C
3.  The system SHALLprovide the ability to capture administrative details (such as insurance information, consents and authorizations for disclosure) as necessary for the referral. 262 DC.1.7.2.4 3 N/C
4.  The system SHALLpresent captured referral information. 263 DC.1.7.2.4 4 N/C
5.  The system SHOULDSHALLprovide the ability to capture completion of a referral appointment. 264 DC.1.7.2.4 5 M
6.  The system SHOULDprovide diagnosis based clinical guidelines for making a referral. 265 DC.1.7.2.4 6 N/C
7.  The system MAYprovide order sets for referral preparation. 266 DC.1.7.2.4 7 N/C
8.  The system SHALLprovide the ability to document transfer of care according to organizational policy, scope of practice, and jurisdictional law. 267 DC.1.7.2.4 8 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.7.3 F EN Manage Order Sets  Statement: Provide order sets based on provider input or system prompt.  

Description: Order sets, which may include medication and non-medication orders, allow a care provider to choose common orders for a particular circumstance or disease state according to standards or other criteria. Recommended order sets may be presented based on patient data or other contexts.		 DC.2.4.1
IN.2.5.1
IN.2.5.2
IN.6		 1.  The system SHALLprovide the ability to present order set(s). 268 DC.1.7.3 1 N/C
2.  The system SHALLprovide the ability to customizeorders at the patient level from presented order set templates. 269 DC.1.7.3 2 M
3.  The system SHALLprovide the ability to record each component of an order settemplatethat is ordered. 270 DC.1.7.3 3 M
4.  The system SHALLconform to function DC.2.4.1 (Support for Order Sets). 271 DC.1.7.3 4 N/C
5.  The system MAYSHOULD provide the ability for a provider to choose from among the order sets pertinent to a certain disease or other criteria. 272 DC.1.7.3 5 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.8 H EN Documentation of Care, Measurements and Results     1.  The system SHALLconform to function IN.2.2 (Auditable Records) 273 DC.1.8 1 N/C


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.8.1 F EN Manage Medication Administration Statement: Present providers with the list of medications that are to be administered to a patient, necessary administration information, and capture administration details.  

Description: In a setting in which medication orders are to be administered by a provider rather than the patient, the necessary information is presented including: the list of medication orders that are to be administered; administration instructions, times or other conditions of administration; dose and route, etc. The system shall securely relate medications to be administered to the unique identity of the patient (see DC.1.1.1). Additionally, the provider can record what actually was or was not administered, whether or not these facts conform to the order. Appropriate time stamps for all medication related activity are generated.   For some settings that administer complete sets of medications from a variety of providers’ orders, it may be useful to provide an additional check for possible drug-drug or other interactions.

The EHR system may support the five “rights”, as well as other criteria from the CMS State Operations Manual (SOM).		 DC.1.1.1
DC.2.3.1.1
DC.2.3.1.2
DC.2.3.2
S.2.2.1
S.2.2.3
IN.1.1
IN.1.2
IN.1.3
IN.1.7
IN.1.9
IN.2.4
IN.2.5.1
IN.2.5.2
IN.6		 1.  The systemSHALLpresent the list of medications that areto be administered. 274 DC.1.8.1 1 M
2.  The system SHALLdisplay the timing(e.g., frequency and hour of administration), route of administration, and dose of all medications on the list. 275 DC.1.8.1 2 M
3.  The system SHOULDSHALLdisplay instructionsorder directions (SIG)for administration of all medications on the list. 276 DC.1.8.1 3 M
4.  The system MAYSHALLnotify the clinicianindicatewhen specific dosesmedication related activitiesare due. 277 DC.1.8.1 4 M
5.  The system MAYSHOULDconform to function DC.2.3.1.1 (Support for Drug Interaction Checking) and check and report allergies, drug-drug interactions, and other potential adverse reactions(e.g., drug to condition), when new medications are about to be given. 278 DC.1.8.1 5 M
6.  The system MAYSHOULDconform to function DC.2.3.1.2 (Support for Patient Specific Dosing and Warnings) and check and report other potential adverse reactions, when new medications are about to be given. 279 DC.1.8.1 6 M
8.  The system SHALLprovide the ability to capture medication administration details -- including timestamps, observations, complications, and reason if medication was not given -- in accordance with organizational policy, scope of practice, and jurisdictional law. 280 DC.1.8.1 7 N/C
8.  The system SHALL provide the ability tosecurely relate interventions associate medication-related activities to be administeredto the unique identity of the patient(e.g., verification of administration to correct patient). 281 DC.1.8.1 8 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.8.2 F EN Manage Immunization Administration  Statement: Capture and maintain discrete data concerning immunizations given to a patient including date administered, type, manufacturer, lot number, and any allergic or adverse reactions. Facilitate the interaction with an immunization registry to allow maintenance of a patient’s immunization history.  

Description: During an encounter, recommendations based on accepted immunization schedules are presented to the provider. Allergen and adverse reaction histories are checked prior to giving the immunization. If an immunization is administered, discrete data elements associated with the immunization including date, type, manufacturer and lot number are recorded. Any new adverse or allergic reactions are noted. If required, a report is made to the public health immunization registry.		 DC.1.3.2
S.1.1
S.2.2.2
S.3.7.1
IN.1.6
IN.1.7
IN.2.4
IN.2.5.1
IN.2.5.2
IN.3.1
IN.3.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.6		 1.  The system SHALLprovide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules (such as from the CDC or applicable State departments of health) 282 DC.1.8.2 1 M
2.  The system SHOULDMAY provide the ability to recommend required immunizations based on patient risk factors. 283 DC.1.8.2 2 M
3.  The system SHALL perform checking for check for and reportpotential adverse or allergic reactions(based on allergen history and adverse reaction history) for all immunizations when they are about to be givenimmediately prior to administration. 284 DC.1.8.2 3 M
4.  The system SHALLprovide the ability to capture immunization administration details, including date, type, lot number and manufacturer. 285 DC.1.8.2 4 N/C
5.  The system SHOULDprovide the ability to capture other clinical data pertinent to the immunization administration (e.g., vital signs). 286 DC.1.8.2 5 N/C
6.  The system SHALLrecord as discrete data elements thedata associated with any each immunization administration. 287 DC.1.8.2 6 M
7.  The system SHOULDprovide the ability to associate standard codes with discrete data elements associated with an immunization. 288 DC.1.8.2 7 N/C
8.  The system SHALLprovide the ability to update the immunization schedule. 289 DC.1.8.2 8 N/C
9.  The system SHOULDprovide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities. such as schools or day-care centers 290 DC.1.8.2 9 M
10. The system SHALLconform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists). 291 DC.1.8.2 10 N/C
11. The system SHOULDMAY transmit required immunization information to a public health immunization registry. 292 DC.1.8.2 11 M
12. The system SHOULDMAY receive immunization histories from a public health immunization registry. 293 DC.1.8.2 12 M


ID# Type Priority Name Statement/ Description See
Also		 Conformance
Criteria		 Row
#		 FM Source
ID
#		 Criteria
#		 Criteria
Status
DC.1.8.4 F EN Manage Patient Clinical Measurements Statement: Capture and manage patient clinical measures, such as vital signs, as discrete patient data.

Description: Patient measures such as vital signs are captured and managed as discrete data to facilitate reporting and provision of care. Other clinical measures (such as expiratory flow rate, size of lesion, etc.) are captured and managed, and may be discrete data.		 IN.2.5.1
IN.2.5.2		 1.  IF required by the scope practice, THEN The system SHALL provide the ability tocapture patient vital signs such as blood pressure, temperature, heart rate, respiratory rate, and severity of pain as discrete elements of structured or unstructured data. 311 DC.1.8.4 1 M
2.  IF required by the scope practice, THEN The system SHALL provide the ability tocapture psychiatric symptoms mood and behaviorand daily functioning as eitherstructured or unstructured data. 312 DC.1.8.4 2 M
3.  The system SHOULD provide the ability tocapture other clinical measures such as (e.g., peak expiratory flow rate, size of lesions, oxygen saturation, height, weight, and body mass index) as discrete elements of eitherstructured or unstructured data. 313 DC.1.8.4 3 M
4.  The system SHOULD MAYcompute and display percentile values when data with normative distributions are entered. 314 DC.1.8.4 4 M
5.  The system MAYprovide normal ranges for data based on age and other parameters such as height, weight, ethnic background, gestational age. 315 DC.1.8.4 5 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.1.8.5 F EN Manage Clinical Documents and Notes Statement: Create, addend, correct, authenticate and close, as needed, transcribed or directly-entered clinical documentation and notes.

Description: Clinical documents and notes may be unstructured and created in a narrative form, which may be based on a template, graphical, audio, etc. The documents may also be structured documents that result in the capture of coded data. Each of these forms of clinical documentation is important and appropriate for different users and situations. 		IN.2.2
IN.2.5.1
IN.2.5.2		 1.  The system SHALLprovide the ability to capture clinical documentation (henceforth "documentation") including original, update by amendment in order to correct, and addenda. 316 DC.1.8.5 1 N/C
2.  The system SHALLprovide the ability to capture free text documentation. 317 DC.1.8.5 2 N/C
3.  The system MAYpresent documentation templates (structured or free text) to facilitate creating documentation. 318 DC.1.8.5 3 N/C
4.  The system SHALLprovide the ability to view other documentation within the patient's logical record while creating documentation. 319 DC.1.8.5 4 N/C
5.  The system SHOULDprovide the ability to associate documentation for a specific patient with a given event, such as a physicianoffice visit, phone communication, e-mail pharmacistconsult,resident injury, lab result, etc. 320 DC.1.8.5 5 M
6.  The system SHOULDprovide the ability to associate documentation with problems and/or diagnoses. 321 DC.1.8.5 6 N/C
7.  The system SHALLprovide the ability to update documentation prior to marking it as complete (finalizing) it. 322 DC.1.8.5 7 M
8.  The system SHALLprovide the ability to mark finalizea document or note as complete (finalize). 323 DC.1.8.5 8 M
9.  The system SHALLprovide the ability to attribute, record and display the identity of all users contributing to or finalizing a document or note, including the date and time of entry (see appropriate criteria in IN.2.2 (Auditable Records). 324 DC.1.8.5 9 N/C
10. The system SHALLpresent captured documentation. 325 DC.1.8.5 10 N/C
11. The system MAY SHALL provide the ability to filter, search or sort notes. 326 DC.1.8.5 11 M
12. The system SHOULD MAY provide documentation templates for data exchange. 327 DC.1.8.5 12 M


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.1.8.6 F EN Manage Documentation of Clinician Response to Decision Support Prompts Statement: Capture the decision support prompts and manage decisions to accept or override decision support prompts.

Description: Clinician actions in response to decision support prompts are captured and can be managed at the patient level or aggregated for organizational trending.		 S.3.7.1
IN.2.5.1
IN.2.5.2
IN.6		 1.  IF decision support prompts are used, THEN the system SHALL provide the ability to capture clinical decision support prompts and user decisions to accept or override those prompts. 328 DC.1.8.6 1 M
2.  The system SHALLprovide the ability to record the reason for variation from the decision support prompt. 329 DC.1.8.6 2 N/C
3.  The system SHOULDprovide the ability to display recorded variances upon request by authorized users of the EHR. 330 DC.1.8.6 3 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.1.9 F EF 2012 Generate and Record Patient-Specific Instructions    Statement: Generate and record patient-specific instructions related to pre- and post-procedural and post- discharge requirements.

Description: When a patient is scheduled for a test, procedure, or discharge, specific instructions about diet, clothing, transportation assistance, convalescence, follow-up with physician, etc., may be generated and recorded, including the timing relative to the scheduled event.		 DC.2.2.4
DC.2.7.2
DC.3.2.3
DC.3.2.4
S.3.7.2
S.3.7.3
IN.1.8
IN.2.2
IN.6		 1.  The system SHALLprovide the ability to generate standardizedinstructionsets pertinent to the patient condition, for standardizedprocedures, or scheduled events. 331 DC.1.9 1 M
2.  The system SHALLprovide the ability to generate instructions pertinent to the patient based on clinical and subject to the clinician’s judgment. 332 DC.1.9 2 M
3.  The system SHALLprovide the ability to include details on further care such as follow up, return visits and appropriate timing of further care. 333 DC.1.9 3 N/C
4.  The system SHALLprovide the ability to record that instructions were given to the patient. 334 DC.1.9 4 N/C
5.  The system SHALLprovide the ability to record the actual instructions given to the patient or reference the document(s) containing those instructions. 335 DC.1.9 5 N/C
6.  The system SHALLconform to function IN.2.2 (Auditable Records). 336 DC.1.9 6 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2 H EN Clinical Decision Support     1.  The system SHALLconform to function IN.1.1 (Entity Authentication). 337 DC.2 1 N/C
2.  The system SHALLconform to function IN.1.2 (Entity Authorization). 338 DC.2 2 N/C
3.  The system SHALLconform to function IN.1.3 (Entity Access Control). 339 DC.2 3 N/C
4.  IF the system is used to enter, modify or exchange data, THEN the system SHALLconform to function IN.1.5 (Non-Repudiation), to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data. 340 DC.2 4 N/C
5.  IF the system exchanges data outside of a secure network, THEN the system SHALLconform to function IN.1.6 (Secure Data Exchange), to ensure that the data are protected. 341 DC.2 5 N/C
6.  IF the system exchanges outside of a secure network, THEN the system SHALLconform Function IN.1.7 10 (Secure Data Routing -LTC), to ensure that the exchange occurs only among authorized senders and receivers. 342 DC.2 6 M
7.  IF the system is used to enter or modify data in the health record, THEN the system SHALLconform to function IN.1.8 (Information Attestation), to show authorship and responsibility for the data. 343 DC.2 7 N/C
8.  The system SHALLconform to function IN.2.1 (Data Retention, Availability and Destruction). 344 DC.2 8 N/C
9.  The system SHOULDconform to function IN.2.3 (Synchronization). 345 DC.2 9 N/C
10. IF the system is used to extract data for analysis and reporting, THEN the system SHALLconform to function IN.2.4 (Extraction of Health Record Information), to support data extraction across the complete health record of an individual. 346 DC.2 10 N/C
11. IF the system stores unstructured data, THEN the system SHALLconform to function IN.2.5.1 (Manage Unstructured Health Record Information), to ensure data integrity through all changes. 347 DC.2 11 N/C
12. IF the system stores structured data, THEN the system SHALLconform to function IN.2.5.2 (Manage Structured Health Record Information), to ensure data integrity through all changes. 348 DC.2 12 N/C
13. IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALLconform to function IN.4.1 (Standard Terminologies and Terminology Models), to support semantic interoperability. 349 DC.2 13 N/C
14. IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALLconform to function IN.4.2 (Maintenance and Versioning of Standard Terminologies), to preserve the semantics of coded data over time. 350 DC.2 14 N/C
15. The system SHOULDconform to function IN.4.3 (Terminology Mapping). 351 DC.2 15 N/C
16. IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALLconform to function IN.5.1 (Interchange Standards), to support interoperability. 352 DC.2 16 N/C
17. IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.2 (Interchange Standards Versioning and Maintenance), to accommodate the inevitable evolution of interchange standards. 353 DC.2 17 N/C
18. The system SHOULDconform to function IN.5.3 (Standards-based Application Integration). 354 DC.2 18 N/C
19. IF the system exchanges data with other systems outside itself, THEN the system SHALLconform to function IN.5.4 (Interchange Agreements), to define how the sender and receiver will exchange data. 355 DC.2 19 N/C
20. The system SHOULDconform to function IN.6 (Business Rules Management). 356 DC.2 20 N/C
21. The system SHOULDconform to function IN.7 (Workflow Management). 357 DC.2 21 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.1 H EN Manage Health Information to Provide Decision Support     1.  The system SHOULDconform to function IN.1.4 (Patient Access Management). 358 DC.2.1 1 N/C
2.  The system SHALLconform to function IN.1.9 (Patient Privacy and Confidentiality). 359 DC.2.1 2 N/C
3.  The system SHALLconform to function IN.2.2 (Auditable Records). 360 DC.2.1 3 N/C
4.  The system SHOULDconform to function IN.3 (Registry and Directory Services). 361 DC.2.1 4 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.1.1 F EN Support for Standard Assessments Statement: Offer prompts to support the adherence to care plans, guidelines, and protocols at the point of information capture.

Description: When a clinician fills out an assessment, data entered triggers the system to prompt the assessor to consider issues that would help assure a complete/accurate assessment. A simple demographic value or presenting problem (or combination) could provide a template for data gathering that represents best practice in this situation, (e.g., Type II diabetic review, fall and 70+, rectal bleeding, etc. risk assessments, psychotherapeutic drug use, incontinence, etc. Examples of accessing 'best practices' include internal application links to clinical resources or evidence-based resources, facility defined help text, etc.)		 DC.1.4
DC.1.5
S.3.7.1
IN.2.3
IN.2.4
IN.6 		1.  The system SHALLprovide the ability to access thestandard assessments in the patient record. 362 DC.2.1.1 1 N/C
2.  The system SHALLprovide the ability to access to health standards and practices related to standard assessment andappropriate to the EHR user’s scope of practice. 363 DC.2.1.1 2 M
3.  The system SHOULDprovide the ability to compare elements of assessments captured by the clinician and those available as best practices and/or evidence based resources. 364 DC.2.1.1 3 N/C
4.  The system MAYprovide the ability to derive supplemental assessment data from evidence based standard assessments, practice standards, or other generally accepted, verifiable, and regularly updated standard clinical sources. 365 DC.2.1.1 4 N/C
5.  The system SHOULDprovide prompts based on practice standards to recommend additional assessment functions. 366 DC.2.1.1 5 N/C
6.  The system SHOULDconform to function DC.1.4.3 (Manage Problem List) and provide the ability to update the problem list by activating new problems and de-activating old problems as identified by conduct of standard assessments. 367 DC.2.1.1 6 N/C
7.  The system SHOULD provide the ability to create standard assessments that correspond to prompt additional areas to be assessed as triggered by the problem list. 368 DC.2.1.1 7 M
8.  The system SHOULDconform to function DC 2.1.2 (Support for Patient Context-driven Assessments). 369 DC.2.1.1 8 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.1.2 F EN Support for Patient Context- Driven Assessments  Statement: Offer prompts based on patient-specific data at the point of information capture for assessment purposes.

Description: When a clinician fills out an assessment, data entered is matched against data already in the system to identify potential linkages. For example, the system could scan the medication list and the knowledge base to see if any of the symptoms are side effects of medication already prescribed. Important diagnoses could be brought to the doctor’s attention, for instance ectopic pregnancy in a woman of child bearing age appendicitis in a geriatric patient who has abdominal pain.		 DC.1.4
DC.1.5
S.3.7.1
IN.2.3
IN.2.4
IN.6		 1.  The system SHALLprovide the ability to access health assessment data in the patient record 370 DC.2.1.2 1 N/C
2.  The system SHOULDprovide the ability to compare assessment data entered during the encounter and the accessed health evidence based standards and best practices 371 DC.2.1.2 2 N/C
3.  The system SHOULDprovide the ability to compare health data and patient context-driven assessments to practice standards, in order to providingprompts such as additionalassessments, testing, possible diagnoses, or adjunctive treatment. 372 DC.2.1.2 3 M
4.  The system SHOULDprovide the ability to correlate assessment data and the data in the patient specific problem list. 373 DC.2.1.2 4 N/C
5.  The system SHALLconform to function DC 2.1.1 (Support for Standard Assessments) 374 DC.2.1.2 5 N/C
6.  The system SHALLconform to function DC.1.5 (Manage Assessments) 375 DC.2.1.2 6 N/C
7.  The system SHOULDconform to function DC.1.4.3 (Manage Problem List) 376 DC.2.1.2 7 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.1.3 F EN Support for Identification of Potential Problems and Trends Statement: Identify trends that may lead to significant problems, and provide prompts for consideration.

Description: When personal health information is collected directly during a patient visit, input by the patient, or acquired from an external source (lab results), it is important to be able to identify potential problems and trends that may be patient-specific, given the individual's personal health profile, or changes warranting further assessment. For example: significant trends (lab results, weight); a decrease in creatinine clearance for a patient on metformin, an abnormal increase in INR for a patient on warfarin, an increase in suicidal ideation; presence of methamphetamines; or absence of therapeutic levels of antidepressants.		 DC.1.4
DC.1.5
S.3.7.1
S.3.7.2
S.3.7.4
IN.6		 1.  The system SHALLconform to function DC.1.5 (Manage Assessments) and provide the ability to access standard assessment data in the patient record. 377 DC.2.1.3 1 N/C
2.  The system SHOULDprovide the ability to access health standards and practices appropriate to the EHR user’s scope of practice at the time of the encounter. 378 DC.2.1.3 2 N/C
3.  The system SHOULDprovide the ability to compare patient context-driven assessments and additional health information to best practices in order to identify patient specific growth or development patterns, health trends and potential health problems. 379 DC.2.1.3 3 N/C
4.  The system SHOULDprovide the ability to configure rules defining abnormal trends. 380 DC.2.1.3 4 N/C
5.  The system SHOULDprompt the provider with abnormal trends. 381 DC.2.1.3 5 N/C
6.  The system SHOULDprompt the provider for additional assessments, testing or adjunctive treatment. 382 DC.2.1.3 6 N/C
7.  The system SHOULDconform to function DC.1.8.6 (Manage Documentation of Clinician Response to Decision Support Prompts). 383 DC.2.1.3 7 N/C
8.  The system MAYprovide the ability to integrate health information contained in the record with appropriate teaching materials. 384 DC.2.1.3 8 N/C
9.  The system SHOULDconform to function DC 2.2.1.2 (Support for Context-sensitive Care Plans, Guidelines, Protocols). 385 DC.2.1.3 9 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.1.4 F EN Support for Patient and Family Preferences Statement: Support the integration of patient and family preferences into clinical decision support.

Description: Decision support functions should permit consideration of patient/family preferences and concerns, such as with language, religion, culture, medication choice, invasive testing, and advance directives. Such preferences should be captured in a manner that allows for their integration with the health record and easy retrieval from the health record. Preferences may be specified across all treatment plans or specifically to a treatment plan. 		DC.1.1.4
DC.1.6.1
DC.1.6.2
DC.1.6.3
DC.1.11.1
DC.1.11.2
DC.2.2.1.1
DC.2.2.1.2
DC.2.2.2
S.3.7.1
S.3.7.2
S.3.7.4
IN.6		 1.  The system SHALLconform to DC.1.3.1 (Manage Patient and Family Preferences). 386 DC.2.1.4 1 N/C
2.  The system SHALLprovide for the ability to capture and manage patient and family preferences as they pertain to current treatment plans. 387 DC.2.1.4 2 N/C
3.  The system SHALLprovide the ability to update care guidelines and options relating to documented patient and family preferences, including standards of practice (e.g., treatment options for individuals who refuse blood transfusions IV hydration as part of their advanced directives). 388 DC.2.1.4 3 M
4.  The system SHOULD MAY provide the ability to compare care guidelines and options relating to documented patient and family preferences, including standards of practice. 389 DC.2.1.4 4 M
5.  The system SHOULD MAY prompt the provider for testing and treatment options based on patient and family preferences and provide the ability to compare to standard practice. 390 DC.2.1.4 5 M
6.  The system MAYprovide the ability to integrate preferences with appropriate teaching materials. 391 DC.2.1.4 6 N/C
7.  The system SHOULD SHALL provide the ability to integrate necessary documentation of preferences, such as living wills, advance directives, health care proxies,specific consents or releases. 392 DC.2.1.4 7 M
8.  The system SHALLconform to function DC.1.3.2 (Manage Patient Advance Directives). 393 DC.2.1.4 8 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.2 H EN Care and Treatment Plans, Guidelines and Protocols   DC.1.2 1.  The system SHALLconform to function IN.1.9 (Patient Privacy and Confidentiality). 394 DC.2.2 1 N/C
2.  The system SHALLconform to function IN.2.2 (Auditable Records). 395 DC.2.2 2 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.2.1 H EN Support for Condition Based Care and Treatment Plans, Guidelines, Protocols     1.  The system SHOULDconform to function IN.1.4 (Patient Access Management). 396 DC.2.2.1 1 N/C
2.  The system SHOULDconform to function IN.3 (Registry and Directory Services). 397 DC.2.2.1 2 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.2.1.1 F EN Support for Standard Care Plans, Guidelines, Protocols Statement: Support the use of appropriate standard care plans, guidelines and/or protocols for the management of specific conditions.

Description: Before they can be accessed upon request (e.g., in DC 1.6.1), standard care plans, protocols, and guidelines must be created. These documents may reside within the system or be provided through links to external sources, and can be modified and used on a site specific basis. To facilitate retrospective decision support, variances from standard care plans, guidelines, and protocols can be identified and reported.

It is not the intent of this function to suggest that guidelines and protocols are presented for all entries in the care plan. Unlike the medical model used in acute care settings, the social model of care used in LTC does not lend itself as easily to the use of standard guidelines and protocols. LTC care planning incorporates the MDS and RAP process (as well as other assessments/orders) to identify social as well as physical strengths and deficits. There may be no "standard protocol" for how to measure or further assess "strength in faith".  However where relevant guidelines and protocols do exist, they are presented to the user. 		DC.1.6.1 1.  The system SHALLconform to function DC.1.6.1 (Present Guidelines and Protocols for Planning Care) and provide the ability to access standard care plans, protocols and guidelines when requested within the context of a clinical encounter. 398 DC.2.2.1.1 1 N/C
2.  The system MAY SHOULD provide the ability to create and use site-specific care plans, protocols, and guidelines. 399 DC.2.2.1.1 2 M
3.  The system MAY SHOULD provide the ability to make site-specific modifications to standard care plans, protocols, and guidelines obtained from outside sources. 400 DC.2.2.1.1 3 M
4.  The system SHOULDidentify, track and provide alerts, notifications and reports about significantvariances from standard care plans, guidelines and protocols. 401 DC.2.2.1.1 4 M
5.  The system SHALLconform to DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols). 402 DC.2.2.1.1 5 N/C
6.  The system SHALLconform to DC.2.1.1 (Support for Standard Assessments). 403 DC.2.2.1.1 6 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.2.1.2 F EN Support for Context-Sensitive Care Plans, Guidelines, Protocols Statement: Identify and present the appropriate care plans, guidelines and/or protocols for the management of patient specific conditions that are identified in a patient clinical encounter.

Description: At the time of the clinical encounter (problem identification), recommendations for tests, treatments, medications, immunizations, referrals and evaluations are presented based on evaluation of patient specific data such as age, gender, developmental stage, their health profile, and any site-specific considerations. These may be modified on the basis of new clinical data at subsequent encounters.		 DC.1.3.1
DC.1.4
DC.1.5
DC.1.6
DC.1.6.1
DC.1.6.3
S.2.2.1
IN.2.4
IN.6		 1.  The system SHALLprovide the ability to access care and treatment plans that are sensitive to the context of patient data and assessments. 404 DC.2.2.1.2 1 N/C
2.  The system MAYprovide the ability to capture care processes across the continuum of care. 405 DC.2.2.1.2 2 N/C
3.  The system MAYpresent care processes from across the continuum of care. 406 DC.2.2.1.2 3 N/C
4.  The system MAYprovide the ability to document the choice of action in response to care plan suggestions. 407 DC.2.2.1.2 4 N/C
5.  The system SHOULDidentify, track and provide alerts, notifications and reports about significantvariances from standard care plans, guidelines and protocols. 408 DC.2.2.1.2 5 M
6.  The system SHALLconform to function DC.2.2.1.1 (Support for Standard Care Plans, Guidelines, Protocols). 409 DC.2.2.1.2 6 N/C
7.  The system SHALLconform to function DC.2.1.1 (Support for Standard Assessments). 410 DC.2.2.1.2 7 N/C
8.  The system SHALLconform to function DC.2.1.2 (Support for Patient Context-Driven Assessments). 411 DC.2.2.1.2 8 N/C


ID# Type Priority Name Statement/ Description See
Also 		Conformance
Criteria 		Row
# 		FM Source
ID
# 		Criteria
# 		Criteria
Status
DC.2.2.2 F EF 2012 Support Consistent Healthcare Management of Patient Groups or Populations Statement: Provide the ability to identify and consistently manage healthcare, over time and across populations or groups of patients, that share diagnoses, problems, functional limitations, treatment, medications, and demographic characteristics that may impact care, (e.g., population management, disease management, wellness management or care management).

Description: Populations or groups of patients that share diagnoses (such as diabetes or hypertension), problems, functional limitations, treatment, medication, and demographic characteristics such as race, ethnicity, religion, socio-economic status that may impact care are identified for the clinician. The clinician is advised and assisted with management of these patients to optimize the clinician’s ability to provide appropriate care. For example, a clinician is alerted to racial, cultural, religious, socio-economic, living situation and functional accommodations of the patient that are required to provide appropriate care. A further example -- the clinician may be notified of eligibility for a particular test, therapy, or follow-up; availability of supportive resources in the community; or results from audits of compliance of these populations with disease management protocols. 		DC.2.2.1.2
S.2.2.2
IN.2.2
IN.6		 1.  The system SHALLconform to DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols). 412 DC.2.2.2 1 N/C
2.  The system SHALLprovide the ability to identify patients eligible for healthcare management protocols based on criteria identified within the protocol. 413 DC.2.2.2 2 N/C
3.  The system SHOULD SHALL provide the ability to include or exclude a patient from an existing health care management protocol group. 414 DC.2.2.2 3 M
4.  The system SHOULD provide the ability to audit compliance of selected populations and groups that are the subjects of healthcare management protocols. 415 DC.2.2.2 4 N/C
5.  The system SHALLconform to function S.2.2.2 (Standard Report Generation). 416 DC.2.2.2 5 N/C
6.  The system SHOULDconform to function IN.3 (Registry and Directory Services). 417 DC.2.2.2 6 N/C


ID# Type Priority Name