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

Publication Date

Jun 30, 2008

LTC-NH EHR-S Functional Profile Workgroup

Co-Facilitators:

Jennie Harvell, MEd
U.S. Department of Health and Human Services

Michelle Dougherty, MA, RHIA, CHP
American Health Information Management Association

Nathan Lake, RN, BSN, MSHA
American HEALTHTECH

Sue Mitchell, RHIA
Omnicare Information Solutions

This report was prepared under contract #HHS-100-03-0026 between U.S. Department of Health and Human Services (HHS), Office of Disability, Aging and Long-Term Care Policy (DALTCP) and Abt Associates. For additional information about this subject, you can visit the DALTCP home page at http://aspe.hhs.gov/_/office_specific/daltcp.cfm or contact the ASPE Project Officer, Jennie Harvell, at HHS/ASPE/DALTCP, Room 424E, H.H. Humphrey Building, 200 Independence Avenue, S.W., Washington, D.C. 20201. Her e-mail address is: Jennie.Harvell@hhs.gov.

The opinions and views expressed in this report do not necessarily reflect the views of the Department of Health and Human Services, the contractor or any other funding organizations.

PREFACE

1. Notes to Readers

Release 1 of the Long-Term Care Nursing Home (LTC-NH) Electronic Health Record System (EHR-S) Functional Profile, based on the Health Level Seven (HL7) EHR-S Functional Model Release 1, February 2007, has been balloted through the LTC-NH EHR-S Functional Profile Workgroup, and will be registered with the HL7 EHR Technical Committee and submitted for balloting at the committee level. The intention is for this functional profile to become an ANSI approved normative standard.

2. Acknowledgements

The LTC-NH EHR-S Functional Profile Workgroup was sponsored and facilitated by:

U.S. Department of Health and Human Services (HHS), Office of the Assistant Secretary for Planning and Evaluation (ASPE);
American Association of Homes and Services for the Aging/Center for Aging Services Technology (AAHSA/CAST);
American Health Care Association/National Centers for Assisted Living (AHCA/NCAL);
American Health Information Management Association (AHIMA); and
National Association for the Support of Long Term Care (NASL).

These organizations are indebted to the following workgroup facilitators and members for their contributions to the LTC-NH community and the materials presented in this profile.

The long-term care community is particularly indebted to Sue Mitchell for her leadership and significant contribution to the development of the LTC-NH EHR-S Functional Profile. This Functional Profile would not have been possible without her guidance and assistance.

Member Name	Affiliation
Co-Facilitators
Jennie Harvell, MEd	HHS, ASPE
Michelle Dougherty, MA, RHIA, CHP	AHIMA
Nathan Lake, RN, BSN, MSHA	American HEALTHTECH
Sue Mitchell, RHIA	Omnicare Information Solutions
Profile Developers/Balloters
Adam Prybyl	Momentum Healthware
Amy Killian	Phoebe Services
Annessa Kirby	NASL
Beth de la Hunt	Achieve Healthcare Technologies
Betty Pilous	Ohio KePRO
Brian Young	Accu-Med Services, LLC
Carla Saxton McSpadden	American Society of Consultant Pharmacists
Dan Cobb	HealthMEDX
Debra Ann Phillips	Genesis Health Care Corp
Denine Hastings	Genesis Health Care Corp
Doc DeVore	MDI Achieve
Donna Brickey	American HEALTHTECH
Doron Gutkind	LINTECH
Eileen Doll	EDHC, Inc.
Frank Leonard	Armed Forces Retirement Home
Frank McKinney	Achieve Healthcare Technologies
Ginna Sloan	Accu-Med Services, LLC
James Hancock	QS/1 Data Systems
Judy Baker	Accu-Med Services, LLC
Karrie Ingram	Citizens Memorial Healthcare
Karyn Downie	AAHSA
Kristine Cerchiara	Healthcare Innovation Partners
Linda Lucas	Fulton Manor
Linda Spurrell	Keane Care
Lorraine Toderash	Momentum Healthware
Louis Hyman	eHealth Solutions
Marcelle Feltman	Sun Healthcare
Margie White	Columbus Colony Elderly Care
Maria Moen	Healthware Consulting Services
Melanie Brodnik	The Ohio State University
Melissa Carter	American Health Care Software Enterprises
Mike Crowder	Golden Ventures
Nathan Simonis	American Data
Peter Kress	ACTS Retirement Life Communities
Rhonda Anderson	Anderson Health Information Systems
September Stone	National Health Care Learning Center
Shelly Spiro	R. Spiro Consulting
Sue Lewis	Accu-Med Services, LLC
Susan Greenly	Keane Care
Tim Smith	Golden Ventures
Todd Smith	American Health Care Association
Zoe Bolton	Independent Consultant
Workgroup Participants
Alan Adediger	Medicalodges
Allan Neoh	Achieve Healthcare Technologies
Allan Rosenbloom	Alliance for Quality Nursing Home Care
Barbara Manard	AAHSA
Bill Russell	Erickson Retirement Communities
Brenda Parks	Keane Care
Brett Klausman
Bryce Berry	Sunshine Terrace Foundation
Chris Thomas	Accu-Med Services, LLC
Christa Hojlo	Veterans Administration
Craig Baker	Accu-Med Services, LLC
Daniel Stein	Columbia University
Daniel Wilt	Erickson Retirement Communities
Darin Ballweg	American Data
Dave Dring	Interactive Aging Network
Dave Oatway	Care Track Systems, LLC
Dave Piehl
Debra Sperry	Good Samaritan Society
Denise Trcka	Achieve Healthcare Technologies
Donna Maassen	Extendicare
Eric Baker	Innovatix, LLC
Gary Schoetmer	RNA Health Information Systems
Geoffrey Bunza	Vigilan Inc
Gillian Broderick	Fundamental
Gloria Bean	TMF Health Quality Institute
Gregory Kaupp
Heath Boddy	Nebraska Health Care Assocication
Hongsoo Kim	NYU College of Nursing
Irene Wright	American Health Care Software Enterprises
James Albert	Masonicare
James Kwokon Eng	American Physical Therapy Association
Jamie Husher	The Evangelical Lutheran Good Samaritan Society
Janet Barber	Veterans Administration
Jeanette Kranacs	HHS, Centers for Medicare & Medicaid Services
Jeffrey Woodside	INHOUSE Pharmacy Solutions
Jerry Gurwitz, MD	Division of Geriatric Medicine University of Massachusetts Medical School
Jesse Wrenn	Columbia University
Jessica Dalton	Park River Estates Care Center
Joann Ross	Genesis Health Care Corp
Joe Wilson	Omnicare
Johnine Brooks	HCR Manor Care
Joy Thompson	HHS, Centers for Medicare & Medicaid Services
Judi Hummel
Julie Purcell	SavaSeniorCare Administrative Services
Julie Thompson	Beacon Partners, Inc
Karen Jennings	Ohio Department of Jobs & Family Services
Karen Thiel	Patton Boggs LLP
Karthik Natarajan	Columbia University
Kathy Hurst	SavaSeniorCare Administrative Services
Keith Speights	American HEALTHTECH
Keith Weaver	Ohio Department of Health
Kenneth Brouse	Community Health Systems
Kevin McCormack	Keane Care
Kevin Unrein	Lake Point
Kevin Warren	TMF Health Quality Institute
Larry Hillock	Community Health Systems
Larry Wolf	Kindred Healthcare
Linda Kunz	DART Chart
Marcia DeRosia	American Health Care Software Enterprises
Maria Arellano	American Association of Nurse Assessment Coordinators
Martin Rice	HHS, Centers for Medicare & Medicaid Services
Mary Anne Kurowski	Genesis Health Care Corp
Mary Guthrie	Veterans Administration
Mary Pratt	HHS, Centers for Medicare & Medicaid Services
Matthew Mullins	Momentum Healthware
Mike Easley	Home Quality Management Inc
Murry Mercier	HCR Manor Care
Nancy Robinson	American Medical Directors Association
Nelwyn Madison	American HEALTHTECH
Patty Padula	Myers & Stauffer
Rhonda Hamilton	National Government Services (FI)
Rich Castor	Genesis Health Care Corp
Rich Giddings	Achieve Healthcare Technologies
Rob Sutton	Accu-Med Services, LLC
Robert Abrams	My ZIVA
Roger Smith	Strafford County IT Department
Roi Qualls	eHDS Operations
Ron Cram
Royall Chambers	Eliza Bryant Village
Russ Depriest	HCR Manor Care
Scott Krueger
Sheila Dosher	Sun Healthcare
Sheila Lambowitz	HHS, Centers for Medicare & Medicaid Services
Sherrie Orvis	Veterans Administration
Steven Handler	University of Pittsburg School of Medicine
Sue Rucinski	Sava Senior Care Administrative Services
Suzanne Weaver	Neshaminy Manor
Thomas Welch	Eagle Software Group
Tydette Tisdell	Veterans Administration
Yael Harris	Office of the National Coordination of Health Information Technology

3. Changes from Previous Release

Not applicable.

This is Release 1 of the Long-Term Care-Nursing Home (LTC-NH) Electronic Health Record System (EHR-S) Functional Profile. Based on, and conformant with, the Health Level Seven (HL7) EHR-S Functional Model (FM) Release 1, February 2007, this document represents the culmination of one year of extensive work by private and public industry representatives and other stakeholders to identify functional requirements for EHR systems in nursing home settings. This document has been balloted by the LTC-NH EHR-S Functional Profile Workgroup and represents industry consensus on system requirements.

1. BACKGROUND

In late 2006, the U.S. Department of Health and Human Services (HHS) authorized and funded the Certification Commission for Healthcare Information Technology (CCHIT) to expand its certification scope of work and begin addressing EHR products to include ambulatory medical specialties and specialized care settings. Key stakeholders in the long-term care community, led by the joint efforts of the American Association of Homes and Services for the Aging (AAHSA), the American Health Care Association (AHCA), and the National Association for the Support of Long-Term Care (NASL), petitioned CCHIT for the inclusion of nursing homes in this expanded scope of certification activity. In March 2007, CCHIT officially announced their Roadmap for expansion of product certification -- and nursing homes were included. Actual certification of nursing home EHR products is anticipated in 2010.

In creating the certification criteria for nursing home EHR products, CCHIT will draw heavily on the requirements published in the 2007 HL7 EHR-S FM standard, as well as the industry specific requirements identified in the LTC-NH EHR-S Functional Profile.

While the HL7 EHR-S FM provides a reference list of functions that may be present in an EHR-S, the nursing home community has developed this LTC Functional Profile that identifies the subset of functions from the model that reflects the unique aspects and needs for EHR systems in the long-term care setting. CCHIT will use the LTC EHR-S Functional Profile as a reference when they develop the functionality, interoperability, and security requirements for certified NH EHR-S products.

2. PROCESS

Funding for the development of this LTC EHR-S Functional Profile has been provided by the HHS Office of the Assistant Secretary for Planning and Evaluation (ASPE). Project leadership has been provided by ASPE, the American Health Information Management Association (AHIMA), the Health Level Seven Electronic Health Record Technical Committee (HL7 EHR TC) and the National Council for Prescription Drug Programs (NCPDP).

Extensive volunteer support has been provided by a broad array of LTC industry and stakeholder representatives who have participated in the virtual meetings that were held each week to define the content of the profile.

3. NEXT STEPS

This document will be registered with the HL7 EHR TC as a conformant profile in July 2008. It will also be made available to appropriate CCHIT staff and committees at that time. In addition, the profile will be submitted to the HL7 EHR TC for the first cycle of balloting as a normative standard. This HL7 balloting will occur in the September 2008 ballot cycle.

4. ORGANIZATION OF THIS DOCUMENT

In addition to this Overview section, the LTC-NH EHR-S Functional Profile is organized into three sections of system requirements as follows.

Direct Care	Functions employed in the provision of care to individual patients and to collect information that will comprise the patients EHR. Direct care functions are the subset of functions that enable delivery of health care or offer clinical decision support.
Supportive Functions	Functions that support the delivery and optimization of care, but generally do not impact the direct care of an individual patient. These functions assist with the administrative and financial requirements associated with the delivery of health care, provide support for medical research and public health, and improve the global quality of health care.
Information Infrastructure	Functions that support the reliability, integrity, security and interoperability of the EHR-S. These functions are not involved in the provision of health care, but are necessary to ensure the integrity and security of the patients electronic health information.

5. CONFORMANCE CLAUSE

This profile is based on HL7 EHR-S FM, Release 1, February 2007. Key to the FM and derived profiles is the concept of conformance which may be defined as verification that an implementation faithfully meets the requirements of a standard or specification. A profile can be said to conform to the FM if it adheres to the defined rules identified by the FM specification. The LTC-NH EHR-S Functional Profile adheres to the defined rules of the EHR-S FM. Similarly, an EHR-S may claim conformance to the LTC-NH EHR-S Functional Profile if it meets all the requirements outlined in this profile.

5.1. Scope and Field of Application

The LTC-NH EHR-S Functional Profile applies to EHR systems developed for nursing homes. This profile makes no distinction regarding implementation -- the EHR-S described in this functional profile may be a single system or a system of systems.

5.2. Functional Priorities

The LTC-NH EHR-S Functional Profile Workgroup recognizes that clinical computing is an evolving field, and that many of the desired functions of EHR systems are not currently available. Nevertheless, it is important for functional profiles to outline major trends and articulate a vision for functionality (especially interoperability) for the future. Furthermore, the delineation of potential functions for future implementation and adoption should guide vendors in system development, and help purchasers develop and articulate to vendors a strategic vision for future functional requirements.

Each function in the profile is assigned a single priority as follows:

EN	Essential Now	Indicates that the implementation of the function is mandatory and SHALL be implemented in EHR systems claiming conformance to this profile.
EF xxxx	Essential Future	Indicates that the function has significant importance but is not widely available. The function will become mandatory and SHALL be implemented in EHR systems claiming conformance to this profile by the end of the year identified.
O	Optional	Indicates that, while the function may have value to some organizations, it is not viewed as being essential.
N/A	Not Applicable	Function not applicable in the nursing home setting and rejected for purposes of the LTC-NH EHR-S Functional Profile.

5.3. Normative Language

The key words SHALL, SHALL NOT, SHOULD, and MAY in this document are to be interpreted as described in HL7 EHR-S Functional Model, Release 1, February 2007 Chapter 2: Conformance Clause:

SHALL	Indicates a mandatory requirement to be followed (implemented) in order to conform. Synonymous with "is required to" and "must".
SHALL NOT	Indicates a prohibited action. Synonymous with "prohibited" and "must not".
SHOULD	Indicates an optional recommended action, one that is particularly suitable, without mentioning or excluding others. Synonymous with "is permitted and recommended".
MAY	Indicates an optional, permissible action. Synonymous with "is permitted".

5.4. Claiming Conformance to the Profile

The following provisions apply to claims of conformance to the LTC-NH EHR-S Functional Profile:

Systems claiming conformance to this Profile SHALL	Implement all functions designated Essential Now. Fulfill (i.e., meet or satisfy) all the SHALL criteria for each implemented function.
Systems claiming conformance to this Profile MAY	Implement functions designated Essential Future. Fulfill any of the SHOULD or MAY criteria associated with an implemented function.
Systems claiming conformance to this Profile SHALL NOT	Negate or contradict defined functionality of this profile when including additional functionality beyond what is specified in this profile.
Derived profiles claiming conformance to this Profile SHALL	Inherit all functions designated Essential Now. Inherit all SHALL criteria for functions included in the derived profile. Follow the rules for profiles in Chapter 2, Section 6.1 of the HL7 EHR-S FM standard. Adhere to the rules for creating new functions in Chapter 2, Section 6.3 of the HL7 EHR-S FM standard.
Derived profiles claiming conformance to this Profile MAY	Change SHOULD and MAY criteria to SHALL, SHOULD or MAY criteria.
Derived profiles claiming conformance to this Profile SHALL NOT	Change the functions name or statement.

6. APPLYING THE CONFORMANCE REQUIREMENTS

In some instances a SHALL criterion in a function may require conformance with another function in the profile that has a different timing priority (i.e., a criterion in an Essential Now (EN) function may require conformance with a function designated as Essential Future (EF) 2011). This situation would arise when HL7 requirements regarding profiles adopting mandatory requirements from the FM did not harmonize well with timing priorities for functions identified by profile developers. It is important to understand that the priority timing of a referencing function DOES NOT supersede the timing priority established for the referenced function. Examples include:

Example #1 (Referencing Function EN, Referenced Function EF)
Referencing Function
ID/Name:	DC.3.2.3 (Support for Communications Between Provider and Patient)
Priority:	Essential Now
SHALL Criteria for This Function:	There are 5 SHALL criteria for function DC.3.2.3 found at criteria #1, 2, 3, 5, and 10. Of these, only criterion #10 requires conformance to another function within the profile. Specifically, criterion #10 states The system SHALL conform to function IN.1.4 (Patient Access Management).
Referenced Function
ID/Name:	IN.1.4 (Patient Access Management)
Priority:	Essential Future 2010
Result
The SHALL criteria for function DC.3.2.3 found at criteria #1, 2, 3, and 5 are expected to be implemented at the time conformance is claimed with this profile. Conformance with DC.3.2.3 criterion #10 will not be expected until 2010.
Example #2 (Referencing Function EF, Referenced Function EN)
Referencing Function
ID/Name:	DC.2.2.2 (Support Consistent Healthcare Mgt of Patient Groups or Populations)
Priority:	Essential Future 2012
SHALL Criteria for This Function:	There are 4 SHALL criteria for function DC.2.2.2 found at criteria #1, 2, 3 and 5. The following criteria require conformance to other functions within the profile. Specifically, Criterion #1 states The system SHALL conform to DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols). Criterion #5 states The system SHALL conform to function S.2.2.2 (Standard Report Generation).
Referenced Functions
ID/Name:	DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols)
Priority:	Essential Now
ID/Name:	S.2.2.2 (Standard Report Generation)
Priority:	Essential Now
Result
Function DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols) is Essential Now, and the SHALL criteria found at DC.2.2.1.2 criteria #1, 6, 7 and 8 are expected to be implemented at the time conformance is claimed with this profile. Function S.2.2.2 (Standard Report Generation) is Essential Now and the SHALL criteria found at S.2.2.2 criteria #1 and 4 are expected to be implemented at the time conformance is claimed with this profile. Function DC.2.2.2 (Support Consistent Healthcare Management of Patient Groups or Populations) is Essential Future, and the ability to support context-sensitive care plans/guidelines/protocols, or generate standard reports, related to consistent healthcare management of patient groups or populations will not be expected until 2012.

7. STANDARDIZING TERMS IN FUNCTION CRITERIA

Additional clarification is necessary to understand the standardized nomenclature used to describe the functions of a system. The following chart, adapted from the EHR-S FM How to Guide for Creating Functional Profiles, illustrates the hierarchy of nomenclature. For example, capture is used to describe a function that includes both direct entry create and indirect entry through another device input. Similarly, maintain is used to describe a function that entails reading, updating, or removal of data.

MANAGE
Capture		Maintain
Input Device (External)	Create (Internal)	Read (Present)	Update	Remove Access
		View Report Display Access	Edit Correct Amend Augment	Obsolete Inactivate Destroy Nullify Purge

8. COMPONENTS OF LTC-NH EHR-S FUNCTIONAL PROFILE OUTLINE

Each function in the LTC-NH EHR-S Functional Profile is identified and described using a set of elements or components as detailed below.

ID	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status

Function ID

This is the unique outline identification of a function. Functions inherited from the HL7 EHR-S FM retain the ID assigned in the model. New functions added by the authors of the LTC-NH Functional Profile are underscored and shown in blue font.

Direct Care functions are identified by "DC" followed by a number (Example DC.1.1.3.1; DC.1.1.3.2).
Supportive functions are identified by an "S" followed by a number (Example S.2.1; S.2.1.1).
Information Infrastructure functions are identified by an "IN" followed by a number (Example IN.1.1; IN.1.2).

Function Type

Indication of the line item as being a header (H) or function (F).

Function Priority

Indication that implementation of the function is Essential Now (EN), Essential Future (EFxxxx), Optional (O), or Not Applicable (N/A). The definitions for these priorities are found above.

Function Name

The name of the Function (Example: Entity Authentication). Functions inherited from the HL7 EHR-S FM retain the Function Name as stated in the model. Names for new functions added by the authors of the LTC-NH EHR-S Functional Profile are underscored and shown in blue font.

Function Statement

Brief statement of the purpose of this function (Example: Authenticate EHR-S users and/or entities before allowing access to an EHR-S). Functions inherited from the HL7 EHR-S FM retain the Function Statement as shown in the model. Statements for new functions added by the authors of the LTC-NH EHR-S Functional Profile are underscored and shown in blue font.

Description

Detailed description of the function, including examples if needed (Example: Both users and applications are subject to authentication. The EHR-S must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S...) Functions inherited from the HL7 EHR-S FM retain the portions of the Description shown in the model that are relevant to the nursing home setting, with additional industry-specific explanation being underscored and shown in blue font. Descriptions for new functions added by the authors of the LTC-NH EHR-S Functional Profile are underscored and shown in blue font.

See Also

This element is intended to identify relationships between functions.

Conformance Criteria

This element displays valuable statements used to determine if a particular function is met (Example: The system SHALL authenticate principals prior to accessing an EHR-S application or EHR-S data). Modifications to conformance criteria inherited from the HL7 EHR-S FM are underscored and shown in blue font. Conformance criteria added to functions inherited from the functional model are indicated by an alpha designation (e.g., criterion #4a) and are underscored and shown in blue font. This numbering method allowed developers to display criteria in a logical sequence -- there is no relationship implied in regards to other criterion for the function. Finally, for new functions added to the LTC-NH EHR-S Functional Profile, criterion are underscored and shown in blue font.

Row #

This element is provided to help users when navigating the various sections (i.e., a user can reference row #38 of the IN section versus stating function IN.1.6, criterion #5).

FM Source -- ID #

This element is intended to assist with tracing profile content back to the HL7 EHR-S FM. The column displays the ID# for the source function from the model, or is blank if the function was added by the authors of the LTC-NH EHR-S Functional Profile.

FM Source -- Criteria #

This element is intended to assist with tracing profile content back to the HL7 EHR-S FM. The column displays the number for the source criterion from the model, or is blank if the criterion was added by the authors of the LTC-NH EHR-S Functional Profile.

FM Source -- Criteria Status

This element is intended to assist with tracing profile content back to the HL7 EHR-S FM. The following codes are used to convey the status of the profile’s criteria in relation to the FM:

N/C (No Change) -- the criterion is exactly the same as in the FM.
A (Added) -- the criterion was added by the EHR-S Functional Profile authors and is not found in the FM.
M (Modified) -- the criterion has been modified and is not the same as in the FM. Modifications to the FM text are underscored and shown in blue font.
D (Deleted) -- the criterion from the FM was determined to be inappropriate for the profile and was deleted. Only “SHOULD” and “MAY” criterion can be deleted -- “SHALL” criteria from the FM must be inherited by the profile.

ATTACHMENTS

Direct Care Functions

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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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
DC.1.1.3	H	EN	Data and Documentation from External Sources			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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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: 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) 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) 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) 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) Other forms of clinical results, such as wave files of EKG tracings (cc#8) 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) Structured, text-based reports (such as medical summary text in a structured format) (cc#10) 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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: the patient a surrogate (parent, spouse, guardian) or 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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: the patient a provider a payer, or 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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
DC.1.3	H	EN	Preferences, Directives, Consents and Authorizations			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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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
DC.1.4	H	EN	Summary Lists		S.2.2.2 IN.2.4 IN.2.5.1 IN.2.5.2	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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: the Conditions of Participation for Medicare and Medicaid (i.e., assessments related to resident risk of dehydration, unintended weight loss, or pressure ulcers), jurisdictional regulations, professional standards of practice, and 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 previous~~ly 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~SHOULD~~SHALL 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~SHOULD~~SHALLprovide 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~MAY~~SHOULD 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~SHOULD~~SHALLdisplay ~~instructions~~order directions (SIG)for administration of all medications on the list.	276	DC.1.8.1	3	M
						4. The system ~~MAY~~SHALL~~notify the clinician~~indicatewhen ~~specific doses~~medication related activitiesare due.	277	DC.1.8.1	4	M
						5. The system ~~MAY~~SHOULDconform 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 ~~MAY~~SHOULDconform 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 administered~~to 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~SHOULD~~MAY 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 given~~immediately 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 ~~SHOULD~~MAY transmit required immunization information to a public health immunization registry.	292	DC.1.8.2	11	M
						12. The system ~~SHOULD~~MAY 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~finalize~~a 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 standardized~~procedures, 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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 ~~the~~standard 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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
DC.2.2	H	EN	Care and Treatment Plans, Guidelines and Protocols		DC.1.2	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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
DC.2.2.1	H	EN				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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	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	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.2.3	F	O	Support for Research Protocols Relative to Individual Patient Care	Statement: Provide support for the management of patients enrolled in research protocols. Description: The clinician is presented with appropriate protocols for patients participating in research studies, and is supported in the management and tracking of study participants.	S.1.1 S.1.5 S.2.2.2 S.3.3.1 IN.1.1 IN.1.2 IN.1.3 IN.1.9 IN.2.2 IN.2.4 IN.4.1 IN.4.2 IN.4.3 IN.5.1 IN.5.2 IN.5.4 IN.6 IN.7	1. The system SHALLprovide the ability to present protocols for patients enrolled in research studies.	418	DC.2.2.3	1	N/C
						2. The system SHALLprovide the ability to maintain research study protocols.	419	DC.2.2.3	2	N/C
						3. The system SHOULDconform to function S.3.3.1 (Enrollment of Patients), to enable participation in research studies.	420	DC.2.2.3	3	N/C
						4. The system SHOULDprovide the ability to identify and track patients participating in research studies.	421	DC.2.2.3	4	N/C
						5. The system MAYprovide the ability to capture appropriate details of patient condition and response to treatment as required for patients enrolled in research studies.	422	DC.2.2.3	5	N/C
						6. The system SHALLconform to function S.2.2.2 (Standard Report Generation).	423	DC.2.2.3	6	N/C
						7. The system SHOULDconform to function IN.1.4 (Patient Access Management).	424	DC.2.2.3	7	N/C
						8. IF research protocols require standardized transmission of data to/from a registry or directory, THEN the system SHALLconform to function IN.3 (Registry and Directory Services).	425	DC.2.2.3	8	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.2.4	F	O	Support Self-Care	Statement: Provide the patient with decision support for self-management of a condition between patient-provider encounters. Description: Patients with specific conditions need to follow self-management plans that may include schedules for home monitoring, lab tests, and clinical check ups; recommendations about nutrition, physical activity, tobacco use, etc.; and guidance or reminders about medications. Information to support self-care may be appropriately provided to: the patient a surrogate (parent, spouse, guardian), or others involved directly in the patients self care.	DC.1.1.4 DC.1.11.1 S.3.7.1 S.3.7.2 S.3.7.3 IN.1.4 IN.1.9 IN.6	1. The system SHALLprovide the ability to present patient guidance and reminders appropriate for self-management of clinical conditions.	426	DC.2.2.4	1	N/C
						2. The system SHALLprovide the ability to manage and/or develop patient guidance and reminders related to specific clinical conditions.	427	DC.2.2.4	2	N/C
						3. The system SHOULDconform to function DC.1.1.3.2 (Capture of Patient Originated Data).	428	DC.2.2.4	3	N/C
						4. The system SHOULDconform to function DC.1.3.1 (Manage Patient and Family Preferences).	429	DC.2.2.4	4	N/C
						5. The system SHOULDconform to function IN.1.4 (Patient Access Management).	430	DC.2.2.4	5	N/C
						6. The system SHOULDconform to function IN.3 (Registry and Directory Services).	431	DC.2.2.4	6	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.3	H	EN	Medication and Immunization Management			1. The system SHALLconform to function IN.1.9 (Patient Privacy and Confidentiality).	432	DC.2.3	1	N/C
						2. The system SHALLconform to function IN.2.2 (Auditable Records).	433	DC.2.3	2	N/C
						3. The system SHOULDconform to function IN.3 (Registry and Directory Services).	434	DC.2.3	3	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.3.1	H	EN	Support for Medication and Immunization Ordering				435	DC.2.3.1		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.3.1.1	F	EN	Support for Drug Interaction Checking	Statement: Identify drug interaction warnings time of medication ordering. Description: The clinician is alerted to drug-drug, drug-allergy, and drug-food interactions at levels appropriate to the health care setting and with respect to the patient condition. These alerts may be customized to suit the user or group. If the patient’s condition is one where, in order to view the necessary components of the health record, patient authorization or consent is required, then the system should show the medication but mask the condition for which the medication is prescribed until the required consent or authorization is available. In an emergent situation, where all health information is required to provide the most effective treatment, and it is not possible to obtain an authorization or consent, the system should provide an override function to allow access to the diagnosis or problem for which a medication was ordered. This may vary based on jurisdictional law.	S.3 IN.2.4 IN.6	1. The system SHALLcheck for and alert providers to interactions between prescribed drugs and medications on the current medication list.	436	DC.2.3.1.1	1	N/C
						2. The system SHALLrelate medication allergies to medications to facilitate allergy checking decision support for medication orders.	437	DC.2.3.1.1	2	N/C
						3. The system SHOULDprovide the ability to document that a provider was presented with and acknowledged a drug interaction warning.	438	DC.2.3.1.1	3	N/C
						4. The system SHALLprovide the ability to prescribe a medication despite alerts for interactions and/or allergies being present.	439	DC.2.3.1.1	4	N/C
						5. The system MAYprovide the ability to set the severity level at which warnings should be displayed.	440	DC.2.3.1.1	5	N/C
						6. The system ~~SHOULD~~ SHALL provide the ability to check for duplicate therapies.	441	DC.2.3.1.1	6	M
						7. The system ~~SHOULD~~ SHALL conform to DC.1.8.6 (Manage Documentation of Clinician Response to Decision Support Prompts) and provide the ability to document why a drug interaction warning was overridden.	442	DC.2.3.1.1	7	M
						8. The system MAYcheck for interactions between prescribed drugs and food detailing changes in a drug's effects potentially caused by food (including beverages) consumed during the same time period.	443	DC.2.3.1.1	8	N/C
						9. The system SHOULDcheck for drug-lab interactions, to indicate to the prescriber that certain lab test results may be impacted by a patient’s drugs.	444	DC.2.3.1.1	9	N/C
						10. The system SHOULDprovide the ability to check medications against a list of drugs noted to be ineffective for the patient in the past.	445	DC.2.3.1.1	10	N/C
						11. The system SHOULDidentify contraindications between a drug and patient conditions at the time of medication ordering.	446	DC.2.3.1.1	11	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.3.1.2	F	EN	Support for Patient Specific Dosing and Warnings	Statement: Identify and present appropriate dose recommendations based on known patient-conditions and characteristics at the time of medication ordering. Description: The clinician is alerted to drug-condition interactions and patient specific contraindications and warnings such as ~~e.g. pregnancy, breast-feeding or occupational risks,~~hepatic or renal insufficiency. The preferences of the patient may also be presented ~~e.g.~~ such asreluctance to use an antibiotic. Additional patient parameters, such as age, ~~gestation, Ht, Wt~~, height, weight, BSA, shall also be incorporated. While current versions of available standards and knowledge-bases may not fully support all requirements of this function, it is anticipated that these resources -- and therefore EHR systems -- will continue to evolve and support this function in an ever more robust fashion.	DC.2.3.1.1 IN.6	1. The system SHALLprovide the ability to identify an appropriate drug dosage range, specific for each known patient condition (e.g., diagnosis) and parameter (e.g., height, weight, pulse, etc.) at the time of medication ordering.	447	DC.2.3.1.2	1	M
						2. The system SHALLprovide the ability to automatically alert the provider if contraindications to the ordered dosage range are identified.	448	DC.2.3.1.2	2	N/C
						3. The system SHALLprovide the ability for the provider to override a drug dosage warning.	449	DC.2.3.1.2	3	N/C
						4. The system ~~SHOULD~~ SHALL provide the ability to document reasons for overriding a drug alert or warning at the time of ordering.	450	DC.2.3.1.2	4	M
						5. The system ~~SHOULD~~ SHALL transmit documented reasons for overriding a drug alert to the pharmacy to enable communication between the clinician and the pharmacist.	451	DC.2.3.1.2	5	M
						5a. The system SHOULDtransmit documented reasons for overriding a drug alert to the consulting pharmacist system (when available) to enable communication between the clinician and the consulting pharmacist .	452			A
						6. The system SHOULDconform to function IN.1.4 (Patient Access Management).	453	DC.2.3.1.2	6	N/C
						7. IF the maximum daily doses are known, THEN the system SHALL ~~apply~~ indicate the maximum dose per day in dosing decision support.	454	DC.2.3.1.2	7	M
						8. The system SHOULDcompute drug doses, based on appropriate dosage ranges, using the patient’s body weight.	455	DC.2.3.1.2	8	N/C
						9. The system SHOULDprovide the ability to specify an alternative “dosing weight” for the purposes of dose calculation.	456	DC.2.3.1.2	9	N/C
						10. The system SHOULDperform drug dosage functions using any component of a combination drug (e.g., acetaminophen-hydrocodone).	457	DC.2.3.1.2	10	N/C
						11. The system SHOULD provide the ability to ~~record~~ display the factors(e.g., lab values, weight, age, etc.) used to calculate the ~~future~~ dose for a given ~~prescription~~ order.	458	DC.2.3.1.2	11	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.3.1.3	F	EN	Support for Medication Recommendations	Statement: The system should provide recommendations and options in medication and monitoring on the basis of patient diagnosis, cost, local formularies or therapeutic guidelines and protocols. Description: Offer alternative medications on the basis of practice standards (e.g., cost or adherence to guidelines), a generic brand, a different dosage, a different drug, or no drug (watchful waiting). Suggest lab order monitoring as indicated by the medication or the medical condition to be affected by the medication. Support expedited entry of series of medications that are part of a treatment regimen (i.e., renal dialysis, Oncology, transplant medications, etc.).	DC 2.3.1.2 S.3.3.2 IN.6	1. The system ~~SHOULD~~ SHALL conform to function DC 2.3.1.2 (Support for Patient-Specific Dosing and Warnings).	459	DC.2.3.1.3	1	M
						2. The system SHOULDpresentrecommendations for medication regimens based on ~~findings related to~~ the patient diagnosis (es) (e.g., recommendations based on diagnoses in accordance with the Beers list).	460	DC.2.3.1.3	2	M
						3. The system SHALLpresent alternative treatments in medications on the basis of practice standards, cost, formularies, or protocols.	461	DC.2.3.1.3	3	N/C
						4. The system SHOULDpresent suggested ~~lab~~ monitoring (such as labs, behaviors, adverse reactions, side effects) as appropriate to a particular medication.	462	DC.2.3.1.3	4	M
						5. The system SHOULDconform to function IN.1.4 (Patient Access Management).	463	DC.2.3.1.3	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.3.2	F	EN	Support for Medication and Immunization Administration	Statement: Alert providers to potential administration errors (such as wrong patient, wrong drug, wrong dose, wrong route and wrong time) in support of safe and accurate medication administration and support medication administration workflow. Description: To reduce medication errors at the time of administration of a medication, the patient is positively identified; checks on the drug, the dose, the route and the time are facilitated and appropriate alerts are provided at the point of care. Documentation is a by-product of this checking; administration details and additional patient information, such as injection site, vital signs, and pain assessments, are captured. Access to drug monograph information may be provided to allow providers to check details about a drug and enhance patient education. Workflow for medication administration is supported through prompts and reminders regarding the “window” for timely administration of medications.	DC.1.3.3 DC.1.7.2 DC.1.10.1 DC.2.7.1 S.1.4.1 S.2.2.2 S.3.7.1 IN.2.3 IN.2.4 IN.6	1. The system SHALLpresent information necessary to correctly identify the patient and accurately administer medications and immunizations such as ~~patient name~~, medication name, strength, dose, route and frequency, and patient name, patient photo, or other means of positive patient identification.	464	DC.2.3.2	1	M
						2. The system SHALLalert providers to potential administration errors ( such as wrong patient, wrong drug, wrong dose, wrong route and wrong time) as it relates to medication and immunizations administration.	465	DC.2.3.2	2	N/C
						3. The system ~~SHOULD~~ SHALL alert providers to potential medication administration errors at the point of medication administration.	466	DC.2.3.2	3	M
						4. The system SHALLprovide the ability to capture all pertinent details of the medication administration including medication name, strength, dose, route, time of administration, exceptions to administration, and administrator of the medication.	467	DC.2.3.2	4	N/C
						5. ~~IF required by the EHR user’s scope of practice, THEN~~ The system SHALL provide the ability to capture the administrator of the immunization and the immunization information identified in DC.1.8.2 (Manage Immunization Administration), Conformance Criteria #4 (The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer).	468	DC.2.3.2	5	M
						6. ~~The system MAYgenerate documentation of medication or immunization administration as a by-product of verification of patient, medication, dose, route and time~~ IF the system has an electronic means for verification of patient, medication, dose, route and time THEN the system SHALLautomatically capture the details of medication or immunization administration.	469	DC.2.3.2	6	M
						7. The system SHOULDprompt or remind providers regarding the date/time range for timely administration of medications.	470	DC.2.3.2	7	N/C
						8. The system MAYsuggest alternative administration techniques based on age, developmental stage, weight, physiological status, mental status, educational level, and past physical history of the patient.	471	DC.2.3.2	8	N/C
						9. The system ~~MAY~~ SHOULDconform to function DC.2.7.1 (Access Healthcare Guidance) and provide to the ability for a provider to access drug monograph information.	472	DC.2.3.2	9	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4	H	EN	Orders, Referrals, Results and Care Management			1. The system SHALLconform to function IN.1.9 (Patient Privacy and Confidentiality).	473	DC.2.4	1	N/C
						2. The system SHALLconform to function IN.2.2 (Auditable Records).	474	DC.2.4	2	N/C
						3. The system SHOULD conform to function IN.3 (Registry and Directory Services).	475	DC.2.4	3	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.1	F	EN	Create Order Set Templates	Statement: Create, capture, maintain and display order set templates based on patient data or preferred standards or other criteria. Description: Order set templates, which may include 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.1.9.3 S.2.2.2 S.3.7.1 IN.1.1 IN.1.2 IN.1.3 IN.6	1. The system SHALL provide the ability to create order set templates.	476	DC.2.4.1	1	N/C
						2. The system SHALL provide the ability to maintain order set templates, including version control.	477	DC.2.4.1	2	N/C
						3. The system ~~MAY~~ SHOULD provide the abilityfor providers to create individually customized order set templates ~~from provider input~~.	478	DC.2.4.1	3	M
						4. The system MAY capture order sets based on patient data that may be provided by the provider or that may be in accordance with preferred standards.	479	DC.2.4.1	4	N/C
						5. The system MAY provide the ability to create order set templates for ~~known~~ conditions ~~for a particular~~ or diseases.	480	DC.2.4.1	5	M
						6. The system SHALL present the order set templates to the provider.	481	DC.2.4.1	6	N/C
						7. The system MAY ~~record~~ provide the ability to capture the basis of the practice standards or criteria for the creation of the order set templates.	482	DC.2.4.1	7	M
						8. The system MAY provide the ability to ~~relate~~ present order set templates to providers based on diagnoses, conditions, or symptoms to aid decision support.~~for certain diseases.~~	483	DC.2.4.1	8	M
						9. The system SHALL conform to DC.1.7.3 (Manage Order Sets).	484	DC.2.4.1	9	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.2	F	EN	Support for Non-Medication Ordering	Statement: Display and request provider validation of information necessary for non-medication orders that make the order pertinent, relevant and resource-conservative at the time of provider order entry. Description: Possible order entry support includes, but is not limited to: notification of missing results required for the order, suggested corollary orders, notification of duplicate orders, institution-specific order guidelines, guideline-based orders/order sets, order sets, order reference text, patient diagnosis specific recommendations pertaining to the order. Also, warnings for orders that may be inappropriate or contraindicated for specific patients (e.g., X-rays for pregnant women) are presented. Non-medication orders include orders such as: DNR order leave of absence supplies such as 4x4’s and ACE bandages non-medical devices such as TTY phones for the hearing impaired groups of supplies or kits common to an organization simple durable medical equipment (DME) such as crutches or walkers complex DME such as wheelchairs and hospital beds therapies and other services that may require a referral and/or an authorization for insurance coverage	S.3.3.3 IN.6	1. The system SHALL identify required order entry components for non-medication orders.	485	DC.2.4.2	1	N/C
						2. The system SHALL present an alert at the time of order entry, if a non-medication order is missing required information.	486	DC.2.4.2	2	N/C
						3. The system ~~SHOULD~~ MAY present an alert via warnings of orders that may be inappropriate or contraindicated for specific patients at the time of provider order entry.	487	DC.2.4.2	3	M
						4. The system SHOULD conform to function S.3.3.3. (Service Authorizations).	488	DC.2.4.2	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.3	F	EF 2012	Support for Result Interpretation	Statement: Evaluate results and notify provider of results within the context of the patient’s healthcare data. Description: Possible result interpretations include, but are not limited to: abnormal result evaluation/notification, trending of results (such as discrete lab values), evaluation of pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam), evaluation of incoming results against active medication orders.	S.2.2.2 S.3.7.1 IN.2.4 IN.6	1. The system SHALL present alerts for a result that is outside of a normal value range.	489	DC.2.4.3	1	N/C
						2. The system SHOULD provide the ability to trend results.	490	DC.2.4.3	2	N/C
						3. The system MAY provide the ability to evaluate pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam).	491	DC.2.4.3	3	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.4	H	EN	Support for Referrals				492	DC.2.4.4		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.4.1	F	EN	Support for Referral Process	Statement: Evaluate referrals within the context of a patient’s healthcare data. Description: When a healthcare referral is made, health information, including pertinent clinical and behavioral health results, demographic and insurance data elements (or lack thereof) are presented to the provider. Standardized or evidence based protocols for appropriate workup prior to referral may be presented.	S.1.3.1a S.1.3.5 S.2.2.2 S.3.3.2 IN.2.4 IN.6	1. The system SHALL provide the ability to include clinical and administrative data (e.g., insurance information) as part of the referral process.	493	DC.2.4.4.1	1	N/C
						2. The system SHALL provide the ability to include test and procedure results with a referral.	494	DC.2.4.4.1	2	N/C
						3. The system MAY provide the ability to include standardized or evidence based protocols with the referral.	495	DC.2.4.4.1	3	N/C
						4. The system SHOULD allow clinical, administrative data, and test and procedure results to be transmitted to the referral clinician or clinical setting.	496	DC.2.4.4.1	4	M
						5. The system SHALL conform to function S.2.2.1 (Health Record Output).	497	DC.2.4.4.1	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.4.2	F	O	Support for Referral Recommendations	Statement: Evaluate patient data and recommend that a patient be referred based on the specific patient's healthcare data. Description: Entry of specific patient conditions may lead to recommendations for referral (e.g., ~~for smoking cessation counseling if the patient is prescribed a medication to support cessation screening or assessment for behavioral health conditions~~ diagnosis of depression recommends referral to psychologist).	S.3.7.1 IN.6	1. The system SHALL present recommendations for potential referrals based on diagnosis(es).	498	DC.2.4.4.2	1	N/C
						2. The system SHALL present recommendations for potential referrals based on patient condition (e.g. ~~for smoking cessation counseling if the patient is prescribed a medication to support cessation~~ conditions triggered from MDS such as declining ADL's, vision or hearing problems, abnormal lab values, recommendation for medication evaluation, etc. ).	499	DC.2.4.4.2	2	M
						3. The system SHOULD conform to IN.1.4 (Patient Access Management).	500	DC.2.4.4.2	3	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.5	H	O	Support for Care Delivery				501	DC.2.4.5		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.5.1	F	O	Support for Safe Blood Administration	Statement: Provide checking in real-time for potential blood administration errors. Description: To reduce errors at the time of blood product administration, the patient is positively identified. Additionally, checks on blood product identification, amount to be delivered, route and time of administration are captured, and alerts are provided as appropriate.	DC.1.10.2 S.1.2 S.2.2.1 IN.6	1. The system SHALL present information necessary to correctly identify the patient and accurately administer blood products including patient name, blood product number, amount, route, product expiration date and time of administration.	502	DC.2.4.5.1	1	N/C
						2. The system SHALL capture validation of the correct matching of the patient to the blood product.	503	DC.2.4.5.1	2	N/C
						3. The system SHALL capture the blood product number, amount, route and time of administration.	504	DC.2.4.5.1	3	N/C
						4. The system SHALL conform to function DC.1.8.4 (Manage Patient Clinical Measurements) and capture the blood pressure, temperature, pulse, respirations of the patient receiving the product.	505	DC.2.4.5.1	4	N/C
						5. The system SHALL conform to function S.2.2.1 (Health Record Output).	506	DC.2.4.5.1	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.4.5.2	F	O	Support for Accurate Specimen Collection	Statement: Provide checking to ensure accurate specimen collection is supported. Description: To ensure the accuracy of specimen collection, the patient and specimen are positively identified. The provider is notified in real-time of potential collection errors such as wrong patient, wrong specimen type, wrong means of collection, wrong site, and wrong date and time.	S.1.4.1 S.2.2.1 IN.1.6 IN.1.7 IN.1.9 IN.2.3 IN.2.4 IN.6	1. The system SHALL provide the ability to present information necessary to correctly identify the patient and accurately identify the specimen to be collected including, but not limited to, patient name, specimen type, specimen source, means of collection, date and time.	507	DC.2.4.5.2	1	N/C
						2. The system SHALL report variation between the type of specimen order placed and actual specimen received.	508	DC.2.4.5.2	2	N/C
						3. The system SHALL capture the details of specimen collection.	509	DC.2.4.5.2	3	N/C
						4. The system SHALL conform to function S.2.2.1 (Health Record Output).	510	DC.2.4.5.2	4	N/C
						5. The system SHOULD notify the provider in real-time of a variation between the type of specimen order placed and the actual specimen received.	511	DC.2.4.5.2	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.5	H	O	Support for Health Maintenance: Preventive Care and Wellness			1. The system SHOULD conform to function IN.1.4 (Patient Access Management).	512	DC.2.5	1	N/C
						2. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).	513	DC.2.5	2	N/C
						3. The system SHALL conform to function IN.2.2 (Auditable Records).	514	DC.2.5	3	N/C
						4. The system SHOULD conform to function IN.3 (Registry and Directory Services).	515	DC.2.5	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.5.1	F	O	Present Alerts for Preventive Services and Wellness	Statement: At the point of clinical decision making, identify patient specific suggestions/reminders, screening tests/exams, and other preventive services in support of routine preventive and wellness patient care standards. Description: At the time of an encounter, the provider or patient is presented with due or overdue activities based on protocols for preventive care and wellness. Examples include but are not limited to, routine immunizations, ~~adult and well child care, age and gender appropriate screening exams, such as PAP smears~~ screening such as mammograms and prostate cancer checks, colonoscopy, etc. The provider may wish to provide reminders to the patient based on the alert.	DC.2.5.1 DC.2.5.2 DC.2.6.2 IN.6	1. The system SHALL provide the ability to establish criteria for the identification of preventive care and wellness services based on patient demographics (e.g., age, gender).	516	DC.2.5.1	1	N/C
						2. The system ~~SHOULD~~ SHALL provide the ability to modify the established criteria that trigger the alerts.	517	DC.2.5.1	2	M
						3. The system SHOULD present recommended preventative or wellness services needed based upon clinical test results.	518	DC.2.5.1	3	N/C
						4. The system SHALL present alerts to the provider of all patient specific preventive services that are due.	519	DC.2.5.1	4	N/C
						5. The system MAY provide the ability to produce a list of all alerts along with the scheduled date and time for the preventive service.	520	DC.2.5.1	5	N/C
						6. The system MAY provide the ability to produce a history of all alerts that were generated for the patient in the record.	521	DC.2.5.1	6	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.5.2	F	N/A	~~Notifications and Reminders for Preventive Services and Wellness~~	Statement: Between healthcare encounters, notify the patient and/or appropriate provider of those preventive services, tests, or behavioral actions that are due or overdue. Description: The provider can generate notifications to patients regarding activities that are due or overdue and these communications can be captured. Examples include but are not limited to time sensitive patient and provider notification of: follow-up appointments, laboratory tests, immunizations or examinations. The notifications can be customized in terms of timing, repetitions and administration reports. E.g. a PAP test reminder might be sent to the patient two months prior to the test being due, repeated at three month intervals, and then reported to the administrator or clinician when nine months overdue.	~~S.3.7.2~~ ~~S.3.7.4~~ ~~IN.6~~	1. The system SHOULD generate timely notifications to patients including services, tests or actions that are due or overdue.	522	DC.2.5.2	1	D
						~~2. The system SHOULD capture a history of notifications.~~	523	DC.2.5.2	2	D
						~~3. The system SHOULD provide the ability to track overdue preventive services.~~	524	DC.2.5.2	3	D
						~~4. The system SHOULD provide notification of overdue preventative services in the patient record.~~	525	DC.2.5.2	4	D
						~~5. The system MAY provide the ability to configure patient notifications (such as repetitions or timing of the activity).~~	526	DC.2.5.2	5	D
						~~6. The system SHOULD provide the ability to update content of notifications, guidelines, reminders and associated reference materials.~~	527	DC.2.5.2	6	D
						~~7. The system MAY provide the ability to manage the lifecycle of the states of the notifications and reminders.~~	528	DC.2.5.2	7	D

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.6	H	EF 2011	Support for Population Health			1. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).	529	DC.2.6	1	N/C
DC.2.6	H	EF 2011	Support for Population Health			2. The system SHALL conform to function IN.2.2 (Auditable Records).	530	DC.2.6	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.6.1	F	O	Support for Epidemiological Investigations of Clinical Health Within a Population	Statement: Support internal and external epidemiological investigations of clinical health of aggregate patient data for use in identifying health risks from the environment and/or population in accordance with jurisdictional law. Description: Standardized surveillance performance measures that are based on known patterns of disease presentation can be identified by aggregating data from multiple input mechanisms. For example, elements include, but are not limited to patient demographics, resource utilization, presenting symptoms, acute treatment regimens, laboratory and imaging study orders and results and genomic and proteomic data elements. Identification of known patterns of existing diseases involves aggregation and analysis of these data elements by existing relationships. However, the identification of new patterns of disease requires more sophisticated pattern recognition analysis. Early recognition of new patterns requires data points available early in the disease presentation. Demographics, ordering patterns and resource use (e.g., ventilator or intensive care utilization pattern changes) are often available earlier in the presentation of non-predictable diseases. Consumer-generated information is also valuable with respect to surveillance efforts.	S.1.5 S.2.1.1 S.2.1.2 S.2.2.2 S.2.2.3 IN.1.6 IN.1.9 IN.2.2 IN.2.3 IN.2.4	1. The system SHALL provide the ability to aggregate patient information based on user-identified criteria.	531	DC.2.6.1	1	N/C
						2. The system SHALL apply local privacy and confidentially rules when assembling aggregate data to prevent identification of individuals by unauthorized parties.	532	DC.2.6.1	2	N/C
						3. The system SHOULD provide the ability to use ~~any~~ demographic or clinical information as criteria for aggregation.	533	DC.2.6.1	3	M
						4. The system SHOULD present aggregate data in the form of reports for external use.	534	DC.2.6.1	4	N/C
						5. The system SHOULD provide the ability to save report definitions for later use.	535	DC.2.6.1	5	N/C
						6. The system MAY present aggregate data in an electronic format for use by other analytical programs.	536	DC.2.6.1	6	N/C
						7. The system MAY provide the ability to derive statistical information from aggregate data.	537	DC.2.6.1	7	N/C
						8. IF biosurveillance or other epidemiological investigations require standardized transmission of data to/from a registry or directory, THEN the system SHALL conform to function IN.3 (Registry and Directory Services).	538	DC.2.6.1	8	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.6.2	F	EF 2011	Support for Notification and Response	Statement: Upon notification by an external, authoritative source of a health risk within the cared for population, alert relevant providers regarding specific potentially at-risk patients with the appropriate level of notification. Description: After receiving a notice of a health risk within a cared-for population from public health authorities or other external authoritative sources: Identify and notify individual care providers or care managers that a risk has been identified and requires attention; and Provide suggestions on the appropriate course of action. A care provider now has the ability to decide how patients are notified, if necessary. For example, this function may be used after detection of a local outbreak of hepatitis A, advising providers of the at-risk population and potential prophylactic treatment. A second example might be the dissemination of new care guidelines for elderly patients with a specific chronic disease. Notifications to clinicians or patients may occur by telephone, email, FAX or other methods.	S.1.3.6 S.2.2.2 S.3.7.1 S.3.7.4 IN.1.6 IN.1.7 IN.2.4 IN.3.1 IN.3.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 identify individual care providers or care managers within ~~a cared for population~~ the facility.	539	DC.2.6.2	1	M
						2. The system SHALL provide the ability to prepare a response notification to the care providers or care managers.	540	DC.2.6.2	2	N/C
						3. The system SHALL provide the ability to capture notification of a health risk within ~~a cared-for~~ the resident/patient population from public health authorities or other external authoritative sources as either free-text or a structured message (or by other means).	541	DC.2.6.2	3	M
						4. The system SHOULD provide the ability to coordinate with local and national programs to disseminate notifications of health risk to individual care providers or care-managers within the facility.	542	DC.2.6.2	4	M
						5. The system MAY provide the ability to notify patients, directly or indirectly, who are described by the health risk alert.	543	DC.2.6.2	5	N/C
						6. The system ~~SHOULD~~ MAY present suggestions to the care provider indicating an appropriate course of action.	544	DC.2.6.2	6	M
						7. The system SHALL provide the ability to notify public health authorities or other external authoritative sources of a health risk within ~~a cared for~~ the resident/patient population in accordance with scope of practice, organizational policy and jurisdictional law.	545	DC.2.6.2	7	M
						8. The system SHOULD conform to function IN.3 (Registry and Directory Services).	546	DC.2.6.2	8	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.6.3	F	EF 2011	Support for Monitoring Response Notifications Regarding a Specific Patient’s Health	Statement: In the event of a health risk alert and subsequent notification related to a specific patient, monitor if expected actions have been taken, and execute follow-up notification if they have not. Description: Identifies that expected follow-up for a specific patient event (e.g., follow up to error alerts or absence of an expected lab result) has not occurred and communicate the omission to appropriate care providers in the chain of authority. The notification process requires a security infrastructure that provides the ability to match a care provider’s clinical privileges with the clinical requirements of the notification.	DC.1.6.1 DC.1.6.2 S.1.3.6 S.1.4.1 S.2.2.2 S.2.2.3 S.3.7.4 IN.2.4 IN.6	1. The system SHALL present specific actions to be taken at the patient level for a health risk alert.	547	DC.2.6.3	1	N/C
						2. The system SHALL notify appropriate care providers of specific patient actions required by a health risk alert.	548	DC.2.6.3	2	N/C
						3. The system SHALL provide the ability to identify those patients who have not received appropriate action in response to a health risk alert.	549	DC.2.6.3	3	N/C
						4. The system SHOULD provide the ability to produce a report on the omission of an appropriate response to the health risk alert in specific patients.	550	DC.2.6.3	4	M
						5. The system ~~SHOULD~~ MAY conform to function IN.1.4 (Patient Access Management).	551	DC.2.6.3	5	M
						6. The system SHOULD conform to function IN.3 (Registry and Directory Services).	552	DC.2.6.3	6	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.7	H	EF 2011	Support for Knowledge Access			1. The system SHOULD conform to function IN.3 (Registry and Directory Services)	553	DC.2.7	1	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.7.1	F	EF 2011	Access Healthcare Guidance	Statement: Provide pertinent information from available evidence-based knowledge, at the point of care, for use in healthcare decisions and care planning. Description: The information available regarding disease, disease processes, diagnostic testing, pharmaceuticals, treatment patterns and all aspects of healthcare is constantly changing. The practitioner should be able to access a wide variety of sources that provide relevant, accurate information about any given subject. Examples of resources include, but are not limited to: evidence on treatment of specific medical conditions, maintenance of wellness, drug or device trials, context-specific information available through online journals, printed resources such as books and specialty organizations resources. For example, when a condition is diagnosed the provider might be directed to relevant resources that give updated clinical research, useful pharmaceutical combinations, surgical techniques, products or other information useful in the management of the specific condition under consideration.	S.3.7.1 S.3.7.4 IN.5.1 IN.5.2 IN.5.3 IN.5.4 IN.6	1. The system SHALL provide the ability to access evidence-based healthcare recommendations, with documentation of sources	554	DC.2.7.1	1	N/C
						2. The system ~~SHOULD~~ SHALL provide the ability to access evidenced-based documentation appropriate for the care provider to render a timely judgment.	555	DC.2.7.1	2	M
						3. The system ~~MAY~~ SHOULD provide the ability to access external evidence-based documentation.	556	DC.2.7.1	3	M
						4. The system SHALL conform to function DC.2.2.1.1 (Support for Standard Care Plans, Guidelines, Protocols).	557	DC.2.7.1	4	N/C
						5. The system SHOULD conform to function IN.1.4 (Patient Access Management).	558	DC.2.7.1	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.2.7.2	F	EF 2012	Patient Knowledge Access	Statement: Provide the ability to access reliable information about wellness, disease management, treatments, peer support groups and related information that is relevant for a specific patient. Description: An individual will be able to find reliable information to research a health question, follow up from a clinical visit, identify treatment options, or other health information needs. The information may be linked directly from entries in the health record, or may be accessed through other means such as key word search. The information may be provided as part of the EHR system but may also include patient information from external databases or specific websites.	DC.3.2.4 DC.3.4.9 S.3.7.1 S.3.7.2 S.3.7.4 IN.1.4 IN.5.1 IN.5.3 IN.5.4 IN.6	1. The system SHALL provide the ability to access information about wellness, disease management, treatments, and related information that is relevant for a specific patient.	559	DC.2.7.2	1	N/C
						2. The system MAY provide the ability to access information related to a health question directly from data in the health record or other means such as key word search.	560	DC.2.7.2	2	N/C
						3. The system MAY provide the ability to access patient educational information from external sources.	561	DC.2.7.2	3	N/C
						4. IF the information is external-based, THEN the system MAY provide the ability to identify links specific to the information.	562	DC.2.7.2	4	N/C
						5. The system SHALL conform to function IN.1.4 (Patient Access Management).	563	DC.2.7.2	5	N/C
						6. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).	564	DC.2.7.2	6	N/C
						7. The systemSHALL conform to function IN.2.2 (Auditable Records).	565	DC.2.7.2	7	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3	H	EN	Operations Management and Communication			1. The system SHALL conform to function IN.1.1 (Entity Authentication).	566	DC.3	1	N/C
						2. The system SHALL conform to function IN.1.2 (Entity Authorization).	567	DC.3	2	N/C
						3. The system SHALL conform to function IN.1.3 (Entity Access Control).	568	DC.3	3	N/C
						4. IF the system exchanges data across entity boundaries within an EHR-S or external to an EHR-S, THEN the system SHALL conform to function IN.1.6 (Secure Data Exchange) to ensure that the data are protected.	569	DC.3	4	N/C
						5. IF the system exchanges data with other sources or destinations of data, 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”.	570	DC.3	5	M
						6. 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.	571	DC.3	6	N/C
						7. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).	572	DC.3	7	N/C
						8. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction).	573	DC.3	8	N/C
						9. The system SHALL conform to function IN.2.2 (Auditable Records).	574	DC.3	9	N/C
						10. The system SHOULD conform to function IN.2.3 (Synchronization).	575	DC.3	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.	576	DC.3	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.	577	DC.3	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.	578	DC.3	13	N/C
						14. 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.	579	DC.3	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.2 (Maintenance and Versioning of Standard Terminologies) to preserve the semantics of coded data over time.	580	DC.3	15	N/C
						16. The system SHOULD conform to function IN.4.3 (Terminology Mapping).	581	DC.3	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.1 (Interchange Standards) to support interoperability.	582	DC.3	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.2 (Interchange Standards Versioning and Maintenance) to accommodate the inevitable evolution of interchange standards.	583	DC.3	18	N/C
						19. The system SHOULD conform to function IN.5.3 (Standards-based Application Integration).	584	DC.3	19	N/C
						20. 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.	585	DC.3	20	N/C
						21. The system SHOULD conform to function IN.6 (Business Rules Management).	586	DC.3	21	N/C
						22. The system SHOULD conform to function IN.7 (Workflow Management).	587	DC.3	22	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.1	H	EN	Clinical Workflow Tasking	Statement: Schedule and manage tasks with appropriate timeliness. Description: Since the electronic health record will replace the paper chart, tasks that were based on the paper artifact must be effectively managed in the electronic environment. Functions must exist in the EHR-S that support electronically any workflow that previously depended on the existence of a physical artifact (such as the paper chart, a phone message slip) in a paper based system. Tasks differ from other more generic communication among participants in the care process because they are a call to action and target completion of a specific workflow in the context of a patient's health record (including a specific component of the record). Tasks also require disposition (final resolution). The initiator may optionally require a response. For example, in a paper based system, physically placing charts in piles for review creates a physical queue of tasks related to those charts. This queue of tasks (for example, a set of patient phone calls to be returned) must be supported electronically so that the list (of patients to be called) is visible to the appropriate user or role for disposition. Tasks are time-limited (or finite). The state transition (e.g., created, performed and resolved) may be managed by the user explicitly or automatically based on rules. For example, if a user has a task to signoff on a test result, that task should automatically be marked complete by the EHR when the test result linked to the task is signed in the system. Patients will become more involved in the care process by receiving tasks related to their care. Examples of patient related tasks include acknowledgement of receipt of a test result forwarded from the provider, or a request to schedule an appointment for a pap smear (based on age and frequency criteria) generated automatically by the EHR-S on behalf of the provider.			588	DC.3.1		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.1.1	F	EN	Clinical Task Assignment and Routing	Statement: Assignment, delegation and/or transmission of tasks to the appropriate parties. Description: Tasks are at all times assigned to at least one user or role for disposition. Whether the task is assignable and to whom the task can be assigned will be determined by the specific needs of practitioners in a care setting. Task-assignment lists help users prioritize and complete assigned tasks. For example, after receiving communication (e.g. a phone call or e-mail) from a ~~patient, the triage nurse routes or assigns a task to return the patient's call to the physician who is on call~~ physician for a urinalysis, the nurse routes or assigns a task to clinical staff to collect a urine specimen. Task creation and assignment may be automated, where appropriate. An example of a system-triggered task is when lab results are received electronically; a task to review the result is automatically generated and assigned to a clinician. Task assignment ensures that all tasks are disposed of by the appropriate person or role and allows efficient interaction of entities in the care process.	S.1.3.1a S.1.3.5 IN.6	1. The system SHALL provide the ability for users to create manual clinical tasks.	589	DC.3.1.1	1	N/C
						2. The system SHALL provide the ability to automate clinical task creation.	590	DC.3.1.1	2	N/C
						3. The system SHALL provide the ability to manually modify and update task status (e.g., created, performed, held, canceled, pended, denied, and resolved).	591	DC.3.1.1	3	N/C
						4. The system ~~MAY~~ SHOULD provide the ability to automatically modify or update the status of tasks based on workflow rules.	592	DC.3.1.1	4	M
						5. The system SHOULD provide the ability to assign, and change the assignment of, tasks to individuals or to clinical roles.	593	DC.3.1.1	5	N/C
						6. The system ~~MAY~~ SHOULD provide the ability to manage workflow task routing to multiple individuals or roles in succession and/or in parallel.	594	DC.3.1.1	6	M
						7. The system ~~MAY~~ SHOULD provide the ability to prioritize tasks based on urgency assigned to the task.	595	DC.3.1.1	7	M
						8. The system ~~MAY~~ SHOULD provide the ability to restrict task assignment based on appropriate role as defined by the entity.	596	DC.3.1.1	8	M
						8a. The system MAY provide the ability to restrict task assignment based on an individual as defined by the entity .	597			A
						9. The system ~~MAY~~ SHOULD provide the ability to escalate clinical tasks manually or per business rules as appropriate to ensure timely completion.	598	DC.3.1.1	9	M
						10. IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/modified/sent/received the data.	599	DC.3.1.1	10	M
						11. The system SHOULD conform to function IN.3 (Registry and Directory Services).	600	DC.3.1.1	11	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.1.2	F	EN	Clinical Task Linking	Statement: Linkage of tasks to patients and/or a relevant part of the electronic health record. Description: Clinical tasks must include information or provide an electronic link to information that is required to complete the task. For example, this may include a patient location in a facility, a ~~patient’s~~ family’s contact information, or a link to new lab results in the patient’s EHR. An example of a well defined task is "Dr. Jones must review Mr. Smith's blood work results." Efficient workflow is facilitated by navigating to the appropriate area of the record to ensure that the appropriate test result for the correct patient is reviewed. Other examples of tasks might involve fulfillment of orders or responding to ~~patient~~ family phone calls.	S.1.3.1 S.1.4.1 S.1.4.2 S.1.4.4 S.1.6 S.1.7 IN.2.3 IN.7	1. The system SHALL provide the ability to link a clinical task to the component of the EHR required to complete the task (e.g., a task to take weights links to the ‘Weights and Vitals’ screen to record the result; a task to complete a Fall assessment links to the Fall assessment form to be completed; the weekly task to perform skin checks links to the documentation template for skin assessment).	601	DC.3.1.2	1	M
DC.3.1.2	F	EN	Clinical Task Linking		S.1.3.1 S.1.4.1 S.1.4.2 S.1.4.4 S.1.6 S.1.7 IN.2.3 IN.7	2. The system SHALL conform to function IN.1.5 (Non-Repudiation).	602	DC.3.1.2	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.1.3	F	EN	Clinical Task Tracking	Statement: Track tasks to facilitate monitoring for timely and appropriate completion of each task. Description: In order to reduce the risk of errors during the care process due to missed tasks, the provider is able to view and track un-disposed tasks, current work lists, the status of each task, unassigned tasks or other tasks where a risk of omission exists. The timeliness of certain tasks can be tracked, or reports generated, in accordance with relevant law and accreditation standards. For example, a provider is able to create a report ~~to show test results that have not been reviewed by the ordering provider based on an interval appropriate to the care setting~~ that shows tests that have not yet been performed such as urine specimen obtained, blood work drawn, etc.	S.2.2.2 S.2.2.3 IN.2.4 IN.7	1. The system SHALL provide the ability to track the status of tasks.	603	DC.3.1.3	1	N/C
						2. The system SHALL provide the ability to notify providers of the status of tasks.	604	DC.3.1.3	2	N/C
						3. The system ~~SHOULD~~ SHALL provide the ability to sort clinical tasks by status.	605	DC.3.1.3	3	M
						4. The system ~~MAY~~ SHOULD provide the ability to present current clinical tasks as work lists.	606	DC.3.1.3	4	M
						5. The system SHOULD provide the ability to ~~define the presentation of~~ sort or filter clinical task lists presented in reports or on the screen.	607	DC.3.1.3	5	M
						6. IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/modified /sent/received the data.	608	DC.3.1.3	6	M
						7. The system SHOULD conform to function IN.3 (Registry and Directory Services).	609	DC.3.1.3	7	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.2	H	EN	Support Clinical Communication	Statement: Description: Health care requires secure communications among various participants: patients, doctors, nurses, chronic disease care managers, pharmacies, laboratories, payers, consultants, and etc. An effective EHRS supports communication across all relevant participants, reduces the overhead and costs of healthcare-related communications, and provides automatic tracking and reporting. The list of communication participants is determined by the care setting and may change over time. Because of concerns about scalability of the specification over time, communication participants for all care settings or across care settings are not enumerated here because it would limit the possibilities available to each care setting and implementation. However, communication between providers and between patients and providers will be supported in all appropriate care settings and across care settings. Implementation of the EHRS enables new and more effective channels of communication, significantly improving efficiency and patient care. The communication functions of the EHRS will eventually change the way participants collaborate and distribute the work of patient care.		1. The system SHOULD conform to function IN.3 (Registry and Directory Services).	610	DC.3.2	1	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.2.1	F	EN	Support for Inter-Provider Communication	Statement: Support exchange of information between providers as part of the patient care process, and the appropriate documentation of such exchanges. Support secure communication to protect the privacy of information as required by federal or jurisdictional law. Description: Communication among providers involved in the care process can range from real time communication (for example, ~~fulfillment of an injection while the patient is in the exam room~~, communication between a therapist and nurse), to asynchronous communication (for example, consult reports between physicians). Some forms of inter-practitioner communication will be paper based and the EHR-S must be able to produce appropriate documents. The system should provide for both verbal and written communication. These exchanges would include, but not be limited to, consults and referrals as well as possible exchanges within the office as part of the provision and administration of patient care (for example, the communication of new information obtained within the office environment during the process of administration of a tetanus shot while the patient is in the exam room). The system should support the creation and acceptance of paper artifacts where appropriate.	DC.1.1.3 DC.1.9.5 S.1.3.1a S.1.3.2 S.1.3.3 S.1.3.4 S.2.2.2 IN.1.5 IN.1.6 IN.1.7 IN.1.9 IN.2.2. IN.3.1 IN.5.1 IN.5.2	1. The system SHALL provide the ability to document in the patient record verbal/telephone communication between providers.	611	DC.3.2.1	1	N/C
						2. The system SHALL provide the ability to incorporate scanned documents from ~~external~~ providers into the patient record.	612	DC.3.2.1	2	M
						3. The system ~~MAY~~ SHOULD provide the ability to communicate using real-time messaging.	613	DC.3.2.1	3	M
						4. The system SHOULD provide the ability to communicate clinical information (e.g. referrals) via secure e-mail or other electronic means (such as a CCD).	614	DC.3.2.1	4	M
						5. The system MAY provide the ability to transmit electronic multi-media data types representing pictures, sound clips, or video as part of the patient record.	615	DC.3.2.1	5	N/C
						6. The system SHALL conform to function IN.1.5 (Non-Repudiation).	616	DC.3.2.1	6	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.2.2	F	EN	Support for Provider -Pharmacy Communication	Statement: Provide features to enable secure bi-directional communication of information electronically between practitioners and pharmacies or between practitioner and intended recipient of pharmacy orders. Description: When a medication is prescribed, the order is routed to the pharmacy or other intended recipient of pharmacy orders. This information is used to avoid transcription errors and facilitate detection of potential adverse reactions. If there is a question from the pharmacy, that communication can be presented to the provider with their other tasks. In the nursing facility, medication order creation is a collaborative process involving the prescriber and facility staff. Accordingly, this function applies to communication process between the prescriber, facility and the pharmacy or other intended recipient of pharmacy orders. The transmission of prescription data between systems should conform to realm acceptable messaging standards. As an example, specific standards in the United States include the most recent versions of criteria from Health Level 7 (HL7), X12N, and/or the National Council for Prescription Drug Programs (NCPDP); and those of the National Electronic Claims Standard (NeCST) in Canada. It is anticipated that other realms may list other acceptable messaging standards. As required in IN.5.1 (Interchange Standards), transmission of prescription data between a facility and pharmacy that are not part of the same legal entity shall conform to NCPDP SCRIPT version 10.2 or higher. If the facility and pharmacy exchanging electronic prescription data are part of the same legal entity, IN.5.1 (Interchange Standards) supports the use of HL7 messaging or NCPDP SCRIPT version 10.2 or higher.	S.3.7.1 IN.1.5 IN.1.6 IN.1.7 IN.1.9 IN.2.2 IN.3.1 IN.4.1 IN.4.2 IN.4.3 IN.5.1 IN.5.2 IN.5.3 IN.5.4 IN.6 IN.7	1. The system SHALL conform to function DC.1.7.1 (Manage Medication Orders) and provide the ability to order medications.	617	DC.3.2.2	1	N/C
						1a. The system SHALL conform to function IN.5.1 (Interchange Standards).	618			A
						2. The system SHALL electronically communicate orders between the prescriber/~~provider~~ facility and pharmacy, as necessary, to initiate, change, or renew a medication order.	619	DC.3.2.2	2	M
						2a. The system SHOULD provide the ability to communicate a request to the pharmacy (based on an existing order) that additional medication be delivered (i.e., re-supply request).	620			A
						3. The system SHALL receive any acknowledgements, prior authorizations, renewals, inquiries and fill notifications provided by the pharmacy or other participants in the electronic prescription and make it available for entry in the patient record.	621	DC.3.2.2	3	N/C
						4. ~~The system SHOULD provide the ability to electronically communicate current realm-specific standards to pharmacies.~~	622	DC.3.2.2	4	D
						4a. The system SHALL have the ability to indicate that a NCPDP SCRIPT message has been sent or received, and display that message in human readable form.	623			A
						4b. The system SHOULD have the ability to exchange Drug Utilization Review (DUR) findings and Formulary & Benefits (F&B) data with the pharmacy using NCPDP SCRIPT (version 10.2 or higher).	624			A
						4c. The system SHOULD have the ability to notify the user when an NCPDP SCRIPT message has been received from an external source (such as pharmacy or prescriber).	625			A
						5. The system MAY provide the ability for providers and pharmacies to communicate clinical information via secure e-mail or other electronic means, on both general and specific orders.	626	DC.3.2.2	5	M
						6. The system MAY provide the ability to use secure SHALL transmit prescription messages in real-time. ~~messaging.~~	627	DC.3.2.2	6	M
						7. The system MAY provide the ability to include workflow tasks as part of communication to the provider.	628	DC.3.2.2	7	N/C
						8. IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/modified/ sent/received the data.	629	DC.3.2.2	8	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.2.3	F	EN	Support for Communications Between Provider and Patient and/or the Patient Representative	Statement: Facilitate communications between providers and patients and/or the patient representatives. Description: Providers are able to communicate with patients and others, capturing the nature and content of electronic communication, or the time and details of other communication. The "capture of communication" can be in the form of progress notes that are designated as "communication" or through automated processes. Examples: ~~When test results arrive, the clinician may wish to email the patient that test result was normal (details of this communication are captured).~~ ~~A patient may wish to request a refill of medication by emailing the physician.~~ ~~Patients with asthma may wish to communicate their peak flow logs/diaries to their provider.~~ ~~Hospital may wish to communicate with selected patients about a new smoking cessation program.~~ Notification of patient surrogate of the results of tests (such as x-ray) or assessments (such as Fall Risk) e-Mail notification of care plan conference schedules Automated notification regarding annual flu shots	DC.1.1.3 DC.1.11.3 S.1.3.6 S.1.4.1 S.3.5.1 S.3.5.3 S.3.5.4 S.3.7.1 S.3.7.2 S.3.7.3 S.3.7.4 IN.1.5 IN.1.6 IN.1.7 IN.1.9 IN.2.2 IN.6	1. The system SHALL provide the ability to capture documentation of communications between providers and patients and/ or the patient representatives.	630	DC.3.2.3	1	N/C
						2. The system SHALL provide the ability to incorporate scanned documents.	631	DC.3.2.3	2	N/C
						3. The system SHALL provide the ability to document communication originating with the patient or patient representative (e.g. date, entity, details of communication).	632	DC.3.2.3	3	N/C
						4. The system SHOULD provide the ability to communicate between providers and patients or their representative using a secure internet connection.	633	DC.3.2.3	4	N/C
						5. The system SHALL provide the ability to manage documentation regarding family member or patient representative authorizations to receive patient related health information.	634	DC.3.2.3	5	N/C
						6. The system SHOULD alert providers to the presence of patient or patient representative originated communications.	635	DC.3.2.3	6	N/C
						7. The system ~~SHOULD~~ MAY provide the ability to alert patients or patient representative to provider absences (e.g., vacations) and recommend rerouting of the information or request.	636	DC.3.2.3	7	M
						~~8. The system MAY provide the ability to notify providers of events and new treatment options.~~	637	DC.3.2.3	8	D
						9. The system MAY provide the ability to remind the patient or patient representative of events related to their care (e.g. upcoming appointments) as agreed upon by the patient and/or the patient representative.	638	DC.3.2.3	9	N/C
						10. The system SHALL conform to function IN.1.4 (Patient Access Management).	639	DC.3.2.3	10	N/C
						11. IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/modified/sent/received the data.	640	DC.3.2.3	11	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.2.4	F	EF 2010	Patient, Family and Care Giver Education	Statement: Facilitate access to educational or support resources pertinent to, and usable by, the patient or patient representative. Description: The provider or patient is presented with a library of educational materials. Material may be made available in the language or dialect understood by the patient or representative. Material should be at the level of the patient or representative’s level of understanding and sensory capability. Special needs are documented. Material may be disseminated via a mode available to and acceptable by the patient (e.g., printed, electronically or otherwise). The review of material between the clinician and the patient, and the patient’s understanding of the review, is documented when desired by the clinician. The patient or patient’s representatives are able to obtain educational information independently without formal review with the clinician if desired.	DC.2.1.4 DC 3.2.3 S.3.5.1 S.3.5.3 S.3.5.4 S.3.7.1 S.3.7.2 S.3.7.4 IN.1.4 IN.1.6 IN.1.7 IN.1.9 IN.2.2	1. The system SHALL provide the ability to access to a library of educational material for health concerns, conditions, and/or diagnosis.	641	DC.3.2.4	1	M
						2. The system SHALL provide the ability to communicate applicable educational materials to the patient and/or patient representative.	642	DC.3.2.4	2	N/C
						3. The system MAY provide ~~the ability to deliver multilingual~~ educational material in multiple languages.	643	DC.3.2.4	3	M
						4. The system MAY provide ~~the ability to deliver~~ patient educational materials using alternative modes to accommodate patient sensory capabilities.	644	DC.3.2.4	4	M
						5. ~~The system MAY provide the ability to access to external educational materials~~.	645	DC.3.2.4	5	D
						6. The system MAY provide the ability to use rules-based support to identify the most pertinent educational material, based on the patient health status, condition and/or diagnosis.	646	DC.3.2.4	6	N/C
						7. The system MAY provide the ability to document who received the educational material provided (the patient or the patient representative).	647	DC.3.2.4	7	N/C
						8. The system MAY provide the ability to document that the educational material was reviewed with the patient and/or patient representative and their comprehension of the material.	648	DC.3.2.4	8	N/C
						9. The system MAY provide ~~the ability to identify age-appropriate and/or reading-ability appropriate educational materials for the patient and/or patient representative~~ educational materials written for various ages and/or reading ability.	649	DC.3.2.4	9	M
						10. The system MAY provide the ability for direct access to the educational material available, by patients and/or patient representatives.	650	DC.3.2.4	10	N/C
						11. IF the system provides access to personal health information in the context of accessing patient education materials, THEN the system SHALL conform to function IN.1.4 (Patient Access Management).	651	DC.3.2.4	11	M
						12. IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/modified/sent/received the data.	652	DC.3.2.4	12	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
DC.3.2.5	F	EF 2011	Communication with Medical Devices	Statement: Support communication and presentation of data captured from medical devices. Description: Communication with medical devices is supported. ~~as appropriate to the care setting such as an office or a patient’s home~~. Examples include: vital signs/pulse-oximeter, ~~anesthesia machines~~, home diagnostic devices for chronic disease management, laboratory machines, bar coded artifacts (medicine, immunizations, demographics, history, and identification), etc.	IN.1.1 IN.1.2 IN.1.3 IN.1.6 IN.1.7 IN.1.9 IN.4.1 IN.4.2 IN.4.3 IN.5.1 IN.5.2 IN.5.3 IN.7	1. The system SHALL provide the ability to collect accurate electronic data from medical devices according to ~~realm-specific applicable regulations and/or requirements~~ scope of practice, organizational policy or jurisdictional law.	653	DC.3.2.5	1	M
						2. The system ~~SHOULD~~ SHALL provide the ability to present information collected from medical devices as part of the medical record ~~as appropriate~~.	654	DC.3.2.5	2	M
						3. IF the system provides access to personal health information in the context of the patient viewing information generated by the medical device, THEN the system SHOULD conform to function IN.1.4 (Patient Access Management).	655	DC.3.2.5	3	M

Supportive Functions

HL7 LTC-Nursing Home EHR-S Functional Profile (based on the HL7 EHR-S Functional Model, February 2007) -- Supportive 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1	H	EN	Clinical Support			1. The system SHALL conform to function IN.1.1 (Entity Authentication).	1	S.1	1	N/C
						2. The system SHALL conform to function IN.1.2 (Entity Authorization).	2	S.1	2	N/C
						3. The system SHALL conform to function IN.1.3 (Entity Access Control).	3	S.1	3	N/C
						4. The system SHALL conform to function IN.1.4 (Patient Access Management)	4			A
						5. The system SHALL conform to function IN.1.5 (Non-Repudiation)	5			A
						6. The system SHALL conform to function IN.1.6 (Secure Data Exchange)	6			A
						7. The system SHALL conform to function IN.1.8 (Information Attestation)	7			A
						8. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality)	8			A
						9. The system SHALL conform to function IN.1.10 (Secure Data Routing – LTC)	9			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.1	F	O	Registry Notification	Statement: Enable the automated transfer of formatted demographic and clinical information to and from local disease specific registries (and other notifiable registries) for patient monitoring and subsequent epidemiological analysis. Description: The user can export personal health information to disease specific registries, other notifiable registries such as immunization registries, through standard data transfer protocols or messages. The user can update and configure communication for new registries.	IN.2.4 IN.4.1 IN.4.2 IN.5.1 IN.5.2 IN.5.4	1. The system SHOULD automatically SHALL provide the ability to transfer formatted demographic and clinical information to local disease specific registries (~~and~~ or other notifiable registries) as directed by scope of practice, organizational policy or jurisdictional law.	10	S.1.1	1	M
						2. The system MAY provide the ability to automate the retrieval of formatted demographic and clinical information from local disease specific registries (~~and~~ or other notifiable registries).	11	S.1.1	2	M
						3. The system ~~SHOULD~~ SHALL provide the ability to add, change, or remove access to registries.	12	S.1.1	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.2	F	O	Donor Management Support	Statement: Provide capability to capture or receive, and share needed information on potential donors and recipients. Description: The user is able to capture or receive information on potential donors and recipients (for products such as blood, organs, ~~eggs, sperm, or stem cells~~ eye, cadaver, etc.). The user can make this information available to internal and external donor matching agencies.	IN.1.7 IN.2.4	1. The system ~~MAY~~ SHALL provide the ability to ~~document~~ capture demographic and clinical information needed for the donation.	13	S.1.2	1	M
						~~2. The system MAY receive demographic and clinical information about potential donors.~~	14	S.1.2	2	D
						~~3. The system MAY receive demographic and clinical information about the donation.~~	15	S.1.2	3	D
						4. The system MAY ~~share~~ communicate documented demographic and clinical information about potential donors with appropriate outside parties.	16	S.1.2	4	M
						5. The system MAY ~~share~~ communicate documented demographic and clinical information about the donation with appropriate outside parties (e.g. donor management organization, eye bank, surgeon).	17	S.1.2	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3	H	EN	Provider Information	Statement: Maintain, or provide access to, current provider information.	IN.1.3 IN.4		18	S.1.3		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.1	F	EN	Provider Access Levels	Statement: Provide a current registry or directory of practitioners that contains data needed to determine levels of access required by the system. Description: Provider information may include any credentials, certifications, or any other information that may be used to verify that a practitioner is permitted to use or access authorized data.	IN.2.3 IN.3	1. The system SHOULD provide SHALL create and maintain a registry or directory of all personnel who currently use or access the system.	19	S.1.3.1	1	M
						2. The system SHOULD contain, in the directory, the SHALLprovide the ability to capture realm-specific legal identifiers required for care delivery ~~such as the practitioner's license number~~ as discrete data elements, including the NPI, practitioner's license number and other identifiers as required by scope of practice, organizational policy, or jurisdictional law.	20	S.1.3.1	2	M
						3. The system ~~SHOULD~~ SHALL provide the ability to add, update, and inactivate entries in the directory ~~so that it is current~~.	21	S.1.3.1	3	M
						4. The system SHOULD contain, in the directory, the information necessary to determine levels of access required by the system security functionality.	22	S.1.3.1	4	N/C
						5. The system MAY provide SHOULD create and maintain a directory of clinical personnel external to the organization, that are not users of the system, to facilitate ~~documentation~~ communication and information exchange (i.e., e-mail alert for change in condition, critical lab value to a dialysis center, etc.).	23	S.1.3.1	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.2	F	O	Provider's Location Within Facility	Statement: Provide provider location or contact information on a facility's premises. Description: The identification of provider’s location within a facility may facilitate the handling of critical care situations. This may include the location of on site practitioners by name or immediate required specialty. A real-time tracking system may provide automatic update of such information.		1. The system ~~SHOULD~~ SHALL provide the ability to input or create information on provider location or contact information on a facility's premises.	24	S.1.3.2	1	M
S.1.3.2	F	O	Provider's Location Within Facility			2. The system ~~SHOULD~~ SHALL provide the ability to add, update, or inactivate information on provider's location or contact information on a facility's premises, so that it is current.	25	S.1.3.2	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.3	F	EN	Provider's On Call Location	Statement: Provide provider location or contact information when on call. Description: The provider immediate contact information. This may include on call practitioners on a facility’s premises as well as on call contact information (e.g., phone number, pager, cell phone, etc.) after scheduled working hours.	IN.2.3	1. The system ~~SHOULD~~ SHALL provide the ability to input or create information on provider on-call location or contact information ~~when on call~~.	26	S.1.3.3	1	M
S.1.3.3	F	EN	Provider's On Call Location		IN.2.3	2. The system ~~SHOULD~~ SHALL provide the ability to add, update, or ~~obsolete~~ inactivate information on a provider's on call location or contact information, so that it is current.	27	S.1.3.3	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.4	F	EN	Provider's Location(s) or Office(s)	Statement: Provide locations or contact information for the provider in order to direct patients or queries. Description: Providers may have multiple locations or offices where they practice. The system ~~should~~ shall capture and maintain information necessary to identify and contact practice locations or offices of providers, and may include information such as on the primary location, any secondary locations, as well as the scheduled hours at each location, ~~Information maintained may include~~ web sites, maps, office locations, etc.	IN.2.3 IN.3	1. The system ~~SHOULD~~ SHALL ~~contain~~ capture information necessary to identify and contact ~~primary and secondary~~ practice locations or offices of providers ~~to support communication and access~~.	28	S.1.3.4	1	M
S.1.3.4	F	EN	Provider's Location(s) or Office(s)		IN.2.3 IN.3	2. The system ~~SHOULD~~ SHALL provide the ability to add, update and inactivate ~~obsolete~~ information necessary to identify and contact ~~on the provider's primary and secondary~~ practice locations or offices of providers.	29	S.1.3.4	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.5	F	O	Team/Group of Providers Registry or Directory	Statement: Provide access to a current directory, registry or repository of information on Teams or Groups of providers in accordance with relevant laws, regulations, and organization or internal requirements. Description: An organization may assign caregivers to teams that need to be registered as such. In another scenario, an organization might contract with a group of providers. The group would be listed by the group name or individually or both. A caregiver might be part of more than 1 team or group. All of these factors need to be supported. Information includes, but is not limited to; full name, address or physical location, and a 24x7 telecommunications address (e.g., phone or pager access number).	IN.2.3	1. The system ~~SHOULD~~ SHALL provide the ability to access a current directory, registry or repository of Teams or Groups of providers in accordance with relevant laws, regulations, and organization or internal requirements.	30	S.1.3.1	1	M
						2. The system SHOULD conform to IN.3 (Registry and Directory Services), Conformance Criteria #13 (The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource management purposes).	31	S.1.3.1	2	N/C
						3. The system SHOULD conform to S.3.4 (Manage Practitioner/Patient Relationships), Conformance Criteria #2 (The system SHALL provide the ability to specify the role of each provider associated with a patient such as ~~encounter provider, primary care provider,~~ attending physician, ophthalmologist, psychologist, dentist, podiatrist, geriatric nurse practitioner, physician assistant, ~~resident~~, or consultant).	32	S.1.3.1	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.6	F	EN	Provider Caseload/Panel	Statement: Provide access to a provider's caseload or panel information. Description: ~~An organization might employ the concept of~~ A facility may maintain a caseload ~~or panel~~ of patients to facilitate continuity of care and distribution of work. A caregiver may have, or be accountable for, zero to multiple defined caseloads or panels of members/patient/clients within the organization. Information about the caseload or panel includes such things as whether or not a new member/patient/client can be added. A member/patient may be provided access to a listing of caregivers with open caseloads or panels to select a provider. For example, a wound care nurse (or team) may have a list of assigned residents based upon the resident's care needs. A list of these residents would be produced to assist that nurse in delivering care. Another example might be a list of residents receiving hospice care. A list of those residents would be produced that were assigned to hospice care personnel. A somewhat different example of this functionality would be the ability to identify those providers able to accept new patients	DC.1.7.2.4 DC.3.1.1 DC.3.1.3 IN.2.3 IN.2.4	1. The system SHALL provide the ability to access a provider's resident caseload ~~or panel~~ information.	33	S.1.3.1	1	M
						2. The system SHALL provide the ability to add, update, and remove access to ~~panel information such as status~~ the provider’s resident caseload information.	34	S.1.3.1	2	M
						3. The system ~~SHOULD~~ SHALL conform to function S.3.4 (Manage Practitioner/Patient Relationships).	35	S.1.3.1	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.3.7	F	EN	Provider Registry or Directory	Statement: Provide access to a current directory, registry or repository of provider information in accordance with relevant laws, regulations, and organization or internal requirements. Description: A system maintains or has access to provider information needed in the provision of care. This is typically a directory, registry or repository. Information includes, but is not limited to; full name, specialty, credentials, address or physical location, and a 24x7 telecommunications address (e.g., phone or pager access number). Views of the information are tailored to the user's security level and access need. For example, a nursing supervisor may need access to a provider's home phone. A member/patient wishing to select a primary care provider has a narrower view that would not include personal access information.	IN.1.3 IN.2.1 IN.3	1. The system SHOULD conform to IN.3 (Registry and Directory Services), Conformance Criteria #7 (The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care).	36	S.1.3.7	1	N/C
						2. The system SHALL contain provider information including (but not limited to) ~~(such as~~ full name, ~~specialty, address and~~ contact information, and NPI and license number (where applicable), in accordance with scope of practice, organizational policy and jurisdictional law.	37	S.1.3.7	2	M
						3. The system SHALL provide the ability to add, update, and remove access to entries in the registry or directory so that it is current.	38	S.1.3.7	3	N/C
						4. The system ~~MAY~~ SHOULD provide a directory of clinical personnel external to the organization that are not users of the system to facilitate documentation.	39	S.1.3.7	4	M
						5. The systems ~~SHOULD~~ SHALL provide the ability to restrict the view of selected elements of the registry or directory information, subject to the user's security level and access needs.	40	S.1.3.7	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.4	H	EN	Patient Directory	Statement: Provide a current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions. Description: The patient directory may capture information including but not limited to, full name, address or physical location, alternate contact person, primary phone number, and relevant health status information. The view of this information may vary based on purpose, scope of practice, organizational policy or jurisdictional law. Several specific directory views are described in the following functions.	DC.1.1.1 IN.1.4		41	S.1.4		M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.4.1	F	EN	Patient Demographics	Statement: Support interactions with other systems, applications, and modules to enable the maintenance of updated demographic information in accordance with realm-specific recordkeeping requirements. Description: The minimum demographic data set must include the data required by ~~realm-specific laws~~ organizational policy and jurisdictional law governing health care transactions and reporting. For example, this may include data input of death status information, or may include support to identify multiple names, such as updating from ~~Baby Girl~~ John Doe, to ~~neonate's~~ patient’s given name. This function addresses exchange of demographic information with systems both internal and external to the organization such as between: The facility and the external pharmacy services provider The EHR ADT module and the facility’s Dietary Management system.	DC.1.3.3 S.1.4 S.3.7.3 IN.2.3	1. The system ~~MAY~~ SHOULD provide the ability to reconcile ~~add and update~~ patient demographic information (subject to authorized user approval) through interaction with other systems, applications and modules.	42	S.1.4.1	1	M
S.1.4.1	F	EN	Patient Demographics		DC.1.3.3 S.1.4 S.3.7.3 IN.2.3	2. The system ~~MAY~~ SHALL accept and retrieve patient demographic information ~~as required by realm specific laws governing health care transactions and reporting~~ in accordance with IN.5.1 (Interchange Standards).	43	S.1.4.1	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.4.2	F	EN	Patient's Location Within a Facility	Statement: Provide the patient's location information within a facility's premises. Description: This function is intended to support maintaining and/or providing access to information on the patient's location during an episode of care. This function can be as simple as displaying the assigned bed for a patient (i.e., Adam, ~~W2-Reb 214~~ West Wing Rm #214). It can also be a function that supports real-time information on the patient location as they receive ancillary services in other parts of a facility (such as physical therapy ~~or diagnostic imaging~~ in the Rehab Department). Note: For standard reports like ~~an ER Log or~~ a Census, see the Standard Reports function (S.2.2). The system ~~should~~ shall support viewing a patient’s specific location in terms that may include campus, building, wing, unit, room, bed. The system should support jurisdictional laws related to patient consent on disclosure. The patient location information should also be available when the provider is not in the patient record. As such, the systems may need to provide a query feature on patient location information. The system may support the identification of the patient by alternate identifying names.		1. IF the patient has an assigned location, THEN the system SHALL provide the ability to identify and display/view the patient’s assigned location.	44	S.1.4.2	1	N/C
						2. The system SHOULD support consents as they apply to the release of patient location information according to scope of practice, organization policy, or jurisdictional laws.	45	S.1.4.2	2	N/C
						3. The system MAY provide the ability to identify the patient’s current, real-time location, unambiguously, within a facility.	46	S.1.4.2	3	N/C
						4. The system ~~MAY~~ SHALL provide the ability to query patient location information.	47	S.1.4.2	4	M
						5. The system ~~MAY~~ SHOULD provide the ability to query patient location by alternate identifying names.	48	S.1.4.2	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.4.3	F	EN	Patient's Residence for the Provision and Administration of Services	Statement: Provide the patient's residence information for the provision and administration of services to the patient, patient transport, and as required for public health reporting. Description: This function is intended to support the provision of services to patients at their place of residence. Examples include but are not limited to the following: ~~Visiting nurse may be providing care to a new mother and baby at their place of residence~~. SNF staff providing services to a resident of the organization’s assisted living facility. A patient with a mobility problem may require transport to and from a clinic appointment. Support identification of multiple residences ~~for~~ related to a patient ~~like a child with multiple~~ such as a guardians ~~(divorced parents with joint custody) or adults~~ with Winter/Summer residences.	DC 1.1.2	1. The system ~~SHOULD~~ SHALL provide the ability to identify the patient’s primary residence.	49	S.1.4.3	1	M
						2. The system ~~MAY~~ SHALL provide the ability to identify the patient’s secondary or alternate residence.	50	S.1.4.3	2	M
						3. The system MAY provide the ability to enter and update patient information related to the provision of service.	51	S.1.4.3	3	N/C
						4. The system SHOULD provide the ability to enter and update patient information related to transport, such as, mobility status, special needs and facility access (stairs, elevator, wheelchair access).	52	S.1.4.3	4	N/C
						5. The system ~~SHOULD~~ SHALL provide the ability to enter and update patient residence information as necessary for public health reporting.	53	S.1.4.3	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.4.4	F	EN	Patient Bed Assignment	Statement: Support interactions with other systems, applications, and modules to ensure that the patient's bed assignments within the facility optimize care and minimize risks (e.g., of exposure to contagious patients). Description: Access to a list of available beds is important to safely manage the care of patients whose bed requirements may change based on change in condition or risk factors (for example, ~~a patient may~~ by gender, certification level, need for a room with special equipment such as oxygen, or need to be close to the nursing station/cohort by condition or to be in a private room, etc.).	S.1.7 IN.6	1. The system ~~SHOULD~~ SHALL support interactions as required to ~~support~~ facilitate patient bed assignment ~~internal or external to~~ within the system.	54	S.1.4.4	1	M
						1a. The system SHOULD support interactions as required to facilitate patient bed assignment external to the system.	55			A
						2. The system MAY provide patient information to an external system to facilitate bed assignment that optimizes care and minimizes risk.	56	S.1.4.4	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.5	F	O	De-Identified Data Request Management	Statement: Provide patient data in a manner that meets local requirements for de-identification. Description: When an internal or external party requests patient data and that party requests de-identified data (or is not entitled to identified patient information, either by scope of practice, organizational policy or jurisdictional law ~~or custom~~), the user can export the data in a fashion that meets requirements for de-identification ~~in that locale or realm~~ as required by scope of practice, organizational policy or jurisdictional law. An auditable record of these requests and associated exports ~~may~~ shall be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review. A random re-identification key may be added to the data, to support re-identification for the purpose of alerting providers of potential patient safety issues. For example, if it is discovered that a patient is a risk for ~~a major cardiac event~~ clinical complications (such as hip fracture), the provider could be notified of this risk, allowing the provider to identify the patient from the random key.	IN.1.6 IN.1.7 IN.1.8 IN.2.2 IN.3 IN.4.3 IN.5.1 IN.5.4 IN.6.1	1. The system SHALL conform to IN.1.9 (Patient Privacy and Confidentiality) and provide de-identified views of data in accordance with scope of practice, organizational policy and jurisdictional law.	57	S.1.5	1	N/C
S.1.5	F	O	De-Identified Data Request Management			2. ~~The system SHOULD conform to IN.2.4 (Extraction of Health Record Information), Conformance Criteria #3 (The system SHOULD provide the ability to de-identify extracted information)~~. The system SHALL provide the ability to de-identify extracted information.	58	S.1.5	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.6	F	EF 2013	Scheduling	Statement: Support interactions with other systems, applications, and modules to provide the necessary data to a scheduling system for optimal efficiency in the scheduling of patient care, for either the patient or a resource/device. Description: The system may support user access to scheduling systems as required. Relevant clinical or demographic information required in the scheduling process could be linked to the task.	DC.3.1 DC.3.2.1 IN.2.3 IN.4.1 IN.7	1. The system ~~MAY~~ SHALL provide the ability to access ~~scheduling~~ data/features, ~~either internal or external to the system, for~~ from other internal systems that are necessary for scheduling patient care or patient resources/devices.	59	S.1.6	1	M
						2. The system MAY provide the ability to access scheduling features, either internal or external to the system, for patient care devices/equipment.	60	S.1.6	2	M
						3. The system ~~MAY~~ SHOULD incorporate relevant clinical or demographic information in the scheduling process.	61	S.1.6	3	M
						4. The system MAY pass relevant clinical or demographic information to support efficient scheduling with other system.	62	S.1.6	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.7	F	EF 2015	Healthcare Resource Availability	Statement: Support the collection and distribution of local health care resource information, through interactions with other systems, applications, and modules, to enable planning and response to extraordinary events such as local or national emergencies. Description: In times of identified local or national emergencies and upon request from authorized bodies, provide current status of the organization’s physical and human health care resources including, but not limited to, available beds, providers, support personnel, ancillary care areas and devices, ~~operating theaters~~, medical supplies/equipment, vaccines, and pharmaceuticals. The intent is to enable the authorized body to distribute or re-distribute either resources or patient load to maximize efficient healthcare delivery. In addition, these functions may also be used for internal assessment and planning purposes by facility administrators.	S.1.4.4 IN.1.6 IN.5.1 IN.5.4	1. The system ~~MAY~~ ~~collect~~ SHALL capture information on health care resource availability through interactions with other ~~systems,~~ applications, and modules.	63	S.1.7	1	M
						2. The system MAY provide the ability to access information on health care resource availability for internal assessment and planning purposes. Health care resources may include, but is not limited to available beds, providers, support personnel, ancillary care areas and devices, ~~operating theaters~~, medical supplies/equipment, vaccines, and pharmaceuticals.	64	S.1.7	2	M
						3. The system ~~MAY~~ SHALL provide the ability to export information on healthcare resource availability to authorized external parties.	65	S.1.7	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.1.8	F	O	Information View	Statement: Support user-defined information views. Description: Views of the information can be tailored for or by the user (or department or "job classification”) for their presentation preferences, within local or facility established rules. For example, a nursing supervisor may elect or prefer to see summary data on all patients as the default view.	IN.2.4 IN.2.5.1 IN.2.5.2	1. The system ~~MAY~~ SHALL provide authorized administrators the ability to tailor the presentation of information for preferences of the user, department/area or user type.	66	S.1.8	1	M
S.1.8	F	O	Information View		IN.2.4 IN.2.5.1 IN.2.5.2	2. The system MAY provide authorized users the ability to tailor their presentation of information for their preferences.	67	S.1.8	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2	H	EN	Measurement, Analysis, Research and Reports			1. The system SHALL conform to function IN.1.1 (Entity Authentication).	68	S.2	1	N/C
						2. The system SHALL conform to function IN.1.2 (Entity Authorization).	69	S.2	2	N/C
						3. The system SHALL conform to function IN.1.3 (Entity Access Control).	70	S.2	3	N/C
						4. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).	71	S.2	4	N/C
						5. The system SHALL conform to function IN.2.4 (Extraction of Health Record Information).	72	S.2	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.1	H	EN	Measurement, Monitoring, and Analysis	Statement: Support measurement and monitoring of care for relevant purposes. Description:	DC.2.6.1		73			N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.1.1	F	EN	Outcome Measures and Analysis	Statement: Support the capture and subsequent export or retrieval of data necessary for the reporting on patient outcome of care by population, facility, provider or community. Description: Many regions require regular reporting on the health care provided to individuals and populations. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software. The system may also provide the functionality to prompt for the collection of necessary information at the appropriate time in a patient encounter if such collection need can be properly defined in a supportive workflow. e.g., Requesting specific information for reporting of emergency services such as gun shot, suspected abuse, communicable diseases etc, or for the collection of additional research data for specific a specific diagnosis.	S.3.6.2 IN.4.3 IN.6	1. The system ~~SHOULD~~ SHALL provide the ability to export or retrieve data required to evaluate patient outcomes as required by organizational policy or jurisdictional law.	74	S.2.1.1	1	M
						2. The system ~~MAY~~ SHOULD provide data detailed by physician, facility, facility subsection, community or other selection criteria.	75	S.2.1.1	2	M
						3. The system SHOULD provide the ability to define outcome measures for specific patient diagnosis.	76	S.2.1.1	3	N/C
						4. The system SHOULD provide the ability to define outcome measures to meet various regional requirements.	77	S.2.1.1	4	N/C
						5. The system SHOULD provide for the acceptance and retrieval of unique outcome data defined to meet regional requirements.	78	S.2.1.1	5	N/C
						6. The system ~~MAY~~ SHOULD provide the ability to define report formats for the export of data. This formatted data could be viewed, transmitted electronically or printed.	79	S.2.1.1	6	M
						7. The system ~~MAY~~ SHOULD provide the ability to define prompts in the clinical care setting that would request information needed to comply with regional requirements when specific triggers are met (e.g., have user defined/customizable fields to collect required information).	80	S.2.1.1	7	M
						8. The system MAY export data or provide a limited query access to data through a secure data service.	81	S.2.1.1	8	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.1.2	F	EN	Performance and Accountability Measures	Statement: Support the capture and subsequent export or retrieval of data necessary to provide quality, performance, and accountability measurements which providers, facilities, delivery systems, and communities are held accountable. Description: Many regions require regular reporting on the health care provided to individuals and populations (quality measures, report cards, dashboards, etc.). These reports may include measures related to process, outcomes, costs of care, may be used in 'pay for performance' monitoring and adherence to best practice guidelines. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software.	DC.2.6.3 DC.2.6.2 S.3.6 IN.5.4	1. The system ~~SHOULD~~ SHALL provide the ability to export or retrieve data required to assess health care quality, performance and accountability.	82	S.2.1.2	1	M
						2. The system SHOULD provide the ability to define multiple data sets required for performance and accountability measures.	83	S.2.1.2	2	N/C
						3. The system ~~MAY~~ SHALL provide the data export in a report format that could be displayed, transmitted electronically or printed.	84	S.2.1.2	3	M
						4. The system MAY export data or provide a limited query access to data through a secure data service.	85	S.2.1.2	4	N/C
						5. The system SHOULD calculate and report quality calculations such as CMS Quality Indicators (QIs) from the MDS, or other required instruments, in accordance with the most recent jurisdictional specifications and export the information to administrative and financial systems.	86			A
						6. The system SHOULD calculate and report quality calculations such as CMS Quality Measures (QMs) from the MDS, or other required instruments, in accordance with the most recent jurisdictional specifications and export the information to administrative and financial systems.	87			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.2	H	EN	Report Generation	Statement: Support the export of data or access to data necessary for report generation and ad hoc analysis. Description: Providers and administrators need access to data in the EHR-S for the generation of both standard and ad hoc reports. These reports may be needed for clinical, administrative, and financial decision-making, as well as for patient use. Reports may be based on structured data and/or unstructured text from the patient's health record.	DC.2.6.3 S.1.5 S.3.6	1. The system SHALL conform to function IN.2.2 (Auditable Records) in accordance with scope of practice, organizational policy and jurisdictional law.	88	S.2.2	1	N/C
S.2.2	H	EN	Report Generation		DC.2.6.3 S.1.5 S.3.6	2. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction).	89	S.2.2	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.2.1	F	EN	Health Record Output	Statement: Support the definition of the formal health record, a partial record for referral purposes, or sets of records for other necessary disclosure purposes. Description: Provide hardcopy and electronic output that fully chronicles the health care process, supports selection of specific sections of the health record, and allows health care organizations to define the report and/or documents that will comprise the formal health record for disclosure purposes. A mechanism should be provided for both chronological and specified record element output. This may include defined reporting groups (i.e., print sets). For example: Print Set A = Patient Demographics, History & Physical, Consultation Reports, and Discharge Summaries. Print Set B = all information created by one caregiver. Print Set C = all information from a specified encounter. An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review. The system has the capability of providing a report or accounting of disclosures by patient ~~that meets~~ in accordance with scope of practice, organizational policy and jurisdictional law.	DC.1.1.4 DC.1.4 IN.1.2 IN.2.5.1 IN.2.5.2 IN.4.1 IN.4.3 IN.5.1 IN.5.4 IN.6	1. The system SHALL provide the ability to generate reports consisting of all and part of an individual patient’s record.	90	S.2.2.1	1	N/C
						2. The system ~~SHOULD~~ SHALL provide the ability to define the records or reports that are considered the formal health record for disclosure purposes.	91	S.2.2.1	2	M
						3. The system SHOULD provide the ability to generate reports in both chronological and specified record elements order.	92	S.2.2.1	3	N/C
						4. The system SHOULD provide the ability to create hardcopy and electronic report summary information (procedures, medications, labs, immunizations, allergies, vital signs).	93	S.2.2.1	4	N/C
						5. The system MAY provide the ability to specify or define reporting groups (i.e., print sets) for specific types of disclosure or information sharing.	94	S.2.2.1	5	N/C
						6. The system ~~SHOULD~~ SHALL provide the ability to include patient identifying information on each page of reports generated.	95	S.2.2.1	6	M
						7. The system ~~SHOULD~~ SHALL provide the ability to customize reports to match mandated formats as required by jurisdictional law and/or regulations.	96	S.2.2.1	7	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.2.2	F	EN	Standard Report Generation	Statement: Provide report generation features using tools internal or external to the system, for the generation of standard reports. Description: Providers and administrators need access to data in the EHR-S for clinical, administrative, financial decision-making, audit trail and metadata reporting, as well as to create reports for patients. Many systems may use internal or external reporting tools to accomplish this (such as Crystal Report). Reports may be based on structured data and/or unstructured text from the patient's health record. Users need to be able to sort and/or filter reports. For example, the user may wish to view only the diabetic patients on a report listing patients and diagnoses.	IN.1.9 IN.2.5.1 IN.2.5.2 IN.4.1 IN.4.3	1. The system ~~SHOULD~~ SHALL provide the ability to generate reports of structured clinical and administrative data using either internal or external reporting tools.	97	S.2.2.2	1	M
						2. The system ~~MAY~~ SHOULD provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools.	98	S.2.2.2	2	M
						3. The system SHOULD provide the ability to export reports generated.	99	S.2.2.2	3	N/C
						4. The system ~~SHOULD~~ SHALL provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.	100	S.2.2.2	4	M
						5. The system (or an external application, using data from the system) MAY provide the ability to save report parameters for generating subsequent reports.	101	S.2.2.2	5	N/C
						6. The system (or an external application, using data from the system) MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification.	102	S.2.2.2	6	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.2.2.3	F	EN	Ad Hoc Query and Report Generation	Statement: Provide support for ad hoc query and report generation using tools internal or external to the system. Description : Providers and administrators need to respond quickly to new requirements for data measurement and analysis. This may be as a result of new regulatory requirements or internal requirements. This requires that users be able to define their own query parameters and retain them. The data may be found in both structured and unstructured data. Providers and administrators also need to query for the absence of specific clinical or administrative data. For example, ~~the Quality Control department~~ a quality assurance study may be reviewing whether or not the protocol for management of Diabetes Mellitus is being followed. If the protocol calls for fasting blood sugars every 3 months at minimum, the investigator might need to run an across-patient query locating patients with diabetes who do not show an FBS result within the last 3 months.	IN.2.5.1 IN.2.5.2	1. The system ~~SHOULD~~ SHALL provide the ability to generate ad hoc query and reports of structured clinical and administrative data through either internal or external reporting tools.	103	S.2.2.3	1	M
						2. The system ~~MAY~~ SHOULD provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools.	104	S.2.2.3	2	M
						3. The system SHOULD provide the ability to export reports generated.	105	S.2.2.3	3	N/C
						4. The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.	106	S.2.2.3	4	N/C
						5. The system MAY provide the ability to save report parameters for generating subsequent reports.	107	S.2.2.3	5	N/C
						6. The system MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification.	108	S.2.2.3	6	N/C
						7. The system MAY provide the ability to produce reports, using internal or external reporting tools, based on the absence of a clinical data element (e.g., a lab test has not been performed in the last year).	109	S.2.2.3	7	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3	H	EN	Administrative and Financial		IN.1.9 IN.2.4	1. The system SHALL conform to function IN.1.1 (Entity Authentication).	110	S.3	1	N/C
						2. The system SHALL conform to function IN.1.2 (Entity Authorization).	111	S.3	2	N/C
						3. The system SHALL conform to function IN.1.3 (Entity Access Control).	112	S.3	3	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.1	H	EN	Encounter/Episode of Care Management	Statement: Support the definition of Manage and document the health care needed and delivered during an encounter/episode of care. Description: Using data standards and technologies that support interoperability, encounter management promotes patient-centered/oriented care and enables real time, immediate point of service, point of care by facilitating efficient work flow and operations performance to ensure the integrity of: (1) the health record, (2) public health, financial and administrative reporting, and (3) the health care delivery process. This support is necessary for direct care functionality that relies on providing user interaction and workflows, which are configured according to clinical protocols and business rules based on encounter specific values such as care setting, encounter type (inpatient, outpatient, home health, etc.), provider type, patient's EHR, health status, demographics, and the initial purpose of the encounter.			113	S.3.1		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.1.1	F	EN	Specialized Views	Statement: Present specialized views based on the encounter-specific values, clinical protocols and business rules. Description: The system user is presented with a presentation view and system interaction appropriate to the context with capture of encounter-specific values, clinical protocols and business rules. This "user view" may be configurable by the user or system technicians. As an example, a mobile home health care worker using wireless laptop at the patient's home would be presented with a home health care specific workflow synchronized to the current patient's care plan and tailored to support the interventions appropriate for this patient, including chronic disease management protocols Examples include: An attending physician is presented with a view that provides the primary functions used by the physician (physician order entry, physician progress notes, referrals, care plan, etc.). A speech pathologist performing a bedside treatment session, and using a wireless laptop, would be presented with rehabilitation specific workflow synchronized to the patient's current care plan and tailored to support interventions appropriate to this patient, including age and condition-specific guidelines.	DC.2.2.1.2 S.1.3.7	1. The system SHOULD provide the ability to define presentation filters that are specific to the types of encounter, clinical protocols and business rules. These specifics may include care provider specialty, location of encounter, date of encounter, associated diagnosis.	114	S.3.1.1	1	M
						1a. The system SHALL conform to function IN.6 (Business Rules Management).	115			A
						2. The system MAY provide the ability to define presentation filters that are specific to the patent demographics.	116	S.3.1.1	2	N/C
						3. The system SHOULD provide the ability to tailor a "user view".	117	S.3.1.1	3	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.1.2	F	EN	Encounter Specific Functionality	Statement: Provide assistance in assembling appropriate data, supporting data collection and processing output from a specific encounter. Description: Workflows, based on the encounter management settings, will assist (with triggers, alerts and other means) in determining and supporting the appropriate data collection, import, export, extraction, linkages and transformation. As an example, ~~a pediatrician is presented with~~ neonatal diagnostic and procedure codes ~~specific to pediatrics~~ may be filtered out when presenting codes to facility clinicians. Business rules enable automatic collection of necessary data from the patient's health record and patient registry. As the provider enters data, workflow processes are triggered to populate appropriate transactions and documents. For example, data entry might populate an eligibility verification transaction or query the immunization registry.	DC.3.1.1 IN.4.2 IN.4.3 IN.7	1. The system SHALL provide workflow support for data collection appropriate for care setting.	118	S.3.1.2	1	N/C
						2. The system SHOULD provide the ability to create and modify data entry workflows.	119	S.3.1.2	2	N/C
						3. The system SHOULD provide the ability to extract appropriate information from the patient record as necessary to document the patient encounter.	120	S.3.1.2	3	N/C
						4. The system SHOULD provide a reduced set of diagnostic and procedure codes appropriate for the care setting.	121	S.3.1.2	4	N/C
						5. The system MAY initiate secondary reporting workflows as a result of information entered into the encounter.	122	S.3.1.2	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.1.3	F	EN	Automatic Generation of Administrative and Financial Data from Clinical Record	Statement: Provide patients clinical data to support administrative and financial reporting. Description: A user can generate a bill based on health record data. Maximizing the extent to which administrative and financial data can be derived or developed from clinical data will lessen provider reporting burdens and the time it takes to complete administrative and financial processes such as claim reimbursement. This may be implemented by mapping of clinical terminologies in use to administrative and financial terminologies.	S.3.2.2 IN.4.1 IN.4.2 IN.4.3	1. The system SHOULD provide the ability to define the data required for each external administrative and financial system.	123	S.3.1.3	1	N/C
						2. The system ~~SHOULD~~ SHALL export appropriate data to administrative and financial systems.	124	S.3.1.3	2	M
						3. The system SHOULD calculate and report the appropriate Medicare and/or Medicaid payment calculation score from the MDS in accordance with the most recent jurisdictional specifications and export the calculated scores to administrative and financial systems.	125			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.1.4	F	O	Support Remote Healthcare Services	Statement: Support remote health care services such as tele-health and remote device monitoring by integrating records and data collected by these means into the patient's record for care management, billing and public health reporting purposes. Description: Enables remote treatment of patients using monitoring devices, and two way communications between provider and patient or provider and provider. Promotes patient empowerment, self-determination and ability to maintain health status in the community. Promotes personal health, wellness and preventive care. For example, a diabetic ~~pregnant Mom~~ patient can self-monitor her condition from ~~her~~ home and use web TV to report to ~~her provider~~ the facility’s community outreach service. The same TV-internet connectivity allows her to get dietary and other health promoting information to assist ~~her~~ with managing her ~~high-risk pregnancy~~ diabetes and related risk factors.	DC.1.1 DC.1.3.3 DC.1.7.2.1 DC.1.7.2.2 DC.1.7.3 DC.3.2.1 DC.3.2.3 DC.3.2.5 IN.1.4 IN.1.6 IN.1.7 IN.2.2 IN.2.3 IN.2.5.1 IN.2.5.2	1. The system ~~SHOULD~~ SHALL provide the ability to capture patient data from remote devices and integrate that data into the patient's record.	126	S.3.1.4	1	M
S.3.1.4	F	O	Support Remote Healthcare Services			2. The system ~~SHOULD~~ SHALL provide authorized users two-way communication between local practitioner and remote patient, or local practitioner to remote practitioner.	127	S.3.1.4	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.1.5	F	EN	Other Encounter and Episode of Care Support	Statement: Where not covered above, provide the means to manage and organize the documentation of the health care needed and delivered during an encounter/episode of care. Description: Using data standards and technologies that support interoperability, encounter management promotes patient- centered/oriented care and enables real time, immediate point of service, point of care by facilitating efficient work flow and operations performance to ensure the integrity of: (1) the health record, (2) public health, financial and administrative reporting, and (3) the health care delivery process. This support is necessary for direct care functionality that relies on providing user interaction and workflows, which are configured according to clinical protocols and business rules based on encounter specific values such as ~~care setting~~, encounter type (inpatient, outpatient, home health, etc.), provider type, patient's record, health status, demographics, and the initial purpose of the encounter.	DC.3.1 DC.3.2	1. The system SHALL provide the ability to organize patient data by encounter.	128	S.3.1.5	1	N/C
						2. The system SHOULD accept and append patient encounter data from external systems, such as diagnostic tests and reports.	129	S.3.1.5	2	N/C
						3. The system SHALL provide the ability to create encounter documentation by one or more of the following means: direct keyboard entry of text; structured data entry utilizing templates, forms, pick lists or macro substitution; dictation with subsequent transcription of voice to text, either manually or via voice recognition system.	130	S.3.1.5	3	N/C
						4. The system SHOULD provide the ability to define presentation filters that are specific to the types of encounter. These specifics may include care provider specialty, location of encounter, date of encounter, associated diagnosis.	131	S.3.1.5	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.2	H	EN	Information Access for Supplemental Use	Statement: Support extraction, transformation and linkage of information from structured data and unstructured text in the patient's health record for care management, financial, administrative, and public health purposes. Description: Using data standards and technologies that support interoperability, information access functionalities serve primary and secondary record use and reporting with continuous record availability and access that ensure the integrity of: (1) the health record, (2) public health, financial and administrative reporting, and (3) the healthcare delivery process.			132	S.3.2		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.2.1	F	EN	Rules-Driven Clinical Coding Assistance	Statement: Make available all pertinent patient information needed to support coding of diagnoses, procedures and outcomes. Description: The user is assisted in coding information for clinical reporting reasons. For example, a professional coder may have to code the principal diagnosis in the current, applicable ICD as a basis for ~~hospital funding~~ Medicare Part B reimbursement for therapy. All diagnoses and ~~procedures~~ services during the episode may be presented to the coder or clinician, as well as the applicable ICD or CPThierarchy containing these codes.	IN.4.1 IN.4.2 IN.4.3 IN.6 IN.7	1. The system SHALL provide the ability to access pertinent patient information needed to support coding of diagnoses, ~~procedures~~ services and outcomes.	133	S.3.2.1	1	M
S.3.2.1	F	EN	Rules-Driven Clinical Coding Assistance		IN.4.1 IN.4.2 IN.4.3 IN.6 IN.7	2. The system ~~MAY~~ SHOULD assist with the coding of diagnoses, procedures and outcomes based on provider specialty, care setting and other information that may be entered into the system during the encounter.	134	S.3.2.1	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.2.2	F	EN	Rules-Driven Financial and Administrative Coding Assistance	Statement: Provide financial and administrative coding assistance based on the structured data and unstructured text available in the encounter documentation. Description: The user is assisted in coding information for billing or administrative reasons. For example, in the US Domain, the HIPAA 837 Professional claim requires the date of the last menstrual cycle for claims involving pregnancy. To support the generation of this transaction, the provider would need to be prompted to enter this date when the patient is first determined to be pregnant, then making this information available for the billing process. Medicare Part A claims must include HIPPS codes that reflect the payment calculation category and assessment type for MDSs completed during the billing period. To support this transaction, the payment calculation classification and assessment type information would need to be captured for each MDS completed during a Part A stay and the information made available for the billing process.	S.3.1.3 IN.2.5.1 IN.2.5.2 IN.4.1 IN.4.3 IN.6 IN.7	1. The system SHALL maintain financial and administrative codes.	135	S.3.2.2	1	N/C
						2. The system SHOULD provide the ability to retrieve data from the electronic health record as required to simplify the coding of financial and administrative documentation.	136	S.3.2.2	2	N/C
						3. The system ~~MAY~~ SHOULD support rules driven prompts to facilitate the collection of data in the clinical workflow that is required for administrative and financial coding.	137	S.3.2.2	3	M
						4. The system ~~MAY~~ SHOULD assist with the coding of required administrative and financial documents based on provider specialty, care setting and other information that may be entered into the system during the encounter.	138	S.3.2.2	4	M
						5. The system ~~MAY~~ SHOULD internally generate administrative and financial coding such as place of service, type of facility, tax rates, etc.	139	S.3.2.2	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.2.3	F	O	Integrate Cost/Financial Information	Statement: Support interactions with other systems, applications, and modules to enable the use of cost management information required to guide users and workflows. Description: The provider is alerted or presented with the most cost-effective services, referrals, devices and etc., to recommend to the patient. This may be tailored to the patient's health insurance/plan coverage rules. Medications may be presented in order of cost, or the cost of specific interventions may be presented at the time of ordering.	DC.1.7.1 DC.1.7.2.4 IN.4.3 IN.6	1. The system MAY provide the ability to retrieve formularies, preferred providers, and other information, from internal or external sources, that are associated with a patient’s health care plan and coverage so that the provider can offer cost effective alternatives to patients.	140	S.3.2.3	1	N/C
						2. The system MAY provide the ability to retrieve or request information about exemptions on coverage limitations and guidelines.	141	S.3.2.3	2	N/C
						3. The system MAY provide the ability to retrieve and provide expected patient out-of- pocket cost information for medications, diagnostic testing, and procedures, from internal or external sources, that are associated with a patients health care plan and coverage.	142	S.3.2.3	3	N/C
						4. The system ~~MAY~~ SHALL alert the provider of care where formularies, preferred provider and other information indicate the health plan requires an alternative.	143	S.3.2.3	4	M
						5. The system ~~SHOULD~~ SHALL conform to S.3.3.3 (Service Authorizations) to integrate support of prior authorization processes.	144	S.3.2.3	5	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3	H	EN	Administrative Transaction Processing	Statement: Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care. Description: Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care. The EHR system shall capture the patient health-related information needed for administrative and financial purposes including reimbursement. Captures the episode and encounter information to pass to administrative or financial processes (e.g., triggers transmissions of charge transactions as by-product of on-line interaction including order entry, order statusing, result entry, documentation entry, medication administration charting). Automatically retrieves information needed to verify coverage and medical necessity. As a byproduct of care delivery and documentation: captures and presents all patient information needed to support coding. Ideally performs coding based on documentation. Clinically automated revenue cycle -- examples of reduced denials and error rates in claims. Clinical information needed for billing is available on the date of service. Physicians and ~~clinical teams~~ clinicians do not perform additional data entry/tasks exclusively to support administrative or financial processes.			145			M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3.1	F	O	Enrollment of Patients	Statement: Support interactions with other systems, applications, and modules to facilitate enrollment of uninsured patients into subsidized and unsubsidized health plans, and enrollment of patients who are eligible on the basis of health and/or financial status in social service and other programs, including clinical trials. Description: Expedites determination of health insurance coverage~~, thereby increasing patient access to care~~. The provider may be alerted that uninsured patients may be eligible for subsidized health insurance or other health programs because they meet eligibility criteria based on demographics and/or health status. For example: ~~a provider is notified that the uninsured parents of a child enrolled in S-CHIP may now be eligible for a new subsidized health insurance program~~; ~~a provider of a pregnant patient who has recently immigrated~~ a provider is presented with information about eligibility for subsidy for a patient who has recently immigrated. Links may be provided to online enrollment forms. When enrollment is determined, the health coverage information needed for processing administrative and financial documentation, reports or transactions is captured.	DC.2.2.3 IN.1.6 IN.1.7	1. The system ~~SHOULD~~ SHALL provide the ability to retrieve subsidized and unsubsidized health plan options from internal or external sources to allow for presentation of alternatives for health care coverage to patients subject to jurisdictional law.	146	S.3.3.1	1	M
S.3.3.1	F	O	Enrollment of Patients		DC.2.2.3 IN.1.6 IN.1.7	2. The system MAY provide the ability to retrieve health plan enrollment criteria to match patients health and financial status.	147	S.3.3.1	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3.2	F	EN	Eligibility Verification and Determination of Coverage	Statement: Support interactions with other systems, applications, and modules to enable eligibility verification for health insurance and special programs, including verification of benefits and pre-determination of coverage. Description: Retrieves information needed to support verification of coverage at the appropriate juncture in the encounter workflow. Improves patient access to covered care and reduces claim denials. When eligibility is verified, the system would capture eligibility information needed for processing administrative and financial documentation, reports or transactions -- updating or flagging any inconsistent data. In addition to health insurance eligibility, this function would support verification of registration in programs and registries, such as chronic care case management and immunization registries. A system would likely verify health insurance eligibility prior to the encounter, but would verify registration in case management or immunization registries during the encounter. When consistency checks are conducted they may check for consistency between internal data entered by a user in multiple places, consistency between internal data and data received externally, or consistency between data elements received externally.	IN.2.3 IN.5.1 IN.5.3 IN.5.4	1. The system ~~SHOULD~~ SHALL provide the ability to input patient health plan eligibility information for date(s) of service.	148	S.3.3.2	1	M
						2. IF the system is unable to obtain health plan coverage dates through exchange with an external source as per S.3.3.2 (Eligibility Verification and Determination of Coverage), Conformance Criteria #5 (The system SHOULD provide the ability to exchange electronic eligibility information (e.g., health plan coverage dates) with internal and external systems), THEN the system ~~MAY~~ SHALL provide authorized users the ability to input and maintain patient health plan coverage dates.	149	S.3.3.2	2	M
						3. The system ~~MAY~~ SHOULD provide the ability to input general benefit coverage information for patients.	150	S.3.3.2	3	M
						4. The system SHOULD provide for the retention of eligibility date(s) of service, coverage dates, general benefits and other benefit coverage documentation for service rendered.	151	S.3.3.2	4	N/C
						5. The system ~~MAY~~ SHOULD provide the ability to ~~transfer~~ exchange electronic eligibility information ~~from~~ (e.g., health plan coverage dates) with internal and external systems.	152	S.3.3.2	5	M
						6. The system MAY provide the ability to access information received through electronic prescription eligibility checking.	153	S.3.3.2	6	N/C
						7. The system MAY provide authorized users the ability to collect and retain patient registration in special programs such as but not limited to: registries and case management.	154	S.3.3.2	7	N/C
						8. The system ~~MAY~~ ~~provide the ability to check for inconsistencies in the information recorded~~ SHOULD alert the user to inconsistencies present in eligibility and coverage information (e.g., coverage dates, patient identity data, coverage status).	155	S.3.3.2	8	M
						9. IF the system provides the ability to exchange eligibility information with external systems, THEN the system SHALL conduct the information exchange in accordance with ASC X12N 270/271 (Healthcare Eligibility Benefits Inquiry and Response) version 004010X092A1 or higher.	156			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3.3	F	EN	Service Authorizations	Statement: Support interactions with other systems, applications, and modules to enable the creation of requests, responses and appeals related to service authorization, including prior authorizations, referrals, and pre-certification. Description: Retrieves information needed to support verification of medical necessity and prior authorization of services at the appropriate juncture in the encounter workflow. Improves timeliness of patient care and reduces claim denials.	DC.1.1.3.1 IN.5.4	1. IF the system is unable to obtain service authorization data through exchange with an external source per S.3.3.3 (Service Authorizations), Conformance Criteria #3 (The system MAY provide the ability to exchange electronic, computer readable data on service authorization information, including specific data if mandated by local authority), THEN the system ~~SHOULD~~ SHALL provide the ability to input service authorizations relevant to the service provided including the source, dates, and service(s) authorized.	157	S.3.3.3	1	M
						2. IF the system is unable to obtain referral data through exchange with an external source per S.3.3.3 (Service Authorizations), Conformance Criteria #4 (The system MAY provide the ability to exchange electronic, computer readable data on service referral information, including specific data if mandated by local authority), THEN the system ~~SHOULD~~ SHALL provide the ability to input referrals relevant to the service provided including the source, date and service(s) referred.	158	S.3.3.3	2	M
						3. The system MAY provide the ability to ~~transfer and/or collect~~ exchange electronic, computer readable data on service authorization information, including specific data if mandated by local authority.	159	S.3.3.3	3	M
						4. The system MAY provide the ability to ~~transfer and/or collect~~ exchange electronic, computer readable data on service referral information, including specific data if mandated by local authority.	160	S.3.3.3	4	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3.4	F	EN	Support of Service Requests and Claims	Statement: Support interactions with other systems, applications, and modules to support the creation of health care attachments for submitting additional clinical information in support of service requests and claims. Description: Retrieves structured and unstructured data, including but not limited to lab data, imaging data, device monitoring data, and text based data, based on rules or requests for additional clinical information, in support of service requests or claims, at the appropriate juncture in the encounter workflow.	IN.2.5.1 IN.2.5.2	1. The system SHALL provide the ability to view available, applicable clinical information to support service requests.	161	S.3.3.4	1	N/C
						2. The system SHALL provide the ability to view available, applicable clinical information to support claims.	162	S.3.3.4	2	N/C
						3. The system ~~MAY~~ SHOULD provide available, applicable clinical information to support service requests in computer readable formats.	163	S.3.3.4	3	M
						4. The system ~~MAY~~ SHOULD provide available, applicable clinical information to support claims in computer readable formats.	164	S.3.3.4	4	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3.5	F	EN	Claims and Encounter Reports for Reimbursement	Statement: Support interactions with other systems, applications, and modules to enable the creation of claims and encounter reports for reimbursement. Description: Retrieves information needed to support claims and encounter reporting. This reporting occurs at the appropriate juncture in the encounter workflow in a manual or automated fashion. For example this could occur at an initial, interim or final billing. The system may also present the information that is provided for audit and review by local authorities.	IN.2.5.1 IN.2.5.2	1. The system SHALL provide the ability to view available, applicable information needed to enable the creation of claims and encounter reports for reimbursement.	165	S.3.3.5	1	N/C
						2. The system SHALL provide the ability to capture and present available, applicable data as required by local authority for audit and review.	166	S.3.3.5	2	N/C
						3. The system ~~MAY~~ SHOULD provide available, applicable data in a computer readable form when needed to enable the creation of claims and encounter reports for reimbursement.	167	S.3.3.5	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.3.6	F	EN	Health Service Reports at the Conclusion of an Episode of Care	Statement: Support the creation of health service reports at the conclusion of an episode of care. Support the creation of health service reports to authorized health entities, for example public health, such as notifiable condition reports, immunization, cancer registry and discharge data that a provider may be required to generate at the conclusion of an episode of care. Description: Effective use of this function means that providers do not perform additional data entry to support health management programs and reporting. Nursing Homes are required by federal regulations to complete a discharge summary. The proposed CARE Instrument developed by CMS is an example of an end of episode report. State regulations may also include discharge summary requirements.	S.2.2 IN.7	1. The system ~~MAY~~ SHOULD prompt providers for data needed for end of care reporting during the continuum of care to reduce the need for end of care data collection.	168	S.3.3.6	1	M
						1a. The system SHALL conform to function DC.1.1.4 (Produce a Summary Record of Care)	169			A
						2. The system SHOULD create service reports at the completion of an episode of care such as but not limited to; ~~discharge summaries~~, public health reports, etc. using data collected during the encounter as required by scope of practice, organizational policy, or jurisdictional law.	170	S.3.3.6	2	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.4	F	EN	Manage Practitioner/Patient Relationships	Statement: Identify relationships among providers treating a single patient, and provide the ability to manage patient lists assigned to a particular provider. Description: This function addresses the ability to access and update current information about the relationships between caregivers and the patients. This information should be able to flow seamlessly between the different components of the system, and between the EHR system and other systems. Business rules may be reflected in the presentation of, and the access to this information. The relationship among providers treating a single patient will include any necessary chain of authority/responsibility. Example: In a care setting with multiple providers, where the patient can only see certain kinds of providers (or an individual provider); allow the selection of only the appropriate providers. Example: ~~The user is presented with a list of people assigned to a given practitioner and may alter the assignment as required - to a group, to another individual or by sharing the assignment.~~ Designating relationships such as attending physician, dentist, podiatrist, ophthalmologist, etc.	DC.2.6.3 S.1.3.4 S.2.2 IN.2.4	1. The system SHALL provide the ability to identify all providers by name associated with a specific patient encounter.	171	S.3.4	1	N/C
						2. The system SHALL provide the ability to specify the role of each provider associated with a patient such as ~~encounter provider, primary care provider,~~ attending physician, ophthalmologist, psychologist, dentist, podiatrist, geriatric nurse practitioner, physician assistant, ~~resident~~, or consultant.	172	S.3.4	2	M
						3. The system SHALL provide the ability to identify all providers who have been associated with any encounter for a specific patient.	173	S.3.4	3	N/C
						4. The system ~~SHOULD~~ SHALL provide authorized users the ability to add and update information on the relationship of provider to patient.	174	S.3.4	4	M
						5. The system ~~MAY~~ SHOULD provide the ability to view patient lists by provider.	175	S.3.4	5	M
						6. The system SHALL provide the ability to specify primary or principal provider(s) responsible for the care of a patient within a care setting.	176	S.3.4	6	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.5	H	EN	Subject to Subject Relationship	Statement: Document relationships between patients and others to facilitate appropriate access to their health record on this basis if appropriate. Description: A user may assign the relationships between patients and others to facilitate access to their health record. Some examples may include parent, relatives, a legal guardian, health care surrogate or payer.	S.1.4.1 IN.1.3 IN.1.5 IN.2.2		177	S.3.5		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.5.1	F	EN	Related by Genealogy	Statement: Provide information on relationships by genealogy. Description: Relationships by genealogy may include ~~genetic mother~~, next of kin, and/or family members. Appropriate consents must be acquired prior to the collection of or use of this information.	DC.1.1.3.1 DC.1.3.3	1. The system SHALL provide the ability to collect and maintain genealogical relationships.	178	S.3.5.1	1	N/C
						2. The system SHALL provide the ability to identify persons related by genealogy.	179	S.3.5.1	2	N/C
						3. The system ~~SHOULD~~ MAY provide the ability to collect and maintain patient consents required to allow patient records to be ~~viewed for the purposes of a genealogical family member’s family medical history~~ accessed.	180	S.3.5.1	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.5.2	F	EN	Related by Insurance	Statement: Support interactions with other systems, applications, and modules to provide information on relationships by insurance (domestic partner, spouse, and guarantor). Description:		1. The system ~~MAY~~ SHALL provide the ability to identify persons related by insurance plan.	181	S.3.5.2	1	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.5.3	F	EN	Related by Living Situation	Statement: Provide information on relationships by living situation (in same household). Description:		1. The system ~~MAY~~ SHALL provide the ability to identify patients related by living situation.	182	S.3.5.3	1	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.5.4	F	EN	Related by Other Means	Statement: Provide information on relationships by other means. Description: Other relationships that may need to be recorded would include but not be limited to ~~surrogate mother~~, power of attorney/conservator/guardian, a person authorized to see health records, health care surrogate, ~~and~~ persons who may be related by epidemiologic exposure, etc.		1. The system MAY provide the ability to identify patients related by employer and work location for purposes of epidemiological exposure and public health analysis and reporting.	183	S.3.5.4	1	N/C
						2. The system ~~SHOULD~~ SHALL provide the ability to identify persons with Power of Attorney for Health Care or other persons with the authority to make medical decisions on behalf of the patient.	184	S.3.5.4	2	M
						3. The system MAY provide the ability to identify persons related to the patient by other means.	185			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.6	F	EN	Acuity and Severity	Statement: Provide the data necessary to support and manage patient acuity/severity for illness/risk-based adjustment of resource. Description: Research has been done on nurse staffing and patient outcomes; the impact of organizational characteristics on nurse staffing patterns, patient outcomes, and costs; and the impact of nurses’ experience on patient outcomes. The research indicates that nurse staffing has a definite and measurable impact on patient outcomes, medical errors, length of stay, nurse turnover, and patient mortality. Case mix/acuity data helps determine what is, indeed, appropriate staffing -- as modified by the nurses’ level of experience, the organization’s characteristics, and the quality of clinical interaction between and among physicians, nurses, and administrators. Also, case mix, acuity and severity data is routinely the evidential basis most frequently cited by staff when recommending clinical staffing changes.	S.2.1.2	1. The system ~~SHOULD~~ SHALL provide the ability to collect appropriate existing data to support the patient case mix/acuity/severity processes for illness/risk-based adjustment of resources.	186	S.3.6	1	M
						2. The system MAY provide the ability to export appropriate data to support the patient acuity/severity processes for illness/risk-based adjustment of resources.	187	S.3.6	2	N/C
						3. The system MAY prompt the user to provide key data needed to support acuity/severity processes.	188	S.3.6	3	N/C
						4. The system MAY provide the ability to calculate patient acuity and/or severity levels.	189			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.7	H	EN	Supportive Function Maintenance	Statement: Update EHR supportive content using a manual or automated process. Description:			190	S.3.7		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.7.1	F	EN	Clinical Decision Support System Guidelines Updates	Statement: Facilitate and/or perform updates of clinical decision support system guidelines and associated reference material. Description: Clinical decision support rules may be applied to the system using a manual process. As standards are developed to represent these rules, an automated update will be recommended. Any process to update decision support rules should include the verification of the appropriateness of the rules to the system. This may include but not be limited to authenticity of the source, the currency of the version, and any necessary approvals before updates can take place.	DC.2.6.3 DC.2.7.1 IN.2.2 IN.4.1 IN.4.3 IN.5.1 IN.5.3 IN.5.4 IN.6	1. IF providing decision support, THEN the system SHALL provide the ability to update the clinical content or rules utilized to generate clinical decision support reminders and alerts.	191	S.3.7.1	1	M
						2. IF providing decision support, THEN the system SHOULD validate that the most applicable version is utilized for the update, and capture the date of update.	192	S.3.7.1	2	M
						3. IF multiple versions exist, THEN the system ~~MAY~~ SHALL track and retain the version used when guidelines are provided in a ~~patient~~ stay/encounter.	193	S.3.7.1	3	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.7.2	F	O	Patient Education Material Updates	Statement: Receive and validate formatted inbound communications to facilitate and/or perform updating of patient education material. Description: Materials may include information about a diagnosis, recommended diets, associated patient health organizations, or web links to similar educational information. These materials may be provided electronically and may require validation prior to inclusion in the system. For example, First Databank for drug information.	DC.3.2.4	1. The system ~~MAY~~ SHALL provide the ability to capture and update patient education material. ~~that may be printed and provided to the patient at the point of care~~.	194	S.3.7.2	1	M
						1a. The system MAY provide the ability to print the patient education material for provision to the patient at the point of care.	195			A
						2. The system MAY provide the ability to validate the material prior to update.	196	S.3.7.2	2	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.7.3	F	O	Patient Reminder Information Updates	Statement: Receive and validate formatted inbound communications to facilitate updating of patient reminder information from external sources such as Cancer or Immunization Registries. Description: Information from outside groups, such as immunization groups, public health organizations, etc. may periodically send updates to patient care providers. The system should be capable of generating patient reminders based on the recommendations of these organizations. Patient reminders could be provided to patients by a number of means including phone calls, or mail. A record of such reminders may become part of a patient’s record. Examples of reminders could include a recommended immunization, prophylactic guidelines for MVP, patient self-testing for disease, etc.	DC.2.2.4 DC.2.3.2 DC.2.5.1 DC.2.5.2 DC.3.2.3 S.1.4.1 IN.2.2 IN.5.2 IN.6	1. The system MAY provide the ability to add patient reminders for patients based on the recommendations of public health authorities or disease specific associations.	197	S.3.7.3	1	N/C
						2. The system MAY provide the ability to automatically associate patient reminders with patients meeting specific phenotypic criteria such as age, gender, diagnosis, etc.	198	S.3.7.3	2	N/C
						3. The system ~~MAY~~ SHALL provide the ability to display patient reminders, manually process, and record associated ~~telephone~~ contacts.	199	S.3.7.3	3	M
						4. The system MAY provide the ability to automatically generate patient reminders for ~~mailing~~ delivery to patients.	200	S.3.7.3	4	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
S.3.7.4	F	EF 2013	Public Health Related Updates	Statement: Receive and validate formatted inbound communications to facilitate updating of public health reporting guidelines. Description: As standards become available, information and reporting requirements from outside groups, such as public health organizations, may be made available to patient care providers. Examples may include requirements to report on new disease types, or changes to reporting guidelines. The information in these public health updates may be applied to the system so that appropriate data can be collected and reported to comply with requirements.	IN.4.3 IN.5.2	1. The system ~~MAY~~ SHALL provide the ability to capture and update public health reporting guidelines.	201	S.3.7.4	1	M
S.3.7.4	F	EF 2013	Public Health Related Updates		IN.4.3 IN.5.2	2. The system MAY provide the ability to validate the material prior to update.	202	S.3.7.4	2	N/C

Information Infrastructure Functions

HL7 LTC-Nursing Home EHR-S Functional Profile (based on the HL7 EHR-S Functional Model, February 2007) -- Information Infrastructure 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#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1	H	EN	Security	Statement: Secure the access to an EHR-S and EHR information. Manage the sets of access control permissions granted within an EHR-S. Prevent unauthorized use of data, data loss, tampering and destruction. Description: To enforce security, all EHR-S applications must adhere to the rules established to control access and protect the privacy of EHR information. Security measures assist in preventing unauthorized use of data and protect against loss, tampering and destruction. An EHR-S must be capable of including or interfacing with standards-conformant security services to ensure that any Principal (user, organization, device, application, component, or object) accessing the system or its data is appropriately authenticated, authorized and audited in conformance with local and/or jurisdictional policies. An EHR-S should support Chains of Trust in respect of authentication, authorization, and privilege management, either intrinsically or by interfacing with relevant external services.			1	IN.1		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.1	F	EN	Entity Authentication	Statement: Authenticate EHR-S users and/or entities before allowing access to an EHR-S. Description: Both users and applications are subject to authentication. The EHR-S must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include: username/password; digital certificate; secure token biometrics.		1. The system SHALL authenticate principals prior to accessing an EHR-S application or EHR-S data.	2	IN.1.1	1	N/C
						2. The system SHALL prevent access to EHR-S applications or EHR-S data to by all non-authenticated principals.	3	IN.1.1	2	M
						3. The system SHOULD provide the ability to implement a Chain of Trust agreement.	4	IN.1.1	3	N/C
						4. IF other appropriate authentication mechanisms are absent, THEN the system SHALL authenticate principals using at least one of the following authentication mechanisms: username/password, digital certificate, secure token or biometrics.	5	IN.1.1	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.2	F	EN	Entity Authorization	Statement: Manage the sets of access-control permissions granted to entities that use an EHR-S (EHR-S Users). Enable EHR-S security administrators to grant authorizations to users, for roles, and within contexts. A combination of these authorization categories may be applied to control access to EHR-S functions or data within an EHR-S, including at the application or the operating system level. Description: EHR-S Users are authorized to use the components of an EHR-S according to their identity, role, work-assignment, location and/or the patient’s present condition and the EHR-S User’s scope of practice within a legal jurisdiction. User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is a patient defined denial of access to all or part of a record to a particular party for privacy related reasons. Another user based authorization is for a tele-monitor device or robotic access to an EHR-S for prescribed directions and other input. Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device (tele-monitor or robotic); or a nurse, dietician, administrator, legal guardian, and auditor. Context-based Authorization is defined by ISO 10181-3 Technical Framework for Access Control Standard as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For example, an EHR-S might only allow supervising providers’ context authorization to attest to entries proposed by residents under their supervision. In addition to the ISO standard, context authorization for an EHR-S is extended to satisfy special circumstances such as, work assignment, patient consents and authorizations, or other health care-related factors. A context-based example is a patient-granted authorization to a specific third party for a limited period to view specific EHR records. Another example is a right granted for a limited period to view those, and only those, EHR records connected to a specific topic of investigation.	IN.1.3 S.1.3.1	1. The system SHALL provide the ability to create and update sets of access-control permissions granted to principals.	6	IN.1.2	1	N/C
						2. The system SHALL conform to function IN.2.2 (Auditable Records) for the purpose of recording all authorization actions.	7	IN.1.2	2	N/C
						3. The system SHALL provide EHR-S security administrators with the ability to grant authorizations to principals according to scope of practice, organizational policy, or jurisdictional law.	8	IN.1.2	3	N/C
						4. The system SHALL provide EHR-S security administrators with the ability to grant authorizations for roles according to scope of practice, organizational policy, or jurisdictional law.	9	IN.1.2	4	N/C
						5. The system SHALL provide EHR-S security administrators with the ability to grant authorizations within contexts according to scope of practice, organizational policy, or jurisdictional law.	10	IN.1.2	5	N/C
						6. The system ~~MAY~~ SHALL provide the ability to define context for the purpose of principal authorization based on identity, credential, role, work assignment, ~~present condition~~, and location, ~~patient consent, or patient’s present condition~~ in accordance with scope of practice, organizational policy or jurisdictional law.	11	IN.1.2	6	M
						6a. The system SHOULD provide the ability to define context for the purpose of principal authorization based on present situation, patient consent, or patient’s present condition in accordance with organizational policy or jurisdictional law.	12			A
						7. The system MAY provide the ability to define context based on legal requirements or disaster conditions.	13	IN.1.2	7	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.3	F	EN	Entity Access Control	Statement: Verify and enforce access control to all EHR-S components, EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource. Description: Entity Access Control is a fundamental function of an EHR-S. To ensure that access is controlled, an EHR-S must perform authentication and authorization of users or applications for any operation that requires it and enforce the system and information access rules that have been defined.		1. The system SHALL conform to function IN.1.1 (Entity Authentication).	14	IN.1.3	1	N/C
						2. The system SHALL conform to function IN.1.2 (Entity Authorization).	15	IN.1.3	2	N/C
						3. The system SHALL provide the ability to define system and data access rules.	16	IN.1.3	3	N/C
						4. The system SHALL enforce system and data access rules for all EHR-S resources (at component, application, or user level, either local or remote).	17	IN.1.3	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.4	F	EF 2010	Patient Access Management	Statement: Enable a health care delivery organization to allow and manage a patient’s access to the patient’s personal health information. Description: A health care delivery organization will be able to manage a patient’s ability to view his or her EHR based on scope of practice, organization policy or jurisdictional law. Typically, a patient has the right to view his or her EHR and the right to place restrictions on who can view parts or the whole of that EHR. For example, in some jurisdictions, minors have the right to restrict access to their data by parents/guardians. One example of managing a patient’s access to his or her data is by extending user access controls to patients.		1. The system SHALL conform to function IN.1.3 (Entity Access Control) in order for a healthcare delivery organization to manage a patient’s access to his or her healthcare information.	18	IN.1.4	1	N/C
IN.1.4	F	EF 2010	Patient Access Management			2. The system SHALL conform to the HITSP Consumer Empowerment Interoperability Specification (version 2 or later), as it applies to patient access management.	19			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.5	F	EN	Non-Repudiation	Statement: Limit an EHR-S user’s ability to deny (repudiate) the origination, receipt, or authorization of a data exchange by that user. Description: An EHR-S allows data entry and data access to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation guarantees that the source of the data record can not later deny that it is the source; that the sender or receiver of a message cannot later deny having sent or received the message. For example, non-repudiation may be achieved through the use of a: Digital signature, which serves as a unique identifier for an individual (much like a written signature on a paper document). Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent and/or received) and Timestamp, which proves that a document existed at a certain date and time. Date and Time stamping implies the ability to indicate the time zone where it was recorded (time zones are described in ISO 8601 Standard Time Reference).		1. The system SHALL time stamp initial entry, modification, or exchange of data, and identify the actor/principal taking the action as required by users' scope of practice, organizational policy, or jurisdictional law.	20	IN.1.5	1	N/C
						2. The system SHALL provide additional non-repudiation functionality where required by users' scope of practice, organizational policy, or jurisdictional law.	21	IN.1.5	2	N/C
						3. The system ~~MAY~~ SHALL conform to function IN.2.2 (Auditable Records) to prevent repudiation of data origination, receipt, or access.	22	IN.1.5	3	M
						4. The system ~~MAY~~ SHOULD conform to function IN.1.8 (Information Attestation) to ensure the integrity of data exchange and thus prevent repudiation of data origination or receipt.	23	IN.1.5	4	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.6	F	EN	Secure Data Exchange	Statement: Secure all modes of EHR data exchange. Description: Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation as well as both destination and source authentication when necessary. For example, it may be necessary to encrypt data sent to remote or external destinations. A secure data exchange requires that there is an overall coordination regarding the information that is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within an EHR-S or external to an EHR-S.	IN.1.1 IN.2.2	1. The system SHALL secure all modes of EHR data exchange.	24	IN.1.6	1	N/C
						2. The system ~~SHOULD~~ SHALL conform to function ~~IN.1.7 (Secure Data Routing)~~ IN.1.10 (Secure Data Routing -- LTC).	25	IN.1.6	2	M
						3. The system MAY provide the ability to obfuscate data.	26	IN.1.6	3	N/C
						4. The system SHALL encrypt and decrypt EHR data that is exchanged over a non-secure link.	27	IN.1.6	4	N/C
						5. The system SHALL support standards-based encryption mechanisms when encryption is used for secure data exchange.	28	IN.1.6	5	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.7	F	N/A	~~Secure Data Routing~~	Statement: Route electronically exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards). Description: An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP addresses or recordings of DNS names. For dynamic determination of known sources and destinations systems can use authentication mechanisms as described in IN.1.1. For example, the sending of a lab order from the EHRS to a lab system within the same organization usually uses a simple static setup for routing. In contrast sending a lab order to a reference lab outside of the organization will involve some kind of authentication process. ~~In general, when the underlying network infrastructure is secure (e.g., secure LAN or VPN) the simple static setup is used.~~	IN.1.1 IN.1.2	~~1. The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations and only over secure networks.~~	29	IN.1.7	1	D
						~~2. The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to function IN.1.1 (Entity Authentication)).~~	30	IN.1.7	2	D
						~~3. The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to the status of destinations and sources.~~	31	IN.1.7	3	D

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.8	F	EN	Information Attestation	Statement: Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with incoming or outgoing information. Description: The purpose of attestation is to show authorship and assign responsibility for an act, event, condition, opinion, or diagnosis. Every entry in the health record must be identified with the author and should not be made or signed by someone other than the author. (Note: A transcriptionist may transcribe an author's notes and a senior clinician may attest to the accuracy of another's statement of events.) Attestation is required for (paper or electronic) entries such as narrative or progress notes, assessments, flow sheets, and orders. ~~Digital~~ Electronic signatures may be used to implement document attestation. For an incoming document, the record of attestation is retained if included. Attestation functionality must meet applicable legal, regulatory and other applicable standards or requirements. For the LTC profile IN1.8, the term "digital signature" is replaced with "electronic signature”. Electronic signature is defined as, "any representation of the signature in digital form including image of handwritten signature”. This term refers to the process of attestation and proof of identity at the time of data entry in the EHR.		1. The system SHALL conform to function IN.1.1 (Entity Authentication).	32	IN.1.8	1	N/C
						2. The system SHALL conform to function IN.1.2 (Entity Authorization).	33	IN.1.8	2	N/C
						3. The system SHALL provide the ability to associate any attestable content added or changed to an EHR with the content's author (for example by conforming to function IN.2.2 (Auditable Records).	34	IN.1.8	3	N/C
						4. The system SHALL provide the ability for attestation of ~~attestable~~ EHR content by the content's author.	35	IN.1.8	4	M
						5. The system SHALL indicate the status of attestable data which has not been attested.	36	IN.1.8	5	N/C
						6. The system ~~MAY~~ SHOULD provide the ability for attestation of EHR content by properly authenticated and authorized users different from the author as required by users’ scope of practice, organizational policy, or jurisdictional law.	37	IN.1.8	6	M
						7. The system ~~MAY~~ SHOULD provide the ability to use ~~digital~~ electronic signatures as the means for attestation.	38	IN.1.8	7	M

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.9	F	EN	Patient Privacy and Confidentiality	Statement: Enable the enforcement of the applicable jurisdictional and organizational patient privacy rules as they apply to various parts of an EHR-S through the implementation of security mechanisms. Description: Patients’ privacy and the confidentiality of EHRs are violated if access to EHRs occurs without authorization. Violations or potential violations can impose tangible economic or social losses on affected patients, as well as less tangible feelings of vulnerability and pain. Fear of potential violations discourages patients from revealing sensitive personal information that may be relevant to diagnostic and treatment services. Rules for the protection of privacy and confidentiality may vary depending upon the vulnerability of patients and the sensitivity of records. Strongest protections should apply to the records of minors and the records of patients with stigmatized conditions. Authorization to access the most sensitive parts of an EHR is most definitive if made by the explicit and specific consent of the patient. Please see the definition of masking in the glossary.	IN.6	1. The system SHALL provide the ability to fully comply with the requirements for patient privacy and confidentiality in accordance with a user's scope of practice, organizational policy, HIPAA Privacy Rules, Federal Conditions of Participation for Medicare/Medicaid Providers, or jurisdictional law.	39	IN.1.9	1	M
						2. The system SHALL conform to function IN.1.1 (Entity Authentication).	40	IN.1.9	2	N/C
						3. The system SHALL conform to function IN.1.2 (Entity Authorization).	41	IN.1.9	3	N/C
						4. The system SHALL conform to function IN.1.3 (Entity Access Control).	42	IN.1.9	4	N/C
						5. The system SHOULD conform to function IN.1.5 (Non-Repudiation).	43	IN.1.9	5	N/C
						6. The system ~~SHOULD~~ SHALL conform to function IN.1.6 (Secure Data Exchange).	44	IN.1.9	6	M
						7. The system ~~SHOULD~~ SHALL conform to function IN.2.2 (Auditable Records).	45	IN.1.9	7	M
						8. The system SHALL provide the ability to maintain varying levels of confidentiality in accordance with users' scope of practice, organizational policy, HIPAA Privacy Rules or jurisdictional law.	46	IN.1.9	8	M
						9. The system SHALL provide the ability to mask parts of the electronic health record (e.g., medications, conditions, sensitive documents) from disclosure according to scope of practice, organizational policy or jurisdictional law.	47	IN.1.9	9	N/C
						10. The system SHALL provide the ability to override a mask in emergency or other specific situations according to scope of practice, organizational policy or jurisdictional law.	48	IN.1.9	10	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.1.10	F	EN	Secure Data Routing (LTC)	Statement: Route electronically exchanged EHR data only to/from known, registered, and authenticated destinations/sources according to applicable health care-specific rules and relevant standards. Description: An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP addresses or recordings of DNS names. For dynamic determination of known sources and destinations systems can use authentication mechanisms as described in IN.1.1. For example, the sending of a lab order from the EHRS to a lab system within the same organization usually uses a simple static setup for routing. In contrast sending a lab order to a reference lab outside of the organization will involve some kind of authentication process. In general, when the underlying network infrastructure is secure (e.g., secure LAN or VPN) the simple static setup is used.		1. The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations using either secure networks or properly encrypted (in compliance with IN 1.6) if using non-secure networks.	49			A
						2. The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to function IN.1.1 (Entity Authentication)).	50			A
						3. The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to the status of destinations and sources.	51			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.2	H	EN	Health Record Information and Management	Statement: Manage EHR information across EHR-S applications by ensuring that clinical information entered by providers is a valid representation of clinical notes; and is accurate and complete according to clinical rules and tracking amendments to clinical documents. Ensure that information entered by or on behalf of the patient is accurately represented. Description: Since EHR information will typically be available on a variety of EHR-S applications, an EHR-S must provide the ability to access, manage and verify accuracy and completeness of EHR information, maintain the integrity and reliability of the data, and provide the ability to audit the use of and access to EHR information.			52	IN.2		N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.2.1	F	EN	Data Retention, Availability and Destruction	Statement: Retain, ensure availability, and destroy health record information according to scope of practice, organizational policy, or jurisdictional law. This includes: Retaining all EHR-S data and clinical documents for the time period designated by policy or legal requirement; Retaining inbound documents as originally received (unaltered); Ensuring availability of information for the legally prescribed period of time to users and patients; and Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally prescribed retention period. Description: Discrete and structured EHR-S data, records and reports must be: Made available to users in a timely fashion; Stored and retrieved in a semantically intelligent and useful manner (for example, chronologically, retrospectively per a given disease or event, or in accordance with business requirements, local policies, or legal requirements); Retained for a legally prescribed period of time; and Destroyed in a systematic manner in relation to the applicable retention period. An EHR-S must also allow an organization to identify data/records to be destroyed, and to review and approve	IN.1.7	1. The system SHALL provide the ability to store and retrieve health record data and clinical documents for the legally prescribed time.	53	IN.2.1	1	N/C
						2. The system SHALL provide the ability to retain inbound data or documents (related to health records) as originally received (unaltered, inclusive of the method in which they were received) for the legally organizationally prescribed time in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	54	IN.2.1	2	N/C
						3. The system SHALL retain the content of inbound data (related to health records) as originally received for the legally prescribed time.	55	IN.2.1	3	N/C
						4. The system SHOULD provide the ability to retrieve both the information and business context data within which that information was obtained.	56	IN.2.1	4	N/C
						5. The system SHOULD provide the ability to retrieve all the elements included in the definition of a legal medical record in accordance with jurisdictional law.	57	IN.2.1	5	M
						6. The system ~~MAY~~ SHOULD provide the ability to identify specific EHR data/records for destruction, review and confirm destruction before it occurs and implement function IN.2.2 (Auditable Records).	58	IN.2.1	6	M
						6a. IF a system provides the ability to identify specific EHR data/records for destruction and review and confirm destruction before it occurs (as per criterion #6) THEN that process SHALL comply with function IN.2.2 (Auditable Records).	59			A
						7. The system MAY provide the ability to destroy EHR data/records so that all traces are irrecoverably removed according to policy and legal retentions periods.	60	IN.2.1	7	N/C
						8. The system SHOULD pass along record destruction date information (if any) along with existing data when providing records to another entity.	61	IN.2.1	8	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.2.2	F	EN	Auditable Records	Statement: Provide audit capabilities for system access and usage indicating the author, the modification (where pertinent), and the date and time at which a record was created, modified, viewed, extracted, or deleted. Date and Time stamping implies the ability to indicate the time zone where it was recorded (time zones are described in ISO 8601 Standard Time Reference). Auditable records extend to information exchange, to audit of consent status management (to support DC.1.3.3) and to entity authentication attempts. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for an EHR-S. Description: Audit functionality extends to security audits, data audits, audits of data exchange, and the ability to generate audit reports. Audit capability settings should be configurable to meet the needs of local policies. Examples of audited areas include: Security audit, which logs access attempts and resource usage including user login, file access, other various activities, and whether any actual or attempted security violations occurred. Data audit, which records who, when, and by which system an EHR record was created, updated, translated, viewed, extracted, or (if local policy permits) deleted. Audit-data may refer to system setup data or to clinical and patient management data. Information exchange audit, which records data exchanges between EHR-S applications (for example, sending application; the nature, history, and content of the information exchanged); and information about data transformations (for example, vocabulary translations, reception event details, etc.). Audit reports should be flexible and address various users' needs. For example, a legal authority may want to know how many patients a given health care provider treated while the provider's license was suspended. Similarly, in some cases a report detailing all those who modified or viewed a certain patient record. Security audit trails and data audit trails are used to verify enforcement of business, data integrity, security, and access-control rules. There is a requirement for system audit trails for the following events: Loading new versions of, or changes to, the clinical system; Loading new versions of codes and knowledge bases; Taking and restoring of backup; Changing the date and time where the clinical system allows this to be done; Archiving any data; Re-activating of an archived patient record; Entry to and exiting from the clinical system; Remote access connections including those for system support and maintenance activities. Criterion #10 indicates that the "viewer" of data should be identified in audit records. In many cases it is not possible to do this. For example, if a user logs into an EHR and allows another individual to view data displayed on the monitor, the system has no way to include that other individual in its audit data. Therefore, for the purposes of this function, "viewer" is defined as the person logging in and requesting that data be made available for viewing. There is no requirement that the system somehow audit who else might be able to see data that is being displayed. The same applies to printed material. Only the person requesting the printing will be identified in audit data.		1. The system SHALL provide audit capabilities for recording access and usage of systems, data, and organizational resources.	62	IN.2.2	1	N/C
						2. The system SHALL conform to function IN.1.1 (Entity Authentication).	63	IN.2.2	2	N/C
						3. The system SHALL provide audit capabilities indicating the time stamp for an object or data creation.	64	IN.2.2	3	N/C
						4. The system SHALL provide audit capabilities indicating the time stamp for an object or data modification in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	65	IN.2.2	4	N/C
						5. The system SHALL provide audit capabilities indicating the time stamp for an object or data extraction in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	66	IN.2.2	5	N/C
						6. The system SHALL provide audit capabilities indicating the time stamp for an object or data exchange.	67	IN.2.2	6	N/C
						7. The system ~~SHOULD~~ SHALL provide audit capabilities indicating the time stamp for an object or data view.	68	IN.2.2	7	M
						8. The system SHALL provide audit capabilities indicating the time stamp for an object or data deletion in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	69	IN.2.2	8	N/C
						9. The system SHALL provide audit capabilities indicating the author of a change in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	70	IN.2.2	9	N/C
						10. The system ~~SHOULD~~ SHALL provide audit capabilities indicating the viewer of a data set.	71	IN.2.2	10	M
						11. The system ~~MAY~~ SHALL provide audit capabilities indicating the data value before a change.	72	IN.2.2	11	M
						12. The system MAY provide audit capabilities to capture system events at the hardware and software architecture level.	73	IN.2.2	12	N/C
						13. The system SHALL conform to function IN.1.3 (Entity Access Control) to limit access to audit record information to appropriate entities in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	74	IN.2.2	13	N/C
						14. The system SHALL provide the ability to generate an audit report.	75	IN.2.2	14	N/C
						15. The system SHALL provide the ability to view change history for a particular record or data set in accordance with users’ scope of practice, organizational policy, or jurisdictional law.	76	IN.2.2	15	N/C
						16. The system SHOULD provide the ability to record system maintenance events for loading new versions of, or changes to, the clinical system.	77	IN.2.2	16	N/C
						17. The system SHOULD provide the ability to record system maintenance events for loading new versions of codes and knowledge bases.	78	IN.2.2	17	N/C
						18. The system ~~SHOULD~~ SHALL provide the ability to record changing the date and time where the clinical system allows this to be done.	79	IN.2.2	18	M
						18a. The system SHALL NOT provide the capability to alter the time stamp of an existing event.	80			A
						19. The system SHOULD provide the ability to record system maintenance events for creating and restoring of backup.	81	IN.2.2	19	N/C
						20. The system SHOULD provide the ability to record system maintenance events for archiving any data.	82	IN.2.2	20	N/C
						21. The system SHOULD provide the ability to record system maintenance events for re-activating of an archived patient record.	83	IN.2.2	21	N/C
						22. The system ~~SHOULD~~ SHALL provide the ability to record system maintenance events for entry to and exit from the EHR system.	84	IN.2.2	22	M
						23. The system ~~SHOULD~~ SHALL provide the ability to record system maintenance events for remote access connections including those for system support and maintenance activities.	85	IN.2.2	23	M
						24. The system ~~SHOULD~~ ~~utilize standardized time keeping (for example using the IHE consistent time profile)~~ SHALL conform to HITSP accepted consistent time standard.	86	IN.2.2	24	M
						25. The system SHOULD provide the ability to record and report upon audit information using a standards-based audit record format (for example RFC 3881).	87	IN.2.2	25	N/C
						26. The system SHALL NOT provide the capability to modify audit data	88			A
						27. The system MAY provide the capability to manually append information to audit data.	89			A

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.2.3	F	EN	Synchronization	Statement: Maintain synchronization involving: Interaction with entity directories; Linkage of received data with existing entity records; Location of each health record component; and Communication of changes between key systems. Description: An EHR-S may consist of a set of components or applications; each application manages a subset of the health information. Therefore it is important that, through various interoperability mechanisms, an EHR-S maintains all the relevant information regarding the health record in synchrony. For example, if a physician orders an MRI, a set of diagnostic images and a radiology report will be created. The patient demographics, the order for MRI, the diagnostic images associated with the order, and the report associated with the study must all be synchronized in order for the clinicians to view the complete record.		1. The system SHALL conform to function IN.5.1 (Interchange Standards).	90	IN.2.3	1	N/C
						2. The system SHOULD conform to function IN.3 (Registry and Directory Services) to enable the use of registries and directories.	91	IN.2.3	2	N/C
						3. The system SHOULD provide the ability to link entities to external information.	92	IN.2.3	3	N/C
						4. The system SHOULD store the location of each known health record component in order to enable authorized access to a complete logical health record if the EHR is distributed among several applications within the EHR-S.	93	IN.2.3	4	N/C

ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	FM Source
ID#	Type	Priority	Name	Statement/ Description	See Also	Conformance Criteria	Row #	ID #	Criteria #	Criteria Status
IN.2.4	F	EN	Extraction of Health Record Information	Statement: Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions may be used to exchange data and provide reports for primary and ancillary purposes. Description: An EHR-S enables an authorized user, such as a clinician, to access and aggregate the distributed information, which corresponds to the health record or records that are needed for viewing, reporting, disclosure, etc. An EHR-S must support data extraction operations across the complete data set that constitutes the health record of an individual and provide an output that fully chronicles the health care process. Data extractions are used as input to patient care coordination between facilities, organizations and settings. In addition, data extractions can be used for administrative, financial, research, quality analysis, and public health purposes.	S.2.2	1. The system SHALL provide the ability to extract health record information.	94	IN.2.4	1	N/C
						2. The system ~~SHOULD~~ SHALL conform to function IN.1.6 (Secure Data Exchange) to provide secure data exchange capabilities.	95	IN.2.4	2	M
						3. The system SHOULD provide the ability to de-identify extracted information.	96	IN.2.4	3	N/C
						4. The system ~~SHOULD~~ SHALL conform to function IN.5.1 (Interchange Standards) to enable data extraction in standard-based formats.	97	IN.2.4	4	M
						5. The system ~~SHOULD~~ SHALL provide the ability to perform extraction operations across the complete data set that constitutes the health record of an individual within the system.	98	IN.2.4	5	M
						6. The system ~~MAY~~ SHALL provide the ability to perform extraction operations whose output fully chronicles the healthcare process.	99	IN.2.4	6	M
						7. The system ~~SHOULD~~ SHALL provide the ability to extract data for administrative purposes.	100	IN.2.4	7	M
						8. The system SHOULD provide the ability to extract data for financial purposes.	101	IN.2.4	8	N/C
						9. The system SHOULD provide the ability to extract data for research purposes.	102	IN.2.4	9	N/C
						10. The system SHOULD provide the ability to extract data for quality analysis purposes.	103	IN.2.4	10	N/C
						11. The system SHOULD provide the ability to extract data for public health purposes.	104	IN.2.4	11	N/C

ID#

Type

Priority

Name

Statement/ Description

APPENDIX: HIT Standards

During the development of the LTC EHR-S Functional Profile, members of the LTC community discussed whether the Profile should reference specific standards, or whether the Profile and its supporting documentation should remain generic with statements that require compliance/conformance “in a standard manner” or ”adhere to industry standards.” Members of the LTC community recommended:

identifying the recognized standard setting entities and making generic references to complying with standards; and
in some instances, identifying the specific standards needed for certain functions or criteria in the Profile, when such standards are particularly important and/or unique to LTC.

Complying with Industry Standards

As a matter of general principle, the expectation is that the LTC-NH EHR-S Functional Profile will require compliance with applicable industry standards approved, accepted, endorsed, or regulated by the following entities:

Recognized Healthcare Information Technology Standards Panel (HITSP) standards.
Standards endorsed through the Consolidated Health Informatics (CHI) Initiative, accepted by the Secretary of Health and Human Services (HHS), and required for use in all future federal health information systems acquisitions.
Standards required for use by the Centers for Medicare and Medicaid Services (CMS).
Standards that are widely accepted by the industry or industry groups.

The following table provides the reader with some information about the preceding standard setting entities/activities.

STANDARD SETTING ENTITIES/ACTIVITIES
Key Standard Setting Entities/Activities	Comment
HITSP	Health Information Technology Standards Panel (HITSP) is a public-private standards harmonization collaborative. HITSP has identified several widely accepted, consensus-based HIT standards to enable and support the development and use of interoperable HIT products in several healthcare domains, some of which will be useable by nursing home electronic health record systems (EHR-S) such as HITSP EHR Lab Results Reporting v2 and Consumer Empowerment v2.1. The HITSP endorsed HIT standards can be found at: http://www.hitsp.org. The LTC/NH EHR-S Functional Profile shall require use of applicable HITSP standards.
CHI	The Consolidated Health Informatics (CHI) Initiative began in 2001 as part of the President’s Management Agenda. The CHI Initiative was a collaborative effort to identify and adopt Federal Government-wide interoperable HIT standards to be implemented by federal agencies and enable the Federal Government to exchange electronic health information. Through the CHI Initiative 27 HIT content and messaging standards were endorsed, including standards for patient assessments. The CHI reports specifying the specific standards that have been endorsed can be found at: http://www.hhs.gov/healthit/chiinitiative.html. The National Committee for Health and Vital Statistics (NCVHS) and the Secretary of HHS accepted these 27 CHI standards, and the Department of HHS has published two Federal Register notices concerning the Federal Government’s use of CHI standards. The first notice was published on 12/23/2005 for the CHI standards that had been accepted as of that date. On December 17, 2007 another Federal Register notice was published announcing the acceptance of the CHI Disability and Assessment standards and indicated that the “Federal Government will require all future federal health information acquisitions to be based on CHI standards when applicable and as permitted by law, whether system development occurs within the Agency or through use of contractor services” (http://a257.g.akamaitech.net/7/257/2422/01jan20071800/edocket.access.gp…). The LTC/NH EHR-S Functional Profile shall require use of applicable CHI standards when HITSP has not yet accepted standards in a domain that is important to /needed by LTC. As described below, the LTC/NH EHR-S Functional Profile shall specifically reference and require conformance with the CHI Patient Assessments standards.
CMS Required Standards	1. Health Insurance Portability & Accountability Act (HIPAA) The LTC/NH EHR-S Functional Profile shall require conformance with HIPAA mandated standards and requirements. 2. e-Rx final rule, April 7, 2008 requirements are: The National Council for Prescription Drug Programs (NCPDP) SCRIPT Standard Version 8.1 (for the exchange of new prescriptions, changes, renewals, cancellations, fill status notification, medication history, and certain other transactions between prescribers and dispensers). The National Council for Prescription Drug Programs (NCPDP) Formulary and Benefits Standard, Version 1.0, for transmitting formulary and benefits information between prescribers and Medicare Part D sponsors. The National Provider Identifier (NPI) to identify an individual health care provider to Medicare Part D sponsors, prescribers and dispensers in electronically transmitted prescriptions or prescription-related materials for Medicare Part D covered drugs for Medicare Part D eligible individuals. 3. CMS e-Rx Interim Final Rule (IFR) (6/23/2006) (does not require the application of e-prescribing standards to e-prescribing on behalf of nursing home residents). The e-prescribing standards in this IFR are: National Council for Prescription Drug Programs (NCPDP) SCRIPT Standard Version 5.1 or 8.1 (for the exchange of new prescriptions, changes, renewals, cancellations and certain other transactions between prescribers and dispensers). Accredited Standards Committee (ASC) X12N 270/271 Version 4010A1 (for the exchange of eligibility information between prescribers and Medicare Part D sponsors). NCPDP Telecommunication Standard Version 5.1 (for the exchange of eligibility inquiries and responses between dispensers and Medicare Part D sponsors). 4. The CMS e-Rx Final Rule (11/7/2005) provides that entities may use Health Level Seven (HL7) standards or the NCPDP SCRIPT standard to conduct internal electronic prescription transactions. The LTC-NH EHR-S Functional Profile shall not require conformance with the CMS e-RX Final Rule (4/7/08), the e-RX Interim Final Rule (6/23/2006) or the e-Rx Final Rule (11/7/2005) as nursing homes are excluded from the requirements.
Standards widely accepted by industry: 1. Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC) Technical Framework 2. E-prescribing in Nursing Homes	1. IHE PCC standards include: Continuity of Care Document (CCD): Continuity of Care Record (CCR), HL7 CDA -- Clinical Document Architecture. Clinical Document Architecture (CDA). HL7 Care Record Summary. Logical Observation Identifiers Names and Codes (LOINC). Systematized Nomenclature of Medicine Clinical Terms (SNOMED-CT). Basic Patient Privacy Consents (BPPC). 2. E-prescribing in Nursing Homes: NCPDP SCRIPT Standard Version 10.2. ASC X12N 270/271 Version 004010X092A1. NCPDP Formulary and Benefits Standard version 1.0. NCPDP Telecommunication Standard Version 5.1. As described below, the LTC/NH EHR-S Functional Profile shall specifically reference and require conformance with certain IHE standards and industry accepted nursing home e-prescribing standards.

NOTE: Members of the LTC community also acknowledge that some of the standards that have been recognized by the preceding entities are not applicable to the LTC-NH EHR-S Functional Profile either because the nursing home EHR-S Functional Profile does not embed functions/criteria that would require certain standards (e.g., HITSP Emergency Responder standards), or because the standards needed to support certain functions have not yet been required by CMS (e.g., e-prescribing in nursing homes).

Requiring Compliance/Conformance with Specific Standards in the LTC-NH EHR-S Functional Profile

Members of the LTC community recommended that the LTC-NH EHR-S Functional Profile reference and require compliance/conformance with the following specific standards that are particularly important and/or unique to LTC:

HL7 Continuity of Care Document (CCD).
Consolidated Health Informatics (CHI) Disability and Patient Assessment Standards.
e-Prescribing Standards applicable to Nursing Homes.

These standards and their importance to LTC providers are described below.

HL7 Continuity of Care Document (CCD)

HL7 standards include standards for health information exchange (e.g., exchange of results and documents). The HL7 Clinical Document Architecture (CDA) is an HL7 exchange standard by which a wide array of documents can be exchanged. The CDA can support the electronic exchange of both text-based and coded documents. One type of document that can be exchanged using the CDA is the Continuity of Care Document (CCD). The CCD is the exchange standard for documents such as transfer/discharge documents. The CCD allows for the exchange of all and/or some of the following content:

Payers	Advanced Directives
Healthcare Providers	Supports (persons/family)
Social History	Family History
Medical Equipment	Plan of Care
Encounters	Functional Status
Problems	Alerts
Medications	Immunizations
Vital Signs	Results
Procedures

Because persons are frequently transferred to/discharged from nursing homes, members of the LTC community thought that it was important that the LTC-NH EHR-S Functional Profile require/suggest the use of the CCD as the standard to support nursing home transfers/discharges. The CCD has been recognized by HITSP (as the exchange standard for other documents) and recognized by the Certification Commission for Health Information Technology (CCHIT) as an exchange standard for CCHIT certified physician office EHR-S.

There are several criteria in the LTC-NH EHR-S Functional Profile that specifically point to the use of the CCD as the standard that SHALL or SHOULD be used to support particular functions/criterion in the LTC-NH EHR-S Functional Profile regarding the exchange of transfer, discharge, and referral documents.

Consolidated Health Informatics (CHI) Disability and Patient Assessment Standards

In 2006, the CHI Initiative endorsed HIT standards to format, standardize the content of, and exchange federally-required assessment instruments or specific assessment findings from these federally-required instruments. (The link to all CHI reports is: http://www.hhs.gov/healthit/chiinitiative.html. Scroll down to Full Reports item #24 for the report entitled Disability and Assessment Forms.) The CHI patient assessment standards are:

Clinical LOINC® representation of federally-required assessment: (i) questions and answers, and (ii) assessment forms that include functioning and disability content as CHI standards.
CHI Endorsed Vocabulary Content:
1. International Classification of Functioning, Disability and Health (ICF) as a CHI-endorsed standard for the functioning and disability domains;
2. CHI-endorsed vocabulary (e.g., SNOMED-CT) for exact and “usefully related” content matches with federally-required patient/client assessments and other functioning and disability content.
HL7® (Health Level Seven®), Version 2.4 and higher messaging and Clinical Document Architecture (CDA) to exchange patient and client assessments and other standardized functioning and disability content.

In July 2007, the Secretary of HHS accepted the CHI standards for Disability and Assessments instruments, stating that, “these standards will be used by all Federal agencies in implementing new, and as feasible, when updating existing health information technology systems” (http://www.ncvhs.hhs.gov/070731lt.pdf). In December 2007, HHS published a Federal Register Notice stating that the “Federal Government will require all future federal health information acquisitions to be based on CHI standards when applicable and as permitted by law, whether system development occurs within the Agency or through use of contractor services” (http://a257.g.akamaitech.net/7/257/2422/01jan20071800/edocket.access.gp…).

Given (i) the importance of federal assessment requirements in nursing homes (i.e., used to calculate payment rates, monitor facility quality, and develop care plans) and (ii) that health information technology products, including EHR products, have been designed to support the production and exchange of federally-required assessments, the LTC-NH EHR-S Functional Profile indicates that systems SHOULD provide the ability to exchange federally mandated assessment data in conformance with CHI format and content standards.

e-Prescribing Standards in Nursing Homes

The Medicare Modernization Act (MMA) established the Medicare Part D prescription drug benefit. The MMA requires prescriptions for covered Part D drugs for Part D enrolled individuals that are transmitted electronically be transmitted in accordance with e-prescribing standards. The MMA required initial standards be implemented not later than September 1, 2005 and that final standards must be promulgated not later than April 1, 2008.

CMS has published several final e-prescribing rules (i.e., CMS e-Rx Final Rule (4/7/2008), CMS e-Rx Interim Final Rule (6/23/2006), and CMS e-Rx Final Rule (11/7/2005)). CMS has excluded nursing homes from being required to use these e-prescribing standards because of questions concerning the applicability of these standards to nursing homes.

The MMA required pilot testing of standards that (at the time of initial e-prescribing rulemaking) were not ready for adoption. The Agency for Healthcare Research and Quality (AHRQ) and CMS sponsored five e-prescribing pilots, including a pilot in LTC (i.e., nursing homes). The purpose of the AHRQ/CMS pilots was to determine which (if any) additional e-prescribing standards were ready for adoption, including which standards for e-prescribing in nursing homes were ready for adoption. The report of LTC/nursing home e-prescribing pilot can be found at: http://healthit.ahrq.gov/erxpilots.

The evaluation of the LTC/nursing home pilot and the CMS Report to Congress (both of which are also available at the same website referenced above) found with respect to e-prescribing in nursing homes that: “Analysis shows that e-prescribing can be supported, with some technical accommodations to the standards, in long-term care facilities for Part D implementation.”

In November 2007, ANSI approved the NCPDP SCRIPT V10.2 standard. The NCPDP SCRIPT V10.2 provides many of the necessary technical accommodations to this standard that were identified as needed through the AHRQ/CMS pilot.

Specifically, the NCPDP SCRIPT V10. 2 provides for the following (Note: NCPDP SCRIPT V10.2 includes functionality approved in the NCPDP SCRIPT V10.1. Therefore, the table below describes both NCPDP SCRIPTV10.1 and V10.2):

NCPDP SCRIPT 10.1 and 10.2
Version	ANSI Approval	Changes from Prior Version
NCPDP SCRIPT 10.1	September, 2007	CENSUS Update Transaction was added. The Census Update Transaction is originated by the facility in a long term care environment. Support for the Long-Term Care (LTC) Medication Change Process was added. For LTC settings, a new transaction type of “Resupply Request” was added, which looks like a Refill Request, but no response is necessary. Sections throughout the document were updated to include the new request message of CENSUS, the LTC Medication Change Process, and the Resupply Request. Field values were added to the REQ Segment for the CENSUS transaction. (Admit; Change; Discharge -- Expired; Discharge -- Return Not Anticipated; Discharge -- Return Anticipated; Discharge -- Other). Fields added to the REQ Segment for the CENSUS transaction. In the COO Segment, new field values were added for the CENSUS transaction. In the COO Segment, Party Name became a composite. In the COO Segment, Ø7Ø Party Name (Group Name) is available for use (was shaded). In the COO Segment, Address is now available for use (was shaded) and is used for the responsible party’s address. In the COO Segment, Insurance Type, coded is now available for use (was shaded), and values added (Primary, Secondary; Tertiary, Unknown, Private Pay). In the COO Segment, Communication Number has been added. For Long Term Care (LTC) Medication Change Process, in the UIH Segment, trace number assigned by sender. In the REQ Segment, the following values have been added (Significant Change; Frequency Change, Insignificant Change). In the DRU Segment, an enhancement was made for Medication History Response transactions. For Resupply Request transaction, additional notes have been made. DRU Ø2Ø-IØØ9-Ø1-6Ø63 Quantity Qualifier uses the same base list (Unit of Measure X-12 DE 355), but uses a subset list for this field. See the NCPDP External Code List. DRU Ø6Ø-IØØ9-Ø1-6Ø63 Quantity Qualifier added a new value for number of refills remaining on a prescription, for use in Medication History Responses.
NCPDP SCRIPT 10.2	November, 2007	For LTC -- In the DRU Segment, the following fields were added (Needed no later than; Time Zone; Needed no later than reason). Section “Sign” was added to “Numeric Representation” to provide information about the use of the negative sign in the Time Zone Difference Quantity. Section “Time Zone” was added to “Requirement Designation”.

Given the approval by the American National Standards Institute (ANSI) of the NCPDP SCRIPT V. 10.2 standard and the demonstrated functionality of this standard in the AHRQ/CMS e-prescribing pilot, the LTC-NH EHR-S Functional Profile references and requires conformance with NCPDP SCRIPT V.10.2 (as well as the ASC X12N 270/271 V. 004010X092A1+ and NCPDP Telecommunication Standard V. 5.1 as required by CMS in the Medicare Part D e-prescribing requirements).

In addition, consistent with the CMS e-prescribing rule, the LTC-NH EHR-S Functional Profile references and permits the use of either the NCPDP SCRIPT or HL7 standards for prescribing transactions that are internal to the nursing home.

Files

LNEHRSFP1.pdf (pdf, 1.47 MB)

Topics

Nursing Homes & Facilities | Long-Term Services & Supports (LTSS) | Electronic Health Records (EHR)

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

PREFACE

1. Notes to Readers

2. Acknowledgements

3. Changes from Previous Release

1. BACKGROUND

2. PROCESS

3. NEXT STEPS

4. ORGANIZATION OF THIS DOCUMENT

5. CONFORMANCE CLAUSE

5.1. Scope and Field of Application

5.2. Functional Priorities

5.3. Normative Language

5.4. Claiming Conformance to the Profile

6. APPLYING THE CONFORMANCE REQUIREMENTS

7. STANDARDIZING TERMS IN FUNCTION CRITERIA

8. COMPONENTS OF LTC-NH EHR-S FUNCTIONAL PROFILE OUTLINE

ATTACHMENTS

Direct Care Functions

Supportive Functions

Information Infrastructure Functions

APPENDIX: HIT Standards

Complying with Industry Standards

Requiring Compliance/Conformance with Specific Standards in the LTC-NH EHR-S Functional Profile

Connect with Us