[xls]wiki.hl7.orgwiki.hl7.org/images/d/df/hl7_ehr_fm_r2_working... · web view295. 135 7 296. 136 7...

Worksheet Introduction

Functional ModelID#

Type

Name

Statement/Description

See Also

Conformance Criteria

Model Row #

Functional Profile

Change Flag

Functional Priority

Profile Row #

Gap Analysis Tracibility Matrix

St. Joseph EMR RFI

St. Joseph Use Cases

ASCO Rqmts

Gap Comments

Domain Expert Consensus

Date Reviewed

Approval Status

Consensus Comments

Domain Expert Review

Expert Comments 1 to 6

This tab Provides an overview of the worksheet and explains the rows within the worksheets.

Section is owned by HL7 Functional Model - should NOT be changed by project

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

The name of the Function. Example: Manage Medication List

Identified relationships between functions.

Original Row # from HL7 Functional Model

Section is owned by Analyst responsible for development of Functional Profile.

Section is owned by Analyst responsible for gap analysis.

Section owned by Analyst responsible for Domain Expert consensus development.

Approval status (codes to be used will be set by DE team)

Comments from Domain Expert group to Analyst. Conclusions and consensus.

Section owned by Domain Experts

Each column should be used by a Domain Expert to submit feedback, comments, questions or issues.

This is the unique outline identification of a function in the outline. The 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). Numbering for all sections begins at n.1.

A brief statement of the purpose of this function followed by a more detailed description of the function, including examples if needed.

The criteria for which conformance to a given function will be assessed. Refer to section XXX for discussion on conformance language.

Indicator of the type of change between the HL7 Funcitonal Model and the OO Functional Profile.NC = No changeA = AddedD = DeletedC = Changed

The priority by which the function is expected to be implemented. EN = Essential NowEF = Essential FutureO = OptionalOF = Optional FutureNS = Not SupportedNA = Not Applicable (Criteria does not apply because section is not supported).

Row # within Functional Profile - begin at “1” in each section (DC, S, IN)

Link ot the St. Joseph EMR RFI functional requirements.G. = General RequirmentsO. = Oncology RequirementsT. = Technical SpecificationsC. = caBIG (C) Specifications

Link to the St. Joseph Use CasesU. = Use Case paragraph/statement

Link ot the ASCO Oncology EHR functional requirements.A. = ASCO Requirements

Comments, assumptions and notations from Analyst performing Gap Analysis including questions to be answered by Domain Experts.Each comment starts with the ID link from the requirements documents for which it applies.

Date that Domain Expert team reviewed this data item. May contain multiple dates if reviewed multiple times

ChapterChapter TitleChapter AliasChapter Overview

Chapter Description

Model Format Description

Example

Actors


Chapter Description


Example

Actors


Chapter Description


Examples

Actors

3Direct Care EHR-S FunctionsDC

4Supportive EHR-S FunctionsS

Direct Care EHR-S functions are the subset of EHR-S functions that enable delivery of healthcare and offer clinical decision support. The functions are general and are not limited to a specific setting. Instead these functions are part of an Electronic Health Record which could be developed for offices, clinics as well as hospitals. The reach could be system centric or across multiple and disparate systems.

ID#: This identifies the header and/or function record and is a reference point to and from all other functions in the model.

Type: This may be a Header (H) or Function (F) record. The header record usually reflects a larger grouping of related functions.

Name: Name of the function or header.

Statement/Description: The description is intended to be reader friendly and illustrative of what is to be accomplished within that function.

See Also: These are references to other parts of the model. When reading a section, following the links to these other functions and criteria provide additional information about what is important to or in support of that function---but within another part of the model.

Conformance criteria: Conformance criteria provide detail as to accomplishing the function. Criteria are based off of the description---but are more specific. See the Overview and Conformance Chapters for a detailed description of conformance criteria and how they work.

For example, when a child presents with symptoms of common cold, a Direct Care EHR-S Function will enable the doctor to record that event. Additionally, Clinical decision-support functions within the Direct Care EHR-S section will alert the provider that a vaccination is due and will offer contraindication alerts for the medication given to the child who has symptoms of a cold.

The principal users of these functions are expected to be authorized healthcare providers; the patient and/or subject of care will have access to certain functions to view, update or make corrections to their Electronic Health Record. The provider will receive appropriate decision support, as well as support from the EHR-S to enable effective electronic communication between providers, and between the provider and the patient/parent/caregiver.

5Information Infrastructure EHR-S FunctionsIN

S.1 Clinical SupportThe functions in the Clinical Support section are those used to collect, manage and share demographic information on providers and patients, and includes access to directories and registries. The functions include support for location and facility management, like the bed master and scheduling.

S.2 Measurement, Analysis, Research and Reports The functions in Measurement, Analysis, Research and Reports sections provide aspects of the model that support primary and secondary use of the data. Standard, custom, regulatory, quality and research reporting are set-up, modified, requested and run. Support for outcome and performance capture, measurement and reporting are also present in this section.

S.3 Administrative and FinancialThe functions in Administrative and Financial support the capture and management of data on the health care operations in order to enable public health, financial and administrative reporting. The functions include those needed for maintaining files that support direct care operations, relationship management (provider to patient) and acuity measurements.







For example, during the encounter, Supportive EHR-S functions will electronically query local immunization registries (to insure that the child is currently registered), and will determine the child’s immunization status. After treatment, Supportive EHR-S functions will report any immunization to an immunization registry and will provide any encounter data required by financial and administrative systems.

The Support and Administrative Staff are the principal users of these functions but, under certain circumstances, the Healthcare Providers might be expected to perform certain administrative functions.

NOTE: THIS CHAPTER IS A WORK IN PROGRESS AND IS NOT INTENDED FOR THE APRIL-MAY COMMENTS ONLY BALLOT REVIEW. THE DRAFT SKELETAL CONTENT INCLUDED IN THIS CHAPTER ARE TO MAINTAIN THE INTEGRITY OF THE LINKS FROM THE OTHER CHAPTERS. THIS CHAPTER WILL BE COMPLETED PRIOR TO THE PLANNED SEPTEMBER NORMATIVE BALLOT.

The Information Infrastructure section consists of common functions that support the Direct Care and Supportive Functions. Information Infrastructure functions are not involved in the provision of healthcare, but are necessary to ensure that the EHR-S provides necessary safeguards for patient safety, privacy and information security, as well as operational efficiencies and minimum standards for interoperability. They may be provided by the applications that support managing the health record, supporting infrastructure or a combination of both.

IN.2 Health Record Information and ManagementSince 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.

IN.3 Registry and Directory ServicesRegistry and directory service functions are critical to successfully managing the security, interoperability, and the consistency of the health record data across an EHR-S. These services enable the linking of relevant information across multiple information sources within, or external to, an EHR-S for use within an application.

Directories and registries support communication between EHR Systems and may be organized hierarchically or in a federated fashion. For example, a patient being treated by a primary care physician for a chronic condition may become ill while out of town. The new provider’s EHR-S interrogates a local, regional, or national registry to find the patient’s previous records. From the primary care record, a remote EHR-S retrieves relevant information in conformance with applicable patient privacy and confidentiality rules.

IN.4 Standard Terminologies and Terminology ServicesThe purpose of supporting terminology standards and services is to enable semantic interoperability. Interoperability is demonstrated by the consistency of human and machine interpretation of shared data and reports. It includes the capture and support of consistent data for templates and decision support logic.

Terminology standards pertain to concepts, representations, synonyms, relationships and computable (machine-readable) definitions. Terminology services provide a common way for managing and retrieving these items.

IN.5 Standards Based InteroperabilityInteroperability standards enable an EHR-S to operate as a set of applications. This results in a unified view of the system where the reality is that several disparate systems may be coming together.

Interoperability standards also enable the sharing of information between EHR systems, including the participation in regional, national, or international information exchanges.

Timely and efficient access to information and capture of information is promoted with minimal impact to the user.

IN.6 Business Rules ManagementEHR-S business rule implementation functions include: decision support, diagnostic support, workflow control, and access privileges, as well as system and user defaults and preferences.

An EHR-S supports the ability of providers and institutions to customize decision support components such as triggers, rules, or algorithms, as well as the wording of alerts and advice to meet realm specific requirements and preferences.

IN.7 Workflow Management







For example, Direct Care and Supportive EHR-S functions must operate in a secure environment. Therefore, Information Infrastructure functions will provide a secure electronic environment for the immunization registration query mentioned previously and will report the child’s immunization event in a secure manner. Information Infrastructure functions will also transparently provide other essential services, such as the archival and backup of the child’s record and an audit trail of all accesses to the child’s record.

The functions are expected to be performed transparently by EHR-S applications on behalf of EHR-S end-users. The System Administrator is expected to be involved in all operations related to configuring and managing the EHR-S operation. A security administrator is the person responsible for implementing security policy for authentication, authorization, and access control.

Functional Model R1.1 June 2009 Functional Model R2.0

ID#

Type Name Statement:

See

Also Conformance Criteria

Mod

el R

ow #

ID#

Type

Nam

e

X DC.0 H Direct Care

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.0 C

DC.1 H Care Management X DC.1 H Care Management

DC.1 1. The system SHALL conform to f 1 DC.1



DC.1 4. IF the system is used to ente 4 DC.1

DC.1 5. IF the system exchanges data 5 DC.1


DC.1 7. IF the system is used to enter 7 DC.1

DC.1 8. The system SHALL conform to fu8 DC.1


DC.1 10. The system SHOULD conform t10 DC.1

DC.1 11. IF the system is used to extr 11 DC.1

DC.1 12. IF the system stores unstruc 12 DC.1

DC.1 13. IF the system stores structu 13 DC.1

DC.1 14. The system SHOULD conform to14 DC.1

DC.1 15. IF the system processes data 15 DC.1


DC.1 17. The system SHOULD conform 17 DC.1


DC.1 19. IF the system exchanges dat 19 DC.1





DC.1 24. The system SHALL conform to 24 DC.1 C

DC.1.1 H Record Management S.3.1.4 25 DC.1.1 H Record Management

DC.1.1.1 F Identify and Maintain X DC.1.1.1 F Manage a Patient Record

DC.1.1.1 S.1.4.1. The system SHALL create a sing26 DC.1.1.1 C

DC.1.1.1 2. The system SHALL provide the a27 DC.1.1.1 C

DC.1.1.1 C


DC.1.1.1 4. The system SHALL associate ke 29 DC.1.1.1 C

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

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

DC.1.1.1 5. The system SHALL provide the ab30 DC.1.1.1 C

DC.1.1.1 C


DC.1.1.1 7. IF health information has bee 32 DC.1.1.1 C

DC.1.1.1 8. IF health information has been 33 DC.1.1.1 C


DC.1.1.1 10. The system SHOULD provide the35 DC.1.1.1 C

DC.1.1.1 11. IF related patients register 36 DC.1.1.1 C

DC.1.1.1 12. The system SHALL conform to 37 DC.1.1.1

DC.1.1.1 C

DC.1.1.1 C

DC.1.1.1 C

DC.1.1.1.1 F Manage additional research identifiers

DC.1.1.1.1 C

DC.1.1.1.1 C

DC.1.1.1.1 C

DC.1.1.1.1 C

DC.1.1.2 F Manage Patient Demo X DC.1.1.2 F Manage Patient Demographics

DC.1.1.2 S.1.4.1. The system SHALL capture demo38 DC.1.1.2 C

DC.1.1.2 2. The system SHALL store and re 39 DC.1.1.2 C


DC.1.1.2 4. The system SHALL provide the 41 DC.1.1.2

DC.1.1.2 5. The system SHOULD provide th 42 DC.1.1.2

DC.1.1.2 6. The system SHOULD store histo43 DC.1.1.2 C

DC.1.1.2 7. The system SHALL present a set44 DC.1.1.2 C

DC.1.1.2 8. The system SHOULD conform to45 DC.1.1.2

DC.1.1.2 9. The system SHALL conform to f 46 DC.1.1.2

DC.1.1.2 10. The system MAY store the dem? DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2 C

DC.1.1.2.1 F Capture Quick Registration

DC.1.1.2.1 C

DC.1.1.2.1 C

DC.1.1.2.1 C

DC.1.1.2.1 C

DC.1.1.3 F Manage Patient Encounter

DC.1.1.3 C

DC.1.1.3 C

DC.1.1.3 C

DC.1.1.3 C

DC.1.1.3 C

DC.1.1.3 H Data and DocumentatiDescription: External sources are those outside t X DC.1.1.4 H Data and Documentation from External Sources



DC.1.1.3.1 F Capture Data and Docu X DC.1.1.4.1 F Capture Documentation from External Clinical S

DC.1.1.3.1 IN.1.51. The system SHALL provide the 49 DC.1.1.4.1 C

DC.1.1.3.1.1 2. IF lab results are received th 50 DC.1.1.4.1

DC.1.1.3.1.1 3. IF lab results are received t 51 DC.1.1.4.1

DC.1.1.3.1.1 4. The system SHOULD provide the52 DC.1.1.4.1 C

DC.1.1.4.1 C

DC.1.1.3.1.1 5. The system MAY provide the a 53 DC.1.1.4.1 C

DC.1.1.3.1.1 6. The system SHOULD provide the54 DC.1.1.4.1 C

DC.1.1.3.1.1 7. The system SHOULD provide the 55 DC.1.1.4.1

DC.1.1.3.1.1 8. The system SHOULD provide the 56 DC.1.1.4.1

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.

Statement: Incorporate clinical data and documentation from external sources.Description: Mechanisms for incorporating external clinical data and documentation (including identification of source) such as image documents and other clinically relevant data are available. Data incorporated through these mechanisms is presented alongside locally captured documentation and notes wherever appropriate.

DC.1.1.3.1.1 9. The system SHOULD provide the57 DC.1.1.4.1

DC.1.1.3.1.1 10. The system SHOULD provide th58 DC.1.1.4.1 C

DC.1.1.3.1.1 11. The system SHOULD provide th59 DC.1.1.4.1

DC.1.1.4.1 C

DC.1.1.4.1 C

DC.1.1.4.1 C

DC.1.1.4.1 C

DC.1.1.4.2 F Capture Data from External Clinical Sources

DC.1.1.4.2 C

DC.1.1.4.2 C

DC.1.1.4.2 C

DC.1.1.4.2 C

DC.1.1.4.2 C

DC.1.1.4.2 C

DC.1.1.4.2.1 F Capture Data from External Emergency Medical

DC.1.1.4.2.1 C

DC.1.1.4.2.1 C

DC.1.1.4.2.1 C

DC.1.1.4.3 F Capture Images from External Clinical Sources

DC.1.1.4.3 C

DC.1.1.4.3 C

DC.1.1.4.3 C

DC.1.1.3.2 F Capture Patient-Origi X DC.1.1.4.4 F Capture Patient-Originated Data

DC.1.1.3.2 IN.1.41. The system SHALL capture and e60 DC.1.1.4.4 C

DC.1.1.3.2 2. IF the system provides the abi 61 DC.1.1.4.4 C

DC.1.1.3.2 3. The system SHALL capture and l62 DC.1.1.4.4 C

DC.1.1.3.2 4. The system SHALL present pati 63 DC.1.1.4.4 C

DC.1.1.3.2 5. The system SHALL provide the ab64 DC.1.1.4.4 C

DC.1.1.3.2 6. The system SHOULD provide the65 DC.1.1.4.4 C

DC.1.1.4.4 C

DC.1.1.4.4 C

DC.1.1.4.4 C

DC.1.1.4.4 C

DC.1.1.4.4 C

DC.1.1.4.4 C

DC.1.1.3.3 F Capture Patient Healt X DC.1.1.4.5 F Capture Patient Health Data Derived from Admin

DC.1.1.3.3 DC.1.11. The system SHALL provide the a66 DC.1.1.4.5 C

DC.1.1.3.3 2. The system SHALL provide the a67 DC.1.1.4.5 C


DC.1.1.3.3 4. The system SHOULD provide the69 DC.1.1.4.5

DC.1.1.4.5 C

DC.1.1.3.3 5. The system SHOULD provide the 70 DC.1.1.4.5

DC.1.1.4.6 F

DC.1.1.4.6 C

DC.1.1.4.6 C

DC.1.1.4.7 F Capture Referral RequestDC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

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 patient-originated data that is either provided or entered by a 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.

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.

Capture Patient Data Derived from Eligibility, Formulary and Benefit Documentation for Standalone Electronic Prescribing

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4.7 C

DC.1.1.4 F Produce a Summary R X DC.1.1.5 F Produce a Summary Record of Care

DC.1.1.4 S.2.2.1. The system SHALL present sum 71 DC.1.1.5

DC.1.1.4 2. The system SHOULD include at l72 DC.1.1.5 C

DC.1.1.4 3. The system SHOULD conform to 73 DC.1.1.5



DC.1.1.5 F Present Ad Hoc Views X DC.1.1.6

DC.1.1.5 S.1.8;1. The system SHALL provide the a76 DC.1.1.6

DC.1.1.5 2. The system SHOULD provide the77 DC.1.1.6




DC.1.2 F Manage Patient Histor X DC.1.2 F Manage Patient History

DC.1.2 S.2.2.1. The system SHALL provide the a81 DC.1.2 C

DC.1.2 2. The system SHOULD provide the82 DC.1.2 C

DC.1.2 C

DC.1.2 3. The system MAY provide the ab83 DC.1.2

DC.1.2 4. The system SHALL capture the 84 DC.1.2 C

DC.1.2 5. The system SHOULD capture the85 DC.1.2 C

DC.1.2 C

DC.1.2 6. The system SHOULD conform to86 DC.1.2

DC.1.2 7. The system SHALL conform to f 87 DC.1.2

DC.1.2 C

DC.1.2 C

DC.1.2 C

DC.1.2 C

DC.1.2 C

DC.1.2 C

DC.1.3 H Preferences, DirectiveDescription: In the Preferences, Directives, Consen X DC.1.3 H Preferences, Directives, Consents and Authorizat


DC.1.3 2. The system SHALL conform to f 89 DC.1.3

DC.1.3 C

DC.1.3.1 F Manage Patient and Fa X DC.1.3.1 F Manage Patient and Family Preferences

DC.1.3.1 DC.1.31. The system SHALL provide the a90 DC.1.3.1 C


DC.1.3.1 3. The system SHOULD conform to 92 DC.1.3.1 C

DC.1.3.1 C

DC.1.3.1 C

DC.1.3.2 F Manage Patient Advanc X DC.1.3.2 F Manage Patient Advance Directives

DC.1.3.2 C




DC.1.3.2 4. The system SHOULD conform to96 DC.1.3.2 C



DC.1.3.2 7. The system SHALL time and da 99 DC.1.3.2



DC.1.3.2 C

DC.1.3.3 F Manage Consents and X DC.1.3.3 F Manage Consents and Authorizations

DC.1.3.3 DC.1.11. The system SHALL provide the 102 DC.1.3.3 C

DC.1.3.3 2. The system SHALL provide the 103 DC.1.3.3 C


DC.1.3.3 C

DC.1.3.3 C


DC.1.3.3 C

Statement: Present a summarized review of a patient's episodic and/or 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. Create service reports at the completion of an episode of care such as, but not limited to, discharge summaries and public health reports, without additional input from clinicians.

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, depending on need. Jurisdictional laws and organizational policies that prohibit certain users from accessing certain patient information must be supported.

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, clinicians involved in procedures or in past consultations, 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.

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. NOTE This function is focused on the capture and maintenance of facts on patient/family preferences. For issues related to death and dying see DC.1.3.2

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.

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.

DC.1.3.3 5. The system MAY provide the ab106 DC.1.3.3 C

DC.1.3.3 6. The system MAY display the auth107 DC.1.3.3 C




DC.1.3.3 10. The system SHOULD provide th111 DC.1.3.3 C

DC.1.4 H Summary Lists Description: Summary lists are used to present suc X DC.1.4 H Patient Information Lists

DC.1.4 S.2.2.1. The system SHOULD conform to112 DC.1.4

DC.1.4 2. The system SHALL conform to f113 DC.1.4

DC.1.4.1 F Manage Allergy, Intole X DC.1.4.1 F Manage Allergy, Intolerance and Adverse Reactio


DC.1.4.1 2. The system SHOULD provide the 115 DC.1.4.1 C








DC.1.4.1 10. The system MAY present aller123 DC.1.4.1 C



DC.1.4.1 13. They system SHALL provide th126 DC.1.4.1 C


DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.1 C

DC.1.4.2 F Manage Medication Li X DC.1.4.2 F Manage Medication List

DC.1.4.2 S.2.2.1. The system SHALL provide the a128 DC.1.4.2 C

DC.1.4.2 2. The system SHALL display and r129 DC.1.4.2

DC.1.4.2 C





DC.1.4.2 7. The system SHALL present the 134 DC.1.4.2

DC.1.4.2 8. The system SHOULD present the135 DC.1.4.2 C

DC.1.4.2 9. The system SHALL present the 136 DC.1.4.2

DC.1.4.2 10. The system SHALL provide the137 DC.1.4.2 C



DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

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.

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.

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.2 C

DC.1.4.3 F Manage Problem List X DC.1.4.3 F Manage Problem List

DC.1.4.3 DC.1.71. The system SHALL capture, disp140 DC.1.4.3 C

DC.1.4.3 2. The system SHALL capture, disp141 DC.1.4.3 C







DC.1.4.3 10. The system MAY provide the a149 DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.3 C

DC.1.4.4 F Manage Strengths List

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 C

DC.1.4.4 F Manage Immunization X DC.1.4.5 F Manage Immunization List

DC.1.4.4 DC.1.81. The system SHALL capture, dis 150 DC.1.4.5 C

DC.1.4.4 2. The system SHALL record as di 151 DC.1.4.5 C

DC.1.4.5 C

DC.1.4.4 3. The system SHOULD prepare a r152 DC.1.4.5 C

DC.1.4.5 C

DC.1.4.6 F Manage Medical Equipment, Prosthetic/Orthotic,

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.4.6 C

DC.1.5 F Manage Assessments X DC.1.5 F Manage Assessments

DC.1.5 DC.1.51. The system SHALL provide the 153 DC.1.5 C

DC.1.5 2. The system SHOULD provide the154 DC.1.5

DC.1.5 C






DC.1.5 8. The system MAY provide the abi160 DC.1.5 C

DC.1.5 9. The system SHOULD provide th161 DC.1.5 C

DC.1.5 C

Statement: Create and maintain patient- specific problem lists.Description: A problem list may include, but is not limited to Chronic conditions, diagnoses, or symptoms, functional limitations, visit or stay-specific conditions, diagnoses, or symptoms. 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.

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.

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.

DC.1.5 10. The system SHOULD conform 162 DC.1.5

DC.1.5 11. The system SHALL conform to 163 DC.1.5

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.5 C

DC.1.6 H Care Plans, Treatment Plans, Guidelines, and Protocols 164 DC.1.6 H Care Plans, Treatment Plans, Guidelines, and Pro

DC.1.6.1 F Present Guidelines and X DC.1.6.1 F Present Guidelines and Protocols for Planning Ca




DC.1.6.1 4. IF decision support prompts a 168 DC.1.6.1 C

DC.1.6.1 5. The system SHALL conform to f169 DC.1.6.1 C


DC.1.6.2 F Manage Patient-Specif X DC.1.6.2 F Manage Patient-Specific Care and Treatment Pla


DC.1.6.2 2. The system SHALL conform to DC172 DC.1.6.2 C










DC.1.6.2 12. The system SHALL conform to 182 DC.1.6.2

DC.1.6.2 13. The system SHOULD provide in? DC.1.6.2 C

DC.1.6.2 14. The system MAY provide the a ? DC.1.6.2 C

DC.1.6.2 C

DC.1.6.2 C

DC.1.7 H Orders and Referrals Management X DC.1.7 H Orders and Referrals Management


DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

DC.1.7 C

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.

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, including alerts. 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.1.7 C

DC.1.7 C

DC.1.7.1 F Manage Medication O X DC.1.7.1 F Manage Medication Orders


DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 2. The system SHALL capture user185 DC.1.7.1 C


DC.1.7.1 4. The system SHALL provide a li 187 DC.1.7.1 C



DC.1.7.1 7. The system MAY make common co190 DC.1.7.1 C

DC.1.7.1 8. The system MAY provide the abi191 DC.1.7.1 C

DC.1.7.1 9. The system MAY make available192 DC.1.7.1 C


DC.1.7.1 11. The system MAY provide a list194 DC.1.7.1 C


DC.1.7.1 13. The system MAY conform to fun196 DC.1.7.1 C



DC.1.7.1 C


DC.1.7.1 17. The system SHOULD conform t200 DC.1.7.1 C


DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 19. The system SHOULD conform 202 DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

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

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.1 C

DC.1.7.2 H Non-Medication Orders and Referrals Management 203 DC.1.7.2 H Non-Medication Orders and Referrals Managem

DC.1.7.2.1 F Manage Non-Medicatio X DC.1.7.2.1 F Manage Non-Medication Patient Care Orders

DC.1.7.2.1 DC.1.41. The system SHALL provide the 204 DC.1.7.2.1 C


DC.1.7.2.1 3. The system SHALL track the st 206 DC.1.7.2.1 C

DC.1.7.2.1 4. The system SHOULD provide the 207 DC.1.7.2.1 C



DC.1.7.2.1 7. The system SHALL conform to 210 DC.1.7.2.1 C

DC.1.7.2.1 C

DC.1.7.2.2 F Manage Orders for Dia X DC.1.7.2.2 F Manage Orders for Diagnostic Tests



DC.1.7.2.2 C



DC.1.7.2.2 5. The system SHALL communicate 215 DC.1.7.2.2 C

DC.1.7.2.2 6. The system SHOULD communicat216 DC.1.7.2.2 C


DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.2 C

DC.1.7.2.3 F Manage Orders for Blo X DC.1.7.2.3 F Manage Orders for Blood Products and Other Bio

DC.1.7.2.3 DC.2.41. The system SHALL provide the 218 DC.1.7.2.3

DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.3 C


DC.1.7.2.3 3. The system SHOULD conform to 220 DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.3 C

DC.1.7.2.4 F Manage Orders for Ref X DC.1.7.2.4 F Manage Orders for Referral




DC.1.7.2.4 4. The system SHALL present capt224 DC.1.7.2.4 C

DC.1.7.2.4 C

DC.1.7.2.4 C

DC.1.7.2.4 C


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, to ambulate a patient, for medical supplies, durable medical equipment, home IV, and diet or therapy orders.

Statement: Enable the origination, documentation, and tracking of orders for diagnostic tests.Description: Orders for diagnostic tests (e.g. diagnostic radiology, laboratory) 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).

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.

Statement: Enable the origination, documentation and tracking of referrals between care providers or healthcare 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. 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.7.2.4 6. The system SHOULD provide dia226 DC.1.7.2.4 C

DC.1.7.2.4 7. The system MAY provide order 227 DC.1.7.2.4 C


DC.1.7.2.4 9. The system MAY provide guideli? DC.1.7.2.4 C

DC.1.7.2.4 C

DC.1.7.3 F Manage Order Sets X DC.1.7.3 F Manage Order Sets

DC.1.7.3 C

DC.1.7.3 C



DC.1.7.3 C




DC.1.7.3 C

DC.1.7.3 C

DC.1.7.3 C

DC.1.7.3 C

DC.1.7.3 C

DC.1.8 H Documentation of Care, Measurements and Results X DC.1.8 H Documentation of Care, Measurements and Resu


DC.1.8.1 F Manage Medication Ad X DC.1.8.1 F Manage Medication Administration

DC.1.8.1 DC.1.11. The system SHALL present the 235 DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 2. The system SHALL display the t236 DC.1.8.1 C

DC.1.8.1 3. The system SHOULD display inst237 DC.1.8.1 C

DC.1.8.1 4. The system MAY notify the cli 238 DC.1.8.1 C

DC.1.8.1 C




DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 8. The system SHALL securely rela242 DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.1 C

DC.1.8.2 F X DC.1.8.2 F Manage Immunization Administration


DC.1.8.2 2. The system SHOULD provide th244 DC.1.8.2

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.

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.

Manage Immunization AdministrationStatement: 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.8.2 C

DC.1.8.2 3. The system SHALL perform chec245 DC.1.8.2



DC.1.8.2 6. The system SHALL record as d 248 DC.1.8.2




DC.1.8.2 10. The system SHALL conform to 252 DC.1.8.2 C

DC.1.8.2 11. The system SHOULD transmit 253 DC.1.8.2 C

DC.1.8.2 12. The system SHOULD receive i 254 DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.2 C

DC.1.8.3 F Manage Results X DC.1.8.3 F Manage Results

DC.1.8.3 C




DC.1.8.3 4. The system SHOULD indicate n258 DC.1.8.3 C

DC.1.8.3 5. The system SHOULD provide the a259 DC.1.8.3

DC.1.8.3 6. The system SHOULD display num260 DC.1.8.3 C


DC.1.8.3 8. The system SHOULD notify rele262 DC.1.8.3 C



DC.1.8.3 11. The system MAY route results 265 DC.1.8.3 C

DC.1.8.3 C


DC.1.8.3 C


DC.1.8.3 14. The system SHOULD trigger de268 DC.1.8.3

DC.1.8.3 15. IF the system contains the el 269 DC.1.8.3 C


DC.1.8.3 17. The system MAY display a lin 271 DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.3 C

DC.1.8.4 F Manage Patient Clini X DC.1.8.4 F Manage Patient Clinical Measurements

DC.1.8.4 IN.2.51. IF required by the scope pract 272 DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 2. IF required by the scope of p 273 DC.1.8.4 C

DC.1.8.4 3. The system SHOULD capture oth274 DC.1.8.4

DC.1.8.4 4. The system SHOULD compute an275 DC.1.8.4 C

DC.1.8.4 5. The system MAY provide normal276 DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

Statement: Present, annotate, and route current and historical test results to appropriate providers or patients for review. Provide the ability to filter and compare results.Description: Results of tests are presented in an easily accessible manner to the appropriate providers. Flow sheets, graphs, or other tools allow care providers to view or uncover trends in test data over time. In addition to making results viewable, it is often necessary to send results to appropriate providers using electronic messaging systems, pagers, or other mechanisms. Documentation of notification is accommodated. Results may also be routed to patients electronically or by letter.

Statement: Capture and manage patient clinical measures, such as vital signs, as discrete patient data.Description: Within the context of an episode of care, 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.

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.4 C

DC.1.8.5 F Manage Clinical Docu X DC.1.8.5 F Manage Clinical Documents and Notes

DC.1.8.5 IN.2.21. The system SHALL provide the 277 DC.1.8.5 C


DC.1.8.5 3. The system MAY present docume279 DC.1.8.5 C



DC.1.8.5 C





DC.1.8.5 10. The system SHALL present c 286 DC.1.8.5


DC.1.8.5 12. The system SHOULD provide 288 DC.1.8.5 C

DC.1.8.5 13. The system MAY provide the ab288a DC.1.8.5

DC.1.8.5 C

DC.1.8.5 14. The system MAY provide the a288b DC.1.8.5 C

DC.1.8.5 15. The system MAY provide the abi288c DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5 C

DC.1.8.5.1 F Acknowledge/ Amend Other Provider Documenta

DC.1.8.5.1 C

DC.1.8.5.1 C

DC.1.8.5.1 C

DC.1.8.5.1 C

DC.1.8.6 F Manage Documentation X DC.1.8.6 F Manage Documentation of Clinician Response to

DC.1.8.6 S.3.7.1. The system SHALL provide the 289 DC.1.8.6 C



DC.1.8.6 C

DC.1.9 F Generate and Record Pa X DC.1.9 F Generate, Record and Distribute Patient-Specific

DC.1.9 DC.2.21. The system SHALL provide the a292 DC.1.9 C

DC.1.9 2. The system SHALL provide the a293 DC.1.9 C

DC.1.9 C





DC.1.9 C

DC.1.9 C

DC.1.9 C

DC.1.9 C

DC.1.9 C

DC.1.9 C

DC.1.9 C

DC.1.9 C

DC.1.10 F Manage Recommendations for Future Care

DC.1.10 C

DC.1.10 C

DC.1.10 C

DC.1.10 C

DC.1.10 C

DC.1.10 C

DC.2 H Clinical Decision Support X DC.2 H Clinical Decision Support

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. To facilitate the management and documentation on how providers are responding to incoming data on orders and results, there may also be some free text or formal record on the providers’ responsibility and/or standard choices for disposition, such as Reviewed and Filed, Recall Patient, or Future Follow Up. The system may also provide support for documenting the clinician’s differential diagnosis process.

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.

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 1. The system SHALL conform to f298 DC.2



DC.2 4. IF the system is used to ente 301 DC.2


DC.2 6. IF the system exchanges outsi 303 DC.2

DC.2 7. IF the system is used to enter 304 DC.2


DC.2 9. The system SHOULD conform to306 DC.2

DC.2 10. IF the system is used to extr 307 DC.2

DC.2 11. IF the system stores unstruc 308 DC.2

DC.2 12. IF the system stores structu 309 DC.2





DC.2 17. IF the system exchanges dat 314 DC.2





DC.2 C

DC.2.1 H Manage Health Information to Provide Decision Support X DC.2.1 H Manage Health Information to Provide Decision


DC.2.1 2. The system SHALL conform to fu320 DC.2.1


DC.2.1 4. The system SHOULD conform to 322 DC.2.1

DC.2.1 C

DC.2.1.1 F Support for Standard X DC.2.1.1 F Support for Standard Assessments





DC.2.1.1 5. The system SHOULD provide pr327 DC.2.1.1 C




DC.2.1.1 9. The system MAY track and retai330a DC.2.1.1 C

DC.2.1.1 10. The system MAY provide the ab330b DC.2.1.1 C

DC.2.1.2 F Support for Patient C X DC.2.1.2 F Support for Patient Context- Driven Assessments








DC.2.1.2 C

DC.2.1.2 C

DC.2.1.2 C

DC.2.1.2 C

DC.2.1.2 C

DC.2.1.3 F Support for Identifica X DC.2.1.3 F Support for Identification of Potential Problems

DC.2.1.3 DC.1.41. The system SHALL conform to f338 DC.2.1.3 C




DC.2.1.3 5. The system SHOULD prompt th342 DC.2.1.3 C

DC.2.1.3 C

DC.2.1.3 C

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 2 (Adult Onset) Diabetes diabetic review, fall and 70+, and rectal bleeding. Also, support for standard assessment may include the ability to record and store the value for the answers to specific questions in standardized assessment tools or questionnaires.

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 who has abdominal pain.

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.2.1.3 C

DC.2.1.3 6. The system SHOULD prompt the 343 DC.2.1.3 C




DC.2.1.3 C

DC.2.1.3 C

DC.2.1.3 C

DC.2.1.4 F Support for Patient an X DC.2.1.4 F Support for Patient and Family Preferences

DC.2.1.4 DC.1.11. The system SHALL conform to 347 DC.2.1.4 C

DC.2.1.4 2. The system SHALL provide for 348 DC.2.1.4 C



DC.2.1.4 5. The system SHOULD prompt the 351 DC.2.1.4 C




DC.2.1.5 F Support Triage Categorization

DC.2.1.5 C

DC.2.1.5 C

DC.2.1.5 C

DC.2.1.5 C

DC.2.1.5 C

DC.2.1.6 F Support Waiting Room Management

DC.2.1.6 C

DC.2.1.6 C

DC.2.1.6 C

DC.2.2 H Care and Treatment Plans, GuideliDC.1.2 355 DC.2.2 H Care and Treatment Plans, Guidelines and Protoc

DC.2.2 DC.1. 1. The system SHALL conform to fu355 DC.2.2


DC.2.2 C

DC.2.2.1 H Support for Condition Based Care and Treatment Plans, Guidelines, Prot 357 DC.2.2.1 H Support for Condition Based Care and Treatment



DC.2.2.1.1 F Support for Standard C DC 1.6.1; DC.2.5.1 359 DC.2.2.1.1 F Support for Standard Care Plans, Guidelines, Pro

DC.2.2.1.1 DC 1.61. The system SHALL conform to f359 DC.2.2.1.1 C

DC.2.2.1.1 2. The system MAY provide the abi360 DC.2.2.1.1 C


DC.2.2.1.1 4. The system SHOULD identify, tr362 DC.2.2.1.1 C

DC.2.2.1.1 C

DC.2.2.1.1 5. The system SHALL conform to D363 DC.2.2.1.1 C


DC.2.2.1.1 C

DC.2.2.1.2 F Support for Context-Se DC 1.3.1; DC 1.4; DC 1.5; DC 1.6; DC.1.6365 DC.2.2.1.2 F Support for Context-Sensitive Care Plans, Guideli

DC.2.2.1.2 DC 1.31. The system SHALL provide the a365 DC.2.2.1.2 C

DC.2.2.1.2 2. The system MAY provide the ab366 DC.2.2.1.2 C

DC.2.2.1.2 3. The system MAY present care 367 DC.2.2.1.2 C

DC.2.2.1.2 4. The system MAY provide the ab368 DC.2.2.1.2 C

DC.2.2.1.2 5. The system SHOULD identify, tr369 DC.2.2.1.2 C

DC.2.2.1.2 6. The system SHALL conform to f370 DC.2.2.1.2 C


DC.2.2.1.2 8. The system SHALL conform to f372 DC.2.2.1.2 C

DC.2.2.1.2 C

DC.2.2.1.2 C

DC.2.2.2 F Support Consistent He DC.2.2.1.2; DC.3.2.3; S.2.2.2; IN.2.2; IN 373 DC.2.2.2 F Support Consistent Healthcare Management of Pa

DC.2.2.2 DC.2.21. The system SHALL conform to D373 DC.2.2.2 C





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.

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.

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.

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. The system may also Include ability to identify groups of patients based on clinical observations or lab test results and assist in initiating a follow-up or recall for selected patients.


DC.2.2.2 7. The system MAY provide the abi378a DC.2.2.2 C

DC.2.2.2 8. The system MAY provide the abi378b DC.2.2.2 C

DC.2.2.2 C

DC.2.2.2 C

DC.2.2.3 F Support for Research P S.1.1; S.1.5; S.2.2.2; S.3.3.1; IN.1.1; IN. 379 DC.2.2.3 F Support for Research Protocols Relative to Indivi

DC.2.2.3 S.1.1;1. The system SHALL provide the a379 DC.2.2.3 C







DC.2.2.3 8. IF research protocols require 386 DC.2.2.3

DC.2.2.3 C

DC.2.2.3 C

DC.2.2.3 C

DC.2.2.4 F Support Self-Care 387 DC.2.2.4 F Support Self-Care

DC.2.2.4 C


DC.2.2.4 2. The system SHALL provide the 388 DC.2.2.4





DC.2.2.5 F Capture Guidelines and Standards from External

DC.2.2.5 C

DC.2.3 H Medication and Immunization Management 393 DC.2.3 H Medication and Immunization Management

DC.2.3 1. The system SHALL conform to fu393 DC.2.3


DC.2.3 3. The system SHOULD conform to 395 DC.2.3

DC.2.3.1 H Support for Medication and Immunization Ordering 396 DC.2.3.1 H Support for Medication and Immunization Order

DC.2.3.1.1 F Support for Drug Inter S.3; IN.2.4; IN.6 397 DC.2.3.1.1 F Support for Drug Interaction Checking

DC.2.3.1.1 S.3; I 1. The system SHALL check for an397 DC.2.3.1.1 C

DC.2.3.1.1 2. The system SHALL relate medica398 DC.2.3.1.1 C

DC.2.3.1.1 3. The system SHOULD provide th399 DC.2.3.1.1




DC.2.3.1.1 7. The system SHOULD conform to403 DC.2.3.1.1 C

DC.2.3.1.1 8. The system MAY check for inte404 DC.2.3.1.1 C

DC.2.3.1.1 9. The system SHOULD check for dr405 DC.2.3.1.1 C

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.

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, etcetera; and guidance or reminders about medications.Information to support self-care may be appropriately provided to: 1. the patient

DC.1.1.4DC.1.11.1S.3.7.1S.3.7.2

Statement: Identify drug interaction warnings at the 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.

Functional Model R2.0 Tracability Matrix

Statement / Description

See

Also CC# Conformance Criteria

Mod

el R

ow #

Chan

ge C

ode

R1.1

Del

eted Rev#1/#2/#3 Move Links

Statement: Overarching criteria that a0 1 N

1 The system SHALL conform to function IN.1.1 2 M Moved From: DC.1 cc#1; DC.2 cc#1; DC.3 cc#12 The system SHALL conform to function IN.1.2 3 M Moved From: DC.1 cc#2; DC.2 cc#2; DC.3 cc#23 The system SHALL conform to function IN.1.3 4 M Moved From: DC.1 cc#3; DC.2 cc#3; DC.3 cc#34 The system SHALL conform to function IN.1 5 M Moved From: DC.1.1.2 cc#8; DC.1.1.3 cc#1; DC.1.1.4 cc#4; DC.1.1.5 cc#4; D5 IF the system is used to capture, update or 6 M Moved From: DC.1 cc#4; DC.2 cc#4; DC.3.1.2 cc#2; DC.3.2.1 cc#66 IF the system transmits data to or receives 7 M Moved From: DC.1 cc#5; DC.2 cc#5; DC.3 cc#47 IF the system transmits data to or receive 8 M Moved From: DC.1 cc#6; DC.2 cc#6; DC.3 cc#58 IF the system is used to capture or update 9 M Moved From: DC.1 cc#7; DC.2 cc#7; DC.3 cc#69 The system SHALL conform to function IN.1.9 10 M Moved From: DC.1 cc#8; DC.2.1 cc#2; DC.2.2 cc#1; DC.2.3 cc#1; DC.2.4 cc#

10 The system SHALL conform to function IN.2.1 11 M Moved From: DC.1 cc#9; DC.2 cc#8; DC.3 cc#811 The system SHALL conform to function IN.2. 12 M Moved From: DC.1.1.1 cc#12; DC.1.1.2 cc#9; DC.1.1.3 cc#2; DC.1.1.4 cc#5; 12 The system SHOULD conform to function IN. 13 M Moved From: DC.1 cc#10; DC.2 cc#9; DC.3 cc#1013 IF the system is used to extract data for de 14 M Moved From: DC.1 cc#11; DC.2 cc#10; DC.3 cc#1114 IF the system stores unstructured data, TH 15 M Moved From: DC.1 cc#12; DC.2 cc#11; DC.3 cc#1215 IF the system stores structured data, THEN 16 M Moved From: DC.1 cc#13; DC.2 cc#12; DC.3 cc#1316 The system SHOULD conform to function IN.3 17 M Moved From: DC.1 cc#14; DC.2.1 cc#4; DC.2.2.1 cc#2; DC.2.2.2 cc#6; DC.2.217 IF the system manages data for which stand 18 M Moved From: DC.1 cc#15; DC.2 cc#13; DC.3 cc#1418 IF the system manages data for which stand 19 M Moved From: DC.1 cc#16; DC.2 cc#14; DC.3 cc#1519 IF terminology mapping is implemented wit 20 M Moved From: DC.1 cc#17; DC.2 cc#15; DC.3 cc#1620 IF the system receives or transmits data fo 21 M Moved From: DC.1 cc#18; DC.2 cc#16; DC.3 cc#1721 IF the system receives and transmits data 22 M Moved From: DC.1 cc#19; DC.2 cc#17; DC.3 cc#1822 The system SHOULD conform to function IN.5 23 M Moved From: DC.1 cc#20; DC.2 cc#18; DC.3 cc#1923 IF the system receives and transmits data w 24 M Moved From: DC.1 cc#21; DC.2 cc#19; DC.3 cc#2024 The system SHOULD conform to function IN 25 M Moved From: DC.1 cc#22; DC.2 cc#20; DC.3 cc#2125 The system SHOULD conform to function I 26 M Moved From: DC.1 cc#23; DC.2 cc#21; DC.3 cc#22

0 27 C S

0 28 M Moved to: DC.0























1 24. The system SHALL conform to function S 51 NC

0 52 C S

0 53 C N S

1 1. The system SHALL manage a single logical 54 C C

2 2. The system SHALL provide the ability to 55 C C

3 The system SHALL provide the ability to tag 56 N


5 4. The system SHALL link key identifier info 58 C C

Change Type

(N/S/C)

R1.1-R2.0 Moved To: Moved From:

R1.1-R2.0 Moved Link

Statement: Care management functions are those directly used by providers as they deliver patient care, and create or update an electronic health record.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.

Statement: For those functions related to record management that allow the capture and maintanace of clinical and administrative data.Description: For those functions related to data capture, data should 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. Statement: Manage a single logical 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 maintain 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.

P3

Helen: Still have issue with Moved rows that have also been changed.

U3

Enter the Function ID and cc# if moved from or to. R1.1-R2.0 moves only.

V3

Enter "D" if R1.1 row deleted in R2.0

W3

Enter tracibility to FP and review moves. NOT R1.1-R2.0 moves

6 5. The system SHALL provide the ability to un 59 C C

7 The system SHOULD provide the ability to ide 60 N

8 6. The system SHALL provide the ability, thr 61 C C

9 7. The system SHALL provide the ability, wh 62 C C

10 8. The system SHALL provide the ability, wh 63 C C

11 9. The system SHALL provide the ability to re 64 C C

12 10.The system SHALL provide the ability to t 65 C C

13 11. The system MAY provide the ability to au 66 C C


14 The system SHOULD provide anonymized pati 68 N

15 The system SHALL provide the ability to li 69 N

16 The system SHALL provide the ability to re 70 N

0 71 N

1 The system SHALL provide the ability to man 72 N


3 The system SHALL provide the ability to mana 74 N

4 The system SHOULD provide the ability to man 75 N

0 76 C S




3 80 D D

3 81 D D


5 7. The system SHALL render a set of patient 83 C C



6 10. The system MAY store the demographic in 86 NC

7 The system SHALL capture complete date/tim 87 N

8 The system MAY provide the ability to enter 88 N

9 The system SHALL provide the ability to capt 89 N

10 The system SHOULD provide the ability to m 90 N




14 The system SHOULD provide the ability to ca 94 N

15 The system SHOULD provide the ability for 95 N

16 The system SHOULD be able to determine and 96 N

17 The system MAY analyze and render potential 97 N

18 The system SHALL provide the ability to ma 98 N


0 100 N



3 The system SHALL capture or determine regis 103 N

4 The system SHALL provide the ability to har 104 N

Statement: Manage patient encounter 0 105 N


2 The system SHOULD provide the ability to re 107 N Moved From: DC.1.11; DC.1.6

3 The system SHOULD provide the ability to cap 108 N Moved From: DC.1.11; DC.1.6

4 The system SHOULD provide the ability to cap 109 N Moved From: DC.1.11; DC.1.6

5 The system MAY provide the ability to mana 110 N Moved From DC.1.7.2.1; DC.1.7

0 111 C S



0 114 C N S


1 116 M Moved to: DC.1.1.4.2

1 117 D D


3 The system SHOULD provide the ability to c 119 N

4 5. The system SHOULD provide the ability t 120 C C


5 122 M Moved to: DC.1.1.4.3

5 123 M Moved to: DC.1.1.4.3

Statement: Maintain additional identifiers for research purposes.Description: This includes identifying the study, site, patient subject of study, and investigator. Identifiers are captured, maintained and rendered.

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, and sex 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 as specified in the NCHS/NAPHSIS ES. 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. The system will provide the ability to store multiple patient names in each name field, including any accent marks or special characters. For example: (1) first name: “Mary Jane", middle name: ” Sue", last name: “Smith"; (2) last name: “Smith-Jones".

Statement: Receive an account number from the hospital ADT system without complete supporting demographics, in order to facilitate patient care before registration is complete. Description: The registration process, including the verification of full demographics data, insurance, contact information, etc. is frequently time consuming. To facilitate patient care in emergency situations, the system must be interoperable with other hospital systems in a time critical manner. In order to support interoperability with other hospital systems, for such tasks as medication or other order entry the system should be able to, in a time critical manner, receive an account number from the hospital ADT system, or alternatively, generate an account number in concert with the hospital system.

Statement: Capture and manage a variety of information from multiple 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.

Statement: Incorporate clinical documentation (computable and scanned) from external sources.Description: Mechanisms for incorporating external clinical documentation (including identification of source) are available. Documentation incorporated through these mechanisms is presented alongside locally captured documentation and notes wherever appropriate. This covers all types of documents received by the provider 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.

DC.3.2.5DC.1.8.3

5 124 M Moved to: DC.1.1.4.2

6 10. The system SHOULD provide the ability 125 C C

6 126 M Moved to: DC.1.1.4.2

7 The system SHALL provide the ability to un 127 N

8 The system SHOULD provide the ability to li 128 N

9 The system SHOULD accept both structured a 129 N

10 The system MAY provide the ability to proces 130 N Moved From S.1.x

0 131 N

1 The system SHALL provide the ability to capu 132 M Moved From: DC.1.1.3.1 cc#2

2 The system SHOULD provide the ability to rec 133 M Moved From: DC.1.1.3.1 cc#9

3 The system SHOULD provide the ability to re 134 M Moved From: DC.1.1.3.1 cc#11

4 The system SHOULD provide the ability to cap 135 N Moved From DC.1.1.3.1

5 The system SHOULD provide the ability to ca 136 N Moved From DC.1.1.3.1

6 The system MAY provide the ability to captu 137 N Moved From DC.1.1.3.6

Statement: Provide the ability to ca 0 138 N

1 The system SHOULD provide the ability to li 139 N Moved From DC.1.1.3.1

2 The system MAY provide the ability to capu 140 N Moved From DC.1.1.3.1

3 The system MAY provide the ability to electr 141 N Moved From DC.1.1.3.1

0 142 N




0 146 C S

1 1. The system SHALL provide the ability to c 147 C C

2 2. IF the system provides the ability for th 148 C C

3 3. The system SHALL capture the source of cl 149 C C

4 4. The system SHALL provide the ability to r 150 C C

5 5. The system SHALL provide the ability fo 151 C C

6 6. The system SHALL provide the ability for 152 C C

7 The system SHALL ensure provider sourced d 153 N

8 The system MAY provide the ability to captu 154 N

9 The system SHALL accept both structured an 155 N

10 The system MAY provide the ability for the 156 N

11 The system SHOULD provide the ability to s 157 N Moved From S.1.x

12 The system MAY provide the ability to rece 158 N Moved From S.1.x

0 159 C S




3 163 D D

4 The system SHOULD provide the ability to a 164 N

4 165 M Moved to: S.3

0 166 N



0 169 N


2 The system SHALL capture and render the So 171 N Moved From DC.1.1.3.9

3 The system SHOULD provide the ability to imp 172 N

4The system SHALL conform to function DC.1.

173 N

5The system SHALL conform to function DC.1.1

174 N

6 The system SHALL conform to function DC.1.1 175 N

7 The system SHALL provide the ability to ana 176 N

8 IF the system provides the ability to electro 177 N

9 IF the system provides the ability to electr 178 N




13 The system MAY conform to function S.3.3.2 ( 182 N





Statement: Incorporate discrete clinical data from external sources and support communication/presentation of data captured from non-medical devices and entities.Description: Mechanisms for incorporating external clinical data (including identification of source) are available and communication with non-medical devices and entities is supported as appropriate to the care setting such as an office or a patient's home. Data incorporated through these mechanisms is presented alongside locally captured documentation and notes wherever appropriate. This covers all types of data received by the provider 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.

Statement: Incorporate clinical images from external sources.Description: Mechanisms for incorporating external clinical images (including identification of source) are available. Data incorporated through these mechanisms is presented alongside locally captured documentation and notes wherever appropriate. 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.

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.

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.

Statement: Capture and explicitly label patient data derived from eligibility, formulary and benefit information; and link the data source with that data. Description: Sources of eligibility, formulary and benefit may provide data for entry into the standalone electronic prescribing or be given a mechanism for entering this data directly. The data must be explicitly labeled as derived from eligibility, formulary and benefit information.

The management of information on patients who are inbound to the care setting is an important component of information management. This documentation most often begins with a telephone call made from referring provider to receiving care setting.Often, this information gets haphazardly recordcare setting. Data must be easily accessible, central, retrievable, updatable, transportable and reusable. Clinical data from provider to provider is essential to quality coordinatcare setting care for patients referrcare setting to the care setting. Knowlcare settingge of patients who are expectcare setting to arrive helps both care setting and administrative staff plan resource use in real time.




21 IF the referral includes a transfer of care 190 N

22 The system SHOULD provide the ability to el 191 N Moved From DC.1.1.3.9

23 The system SHOULD provide the ability to ca 192 N Moved From DC.1.1.3.9

24 The system MAY provide the ability for provi 193 M Moved From: DC.1.8.5 cc#13

0 194 NC

0 195 D D





1 200 M Moved to: S.2.2.3

1 201 M Moved to: IN.1.4

1 202 M Moved to: S.2.2.3

1 203 M Moved to: S.2.2.3



DC.1.0 206 C S


2 2. The system SHOULD provide the ability to 208 C C


3 210 M Moved to: DC.1.2 cc #6

4 4. The system SHALL capture the complaint, 211 NC

5 5. The system SHOULD capture the reason fo 212 NC




7 The systems MAY provide the ability to captur 216 M Moved From: DC.1.2 cc#3


9 The system SHALL maintain and render doc 218 N

10 The system SHOULD provide the ability to pre 219 N


12 The system MAY provide the ability to capture 221 N

0 222 C S



1 The system SHOULD conform to function DC.2 225 M Moved From: DC.1.3.1 cc#3; DC.1.3.2 cc#9

0 226 NC

1 1. The system SHALL provide the ability to ma 227 C C

2 2. The system SHALL provide the ability to ma 228 C C

3 3. The system SHOULD incorporate patient a 229 C C


5 The system SHOULD provide the ability to in 231 N

0 232 NC


2 1. The system SHALL render an indication th 234 C C



5 4. The system SHOULD conform to function D 237 C C



7 240 D D

7 241 D D

7 242 M Moved to: DC.1.3

8 The system SHOULD provide the ability to 243 N

0 244 NC




4 The system SHOULD conform to function DC.1 248 N


6 4. The system MAY provide the ability to vi 250 C C

7 The system MAY provide the ability to enter 251 N

Statement: Present a summarized review of a patient's episodic and/or 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. Create service reports at the completion of an episode of care such as, but not limited to, discharge summaries and public health reports, without additional input from clinicians.

Statement: Capture and maintain medical, procedural/surgical, mental health, substance use, 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, clinicians involved in procedures or in past consultations, 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.

Statement: Capture and manage patient preferences, advance 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).

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. NOTE This function is focused on the capture and maintenance of facts on patient/family preferences. For issues related to death and dying see DC.1.3.2

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.

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.

8 5. The system MAY provide the ability to r 252 C C

9 6. The system MAY render the consents and au253 C C



12 9. The system SHALL provide the ability to ca 256 C C


0 258 C N S

S.2.2.0 259 M Moved to: DC.0


0 261 C S

DC.2.3 1 1. The system SHALL provide the ability to m 262 C C







8 8. The system SHALL provide the ability to t 269 C C



11 11. The system MAY provide the ability to re 272 C C


13 13. They system SHALL provide the ability t 274 C C



16 The system SHALL provide the ability to cap 277 N


18 The system SHALL provide the ability to ca 279 N



21 The system SHALL tag and render an indicator 282 N

22 The system SHALL provide the ability to rend 283 N

23 The system SHOULD provide the ability to lin 284 N

24 The system SHALL conform to function DC.2.3 285 N Moved From DC.2.3.1.1

25 The system SHOULD capture information that 286 M Moved From: DC.2.3.1.1 cc#3

0 287 NC


1 289 D D


3 291 C C


5 5. The system SHALL provide the ability to c 293 NC

6 6. The system SHALL provide the ability to 294 NC

6 295 D D


7 297 D D



10 12. The system MAY provide the ability to ca 300 C C


12 The system SHALL provide the ability to rec 302 N



15 The system SHOULD provide the ability to r 305 N

16 The system SHOULD provide the ability to ma 306 N


18 The system SHOULD provide the ability to up 308 N

19 The system SHALL conform to function DC.2.3 309 N




23 The system SHOULD provide the ability to re 313 N


25 The system SHALL provide the ability to ren 315 N


Statement: Capture and manage lists used to present summary or detailed information on patient health.Description: Summary lists are used to present succinct “snapshots” of critical health information such as allergy, medication, problem, and immunization lists.

Statement: Manage 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.

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.6DC.1.7.1

3. The system SHALL provide the ability to manage, as discrete data, medication information including presriber, ordering date, dose, route, and SIG (description of the prescription, such as the quantity) according to scope of practice, organizational policy and/or jurisdictional law.

27 The system MAY capture Investigational Pr 317 N Moved From DC.1.4.2.2

28 The system SHALL capture, maintain and pr 318 N Moved From DC.2.3.1.3

29 The system SHALL present pre-admission med 319 N Moved From DC.2.3.1.3

30 The system SHALL provide the ability to cap 320 M Moved From: DC.2.3.2 cc#4

0 321 C S

DC.1.7 1 1. The system SHALL provide the ability to m 322 C C

2 323 C C




6 6. The system SHOULD conform to function IN 327 C C

7 7. The system MAY provide the ability to up 328 C C


9 10. The system MAY provide the ability to l 330 C C

10 The system SHALL provide the ability to lin 331 N





15 The system MAY provide the ability to manag 336 N

16 337 N

17 The system MAY provide the ability to manag 338 N Moved From: DC.1.11

18 The system MAY provide the ability to manage 339 N Moved From: DC.1.11

0 340 N



3 The system SHOULD conform to function IN.2. 343 N

4 The system MAY provide the ability to Updat 344 N

5 The system MAY provide the ability to link 345 N





10 The system SHOULD provide the ability to l 350 N

0 351 C S

DC.1. 1 1. The system SHALL provide the ability to 352 C C





0 357 N







7 The system SHOULD conform to function IN.2. 364 N

8 The system MAY provide the ability to update 365 N

9 366 N

10 The system SHOULD provide the ability to ren 367 N

11 The system MAY provide the ability to capt 368 N


0 370 NC


1 372 D D







8 8. The system MAY provide the ability to rec 379 C C



Statement: Create and maintain patient- specific problem lists.Description: A problem list may include, but is not limited to Chronic conditions, diagnoses, or symptoms, functional limitations, visit or stay-specific conditions, diagnoses, or symptoms. 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.

2. The system SHALL capture and render a history of all problems associated with a patient.

The system SHOULD provide the ability to link actions taken and outcomes with a problem.

Statement: Create and maintain patient- specific strenths lists. Description: A strenth or ' positive factor that may impact patient care' may be recorded as part of the EHR to support the development of care plans and treatment options. Examples of strenths include family support, financial support or health insurance levels, good overall health (e.g. athlete) etc.

Statement: Create and maintain patient-specific and health care delivery organization administered 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.

Statement: Create and maintain a patient-specific list of medical equipment, medical prosthetic, orthotic, and/or implantable devices.Description: Details of medical equipment, orthotic/prosthetic and/or devices are captured as discrete data elements including information such as device type, date issued, date implanted or manufactured, device model number, device serial/lot number, manufacturer, supplier, involved extremity, anatomical location, date of battery change, and other data elements which many be required to correctly identify and track the equipment/device. The list may link to external sources, such as the FDA, so that the provider may be alerted if the medical device is recalled. The entire equipment. prosthetic, orthotic, and/or implantable device list is viewable.

The system SHALL provide the ability to render a list of deleted inactivated/discontinued specialized medical equipment or prosthetic, orthotic, or implantable devices and reason for deletion.

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.




12 The system MAY provide the ability to analyz 385 N


14 The system SHOULD conform to function DC. 387 N

15 The system SHOULD conform to function DC. 388 N



18 The system MAY determine to render a propos 391 N

19 The systsem SHOULD provide the ability to 392 N

Statement: Treatment plans, guideline0 393 C S

0 394 NC




4 4. IF decision support prompts are used to 398 NC

5 5. IF the system supports context sensitive 399 C C


0 401 C S


2 2. The system SHALL conform to function DC.1 403 C C






DC.1. 8 8. The system SHALL provide the ability to t 409 C C

9 9. The system SHOULD conform to function DC 410 C C




12 13. The system SHOULD conform to function 414 C C

13 14. The system MAY conform to function DC. 415 C C

14 416 N

15 The system SHALL provide the ability to cap 417 N Moved From: S.3.7.1

0 418 C S


1 The system SHALL manage role-based, conte 420 N


3 The system SHALL provide the ability to rend 422 N Moved From: DC.2






9 The system SHOULD provide the ability to tag 428 N


11 The system SHALL render the patient name, i 430 N Moved From DC.1.7.2.1

12 The system SHOULD provide the ability to cap 431 N Moved From DC.1.7.2.1

13 The system SHOULD provide the ability to c 432 N Moved From DC.1.7.2.1

14 The system MAY provide the ability to render 433 N Moved From DC.1.7.2.1

15 The system SHOULD provide the ability to t 434 N Moved From DC.1.7.2.1

16 The system SHOULD provide the ability to 435 N Moved From DC.1.7.2.1

17 The system SHOULD provide the ability t 436 N Moved From DC.1.7.2.1

18 The system MAY provide the ability to m 437 N Moved From DC.1.7.2.1


20 The system MAY provide the ability to ca 439 N Moved From DC.1.7.2.1

21 440 N Moved From DC.1.7.2.1

22 The system SHOULD render alternate medi441 N


24 The system SHOULD provide the ability to443 N Moved From DC.1.7.2.2


26 The system MAY provide the ability to li 445 N Moved From DC.1.7.3

27 446 N Moved From: DC.1.7.1.1

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.

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, including alerts. Information such as Order sets for care plans may arrive from an external institution and need to be approved locally before being inserted into the care plan. 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.

The system MAY provide the ability to determine and render a care plan review schedule or conference schedule.

Statement: Provide the capability to capture, process, transmit, diplay and maintain clinical orders and referrals.Description: The provision of clinical care usually includes the need to order from a variety of treatments such as medications and non-medication therapies (e.g. physical therapy, special diet, immunizations, non-allopathic regimens). Additionally, patients are often referred to other health care providers for more specialized diagnostic workup and/or treatment. An effective EHR-S must include supporting these processes to include managing the documentation associated with them.

The system SHOULD provide the ability to capture and render an indicator of an explicit route for the administration of specific medications during the ordering process.

The system SHOULD provide the ability to capture the provider's order-cancellation request for medication/non-medication orders or referrals.

28 The system SHOULD provide the ability t 447 N Moved From: DC.1.7.1.1

29 The system SHOULD provide the ability 448 N Moved From: DC.1.7.1.1

0 449 C S


2 The system MAY provide the ability to trans 451 N

3 The system SHALL determine and render a not 452 N

4 The system SHALL provide the ability to cap 453 M Moved From: DC.2.3.1.2 cc#3

5 The system SHALL provide the ability to capt 454 M Moved From: DC.2.3.1.2 cc#4

6 2.The system SHALL capture user's identity an 455 C C

7 3. The system SHALL conform to function DC. 456 NC


9 5. The system SHALL provide the ability to m 458 NC

10 6. The system SHALL conform to function DC. 459 C C

11 7. The system SHOULD present common conten460 C C

12 8. The system MAY provide the ability for th 461 C C

13 462 C C


15 11. The system MAY render a list of frequent 464 C C

16 12.The system MAY provide the ability to ca 465 C C

17 13.The system SHOULD conform to function S.466 C C



20 The system SHOULD provide the ability to ca 469 N Moved From: DC.1.8.1

21 16. The system SHALL conform to function DC 470 C C



24 The system SHOULD provide the ability to de 473 M Moved From: DC.2.3.1.2 cc#9

25 The system MAY provide the ability to dete 474 N

26 The system MAY provide the ability to dete 475 N

27 19. The system SHOULD conform to functio 476 NC


29 The system SHOULD provide the ability t 478 N


31 The system SHALL provide the ability to 480 N

32 The system SHOULD support specific formu481 N

33 The system MAY provide the ability to re 482 N

DC 1. 34 The system SHALL provide the ability to 483 N

35 484 N


37 The system MAY provide the ability to 486 N

38 IF configuration parameters of the pat 487 N


40 The system MAY provide the ability to m 489 N


42 The system SHOULD provide the ability 491 N



45 The system SHALL provide end-users the ab 494 N

46 The system SHOULD provide the ability to ex 495 N

47 496 N


S.3.2 49 The system MAY provide the ability to recei 498 N

50 The system MAY provide the ability to render 499 N

51 The system MAY provide the ability to rende 500 N

52 The system MAY provide the ability to pr 501 N

53 The system MAY provide the ability to c 502 N

54 The system SHALL provide the ability to m 503 N





59 The system MAY provide the ability to r 508 N



62 511 N

Statement: Create prescriptions or other medication orders with detail adequate for correct filling and administration. Provide information regarding compliance of medication orders with formularies. Provide drug utilization review functionality including alerts regarding drug interactions and allergies. 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. 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. In addition, the system should present the clinician with clinical decision support functionality (such as the presentation of allergies, drug-drug- interactions) during the medication ordering process.

DC.1.4.3DC 1.6, DC1.7, DC1.8, DC1.9

9. The system SHOULD render a list of common patient medication administration instruction and capture the ordering clinician's selection.

The system SHALL provide the ability to manage orders that contain discrete medication components to create combination drugs or compounds (e.g., Butalbital compound).

The system SHOULD provide the ability to capture medication order details including dose, route, frequency and comments as free text.

The system SHOULD provide the ability to transmit a request for a patient's prescription drug insurance eligibility verification.

63 The system SHOULD provide the ability to d 512 N

64 The system SHOULD provide the ability to ca 513 N Moved From: DC.2.3.1.2

65 The system SHOULD provide the ability to r 514 N Moved From: DC.3.2

66 The system SHOULD provide the ability to cap 515 N Moved From: DC.1.4.2


68 The system SHALL provide the ability to ent 517 N Moved From: DC.2.3.1.2

69 The system SHALL provide the ability to 518 N Moved From: DC.2.3.1.2

70 The system SHALL provide the ability to 519 N Moved From: DC.2.3.1.2

71 The system SHALL provide the ability to ca 520 N Moved From: DC.2.3.1.2

72 The system SHALL provide the ability to mana 521 N Moved From: DC.1.4.2


74 IF a prescribed medication or standing 523 N Moved From: DC.1.7.1.1


76 The system SHOULD provide the ability to 525 N Moved From: DC.1.7.1.1

77 The system SHOULD provide the ability to 526 N Moved From: DC.1.7.1.1

0 527 C S

0 528 C S

DC.1.4 1 1. The system SHALL provide the ability to 529 C C


3 3. The system SHALL provide the ability to m 531 C C

4 4. The system SHOULD provide the ability to c 532 C C

5 5. The system SHOULD provide the ability to r 533 C C



8 The system SHOULD provide the ability t 536 N Moved From: DC.1.7.4

0 537 C S

DC.2.4 1 1. The system SHALL provide the ability to 538 C C



4 3. The system SHALL provide the ability to m 541 C C


6 5. The system SHALL provide the ability to tr 543 C C



9 The system MAY provide the ability to transmi 546 N

10 The system SHOULD provide the ability to cap 547 N

11 IF subsequent orders are being captured, TH 548 N

12 The system SHOULD capture and render comple549 N Moved From DC.1.1.3.1




16 The system SHALL provide the ability to 553 N Moved From DC.1.7.2.3

17 The system SHALL provide the ability to ren 554 N Moved From DC.1.7.2.3

0 555 NC

DC.2.0 556 D D

1 The system SHOULD provide the ability to d 557 N





6 The system SHALL conform to function DC.3. 562 N

7 The system SHALL conform to function DC.3. 563 N


9 3. The system SHOULD conform to function S. 565 NC

10 The system MAY provide the ability to manage 566 N

11 The system SHOULD provide the ability to man 567 N Moved From: DC.1.8.7

0 568 C S

DC.1.9 1 569 C C






7 The system SHALL provide the ability to de 575 N

8 5. The system MAY provide the ability to cap 576 C C

Statement: Provide the capability to capture, process, transmit, diplay and maintain referrals and consultations.Description: Patients are often referred to other health care providers for more specialized diagnostic workup and/or treatment. The ability to support documentation and processing (routing to specialist and receiving specialist's report for inclusion in the pateint's EHR) of referrals can provide efficiencies in health care. Further, in conjunction with digital imaging and an EHR, telereferral/teleconsultation can siginificantly improve access to care, particularly in underserved populations.Statement: Enable the origination, documentation, capture, transmision, tracking and maintenance of non-medication patient care orders.Description: Non-medication orders that request actions or items are captured and tracked including new, renewal and discontinue orders. Examples include orders to transfer a patient between units, to ambulate a patient, for medical supplies, durable medical equipment, home IV, 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.

Statement: Enable the origination, documentation, transmission, tracking and maintainance of orders for diagnostic tests.Description: Orders for diagnostic tests (e.g. diagnostic radiology, laboratory) 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).

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.

Statement: Enable the origination, documentation and tracking of referrals between care providers or healthcare 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.

1. The system SHALL provide the ability to manage outbound referral(s), whether internal or external to the organization.


10 578 C C



13 The system SHOULD provide the ability to tr 581 N Moved From: DC.1.6.2

0 582 C S


2 The system SHALL provide the ability t 584 N

DC.2. 3 1. The system SHOULD provide the ability to 585 C C



6 3.The system SHOULD provide the ability to 588 C C



9 591 N



12 594 N


0 596 C S


0 598 C S





5 3. The system SHALL render ordered administr 603 C C





10 608 C C




14 8. The system SHOULD provide the ability to s 612 C C

15 The system SHALL provide the ability to ide 613 N

16 The system SHOULD support integrated point 614 N



19 The system SHALL render an alert, when rend 617 N





24 The system SHOULD provide the ability to an 622 N







31 The system SHOULD provide the ability to n 629 N


33 The system SHALL provide the ability to al 631 N



36 The system MAY generate documentation of m634 M Moved From: DC.2.3.2 cc#6

37 The system SHOULD provide the ability to c 635 N Moved From: DC.2.3.2

38 The system SHALL provide the ability to capt 636 N Moved From: DC.2.3.2

39 The system SHALL provide the ability to cap 637 N Moved From: DC.2.3.2

0 638 C S


1 640 M Moved to: DC.2.3.1.2

7. The system SHOULD provide the ability to determine the contents of a referral by rendering order sets for review by the provider.

Statement: Provide order sets based on provider input or system prompt.Description: Order sets, which may include medication and non-medication orders (e.g. diet, activities, nursing care), 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.

The system SHALL provide the ability to capture and integrate in an order set, various types of orders (e.g., medications, laboratory tests, imaging studies, procedures and referrals).

The system MAY provide the ability to integrate multiple order set templates, customizing and storing it as a new order set template according to scope of practice, organizational policy and/or jurisdictional law.

Statement: Capture and maintain clinical information concerned with episodes of providing health care, to include objective (e.g. blood pressure) and subjective (e.g. pain level score) measurements, results (e.g. laboratory values, radiology reports) and records of medication, immunization and other forms of treatment.Description: The core component of any EHR System is the capability to capture, store, maintain, update, and present clinical care documentation at each episode of care. The list of different information categories covered within this function is quite large and includes, but is not limited to:

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.

7. The system SHALL provide the ability to capture, maintain and render medication administration details as discrete data, including:(1) the medication name, strength and dose;

Statement: Capture and maintain discrete data concerning immunizations given to a patient including

2 The system SHOULD provide the ability to cap 641 N Moved From: DC.1.7.1

2 642 M Moved to: DC.2.3.2

3 643 C C


4 645 D D




8 10. The system SHALL conform to function D 649 C C

9 11. The system SHOULD transmit required im 650 NC

10 12. The system SHOULD receive immunization 651 NC

11 The system SHOULD capture and render immun652 N

12 The system SHALL conform to function DC.1 653 N

13 The system SHOULD harmonize Immunization hi654 N

14 The system SHOULD provide the ability to u 655 N


16 The system SHALL provide the ability to d 657 N



19 The system SHOULD provide the ability to ca 660 N Moved From: DC.2.3.2

0 661 C S






5 667 D D




9 9. The system SHOULD provide the ability fo 671 NC


11 11. The system MAY provide the ability to tr 673 C C

12 The system MAY provide the ability to trans 674 N

13 12. The system MAY provide the ability to c 675 C C

14 The system MAY provide the ability to recei 676 N

15 13. The system MAY provide the ability to ren 677 C C

15 678 M Moved to: DC.2.4.3

16 15. The system SHALL link results to the ele 679 C C



19 The system SHALL provide the ability to impo 682 N

20 The system SHALL provide the ability to impo 683 N



23 The system SHOULD provide the ability to lin 686 N

24 The system MAY provide the ability to link 687 N

25 The system SHALL provide the ability annota 688 N


27 The system SHALL provide the ability to link 690 N

28 The system SHALL provide the ability to tag a 691 N

29 The system MAY provide the ability to manage 692 N Moved From: DC.1.11

0 693 NC


2 The system SHOULD provide the ability to cap 695 M Moved From: DC.1.8.4 cc#3

DC.3. 3 The system SHOULD provide the ability to imp 696 N


4 698 M Moved to: DC.1.8.4 cc #2





9 The system SHOULD provide the abilit to pr 703 N


11 The system SHOULD determine and render th 705 N

4. The system SHALL provide the ability to capture, maintain and render immunization administration details as discrete data, including:(1) the immunization name/type, strength and dose;

Statement: Present, annotate, and route current and historical test results to appropriate providers or patients for

Statement: Capture and manage patient clinical measures, such as vital signs, as discrete patient data.Description: Within the context of an episode of care, 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.




15 The system MAY provide the ability to deter 709 N

0 710 C S



3 3. The system MAY present documentation tem713 NC



6 The system SHOULD provide ability to facili 716 N Moved From DC.1.7.2.1


8 7. The system SHALL provide the ability to u 718 NC

9 8. The system SHALL provide the ability to t 719 C C


10 721 D D



12 724 M Moved to: DC.1.1.4.7

13 The system MAY provide the ability to mainta 725 N

14 14. The system MAY provide the ability for p 726 C C

15 15. The system MAY provide the ability to cap 727 C C



18 The system SHOULD tag specific missing ele 730 N


20 The system MAY provide the ability to captur 732 N


22 The system SHOULD provide the ability tag th 734 N Moved From: S.2.2.1

23 The system SHOULD provide the ability to tag 735 N Moved From: DC.1.10

24 The system SHOULD provide the ability to cap 736 N Moved From: DC.1.10

0 737 N

1 The system SHOULD provide a the ability to 738 N

2 The system SHOULD provide a the ability to 739 N

3 The system SHOULD provide a the ability for 740 N

4 The system SHOULD provide the ability for 741 N

0 742 C S





0 747 C N S



3 The system SHOULD provide the ability to tr 750 N









11 The system MAY pprovide the ability to manag 759 N



14 The systems MAY provide the ability to rend 762 N

0 763 N Moved From DC.1.12

1 The system SHALL provide the ability to ca 764 N Moved From DC.1.12

2 The system SHALL provide the ability to ma 765 N Moved From DC.1.12

3 The system SHALL provide the ability to re 766 N Moved From DC.1.12

4 The system SHALL provide the ability to ca 767 N Moved From DC.1.12

5 The system SHOULD provide the ability to 768 N Moved From DC.1.12

6 The system SHOULD provide the ability to a 769 N Moved From DC.1.12

0 770 C S

Statement: Create, addend ,amend, correct, authenticate, maintain, present 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, graphic, 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. To facilitate the management and documentation on how providers are responding to incoming data on orders and results, there may also be some free text or formal record on the providers’ responsibility and/or standard choices for disposition, such as Reviewed and Filed, Recall Patient, or Future Follow Up. The system may also provide support for documenting the clinician’s differential diagnosis process.

Statement: Review other caregiver notes and indicate or amend as permitted by legal or regulatory restrictions. Description: Scan/review notes from physicians, nurses, technicians and other members (e.g. RT, PT) of the health care team. Annotate for disparities, make additions/amendments and import when desired.

Statement: Capture the decision support prompts and manage provider actions to accept or override decision support prompts.Description: Provider actions in response to prompts offered from decision support are captured. Management of these actions be accomplished at the patient level or aggregated for patient population, research protocol, or organizational trending.

Statement: Generate and record patient-specific instructions related to pre- and post-procedural and post-treatment/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. In an outpatient scenario, similar instructions for post-diagnosis and/or post-treatment needs may also be generated and recorded (e.g. exercise instructions for low back pain, wound or burn care).

Statement: Document and support the management of the disposition process for a patient.Description: Patient encounters can end in many different states and support for these requires that the EHR accommodate, at a minimum, the following possible dispositions:

Statement: Provide Clinical Decision Support to link "health observations with health knowledge to influence health choices by clinicians for improved health care" (Dr. Robert Hayward, Centre for Health Excellence).Description: Clinical Decision Support (CDS) assists clinicians at the point of care by helping them analyze patient data (history, signs, symptoms, ancillary data, etc.) to arrive at likely diagnoses,optimal treatments and care options. CDS does not replace the clinician's judgement but assists them by utilizing both the clinican's understanding and a rich database of knowledge-/evidence-based best practices to suggest likely choices or options for the clinician to consider.






















1 The system SHOULD capture and maintain doc 792 N

0 793 C S





1 The system SHALL provide the ability for eac 798 N

0 799 NC


2 2. The system SHALL provide the ability to a 801 C C



5 5. The system SHOULD provide prompts base 804 NC



7 807 D D

8 9. The system MAY audit the name, version, 808 C C

9 10. The system MAY provide the ability to li 809 C C

0 810 C S






6 6. The system SHALL conform to function 816 NC

7 7. The system SHOULD conform to function 817 NC


9 The system MAY provide ability to render aler 819 N Moved From DC.1.8.5

10 The system SHOULD providethe ability to ma 820 N Moved From DC.1.8.5

11 The system SHOULD provide integrated Diagn 821 N Moved From DC.1.8.5

12 The system SHOULD provide integrated Dispo 822 N Moved From DC.1.8.5

0 823 C S

1 1. The system SHALL conform to function DC 824 NC




5 5. The system SHOULD present the provider 828 C C

6 The system SHOULD provide the ability to tr 829 N

7 830 N

Statement: Manage health information to provide decision support for assessments, problem idenfication, trend analysis and patient/family preferences. Description: Clinical Decision Support systems include a dynamic medical knowledge base. Combined with particular medical information about a patient and rules derived from the experts and evidence-based medicine, and implemented through medical logic modules based on a language such as Arden syntax. It could be based on Expert systems or artificial neural networks or both (connectionist expert systems).

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 2 (Adult Onset) Diabetes diabetic review, fall and 70+, and rectal bleeding. Also, support for standard assessment may include the ability to record and store the value for the answers to specific questions in standardized assessment tools or questionnaires.

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, or appendicitis in a geriatric patient who has abdominal pain.

Statement: Identify conditions of clinical interest, 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 condition- or 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).

Additionally, providing the health care giver with a prompt, notification or alert for specific concerns that are identified is a cornerstone of Clinical Decision Support.

The system SHOULD present lab data in numerical (tabular or spreadsheet) form over time to enable trend analysis.

8 831 N

9 6. The system SHOULD present the provider 832 C C


11 8. The system MAY provide the ability to in 834 NC

12 9. The system SHOULD conform to function DC 835 C C

13 836 N

14 837 N

15 838 N

0 839 C S


2 2. The system SHALL provide for the ability 841 C C

3 3. The system SHALL provide the ability to u 842 C C


5 5. The system SHOULD prompt the provider f 844 NC

6 6. The system MAY provide the ability to re 845 C C



0 848 N

1 The system SHALL provide a means to create 849 N

2 The system SHALL capture, maintain and rend 850 N

3 The system MAY provide the ability to captur 851 N

4 852 N

5 853 N

0 854 N

1 The system SHALL present a list of triaged p 855 N

2 856 N

3 857 N

0 858 C S



1 The system SHOULD capture research protoco 861 N

0 862 C S



0 865 C S




4 4. The system SHOULD determine variances fr 869 C C

5 The system SHOULD determine variances from 870 N




0 874 C S



3 3. The system SHOULD present care process 877 C C


5 5. The system SHOULD identify, track and pro 879 C C

6 6. The system SHALL conform to function DC. 880 NC




10 The system SHOULD provide the ability to man 884 N

0 885 C S


2 2. The system SHALL provide the ability to i 887 NC

3 3. The system SHOULD provide the ability t 888 NC

4 4. The system SHOULD provide the ability t 889 NC

5 5. The system SHALL conform to function S. 890 NC

The system SHOULD present lab data in graphical form over time to enable trend analysis.

The system MAY provide the ability to tag, maintain and render an individual patient's conditions of clinical interest.

The system MAY provide the ability to create a configurable notification for tagged conditions of clinical interest.

The system MAY provide the ability to present to the provider tagged conditions of clinical interest.

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 individual or set of treatment plans. Preferences may also be used to adjust patient information including labeling and medication instructions (e.g. for language and print size).

Statement: Provide support for prioritizing patients based upon acuity, wait time, and practitioner load.Description: The triage process not only collects of data on arriving patients, but the categorization and prioritization of patients who are unable to be seen immediately. It is a dynamic process where patient priorities change over time. Unless a care team has unlimited resources, some patients will invariably need to wait. An EHR-S should support the management of these patients by displaying them and supporting decisions by the providers who are caring for them.

The system SHOULD present evidence-based triage algorithms during the triage process.

The system MAY capture and update a triage category in response to specific prompts for patient associated data or data already captured in the record (e.g., arrival by ambulance, age, vital signs).

Statement: Provide support for prioritizing patients based upon acuity, wait time, and practitioner load.Description: Triage is a fundamental process in healthcare - not the collection of data on arriving patients, but the categorization and prioritization of patients who are unable to be seen immediately. It is a dynamic process where patient priorities change over time. Unless a provider has unlimited resources, some patients will invariably need to wait. An EHR-S should support the management of these patients by displaying them and supporting decisions by the providers who are caring for them.

The system SHOULD provide the ability to present triaged patients filtered and sorted simultaneously by multiple criteria, such as provider, ward, triage acuity rating and wait time.

The system MAY render an alert when a parameter has been exceeded, such as the number of patients waiting, or the length of wait time.

Statement: Provide standard and context-specific guidelines and support for care and treatment plans and protocols.Description: A core capability of Clinical Decision Support is that of providing guidelines, plans and protocols to clinicians. These documents or artifacts can be specific for populations, medical conditions or individual patients. In the case of individual patients, such information may be the product of analysis that takes into account a specific patient's medical scenario (demographics, medications, severity of conidition, etc.) and more generalized treatment or care plan/protocols.

Statement: Provide guidelines and support for care and treatment plans and protocols based on specific medical conditions.Description: An EHR-S with Clinical Decision Support capability will provide care and treatment plans, guidelines and protocols that are based on specific medical conditions. These may also be coupled with an individual pateint's clinical information to more precisely tailor the guideline, plan or protocol to the pateint's particular sitauation.

Statement: Support the use of appropriate standard care plans, guidelines, protocols and/or clinical pathways for the management of specific conditions.Description: Before they can be accessed upon request (e.g., in DC 1.6.1), standard care plans, guidelines, protocols, and clinical pathways 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, protocols and clinical pathways can be identified and reported.

Statement: Identify and present the appropriate care plans, guidelines,protocols and/or clinical pathways 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.

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. The system may also Include ability to identify groups of patients based on clinical observations or lab test results and assist in initiating a follow-up or recall for selected patients.The system may also provide the ability to create and render configurable reports for specific populations/or topics of interest, (e.g. chronic conditions, suicidal risk, or post truamatic stress syndrome, traumatic brain injury, etc.)


6 7. The system MAY provide the ability to det 892 C C

7 8. The system SHALL capture, maintain, and 893 C C

8 The system MAY capture, maintain, and rende 894 N

9 The system MAY determine, based on protocol895 N

0 896 NC

1 1. The system SHALL provide the ability to p 897 NC


3 3. The system SHOULD conform to function S. 899 NC

4 4. The system SHOULD provide the ability to 900 NC


6 6. The system SHALL conform to function S. 902 NC



7 The system SHOULD capture, maintain, and r 905 N

8 The system SHOULD determine patients eligib 906 N

9 The system SHOULD present information notify907 N

0 908 NC

1 The system SHALL provide the ability to capt 909 M Moved From: DC.2.2.4 cc#2

2 2. The system SHALL provide the ability to d 910 C C

2 911 M Moved to: DC.2.2.4 cc #1





0 916 N Moved From: DC.1.1.3.6

1 The system SHOULD import standards based g 917 N Moved From: DC.1.1.3.6

0 918 C S




0 922 C S

0 923 C S

1 1. The system SHALL determine and present 924 C C

2 2. The system SHALL determine the presence 925 C C

2 926 M Moved to: DC.1.4.1





7 8. The system MAY determine the presence 931 C C

8 9. The system SHOULD determine the presence932 C C

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.

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, etcetera; and guidance or reminders about medications.Information to support self-care may be appropriately provided to: 1. the patient

Statement: Capture clinically acceptable practice guidance from a variety of “trusted” external sources.Statement: Support the ordering and administration of medications and immunizations. Description: Immunications and Medications are cornerstones of allopathic medical prevention efforts and treatment. An EHR-S must be able to support the process for providers to order and administer these, to include providing mechnisms to assure the the right patient is being given the right dose for the right condition at the right time. In addition to providers who order and administer immunizations and medications, pharamcies and immunization clinics/departments must be included as part of the "supply chain" and include similar quality assurance mechanisms to insure patient safety and effective prevention and treatment.

Statement: Alert providers to potential ordering errors (such as wrong patient, wrong drug, wrong dose, wrong route and wrong time).

Statement: Identify drug interaction warnings at the time of medication ordering.Description: The clinician is alerted to drug-drug, drug-allergy, and drug-food, drug-herbal, drug-dietary supplements 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.

Tracability Matrix

Chan

ge C

omm

ent Chang

Rev #3 - Done

Input from Overarching Criteria Rev #2 - Done

























Rev #3 - Done
























Rev #3 - Done

Rev #3 - Done

Issues after Rev #2

Issues after Rev #2

Rev #2 - Done

Rev #2 - Done

Term(s) corrected by Glossary T Rev #2 - Done

Comment from Glossary Team -'conform' (as in criteria stating "the system shall conform to function X.xx) is not part of the Action-Verb model

Schedule call with larger WGTerm(s) corrected by Glossary TeamSchedule call with larger WGTerm(s) corrected by Glossary Team

Z3

Use to indicate status of change (draft, final etc)


Input from Pharmacy (StandaloneRev #2 - Done


Rev #2 - Done

Rev #2 - Done


Issues after Rev #2

Rev #2 - Done

Rev #2 - Done

Input from EDIS R2 WG Rev #2 - Done

Input from Vital Records FP Rev #2 - Done

Rev #2 - Done

Input from Clinical Research FP ( Issues after Rev #2

Input from Clinical Research FP ( Rev #2 - Done




Proposed

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Input from Vital Records FP Issues after Rev #2


Rev #2 - Done



Rev #2 - Done

Issues after Rev #2

Input from CCHIT Emergency De Rev #2 - Done

Input from PHR-S FM Issues after Rev #2

Rev #2 - Done

Rev #2 - Done

Input from Public Health Requir Rev #2 - Done


Issues after Rev #2


Rev #2 - Done

Rev #2 - Done


NEW FUNCTION PER REVIEW #2 Rev #2 - Done

Input from Clinical Research FP ( Issues after Rev #2

Proposed

Proposed

Proposed

Proposed

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Input from LTC FP Rev #2 - Done

Rev #2 - Done


Input from CCHIT Ambulatory IFRRev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

*20110207 (MGJ): My take is that we need to insure thatthe concept of "mistakenly" or "in error"be kept in some form for this CC. The concern here is when medical data is incorrectly entered into, and thus attributed to/associated with, the wrong patient. I agree, however, that the intent ought to be regarding data that is inside the record.*Glossary Team is suggesting changing "mistakenly associated with a patient" to "stored in a patient record". The first seems to imply that data outside the record that is linked to the record, while the second only refers to information that is in the record itself.

Schedule call with larger WGTerm(s) corrected by Glossary Team*Term(s) corrected by Glossary Team*Optionality demoted per Behavioral Health and LTC profiles

*2011-02-07 (MGJ): List the potnetial inclusion of the verb "extract"", "searched" may need to be addded to the list of accepted verbs. Is there already a "model" or diagram that flowcharts the process for how medical data/information is retrieved and displayed. For example: User requests --> Record is "searched" --> data/information is "located" or "found" --> data/information "extracted" --> data/information" presented" or "displayed" or "rendered". Just my 2.1 cents worth ...*Input from Child Health FP

*Change to Statement - Input from Pharmacy (Standalone) FP*Change to Description - Input from Vital Records FP

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *2011-02-07 (MGJ): Ambivalent on this one. Modify is probably better.*DC.1.1 Review Team - Question about verb heirarchy and the use of "modify" as suggested by Ambulatory WG instead of the current "update".*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Input from CCHIT IFR Ambulatory criteria

*Input from Vital Records FP*Note: This item actually includes two separate requirements

*2011-02-07 (MGJ): Is there another verb inm the Glossary that could be used? I prefer capture and maintain vs. enter.*Input from CCHIT Child Health*Input from Child Health FP*Term(s) corrected by Glossary Team

*Input from Clinical Research FP*Function DC.1.1.2.1 (Manage Patient Demographics for Healthcare)*Input from EDIS FP*Function DC.1.1.2.3 (ED erge Registration)

*Input from EDIS FP*Function DC.1.1.2.2 (Quick Registration)

*Input from EDIS FP*Function DC.1.1.2.2 (Quick Registration)*Input from EDIS FP*Function DC.1.1.2.2 (Quick Registration)

*Input from EDIS R2 WG *Input from DC.1 Review #1 Team*Input from EDIS R2 WG *Input from DC.1 Review #1 Team*Input from EDIS R2 WG *Input from DC.1 Review #1 Team*Input from Canadian Blueprint 2015*Review #1 Team - Must define “eVisit” as a not-in-person event. This is part of the scheduling process. Must also check that criteria for an eVisit. Check S1.6.

*2/26 -Description needs to be revised based on focus on documents*Input from LTC FP

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Input from Behavioral Health FP*Input from CCHIT Ambulatory IFR*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Input from Behavioral Health FP*Term(s) corrected by Glossary Team

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done


Input from PHR-S FM Rev #2 - Done


Proposed

Issues after Rev #2

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Issues after Rev #2

Rev #2 - Done

Rev #2 - Done

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Issues after Rev #2

Input from DC.1.1 Review #2 Te Rev #2 - Done

Rev #2 - Done

Rev #2 - Done


Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done




Proposed

Proposed

Issues after Rev #2

Proposed

Proposed

Rev #2 - Done

Rev #2 - Done

Issues after Rev #2

Rev #2 - Done

*Input from e-Prescribing FP (DC.Issues after Rev #2

Input from e-Prescribing FP (DC.1Rev #2 - Done

*Input from e-Prescribing FP (DCRev #2 - Done

Input from AOFP Issues after Rev #2

Input from AOFP Rev #2 - Done

Input from EDIS FP (DC.1.2.1) Rev #2 - Done


Corrected by Publications


Input from Publications Corrected by Publications

Input from Publications Rev #2 - Done











*2011-02-07 (MGJ): Not sure what to do here. I see no differenced between Col. F and Col. M entries.*Source file noted "Added with Mod", but no modification was noted

*NEW - Input from Canadian Blueprint 2015*Review #1 Team - Move to DC.1.1.3.2; may be a duplicate

*Input from DC.1.1 Review #2 Team*Modify DC.1.1.3.1 cc #2 to state "The system SHALL provide the ability to caputre, store and render computable data (e.g. Lab results, telemetry, medication details).*Input from DC.1.1 Review #2 Team*Modify DC.1.1.3.1 cc #9 to state "The system SHOULD provide the ability to receive from an external source computable data (e.g. Lab results, telemetry, medication details). "*Input from DC.1.1 Review #2 Team*Modify DC.1.1.3.1 cc #11 to state "The system SHOULD provide the ability to receive from an external source standards-based structured, codified data."*Input from Clinical Research FP*DC.1.1 Review #2 Team - Move from DC.1.1.3.1 to new "External Data" function DC.1.1.4.2*Input from PHRS-FM*DC.1.1 Review #2 Team - Modify "The system SHOULD provide the ability to capture externally sourced clinical documentation as structured content including the original, updates and addenda." to state "The system SHOULD provide the ability to capture, store and render externally sourced structured clinical data documentation as structured data including the original, updates and addenda."*Input from EDIS R2 WG (see DC.1.1.3.6)*DC.1.1 Review #2 Team - Modify "The system MAY provide the ability to capture health-related data, manually and automatically, from non-medical devices (e.g., digital camera or sound recorder)." to state "The system MAY provide the ability to capture health-related data, manually and automatically, from non-medical devices (e.g., digital camera or sound recorder)."

*Input from EDIS FP*DC.1.1 Review #2 Team - Add new function (Capture Data from External Emergency Medical System)*Input from EDIS FP*DC.1.1 Review #2 Team - Modify "The system MAY provide the ability to import the EMS run sheet." to state "The system MAY provide the ability to capure the EMS run sheet." *Input from EDIS FP*DC.1.1 Review #2 Team - Move to new function (Capture Data from External Emergency Medical System)

*Input from DC.1.1 Review #2 Team*Modify DC.1.1.3.1 cc #7 to state "The system SHOULD provide the ability to receive from an external source clinical result images (such as radiologic images)."*Input from DC.1.1 Review #2 Team*Modify DC.1.1.3.1 cc #8 to state "The system SHOULD provide the ability to receive from an external source other forms of clinical results (such as wave files of EKG tracings or psychological assessment results)."

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Input from LTC FP*Should this be split into criteria as per DC.1.1.3.3 criteria 4.a. and 4.b.?*Input from co-Chair call 3-25-2011Input from Public Health Requirements

*NEW - Input from Canadian Blueprint 2015*Review #1 Team - Move to DC.1.1.3.2; may be a duplicate*NEW - Input from Canadian Blueprint 2015*Review #1 Team - Move to DC.1.1.3.2; may be a duplicate

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team 2010-02-07 (MGJ): I'm not convinced that this CC#4.a. differs from CC#3 immediately above. Would suggest deleting this and moving the following CC#4.b. up to be a new CC#6.*Input from LTC FP2010-02-07 (MGJ): See comment immediately above related to proposed CC#4.a. Would suggest deleting it as it is essentailly the same as CC#3 above it, and accept this particular CC#4.b as a new CC#6.*Input from LTC FP*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Input from AOFP*Input from Publications

*Input from AOFP*Input from Publications





Rev #2 - Done

Rev #2 - Done

Proposed

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Input from Behavioral Health FP Proposed

Rev #2 - Done



DC.1.2 Review #2 Team - move to bRev #2 - Done

Rev #2 - Done

Rev #2 - Done

Input from EDIS FP Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

DC.1.2 Review #2 Team - move to bRev #2 - Done


Issues after Rev #2

Issues after Rev #2


Rev #2 - Done

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done



Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done


Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done



Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

*Input from EDIS FP (DC.1.2.1)*Modify "The system SHOULD provide a means to track patients who are en-route to the care setting via the EMS system" to state "The system SHOULD provide the ability to electronically receive and render location data for patients who are en-route to the care setting (e.g. EMS system traking patient arrival to the Emergency Department)."*Input from EDIS FP (DC.1.2.1)*Modify "The system SHOULD allow users to reserve an care setting bcare setting and assign human resources, including registration and RN staff to incoming patients. " to state "The system SHOULD provide the ability to capure resource reservation information for referred patients (e.g. location, equipment and staff resources)."

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team 2011-02-07 (MGJ): The title reference given matches that a in recent versions of the proposed changes for DC.3.3.6, specifically, those advanced by the Pharmacy Standalone WG.

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Input from Publications*Input from LTC FP*Input from Publications*Input from LTC FP

*Input from EDIS FP*Term(s) accepted 2/7/2011 (MGJ)*Input from EDIS FP*Term(s) accepted 2/7/2011 (MGJ)

*Input from Vital Records FP (see DC.1.8.9)*Refer to DC.1.1.1 - revisions may be required.

*Input from LTC FP*Term(s) accepted 2/7/2011 (MGJ)*Input from LTC FP*Term(s) accepted 2/7/2011 (MGJ)*Glossary Team recommended that R1.1 criterion "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" be split into the two criteria listed as DC.1.3.1 cc#3 and DC.1.3.1 cc#4.*Term(s) accepted 2/7/2011 (MGJ)

*Glossary Team recommended revision of proposed criterion "The system shall provide the ability to indicate that advance directive(s) have been completed." *Term(s) accepted 2/7/2011 (MGJ)*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Input from Publications*Glossary Team recommended that R1.1 criterion "4. The system SHOULD 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" be split into the two criteria listed as DC.1.3.2 cc#4a and DC.1.3.1 cc#4b.*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Input from Publications*2011-02-07 (MGJ): Issue corrected; split suggested by GT accepted.*Input from Publications*2011-02-07 (MGJ): Issue corrected; split suggested by GT accepted.*2011-02-07 (MGJ): Issue corrected; split suggested by GT accepted.*Glossary Team recommended that R1.1 criterion "3. The system SHOULD conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and capture scanned paper consent and authorization documents." be split into the two criteria listed as DC.1.3.3 cc#3a and DC.1.3.1 cc#3b.*R1.1 criterion split*Input from ?*R1.1 criterion split*Input from ?

Rev #2 - Done



Issues after Rev #2

Rev #2 - Done

Input from Behavioral Health FP Rev #2 - Done

Review #1 Team - This is a headeRev #3 - Done



Input from Review #1 Team Proposed

Input from Review #1 Team Rev #2 - Done

Input from Review #1 Team Issues after Rev #2














Rev #2 - Done

Input from CCHIT Inpatient IFR Rev #2 - Done






Input from PHRS-FM Rev #2 - Done

Rev #2 - Done

Input from DC.2 Review #2 TeamProposed

Input from Review #1 Team



Rev #2 - Done




Review #1 Team - Discussion needeRev #2 - Done







Rev #2 - Done










Input from CCHIT Ambulatory, e-PRev #2 - Done




Input from CCHIT e-Prescribing I Rev #2 - Done


*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team *Term(s) accepted 2/7/2011 (MGJ)*Term(s) corrected by Glossary Team

*Input from CCHIT Inpatient IFR*Review Team comment - Helen notes this criterion should be in DC.1.7.1

*Input from CCHIT Ambulatory IFR*DC.2 Review #1 Team - move to DC.1.4.1

*Input from Child Health FP*Input from DC.1 Review #2 Team

*Input from PHRS-FM*Input from Review #1 Team

Rev #2 - Done
















Rev #2 - Done



Review #1 Team - Need to discusRev #2 - Done

Rev #2 - Done

Proposed

Proposed

Input from DC.1 Review #2 TeamRev #2 - Done






Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done







Input from LTC FP Proposed

























*Input from Clinical Research*DC.2 Review #1 Team - Move to DC.1.4.2

*Input from CCHIT Inpatient IFR*Input from DC.1 Review #2 Team

*Input from Clinical Research FP*Input from DC.1 Review #2 Team*Input from PHRS-FM*DC.1.11 Review #2 Team - delete function 1.11 (Manage patient's genetic information) and move criterion #1 to DC.1.8.3*Input from PHRS-FM*DC.1.11 Review #2 Team - delete function 1.11 (Manage patient's genetic information) and move criterion #1 to DC.1.8.3

*Input from CCHIT Inpatient IFR*Input from DC.1 Review #2 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #2 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #2 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #2 Team*Input from Clinical Research FP*Input from DC.1 Review #2 Team



Input from Pharmacy FP Rev #2 - Done
































Rev #2 - Done

Rev #2 - Done




Rev #2 - Done

Rev #2 - Done

Rev #2 - Done



*Input from CCHIT Ambulatory I Rev #2 - Done



Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

*Input from LTC FP*Review #1 Team - Question whether this needs to be made specific to the provider/provider or provider/patient or provider/family/patient or all of these? May also fit somewhere else in the model.*Input from CCHIT Ambulatory IFR*Input from Supportive Review #1 Team

*Input from CCHIT Inpatient IFR*Input from DC.1 Review #2 Team*Input from CCHIT Inpatient IFR (DC.2)*"relevant" need to be defined*Input from EDIS FP*Review #1 Team - This should be an 'overarching criteria in DC1.7 to cover DC.1.7.2.1, CC3, DC1.7.2.2 CC#3

*Input from Canadian Blueprint 2015*Input from Review #1 Team - This has been handled at the DC.1.7 level as an overarching criteria. Also Split this criterion into multiple criteria. Align with DC1.7.2.1, which talks to IN 1.6 and 1.7. Need a criterion that says update the order based on status update received from external system, where external system could be from an HIE or a regional repositiory. Add in workflow management or could be added to description of DC 3.1, Clinical Task Tracking. Local EHR must receive order status from external system. Must also update Referrals DC 2.4.4.2. to track status of outstanding referrals. Check DC1.7.2.4. Also could do this by adding Managing commuincation with external systems function. Subroutine tracking could be added in DC3.1. Must acknowledge in the Overview that a 2nd system is performing some complementary action outside of the 1st system. Reveiw DC 3.3.*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from CCHIT Ambulatory IFR*Input from DC.1 Review #1 Team*Input from CCHIT Ambulatory IFR*Input from DC.1 Review #1 Team*Input from CCHIT Ambulatory IFR*Input from DC.1 Review #1 Team*Input from CCHIT Inpatient IFR*Input from DC.1 Review #1 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team

Rev #2 - Done

Rev #2 - Done






Rev #2 - Done















Rev #2 - Done






Input from CCHIT Emergency DepRev #2 - Done












Input from CCHIT Inpatient IFR Issues after Rev #2

























*Input from e-Prescribing FP*Input from DC.1 Review #2 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team

*Input from DC.2 Review #2 Team*Input from Child Health FP

*Input from PHR-S FM*Input from DC.1 Review #1 Team -Is this duplicative of cc# 14 or cc#15 above?

Input from CCHIT Child Health Rev #2 - Done

Input - R1.1 Comment Considered Rev #2 - Done



Proposed

Proposed

Proposed

Input DC.2 Review #2 Team Proposed

Proposed

Proposed

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done


Rev #3 - Done








Rev #2 - Done






Input from Review #1 Team Issues after Rev #2






Input from CCHIT Inpatient IFR (DRev #2 - Done


Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #3 - Done











Input from Child Health FP Rev #2 - Done

Input from Child Health FP (DC.1.Rev #2 - Done










Input from Pharmacy (Standalone) FP*Input from DC.2 Review #2 Team*Input from Child Health FP*Input from DC.2 Review #2 Team*Input from Child Health FP*Input from DC.2 Review #2 Team

*Input from CCHIT Inpatient IFR*Input from Review #2 Team*Input from EDIS FP*Input from DC.1 Review #2 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team*Input from e-Prescribing FP*Input from DC.1 Review #2 Team

*Input from Review #1 Team*Sue - See column W for issues from Review #1 Team

*Input from e-Prescribing FP*Input from DC.1 Review #2 Team

*Input from CCHIT Ambulatory IFR*Input from DC.1 Review #2 Team*Input from CCHIT Ambulatory IFR*Input from DC.1 Review #2 Team*Input from CCHIT Ambulatory IFR*Input from DC.1 Review #2 Team*Input from CCHIT Emergency Department IFR*Input from DC.1 Review #2 Team*Input from CCHIT Emergency Department IFR*Input from DC.1 Review #2 TeamDC.1.7.2.3 Review #1 Team - No changeInput from Child Health to be considered (see column W)







Rev #2 - Done

Rev #2 - Done







Rev #2 - Done

Rev #2 - Done



Rev #2 - Done

Rev #3 - Done

Rev #2 - Done

Rev #3 - Done

Rev #2 - Done



Rev #2 - Done

Rev #2 - Done

Input from ??? Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done






Input from Oncology FP Issues after Rev #2




Input from CCHIT Child Health Issues after Rev #2













Rev #2 - Done

Issues after Rev #2


Proposed


Proposed

Proposed

Proposed

Rev #3 - Needs additional review

Rev #

Rev #2 - Done

*Input DC.1 Review #2 Team*Review #1 Team - Add new criteria as S.2.4.1*Input DC.1 Review #2 Team*Review #1 Team - Add new criteria as S.2.4.1

*Review #1 Team - Add new criteria as S.2.4.1*Sue - There is no function S.2.4.1. Please clarify intended placement.*Review #1 Team - Add new criteria as S.2.4.1*Sue - There is no function S.2.4.1. Please clarify intended placement.

*Review #1 Team - Add new criteria as S.2.4.1*Sue - There is no function S.2.4.1. Please clarify intended placement.

*Input from LTC FP*Input from Public Health Requirements*Input from Behavioral Health FP*Input from LTC FP

*Input from Behavioral Health FP*Input from LTC FP*Input from Behavioral Health FP*Input from LTC FP

*Input from Behavioral Health FP*Input from EDIS FP*Input from Behavioral Health FP*Input from LTC FP

Input from CCHIT Inpatient IFR-Don't think this is necessary Input from CCHIT Inpatient IFR:-don't know what this is for

Input from Pharmacy (Standalone) FP*Input from DC.2 Review #2 Team

*Input from DC.2 Review #2 Team*Input from CCHIT Inpatient IFR*Input from DC.2 Review #2 Team*Input from CCHIT Inpatient IFR*Input from DC.2 Review #2 Team*Input from CCHIT Inpatient IFR

Input from CCHIT Emergency DepProposed


Issues after Rev #2



Rev #2 - Done

Rev #2 - Done


Rev #2 - Done

Rev #2 - Done

Rev #2 - Done




Issues after Rev #2

Input from CCHIT Inpatient IFR Rev #


Input from DC.1 Review #2 TeamRev #

Input from CCHIT Inpatient IFR Issues

Proposed

Rev #3 - Needs additional review

Rev #2 - Done


Modified per Review #2 Team Rev #2 - Done

Modified per Review #2 Team Rev #2 - Done


Rev #2 - Done



Rev #2 - Done

Rev #2 - Done






Rev #2 - Done


Input from ????? Rev #2 - Done

Rev #2 - Done

Rev #2 - Done










Issues after Rev #2

Proposed

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done


*Input from LTC FP Rev #2 - Done

Resequence cc to make this 2nd Rev #2 - Done








Input from DC.1.7.1 Review #1 Team - Replace DC.1.8.2 CC#4 with this criteria (see column W)DC.1.8.2 Review Team needs to reconcile proposed new criterion

*Input from Child Health*Glossary Team - Correction is ackward. Should "reconcile" be added under "Determine" in the hierarchy?

*Input from DC.2 Review #2 Team*Input from Child Health R2 WG*Input from Behavioral Health FP*Input from LTC FP*Input from PHR-S FM*Sequenced as first criterion by Review #1 Team

*Input from Behavioral Health FP*Review #2 Team - Delete - duplicate of new cc#3

*Input from Child Health FP*Input from Publich Health Requirements

*Input from LTC FP*Input from Public Health Requirements*Input from LTC FP*Input from Public Health Requirements

*Input from EDIS R2 WG (DC.1.11)*Review Team comment - need to check or add that results need to be flagged even if patient is no longer actively at the facility.*Input from PHRS-FM*DC.1.11 Review #2 Team - delete function 1.11 (Manage patient's genetic information) and move criterion #1 to DC.1.8.3

*Input from EDIS FP*Input from LTC FP*Input from EDIS FP*Input from LTC FP




Rev #2 - Done

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Proposed

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done



Rev #2 - Done

Input from DC.1.8 Review #2 Te Rev #2 - Done

Rev #2 - Done

Rev #2 - Done








Proposed

Proposed


Input from EDIS R2 WG Proposed



Input from CCHIT Ambulatory IFRProposed

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done



Input from Review Team Rev #2 - Done


Rev #2 - Done

Input from Review Team Rev #2 - Done

Rev #2 - Done

Rev #2 - Done









Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Review Team comment - the DC.2 SRev #3 - Done

*Term(s) accepted 2/7/2011 (MGJ)*Input from Child Health FP

*Input from Canadian Blueprint 2015*DC.1.7 Review #1 Team - Move to DC.1.8.5

*Input from EDIS R2 WG*DC.1.10 Review #2 Team - move to DC.1.8.5*Input from EDIS R2 WG*DC.1.10 Review #2 Team - move to DC.1.8.5

*Input from PHRS-FM*Review Team comment - Not sure we understand this function and the relationship with clinical documents.*Input from PHRS-FM*Review #1 Team comment - Not sure we understand this function and the relationship with clinical documents.*Input from PHRS-FM*Review #1 Team comment - Not sure we understand this function and the relationship with clinical documents.*Input from PHRS-FM*Review #1 Team comment - Not sure we understand this function and the relationship with clinical documents.*Input from PHRS-FM*Review #1 Team comment - Not sure we understand this function and the relationship with clinical documents.*Input from PHRS-FM*Review #1 Team comment - Not sure we understand this function and the relationship with clinical documents.*Input from PHRS-FM*Review #1 Team comment - Not sure we understand this function and the relationship with clinical documents.























Review Team comment - need funRev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done


Rev #3 - Done


Rev #2 - Done



Rev #2 - Done

Rev #2 - Done


Review Team - delete R1.1 criterRev #2 - Done

Rev #2 - Done

*Criterion renumbered Rev #2 - Done




Term(s) corrected by Review Te Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done







Rev #2 - Done



Rev #2 - Done

Rev #2 - Done



*Term(s) corrected by Glossary Team*Criterion renumbered

*Term(s) corrected by Glossary Team*Input from Public Health Requirements*Input from Pharmacy (Standalone) FP*Please verify verb usage - Glossary Team had recommended use of "render" versus "prompt"



Rev #2 - Done

Rev #2 - Done

Rev #2 - Done




Input from e-Prescribing FP (DC.2Rev #3 - Done

Rev #2 - Done


Rev #2 - Done

Rev #2 - Done

Rev #2 - Done


Rev #2 - Done

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #3 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Need statement & description Rev #3 - Done



Rev #2 - Done






Rev #2 - Done

Rev #2 - Done



Rev #2 - Done

Rev #2 - Done



Rev #2 - Done





Rev #2 - Done

Rev #2 - Done




Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

*Review #2 Team - Leave in place*Review #1 Team - delete R1.1 criterion #9

*Term(s) corrected by Glossary Team*Glossary Team comment - should 'teaching materials' be 'education materials'?

*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed*Input from EDIS R2 WG*Proposed content has not been reviewed

*Input from Clinical Research FP (see DC.1.10)*Please verify assignment of criterion to intended function

*Input from LTC FP*Input from EDIS R2 WG*Input from LTC FP*Input from EDIS R2 WG


Rev #2 - Done







This criterion was not used by theIssues after Rev #2







Rev #2 - Done

Rev #2 - Done

Rev #3 - Done


Input from Behavioral Health Rev #2 - Done

Rev #2 - Done

Proposed

Rev #2 - Done



Input from EDIS R2 WG Rev #3 - Needs additional review

Input from EDIS R2 WG Issues after Rev #2





Input from Clinical Research FP Rev #3 - Needs additional review


Issues after Rev #2

Input from e-Prescribing FP Rev #2 - Done

Rev #2 - Done

Rev #2 - Done

Input from e-Prescribing FP Rev #2 - Done

Rev #2 - Done

Input from LTC FP Issues after Rev #2

Rev #2 - Done


R2 Spreadsheet

SECTION Review #1 Status

Direct Care 1.1-1.3 (Lead: Mark J) 100% 2/6/2011

Direct Care 1.4-1.7 (Lead: Pat Van Dyke 75% eta 2/25 3/9/2011

Direct Care 1.8-1.10 (Lead: Helen) 100% 2/6/2011

100% 2/6/2011

Direct Care 2 (Lead: Helen/Hetty) 100% 2/6/2011

Direct Care 3 (Lead: Andre) 100% eta 2/18 3/4/2011

Supportive 1 (Lead: Lenel/Beth) 2/28/2011



IN 1 (Lead: John Ritter, Gora, Sasha) 55% LJ/BA to pickup

IN 2 (Lead: Gary) 100% 2/28/2011

??

IN 3 (Lead: Don) 100% 2/6/2011

IN 4 (Lead: Andre) 100% 2/28/2011IN 5 (Lead: Andre) 90%

IN 6 (Lead: John/Sasha) 100% 2/28/2011

IN 7 (Lead: John/Sasha) 100% 2/28/2011IN 8 – Backup/Restore (Lead: RM-ES) 10%

IN 9 – Archive/Restore (Lead: RM-ES) 0%

10%

3-29-2011: After EHR WG meeting, the R2 Master Spreadsheet was branched into two pathsPath #1 - April Comment Ballot PublicationPath #2 - April R2 Working file

This is the Ballot Publication file and features:*Overarching criteria in DC.0 based ONLY on overarching criteria as identified in R1.1 release.*IN content includes ONLY function numbers and names as identified in R1.1 release.

Spreadsheet Updated

Direct Care add-ons including PHRS items (Lead: Helen)

100% LJ to send to Sue 2/15100% LJ to send to Sue 2/15100% LJ to send to Sue 2/15

IN 2.2 Audit Re-organization (Lead: Michelle Dougherty/RM-ES Team)

IN 10 – Lifecycle Model Subroutines (Lead: Don Mon)

0%IN 11 – System Operation, Performance and Measurement (Lead: John)

Review #2 Status

100%

100%

90%100%

100%

100%

3-29-2011: After EHR WG meeting, the R2 Master Spreadsheet was branched into two paths

*Overarching criteria in DC.0 based ONLY on overarching criteria as identified in R1.1 release.*IN content includes ONLY function numbers and names as identified in R1.1 release.

Spreadsheet Updated