Certification Criteria Essay

CCHIT Certified 2011 LTPAC EHR Certification Criteria
Version 1.1 February 9, 2011
© 2010 The Certification Commission for Health Information Technology

N = New for LTPAC NS = New for Skilled Nursing Facility Add-on NH = New for Home Health Add-on R = Roadmap for LTPAC RS = Roadmap for Skilled Nursing Facility RH = Roadmap for Home Health O = Provisional for 2011 (shaded in YELLOW)
Roadmap 1 2011 Certification Roadmap 2 Comments Criteria Reference Test Script and Step Number SEC = Security Test Script

Criteria #

Category

Criteria

Year introduced or last modified

LT 01.01

Patient record and The system shall provide the ability to create a demographics single patient record for each patient. 2011 N

AM 01.01, DC.1.1.1

1.02

LT 01.02
Patient record and The system shall provide the ability to associate demographics (store and link) key identifier information (e.g., system ID, medical record number) with each patient record. Patient record and The system shall provide the ability to store more demographics than one identifier for each patient record. Patient record and The system shall provide the ability to include demographics demographic information in reports.

2011

N

Key identifier information must be unique to the patient record but may take any system defined internal or external form.

AM 1.02, DC.1.1.1

1.02

LT 01.03

2011

N

LT 01.04

2011

N

For interoperability, practices need to be AM 01.03, DC.1.1.1 able to store additional patient identifiers. Examples include an ID generated by an Enterprise Master Patient Index,using demographics to This includes a health plan or insurance AM 02.01, DC.1.1.2 generate reports and also allows demographics to be gathered into a report. See also "Report generation" functionality. Providers need this for look up and AM 02.02, DC.1.1.2 contact purposes, e.g., when attempting to locate a patient or family member for clinical communications. This is useful for identity management. AM 02.04, DC.1.1.2

1.03

2.02

LT 01.05

Patient record and The system shall provide the ability to maintain and demographics make available historic information for demographic data including prior names and addressess. Patient record and The system shall provide the ability to modify demographics demographic information about the patient. Patient record and The system shall provide the ability to store demographics demographic information in the patient medical record in separate discrete data fields, such that data extraction tools can retrieve these data. Patient record and The system shall provide the ability to access and demographics display demographic information such as name, date of birth, and gender needed for patient care functions as discrete data elements within the patient record.

1.07.02

2011

N

LT 01.06

1.05

2011

N
AM 02.05, DC.1.1.2

LT 01.07

1.07.01

2011

N

LT 01.08

2011

N

Examples of a minimum set of demographic data elements include: name, address, phone number, and date of birth. It is assumed that all demographic fields necessary to meet legislative, regulatory, research, and public health requirements will be included.

FN 01.01.01

1.03

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 1 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 01.09

Patient record and The system shall provide the ability to capture and demographics maintain demographic information as discrete data elements as part of the patient record. 2011 N

Examples of a minimum set of demographic data elements include: name, address, phone number, and date of birth. It is assumed that all demographic fields necessary to meet legislative, regulatory, research, and public health requirements will be included. This criterion will be replaced by FN 01.01.01 in the future.

FN 02.01

1.02

LT 01.10

Patient record and The system shall provide the ability to query for a demographics patient by more than one form of identification.

For example, patient last name, medical FN 02.01 record number, account number, or phone number.

1.03

2011

N

LT 01.11

Patient record and The system shall provide the ability to designate the demographics place of service for a given encounter: permanent or date-sensitive temporary addresses. Patient record and The system shall provide the ability to keep demographics multiple, date-sensitive, temporary patient addresses and phone numbers in addition to listing Patient record and a patient's permanent address. The system shall provide the ability to store demographics directions to a patient's home as free-text.

2011

NH

This does not mean a HIPAA Place of Service codes. This criterion can be captured with free-text.

Source is WG discussion.

1.04.02

LT 01.12

Source is WG discussion.

1.04.01

2011

NH
Source is WG discussion.

LT 01.13

1.04.01

2011

NH
This could be done in free text now, should be discrete data in the future. DC.1.3.1

LT 01.14

LT 01.16

Patient record and The system shall provide the ability to capture, demographics present, maintain, and make available for clinical decisions patient preferences such as language, religion, and spiritual and cultural practices. Patient record and The system shall provide the ability to capture and demographics maintain, as discrete data elements, the identity of all providers associated with a specific patient encounter. Patient record and The system shall provide the ability to capture and demographics maintain, as discrete data elements, the principal physician responsible for oversight an individual patient. Patient record and The system shall provide the ability to associate at demographics least two or more full names with a single patient record. Patient record and The system shall provide the ability to retrieve a demographics patient record by any of the full names associated with it. If a patient record has more than one name associated with it there shall be an indication to the user to that effect.

1.05

2011

N
A provider is defined as anyone FN 03.01, S.3.4 delivering clinical care such as physicians, PAs, CNPs and Nurses; the provider is the person who completes the note. FN 03.02, S.3.4

ADM.02

2011

N

LT 01.17

2.04

2011

N
Intended to address situations where a patient is known by more than one name. AM 02.03.01

LT 01.18

R

LT 01.19

Intent is that the multiple names that are AM 02.03.02 added pursuant to AM 02.03a can used to retrieve the record.

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 2 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 01.20

LT 01.21

Patient record and The system shall provide the ability to retrieve a demographics patient record by any of the prior names associated with it. If a patient record is retrieved by a prior name there should be an indication to the user to that effect. Patient record and The system shall provide the ability to merge patient demographics information from two patient records into a single patient record.

AM 02.03.03

R

If a duplicate chart is created, information could be merged into one chart.

AM 01.05, DC.1.1.1

R

Does not imply an unmerge capability. The intent is to merge information for a single patient; this would include discrete data elements from both patient records. FN 01.01.02

LT 01.22

Patient record and The system shall provide the ability to record a demographics suffix to the patient's name (e.g., Sr., Jr., III, etc.) Patient record and The system shall provide the ability to alert a user if demographics registration is incomplete. Patient List The system shall provide for the ability to identify patients by status (e.g., active, admitted patients or inactive, discharged patients). The system shall provide the ability to search all patient records and identify individual patients with specific problems/diagnoses. The system shall provide the ability to identify all patients on a specific medication. The system shall provide the ability to capture, maintain, and display, as discrete data elements, all problems/diagnoses associated with a patient. The system shall provide the ability to maintain the onset date of a problem/diagnosis. The system shall provide the ability to maintain the resolution date of the problem/diagnosis. The system shall provide the ability to record and display the user ID and date of all updates to the problem/diagnosis list. The system shall provide the ability to associate orders and medications with one or more codified problems/diagnoses. The system shall provide the ability to maintain a coded list of problems/diagnoses.

R
Source is WG discussion.

LT 01.23

R
IP 03.01

LT 02.01

2.02

2011

N
Problems in the care plan need not be a IP 04.11 part of the search.

LT 02.02

Patient List

ADM.07

2011 2011

N N

LT 02.03 LT 03.01

Patient List Problem list

IP 16.12 Would include current/active and past/resolved problems. FN 04.02

ADM.08 1.14

2011

N
It is a vendor design decision whether to AM 03.03, DC.1.4.3 require complete date or free text of approximate date. AM 03.04 AM 03.06, DC.1.4.3

LT 03.02 LT 03.03 LT 03.04

Problem list Problem list Problem list

R R 2011 O

2.05

LT 03.05

Problem list

2011

N

The expectation is to associate multiple AM 03.07, AM 03.08.01, diagnoses. DC.1.4.3

1.59

LT 03.06

Problem list

2011

N

For example: ICD-9 CM, ICD-10 CM, AM 03.09, DC.1.4.3 SNOMED-CT, DSM-IV. The Work Group will not specify which code set(s) are to be employed. For example, active, all, or resolved, or FN 04.06 charted in error.

ADM.03

LT 03.07

Problem list

LT 03.08

Problem list

LT 03.09

Problem list

The system shall provide the ability to display different views of the problem/diagnosis list based upon the status of the problem. The system shall provide the ability to capture, maintain, and display free text comments associated with the problem/diagnosis. The system shall provide the ability to print a problem/diagnosis list.

2.05

2011

O

FN 04.01

R 2011 N
A screen print is not the intention of this FN 04.04 criterion.

1.14

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 3 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 03.10

Problem list

LT 03.11

Problem list

When the display of the problem list exceeds the current screen or printed page, the system shall indicate that the list continues. The system shall provide the ability to modify documentation entered in error, maintaining a record of the original entry, identification of the user correcting the error and the date and time corrected. The system shall provide the ability to record the chronicity (chronic, acute/self-limiting, etc.) of a problem/diagnosis. The system shall provide the ability to associate notes with one or more codified problems/diagnoses. The system shall provide the ability to prevent diagnoses from being viewed, printed, or accessed by users without appropriate privileges. The system shall provide the ability for the user to expressly indicate that the medication list has been reviewed; this must be stored as structured data. The system must capture and display the ID of the user conducting the review, and the date of the review. The system shall provide the ability to maintain medication ordering dates. The system shall provide the ability to maintain other dates associated with medications including start, modify, and end dates as applicable. The system shall provide the ability to display medication history for the patient. The system shall provide the ability to capture medications entered by authorized users other than the prescriber.

2011

N

Use of a scroll bar is acceptable to indicate that the list continues.

IP 04.05

1.14

IP 04.06, HL7 9.4.5 - 9.4.11

1.42

2011

N

LT 03.12

Problem list

AM 03.05, DC.1.4.3

R
AM 03.08.02

LT 03.13

Problem list

R
For example, prevent viewing by nonclinicians. IP 04.04, Regulatory requirements

LT 03.14

Problem list

R
AM 04.01

LT 04.01

Medication list

1.43.02

2011

N

LT 04.02 LT 04.03

Medication list Medication list

2011

N

AM 04.03, DC.1.4.2 AM 04.04, DC.1.4.2

1.48 1.48

2011

N
AM 04.05, DC.1.4.2 It is important to have all current medications in the system for drug interaction checking. This in the future would include the incorporation of medication history obtained from outside electronic interfaces from insurers, PBMs, etc. "User" means medical and non-medical staff who are authorized by policy to enter prescriptions or other documentation. AM 04.06, DC.1.4.2

LT 04.04 LT 04.05

Medication list Medication list

2011

N

1.43 1.42, 2.06

2011

N

LT 04.06

Medication list

LT 04.07

Medication list

The system shall store medication information in discrete data fields. At a minimum, there must be one field for each of the following: - medication name, form and dose; and - sig. The system shall include standard medication codes associated with each medication in the list for medications in the vendor-provided medication database.

AM 04.07, DC.1.4.2

1.43

2011

N

R

This criterion is intended to refer to nationally accepted standards for encoding medications when those become available and the specific standard would be stipulated in an interoperability criterion.

AM 04.08, DC.1.4.2

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 4 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 04.08

Medication list

The system shall provide the ability to enter uncoded or free text medications when medications are not in the vendor-provided medication database or information is insufficient to completely identify the medication.

2011

N

Medications that are not on the vendor- AM 04.09 provided medication database or not enough information is available to completely identify the medication. This could be either uncoded (Synthroid unknown dose) or free text (blue hypertension pill). AM 04.10

1.51

LT 04.09

Medication list

The system shall provide the ability to enter and display that the patient takes no medications, in a discrete field. The system shall provide the ability to record the date of changes made to a patient's medication list and the identity of the user who made the changes.

1.15

2011

N
This information may appear as an AM 04.11 optional view rather than a required view on the main screen. Need to capture the identity of the user and the date of changes made. Changes are to be recorded at the level of the individual medication. AM 04.12

LT 04.10

Medication list

2.06

2011

N

LT 04.11

Medication list

LT 04.12

Medication list

The system shall provide the ability to indicate that a prescription's specified stop or end date has passed, or automatically exclude from the display of current medications a prescription whose specified The system shall provide the ability to update and display a patient-specific medication list based on current medication orders or prescriptions.

1.43.01

2011

N
FN 06.01, DC.1.4.2

1.56

2011

N

LT 04.13 LT 04.14

Medication list Medication list

The system shall provide the ability to display a view that includes only current medications. The system shall provide the ability to exclude a medication from the current medication list (e.g. marked inactive, erroneous, completed, discontinued) and document reason for such action. The system shall provide the ability to print a current medication list. The system shall provide the ability to capture maintain and display, as discrete data elements, all current medications including over-the-counter and complementary medications such as vitamins, herbs, and supplements. When the display of the medication list exceeds the current screen or printed page, the system shall indicate that the list continues. The system shall provide the ability to record and display the reason or indication for the medication when recording historical or home medications.

2011

N

FN 06.02 FN 06.03

2.09 2.08

2011

N

LT 04.15 LT 04.16

Medication list Medication list

2011

N

FN 06.04, DC.1.4.2 FN 06.06, DC.1.4.2

2.10 1.43.01

2011

N

LT 04.17

Medication list

For example, Page one of two, End of report.

IP 06.01

2.10

2011

N
Does not require codified data, may be unknown or free text comments. IP 06.07

LT 04.18

Medication List

1.42

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 5 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 04.19

Medication List

The system shall provide the ability to sort and filter the medication list. The system shall provide the ability to capture and display the patient's preferred pharmacy or pharmacies. The system shall provide the ability to display pharmacies that are associated with medications within patient record. The system shall provide the ability to modify or inactivate an item on the allergy and adverse reaction list.

2011

N

Filters could include, all medications and active medications. Sorting could include by order date or drug name.

IP 06.11

2.09

LT 04.20

Medication List

Source is WG discussion.

1.18

2011

N
This is medication by medication basis. Source is WG discussion.

LT 04.21

Medication List

R
This could include removal, marking as FN 05.01 erroneous, or marking as inactive. "Remove" in this context implies specifying that an allergy or allergen specification is no longer valid or active, as opposed to deleting the information from the database entirely. AM 05.03, DC.1.4.1

LT 05.01

Allergy and adverse reaction list

2.12

2011

N

LT 05.02

LT 05.03

LT 05.04

Allergy and adverse reaction list Allergy and adverse reaction list Allergy and adverse reaction list

The system shall provide the ability to display information which has been inactivated or removed from the allergy and adverse reaction list. The system shall provide the ability to specify the type of allergic or adverse reaction in a discrete data field. The system shall provide the ability to capture and maintain, as discrete data, the identity of the user who added, modified, inactivated, or removed items from the allergy and adverse reaction list, including attributes of the changed items. The user ID and date/time stamp shall be recorded. The system shall provide the ability to explicitly indicate in a discrete field that a patient has no known drug allergies or adverse reactions. The system shall provide the ability to display the allergy list, including date of entry.

2.26

2011

N
FN 05.04

1.47, 2.11

2011

N
Attributes include the name of the allergen and the action (added, modified, inactivated or removed). FN 05.05

2.26

2011

N

LT 05.05

LT 05.06

Allergy and adverse reaction list Allergy and adverse reaction list

FN 05.09

1.17

2011

N
It must be possible for a user to view the date of entry for any allergy on the allergy list, but it is acceptable if that is viewed on another screen, e.g. a 'details' screen. FN 05.12

2.11

2011

N

LT 05.07

Allergy and adverse reaction list

The system shall provide the ability to capture, maintain and display, as discrete data, lists of medications and other agents to which the patient has had an allergic or other adverse reaction. When the display of the allergy list exceeds the current screen or printed page, the system shall indicate that the list continues. The system shall provide the configurable ability to enter free text allergies and display them in a manner that distinguishes them from coded allergy entries.

FN 05.13

2.11

2011

N

LT 05.08

LT 05.09

Allergy and adverse reaction list Allergy and adverse reaction list

2011

N

Use of a scroll bar is acceptable to indicate that the list continues.

IP 05.08

2.11

IP 05.11

2.13

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 6 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 05.10

Allergy and adverse reaction list

The system shall provide the ability to indicate that interaction checking will not occur against free text allergies.
2011 N

The use of a field "other" with associated free text is acceptable.

IP 05.12

2.13

LT 05.11

Allergy and adverse reaction list

The system shall provide the ability to capture store and display lists of medications and other agents to which the patient has had an allergic or other adverse reaction in a standard coded form. The system shall provide the ability to distinguish between an allergy and an intolerance as discrete data.

Pending standard codes for allergens.

AM 05.01

R

LT 05.12

Allergy and adverse reaction list

AM 05.04

R

LT 05.13

Allergy and adverse reaction list

LT 05.14

LT 05.15

Allergy and adverse reaction list Allergy and adverse reaction
list

The system shall provide the ability for a user to explicitly capture and maintain, as discrete data, that the allergy list was reviewed. The user ID and date/time stamp shall be recorded when the allergies reviewed option is selected. The system shall provide the ability to capture the severity of an allergic or adverse reaction. The system shall provide the ability to require the documentation of patient allergies (inclusive of using such terms as Unknown or Unable to Assess) before completion of the medication order. The system shall provide the ability to capture, store, display, and manage patient history. 2011 N

FN 05.07

R

IP 05.02, DC 1.4.1

R
IP 05.04

R

LT 06.01

Patient history

Patient History refers to the AM 06.01, DC.1.2 documentation of past medical, past surgical, family and social history including items such as tobacco, alcohol and drug use. The term "patient" in used in a general manner, patient is synonymous with "resident" or "client" in the LTPAC criteria and test script.

1.19

LT 06.02

Patient history

The system shall provide the ability to capture and display functional status.

2011

N

Standards should be appropriate to the Source is WG discussion. care setting. Examples are MDS and OASIS. Free text is acceptable now and in the future discrete data will be required. Requirement not predicated on the capture of structured data. AM 06.03, DC.1.2

1.19

LT 06.03

Patient history

LT 06.04

Patient history

The system shall provide the ability to update a patient history by modifying, adding, or removing items from the patient history as appropriate. The system shall provide the ability to capture and display patient history as both a presence and absence of conditions, i.e., the specification of the absence of a personal or family history of a specific diagnosis, procedure, or health risk behavior.

2.28

2011

N

Requirement not predicated on the capture of structured data.

AM 06.04, DC.1.2

1.19

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 7 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 06.05

Patient history

The system shall provide the ability to capture history collected from outside sources. 2011 N

This could include data from a personal AM 06.05, DC.1.2 health record, online patient histories, and information from pharmacy benefit management organizations. Please see interoperability criteria (IO-AM 11.xx) for specific requirements for electronic importation. This function demonstrates the ability of AM 06.02, DC.1.2 a system to capture structured data but does not define the required elements of the patient history that shall be structured. Discrete data elements allow for searching and/or reporting by the EHR, and for this criterion, the data could be free text or codified. Future functions would define the required patient history elements that shall be captured discretely as structured data, and where appropriate codified terminologies will be used.

1.22

LT 06.06

Patient history

The system shall provide the ability to capture structured data in the patient history.

R

LT 06.07

Patient history

The system shall provide the ability to capture patient history in a standard coded form. R

Not all data elements may currently be AM 06.06, DC.1.2 represented in existing standard coding schemes. An example would be diagnostic and procedural history using ICD-9, CPT, or SNOMED codes. Health record summary is at the patient AM 07.01, DC.1.1.4 level as opposed to at the level of an individual visit or episode of care.

LT 07.01

Patient views

LT 07.02

Patient views

LT 07.03

Patient views

The system shall provide the ability to create and display a summary list for a patient that includes, at a minimum, the active problem/diagnosis list, current medication list, medication allergies, and adverse reactions. The system shall provide the ability to provide filtered displays of encounters based on encounter characteristics, including date of service, and encounter provider. The system shall provide the ability to provide filtered displays based on encounter characteristics (e.g., diagnosis).

2.57

2011

N

Encounter is any visit by a clinician or home health aide.

S.3.1

2.58

2011

NH
Source is WG discussion.

RH

LT 08.01

LT 08.02

Clinical documents The system shall provide the ability to create clinical and notes documentation or notes (henceforth "documentation"). Clinical documents The system shall provide the ability to display and notes documentation. Clinical documents The system shall provide the ability to save a note and notes in progress prior to finalizing the note.

AM 08.01, DC.1.9.1

2.17

2011

N
AM 08.02, DC.1.9.1

2.17

2011

N
AM 08.03, DC.1.9.1

LT 08.03

2.17

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 8 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 08.04

Clinical documents The system shall provide the ability to finalize a and notes note, i.e., change the status of the note from in progress to complete, so that any subsequent changes are recorded as such.

2011

N

Medico-Legal. User rights are AM 08.04, DC.1.9.1 determined by role-based access defined in security. Only authorized users can complete, change or finalize a clinical note. The words, "sign," "signature," "cosign," and "cosignature" are intended here to convey actions, rather than referring to digital signature standards. It is recognized that an electronic signature is useful here. However, a widely accepted standard for electronic signatures does not exist. Thus, the criteria calls for documenting the actions of authenticated users at a minimum. In the future, when appropriate digital signature standards are available, certification criteria may be introduced using such standards.

2.19

LT 08.05

Clinical documents The system shall provide the ability to addend and notes and/or correct notes that have been finalized.

2011

N

The words, "sign," "signature," "cosign," AM 08.07, DC.1.9.1 and "cosignature" are intended here to convey actions, rather than referring to digital signature standards. It is recognized that an electronic signature is useful here. However, a widely accepted standard for electronic signatures does not exist. Thus, the criteria calls for documenting the actions of authenticated users at a minimum. In the future, when appropriate digital signature standards are available, certification criteria may be introduced using such standards.

2.20

LT 08.06

Clinical documents The system shall provide the ability to identify the and notes full content of a modified note, both the original content and the content resulting after any changes, corrections, clarifications, addenda, etc. to a finalized note. 2011 N

This may be in the GUI or in the audit Source is WG discussion. trail. It is adequate to be able to access pre- and post-modification versions of a note; i.e. it is not necessary for the system to have a single display that shows what modifications were made. The intent of this criterion is to specify the information stored after finalization of a note; other criteria specify requirements prior to finalization.

2.20

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 9 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 08.07

Clinical documents The system shall provide the ability to record and and notes display the identity of the user who addended or corrected a note and the date and time of the change.

2011

N

Necessary for medico-legal purposes. AM 08.09, DC.1.9.1 The words, "sign," "signature," "cosign," and "cosignature" are intended here to convey actions, rather than referring to digital signature standards. It is recognized that an electronic signature is useful here. However, a widely accepted standard for electronic signatures does not exist. Thus, the criteria calls for documenting the actions of authenticated users at a minimum. In the future, when appropriate digital signature standards are available, certification criteria may be introduced using such standards.

2.20

LT 08.08

Clinical documents The system shall provide the ability to enter free text and notes notes. Clinical documents The system shall provide the ability to filter, search, and notes or order notes by the provider who finalized the note. Clinical documents The system shall provide the ability to document and notes multidisciplinary care or case conference including the participants, their discipline, and their role in the conference.

AM 08.10, DC.1.9.1

1.22

2011

N
AM 08.11, DC.1.9.1

LT 08.09

2.29

2011

N
This could be achieved by a free text Source is WG discussion. note but must be categorized as a case conference note that is flagged in some manner to distinguish it from other note types. Documentation of physical attendence in the conference needs to be determined and is not necessarily addressed in this criteria.

LT 08.10

2.59

2011

N

LT 08.11

Clinical documents The system shall provide templates for inputting and notes data in a structured format as part of clinical documentation.

Templates may include any patient AM 08.19, DC.1.9.1 encounter note documentation tool that provide a pre-set collection of clinical findings or fields, including macros driven by speech recognition technology, branching logic.

2.17

2011

N
This list is not necessarily all inclusive of all the technology that may arrive in future.

LT 08.12

Clinical documents The system shall provide the ability to customize and notes clinical templates. 2011 N

Customization at the level of clinical content is satisfactory.

AM 08.20, DC.1.9.1

1.33

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 10 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 08.13

Clinical documents The system shall be provide the ability to record and notes comments by the patient or the patient's representative regarding the accuracy or veracity of information in the patient record (henceforth 'patient annotations').

2011

N

For the current year it is sufficient for AM 08.21 these to be recorded as either free-text notes or scanned paper documents. It is not required that the system facilitate direct entry into the system by the patient or patient's representative.

2.28

LT 08.14

Clinical documents The system shall provide the ability to display and notes patient annotations in a manner which distinguishes them from other content in the system. 2011 N

A patient annotation in free-text or AM 08.22 scanned-document form, when displayed, should indicate that it comes from a patient. This could be a text label on the screen or part of the freetext note itself. It is not necessary to make patient annotations visible from any and all sections of the patient record.

2.28

LT 08.15

Clinical documents The system shall provide the ability to capture and notes clinical data elements as discrete data.

2011

N

For example, quantitative tobacco AM 08.16, DC.1.9.1 consumption, peak expiratory flow rate, size of lesions, severity of pain, etc.

ADM.05

LT 08.16

Clinical documents The system shall provide the ability to capture and notes patient vital signs, including blood pressure, heart rate, respiratory rate, height, and weight, as discrete data.

2011

N

It is understood that vendors should AM 08.13, DC.1.9.1 support conversion to numeric values that can be graphed. Coding in ICD-9 CM, ICD-10 CM, SNOMED, UMLS, etc., would enhance interoperability and for public health surveillance or clinical research. Normal range shall be set at system level as opposed to individual patient level. At a minimum, this must be possible for the following vital signs: systolic and diastolic blood pressures, heart rate, temperature, and respiratory rate. AM 08.15

1.21

LT 08.17

Clinical documents The system shall provide the ability to indicate to and notes the user when a vital sign measurement falls outside a preset normal range as set by authorized users. 2011 N

1.21

LT 08.18

Clinical documents The system shall provide the ability to capture and and notes display temperature, weight and height in either metric or English units.

1.21 2011 N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 11 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 08.19

Clinical documents The system shall provide the ability to cosign a note and notes and record the date and time of signature.

R

The words, "sign," "signature," "cosign," AM 08.06 and "cosignature" are intended here to convey actions, rather than referring to digital signature standards. It is recognized that an electronic signature is useful here. However, a widely accepted standard for electronic signatures does not exist. Thus, the criteria calls for documenting the actions of authenticated users at a minimum. In the future, when appropriate digital signature standards are available, certification criteria may be introduced using such standards. ASTM has developed "2003 Updated ASTM Standard Guide for Electronic Authentication of Health Care Information" to address some of these issues.

LT 08.20

LT 08.21

Clinical documents The system shall provide the ability to filter, search and notes or order notes by one or more associated diagnosis within a patient record. Clinical documents The system shall provide the ability to capture and and notes store discrete data regarding symptoms, signs and clinical history, from a clinical encounter and to associate that data with codes from standardized nomenclatures.

R

This is intended to be the coded diagnosis and not free text in the body of a note.

AM 08.12, DC.1.9.1

R

Examples include but are not limited to AM 08.18, DC.1.9.1 SNOMED-CT, ICD-9 CM, ICD-10 CM, DSM-IV, CPT-4, MEDCIN, and LOINC. This would allow symptoms to be associated with SNOMED terms, labs with LOINC codes, etc. The code associated with a note would remain static even if the code is updated in the future.

LT 08.22

Clinical documents The system shall provide the ability to capture and and notes display temperature, weight and height in both metric and English units. R

The criterion requires that the system AM 08.14 be able to display both; it does not require that both are able to display on the same screen at the same time. The data should be capable of being displayed in the form in which it was entered. This implies the requirement can convert from one scale to the other.

LT 08.23

Clinical documents The system shall provide the ability to graph height and notes and weight over time. Clinical documents The system shall provide the ability to calculate and and notes display body mass index (BMI).

AM 08.24

R
AM 08.25

LT 08.24

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 12 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 09.01

External clinical documents

The system shall provide the ability to capture and store external documents.

2011

N

Scanned documents are sufficient; AM 09.01, DC.1.1.3.1 structured data will be expected in the future. This covers all types of documents received that would typically be incorporated into a medical record, including but not limited to faxes, referral authorizations, consultant reports, and patient correspondence of a clinical nature.

2.18

LT 09.02 LT 09.03

External clinical documents External clinical documents

The system shall provide the ability to display and maintain scanned documents as images. The system shall provide the ability to index scanned documents and associate a date and document type to the document.

2011

N
These dates may include the date the original document was produced, received, and/or scanned.

AM 09.03, DC.1.1.3.1 AM 09.05.01

2.18 2.18

2011

N

Indexing implies associating a scanned document with an individual patient record.

LT 09.04

External clinical documents

The system shall provide the ability to retrieve scanned documents based on document type and date. The system shall provide the ability to receive, store in the patient's record, and display text-based outside reports. The system shall provide access to clinical images. They must be accessible from within the patient's chart and labeled and date-time stamped or included in a patient encounter document. These images may be stored within the system or be provided through direct linkage to external sources.

2011

N

Document types might include lab notes, progress notes, consent forms, etc.

AM 09.05.02

1.11

LT 09.05

External clinical documents External clinical documents

R

This could be either from an outside system or from scanning with optical character recognition. These images may include but are not limited to radiographic, digital, or graphical images. Eventually, the goal would be to allow linkage to outside systems such as a hospital PAC system. The date/time stamp may be the date/time of image creation or acquisition, the date/time of image importation/incorporation into the system, date/time of the clinical encounter with which the image is associated, or manually entered by the user.

AM 09.04, DC.1.1.3.1

LT 09.06

AM 09.06, DC.1.1.3.1

R

LT 09.07

External clinical documents

The system shall provide the ability to accept, store in the patient's record, and display clinical results received through an interface with an external source. R

This is limited to clinical data received AM 09.07, DC.1.1.3.1 through interfaces as defined in CCHIT interoperability criteria. It is acceptable if certain data received through an interface, if not relevant to the end user, are not displayed in the application.

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 13 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 10.01

Patient-specific instructions

LT 10.02

Patient-specific instructions

LT 10.03

Patient-specific instructions

LT 10.04

Patient-specific instructions Patient-specific instructions General Ordering Requirements

LT 10.05 LT 11.01

The system shall provide the ability to access and review medication information (such as patient education material or drug monograph). This may reside within the system or be provided through links to external sources. The system shall provide the ability to produce patient instructions and patient educational materials which may reside within the system or be provided through links to external source. The system shall have the ability to provide access to patient-specific test and procedure instructions that can be modified by the physician or health organization; these instructions are to be given to the patient. These instructions may reside within the system or be provided through links to external sources. The system shall provide the ability to record that patient specific instructions or educational material were provided to the patient. The system shall provide the ability to create patient specific instructions. The system shall provide the ability to document a verbal order (including telephone orders); documentation shall include the ordering clinician as well as the clinician taking the verbal order. The system shall provide the ability to document a verification “read-back” of the complete order by the person receiving the telephone or verbal order.

FN 17.01

1.49

2011

N

An example would be a vaccine information statement.

FN 14.01

R
It is not reqiured that the modified document be stored in the patient record. This will be required for the Skilled Nursing Facility-add on in the future. AM 10.03

RH

R R

This does not require automatic documentation.

AM 10.05, DC.1.10

AM 10.06, DC.1.10 IP 08.05, DC.3.2.1

2.42

2011

N

LT 11.02

General Ordering Requirements

Free text is sufficient for now, discrete data in the future.

2011

N

IP 08.07, JCAHO 2003 National Patient Safety Goal - Goal 2: Improve the effectiveness of communication among caregivers

2.43

LT 11.03

General Ordering Requirements

LT 11.04 LT 11.05

General Ordering Requirements General Ordering Requirements General Ordering Requirements General Ordering Requirements

LT 11.06 LT 11.07

The system shall provide the ability for clinicians to enter all patient care orders electronically, including, but not limited to nursing care, medications/immunizations, diagnostic testing, nutrition and food service, consultation, and blood products. The system shall provide the ability to discontinue orders. The system shall provide the ability to display order history for any order, including the ordering clinician, order details, date, and time. The system shall provide the ability to display orders for a patient by different views. The system shall provide the ability to view status information for ordered services.

IP 08.10, DC 1.7.2.1, DC 1.7.2.2

2.14, 2.31, 2.26.01

2011

N

2011 2011

N N
For example, active, discontinued, all, date, ordering clinician, and type.

IP 08.11, DC.1.7.1 IP 08.14

2.45 2.46

IP 08.27

2.46 2.46

2011

N

Status may be electronically or manually FN 09.02 updated.

2011

N

LT 11.08

General Ordering Requirements

The system shall provide the ability to prohibit verbal orders by role.

R

For example, a Medical Student role cannot be selected for verbal order provider.

IP 08.08

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 14 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 11.09 LT 11.10

General Ordering Requirements General Ordering Requirements General Ordering Requirements

The system shall provide the ability to include urgency status in orders. The system shall provide the ability to notify the receiving department with any order action of new, renew, modify or discontinue. For each order type, the system shall provide the ability to capture and display the identity of the user, the date and the time when the order is signed, cosigned, renewed, modified or discontinued. The system shall provide the ability to require one or more problems or diagnoses as an order component. The system shall provide the ability to set or configure what fields are required for a complete order by individual order or type of order. The system shall provide the ability to create prescription or other medication orders with sufficient information for correct filling and dispensing by a pharmacy including entering dosing instructions in free text. The system shall provide the ability to record and display user and date stamp for prescription/medication order related events, such as initial creation, discontinuation, and cancellation The system shall provide the ability to capture the identity of the prescribing provider for all medication orders. The system shall provide the ability to capture common content for medication order details including dose and sig to be selected by the ordering clinician. The system shall provide the ability to specify medication order details including dose, route, frequency and comments. Dose, route and frequency must be captured and maintained as discrete data. The system shall provide the ability to reorder a prior prescription/order without re-entering previous data (e.g. administration schedule, quantity). The system shall provide the ability to prescribe/order/record fractional amounts of medication (e.g. 1/2 tsp, 1/2 tablet). The system shall provide the ability to express dosing instructions in free text.

R

For example, routine, Now, or STAT, and should be in a discrete field. For example, a medication dose or frequency is changed (pharmacy notified) or a lab frequency is changed (lab notified).

IP 08.09 IP 08.12, Implied in DC.1.7.2; DC.1.7.2.1 (6); DC.1.7.2.2 (6);

R

LT 11.11

IP 08.13, DC.1.7.1 (and others)

R

LT 11.12

General Ordering Requirements General Ordering Requirements Medication Prescribing and Ordering

FN 09.01

RS
FN 09.03

LT 11.13

R
Example of dosing instructions is "pea- AM 11.01.01 sized amount" for topical medications. This will be required for LTPAC domain in the future.

LT 12.01

1.54

2011

NS

LT 12.02

Medication Prescribing and Ordering Medication Prescribing and Ordering Medication Prescribing and Ordering Medication Prescribing and Ordering

DC.1.7.1

1.57

2011

NS
AM 11.03, DC.1.7.1

LT 12.03

1.52

2011

N
The WG encourages the development DC.1.7.1 of standard national abbreviations and that only approved abbreviations should be supported. FN 07.06

LT 12.04

1.52

2011

N

LT 12.05

1.52

2011

N

LT 12.06

Medication Prescribing and Ordering Medication Prescribing and Ordering Medication Prescribing and Ordering

AM 11.07, DC.1.7.1

1.58

2011

NS
AM 11.13, DC.1.7.1

LT 12.07

1.51

2011

N
For example, 'pea-sized amount' for AM 11.13.01 topical medications. The WG encourages standardization of common terms.

LT 12.08

1.51

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 15 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 12.09

Medication Prescribing and Ordering

The system shall provide the ability to capture and maintain, as discrete data, one or more diagnosis or problem codes or descriptions associated with an order of any type (including prescriptions and medications ordered for administration). The system shall provide the ability to add reminders for necessary follow up tests based on medication prescribed/ordered.

FN 09.04

1.52

2011

N

LT 12.10

Medication Prescribing and Ordering

Does not imply that this must be an automated process. It is acceptable if the system requires an action by the user, separate from the action of prescribing the medication, to configure the system to issue future reminders related to follow-up tests for the medication.

AM 11.20

1.55

2011

NS

LT 12.11

Medication Prescribing and Ordering

The system shall provide the ability for a user to select an order for a medication and exit the process of creating the order at some point prior to completion such that another user can access the order for subsequent review and completion. The system shall provide the ability to prescribe/order/record uncoded and non-formulary medications. The system shall provide the ability to maintain a coded list of medications including a unique identifier for each medication. The system shall provide end-users the ability to search for medications by generic or brand name. The system shall provide the ability to access reference information for prescribing/ordering/recording of medications. The system shall provide the ability to check for potential interactions between medications to be prescribed/ordered/recorded and current medications and alert the user at the time of medication prescribing/ordering/recording if potential interactions exist. The system shall provide the ability to alert the user at the time a new medication is prescribed/ordered/recorded that drug interaction and allergy checking will not be performed against the uncoded medication or free text medication. The system shall provide the ability to print and electronically fax prescriptions.

2011

N

The intent is to have the ability for one AM 11.22 user to enter an order, place it in "pending" or similar status, so that a subsequent provider can complete and submit the order.

2.16, 2.30

LT 12.12

LT 12.13

LT 12.14

LT 12.15

Medication Prescribing and Ordering Medication Prescribing and Ordering Medication Prescribing and Ordering Medication Prescribing and Ordering Medication Prescribing and Ordering

FN 07.02

1.51

2011

N
FN 07.03

ADM.09

2011

N
FN 07.04

1.48

2011

N
The reference information may reside within the system or be provided through links to external sources. FN 07.05

1.49

2011

N

LT 12.16

FN 12.01, DC.2.3.1.1

1.50

2011

N

LT 12.17

Medication Prescribing and Ordering

FN 07.01

1.51

2011

N

LT 12.18

Medication Prescribing and Ordering

AM 11.08, DC.1.7.1

RS

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 16 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 12.19

Medication Prescribing and Ordering

The system shall provide the ability to re-print and re-fax prescriptions. RS

This allows a prescription that did not AM 11.09 come out of the printer, or a fax that did not go through, to be resent/reprinted without entering another prescription.

LT 12.20

Medication Prescribing and Ordering

The system shall provide the ability to display a dose calculator for patient-specific dosing based on weight.

R

The intent is to allow input of dose-per- AM 11.11, DC.1.7.1 weight and patient weight and calculate the corresponding dose. The dose-perweight might be directly inputted by a user at the time the dose calculation is to occur, or might have been inputted previously as the default for a particular medication. The output may be in terms that take into account a particular strength and dosage form of a medication (e.g. "5ml" or "2 tablets") OR may be simply in terms of the amount of the active drug component (e.g. "250"). It is not required that the dose calculator automatically populate fields in the prescription itself.

LT 12.21

Medication Prescribing and Ordering

The system shall provide the ability to display the associated problem or diagnosis (indication) on the printed prescription.

RS

At least one diagnosis shall be able to AM 11.17 be displayed but the ability to display more than one is desirable. Associated problem or diagnosis can be non-structured data or structured data.

LT 12.22

Medication Prescribing and Ordering

The system shall provide the ability to allow the user to configure prescriptions to incorporate fixed text according to the user's specifications. RS

This refers to the "written" output and AM 11.15 language on the printed prescription such as practice address, practice telephone number, legally mandated text. For instance, users should be able to modify the format/content of printed prescriptions to comply with state Board of Pharmacy requirements.

LT 12.23

Medication Prescribing and Ordering

The system shall provide the ability to alert the user at the time a new medication is prescribed/ordered that drug interaction, allergy, and formulary checking will not be performed against the uncoded medication or free text medication. The system shall provide the ability to search from medication lists which use “Tall Man” letters. The system shall provide the ability, when a new allergy is documented, to check for a potential interaction between the newly-documented allergy and the patient's current medications, and alert the user if such interactions exist. The system shall provide the ability to view the rationale for a drug interaction alert.

FN 07.01

R

LT 12.24

LT 13.01

Medication Prescribing and Ordering Drug interaction

R

For example, DOBUTamine and DOPamine.

IP 12.12

FN 12.11

2.32

2011

O

LT 13.02

Drug interaction

2011

N

FN 12.05

2.32.01

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 17 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 13.03

Drug interaction

LT 13.04 LT 13.05

Drug interaction Drug interaction

The system shall provide the ability to prescribe/order a medication despite alerts for interactions and/or allergies/intolerances being present. The system shall provide the ability to accept updates to drug interaction databases. The system shall provide the ability to alert the user if the drug interaction information is outdated.

FN 12.08, DC.2.3.1.1

2.33

2011

N
FN 12.09 The drug database should have an "expiration date" based on the frequency of their updates such that when that date has passed, the user is alerted. AM 11.14

2011

N

SEC 6.28

R

This criterion applies if the system requires user action to provide database updates as opposed to providing them automatically.

LT 13.06

Drug interaction

LT 13.07

Drug interaction

The system shall provide the ability to set the severity level at which drug interaction warnings should be displayed. The system shall be capable, at the time of ordering a medication for administration (as opposed to prescribing), of alerting the user that based on the results of a laboratory test, the patient may be at increased risk for adverse effects of the medication.

AM 19.05, DC.2.3.1.1

R
„Ordered for administration‟ refers to administration at the site of care. This criterion is dependent on drug knowledge database being made available by the drug database vendor. AM 19.06

R

LT 13.08

Drug interaction

LT 13.09

Drug interaction

LT 13.10

Drug interaction

LT 13.11

Drug interaction

The system shall provide the ability to check whether a medication being prescribed has been noted to be ineffective for the patient in the past, and alert the user at the time of medication ordering if noted ineffectiveness exists. The system shall provide the ability to display, on demand, potential drug-allergy interactions, drugdrug interactions, and drug-diagnosis interactions based on current medications, active allergies, and active problems. The system shall provide drug-diagnosis interaction alerts at the time of medication prescribing/ordering/recording. The system shall provide the ability to check for drug-disease interactions for medications ordered for administration (as opposed to prescriptions) and alert the user at the time of ordering if potential interactions exist.

R

This criterion assumes that at the time a AM 19.07, DC.2.3.1.1 medication was discontinued, it was marked "ineffective."

FN 12.04

R

FN 13.01

R
„Ordered for administration‟ refers to administration at the site of care. This criterion is dependent on drug knowledge database being made available by the drug database vendor. AM 19.10

R

LT 13.12

Drug interaction

LT 13.13

Drug interaction

The system shall provide drug-disease interaction alerts based on the patient's medications at the time of entering a problem. The system shall provide the ability to check for medication contraindications based on patient age and alert the user during prescribing/ordering/recording.

AM 19.11

R
For example, Tetracycline is listed as a FN 08.06 high risk for older adult patients using the Beers criteria.

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 18 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 13.14

Drug interaction

LT 13.15

Drug interaction

LT 13.16

Drug interaction

LT 13.17

Drug interaction

LT 13.18

Drug interaction

LT 14.01

Medication Reconciliation

The system shall provide the ability to check immunization orders against documented patient allergies (medication and non-medication) and inform the user during prescribing/ordering. The system shall provide the ability to, at the time of medication prescribing/ordering, alert the user that, based on the results of a laboratory test, the patient may be at increased risk for adverse effects of the medication. The system shall provide the ability to capture and maintain at least one reason for overriding any drugdrug or drug-allergy/intolerance interaction warning triggered at the time of medication prescribing/ordering/recording. The system shall provide the ability to enter a structured response when overriding a drug-drug or drug-allergy/intolerance warning. The system shall provide the ability to display patient specific dosing recommendations based on renal function. The system shall provide the ability to capture and display home medications for medication reconciliation during entering of admission orders. At admission, discharge, and each change in level of care during the facility stay, the system shall provide the ability to capture a signature or the user ID and date stamp indicating that medication reconciliation has been completed.

FN 12.02

R
Until third-party vendors support this functionality in databases, this may require manual configuration by organization. FN 12.03

R

FN 12.06

R

FN 12.07

R
FN 08.02

R
IP 11.07

1.16

2011

N
IP 11.13

LT 14.02

Medication Reconciliation

1.44

2011

N

LT 14.03

Medication Reconciliation

LT 14.04

Medication Reconciliation

LT 15.01

Order diagnostic tests Order diagnostic tests Order diagnostic tests

At admission and discharge from the facility, the system shall provide the ability to permit the clinician to designate which home medications are being continued/discontinued. At admission, discharge, and each change in level of care, the system shall provide the ability to retain the history of medication reconciliation (including prior medications reviewed, medications continued/discontinued, new medication orders, signature of each provider completing review) for subsequent review. The system shall provide the ability to order diagnostic tests, including labs and imaging studies. The system shall provide the ability to capture the identity of the ordering/authorizing provider for all test orders. The system shall provide the ability to capture appropriate order entry detail, including associated diagnosis.

IP 11.08

R
IP 11.14

R

2011

N

This includes physicians and authorized AM 12.01, DC.1.7.2.2 non-physicians.

1.59

LT 15.02

AM 12.02

1.60

2011

N
AM 12.03, DC.1.7.2.2

LT 15.03

1.52

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 19 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 15.04

Order diagnostic tests

The system shall provide the ability to relay orders for a diagnostic test to the correct destination for completion.

2011

N

Mechanisms for relaying orders may include providing a view of the order, sending it electronically, or printing a copy of the order or order requisition.

AM 12.05, DC.1.7.2.2

2.14, 2.26.01

LT 15.05 LT 15.06

Order diagnostic tests Order diagnostic tests Order diagnostic tests

The system shall provide the ability to provide a view of active orders for an individual patient. The system shall provide the ability to provide a view of orders by like or comparable type, e.g., all radiology or all lab orders. The system shall provide the ability to display outstanding orders for multiple patients (as opposed to outstanding orders for a single patient). The system shall provide the ability to display instructions and/or prompts when ordering diagnostic tests or procedures.

2011

N

Additional sorts and filters may be provided by a system but not required. May include filters or sorts.

AM 12.06, DC.1.7.2.2

1.60 2.48

AM 12.07, DC.1.7.2.2

2011

O
A report may satisfy this criterion. AM 12.08 Multiple patients may be defined as all patients in the organization or a subset.

LT 15.07

2.47

2011

O

LT 15.08

Order diagnostic tests

RS

Refers to diagnostic test or procedure AM 12.04, DC.1.7.2.2 specific instructions and/or prompts; not patient specific instructions and/or prompts. Instructions and/or prompts may be created by the system administrator. A 3rd party product may be used, providing that the instructions and/or prompts appear at the point of care. The intent is to have the ability for one AM 12.09 user to enter an order, place it in "pending" or similar status, so that a subsequent provider can complete and submit the order.

LT 15.09

Order diagnostic tests

The system shall provide the ability for a user to select an order for a diagnostic test and exit the process of creating the order at some point prior to completion such that another user can access the order for subsequent review and completion. The system shall provide the ability to capture and communicate referral(s) to other care provider(s), whether internal or external to the organization.

RS

LT 16.01

Referral Management

DC.1.7.2.4

R

LT 16.02 LT 16.03

Referral Management Referral Management

The system shall provide the ability to capture clinical details as necessary for the referral. The system shall provide the ability to capture and display administrative details (such as insurance information, consents, and authorizations for disclosure) as necessary for the referral. The system shall provide the ability to capture completion of a referral appointment.

R

DC.1.7.2.4 DC.1.7.2.4

R

LT 16.04

Referral Management

R

Currently this could be met through a DC.1.7.2.4 scanned report or a free text note. This is not the creation of the appointment itself. It is the documentation that the referral appointment has occurred. DC.2.4.4.2

LT 16.05

Referral Management

The system shall have the ability to present recommendations for potential referrals based on patient condition (e.g. conditions triggered from MDS such as declining ADL's, vision or hearing problems, abnormal lab values, recommendation for medication evaluation, etc).

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 20 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 16.06

Referral Management Order Sets

LT 17.01

The system shall provide the ability to record user ID and date/time stamp for all referral related events. The system shall provide the ability to define a set of items to be ordered as a group. The system shall provide the ability to modify order sets. The system shall provide the ability to include in an order set, "order types," including but not limited to medications, laboratory tests, imaging studies, procedures, and referrals. The system shall provide the ability for individual orders in an order set to be selected or deselected by the user. The system shall provide the ability to apply drugdrug, drug-allergy, and drug-disease interactionchecking in the same way to orders placed through an order set as to orders placed individually. The system shall provide the ability to display orders placed through an order set either individually or as a group. The system shall provide the ability to present information necessary to correctly identify the patient and accurately identify the specimen to be collected including, but not limited to, patient name, specimen type, specimen source, means of collection, date, and time. The system shall provide the ability to report variation between the type of specimen order placed and actual specimen received. The system shall provide the ability to capture the details of specimen collection. The system shall provide the ability to indicate normal and abnormal results based on data provided from the original data source. The system shall provide the ability to display nonnumeric current and historical test results as textual data. The system shall provide the ability to notify the relevant providers (ordering, copy to) that new results have been received.

Necessary for medico-legal purposes.

AM 21.02, DC.2.4.2

R
The intent is that the Order Set thus defined will be used across multiple patients on multiple occasions. FN 10.01

R

LT 17.02 LT 17.03

Order Sets Order Sets

R

FN 10.02 FN 10.03

R
FN 11.01

LT 17.04

Order Sets

R
FN 11.03

LT 17.05

Order Sets

R

LT 17.06

Order Sets

FN 11.04

R
DC.2.4.5.2

LT 18.01

Specimen Collection

RS

LT 18.02

Specimen Collection Specimen Collection Results

DC.2.4.5.2

RS RS
DC.2.4.5.2 As each lab has it's own normal values, AM 14.01, DC.1.8.3 these should be reflected in the indication as to whether a lab is normal or abnormal. AM 14.03, DC.1.8.3

LT 18.03 LT 19.01

2.38

2011

N

LT 19.02

Results

2.18

2011

N
Examples of notifying the provider AM 14.04, DC.1.8.3 include, but are not limited to, a reference to the new result in a provider "to do" list or inbox. May include an alert. AM 14.07, DC.1.8.3

LT 19.03

Results

2.38

2011

N

LT 19.04

Results

The system shall provide the ability to forward results or forward an alert that new results are available to other users.

2.38

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 21 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 19.05

Results

LT 19.06

Results

The system shall provide the ability for a user to attach a free text comment to a result that can be seen by another user who might subsequently view that result. The system shall provide the ability to display numerical results in flow sheets and graphical form in order to compare results, and shall provide the ability to display values graphed over time. The system shall provide the ability to filter or sort results by type of test and test date. The system shall provide the ability to link the results to the original order.

AM 14.09, DC.1.8.3

2.38

2011

N
It is desirable for the system indicate if abnormal results are high or low. AM 14.02, DC.1.8.3

R

LT 19.07 LT 19.08

Results Results

R

AM 14.05 This link can be effected manually by AM 14.08, DC.1.8.3 changing the status of the order from pending to complete. Future requirements could automate this link for certain electronically received labs. Not all types of orders can be electronically linked given the variety of result formats (e.g., PT consults, diabetes education).

R

LT 19.09 LT 19.10

Results Results

LT 20.01 LT 20.02

Consents and authorizations Consents and authorizations

The system shall provide the ability to associate one or more images with a non-numerical result. The system shall provide the ability for a user to whom a result is presented to acknowledge the result. The system shall provide the ability to capture scanned paper consent documents. The system shall provide the ability to store, display, and print patient consent forms.

R R 2011 N

Through direct storage or links to the data. This is separate from audit trail.

AM 14.10, DC.1.8.3 AM 14.11, DC.1.8.3

AM 15.01, DC.1.3.3 For example, consent forms stored in the computer which are capable of being signed by the patient with either an electronic pen or a digital signature when widely available. Needed for HIPAA. Scanned copy is acceptable for current year. AM 15.02, DC.1.3.3

1.10 1.10

2011

N

LT 20.03

Consents and authorizations Consents and authorizations Consents and authorizations Consents and authorizations

LT 20.04

The system shall provide the ability to store and display administrative documents (e.g. privacy notices). The system shall provide the ability to chronologically display consents and authorizations. The system shall provide the ability to sort and consents and authorizations chronologically, reverse chronologically, and by type. The system shall provide the ability to display and maintain electronic consent forms for patients using currently available digital signature standards. Electronically signed consent forms shall be maintained within the patient medical record.

AM 15.04, DC.1.3.3

1.10

2011

N

AM 15.05, DC.1.3.3

1.11

2011

N
DC.1.3.3

LT 20.05

1.11

2011

N
This depends on the establishment of national infrastructure for managing digital signatures at the point of care. AM 15.03

LT 20.06

R

LT 20.07

Consents and authorizations

The system shall provide the ability to document the source of each consent and authorization, such as the patient or the patient‟s legally authorized representative if the patient is unable to provide it.

DC.1.3.3

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 22 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 20.08

Consents and authorizations Patient advance directives Patient advance directives

LT 21.01

The system shall provide the ability to document the patient‟s legally authorized representative‟s authority to make decisions. The system shall provide the ability to indicate that a patient has completed advance directive(s). The system shall provide the ability to indicate the type of advance directives, such as a living will, durable power of attorney, or a "Do Not Resuscitate" order. The system shall provide the ability to time and date stamp the entry of advance directives information. The system shall provide the ability to indicate the name and relationship of the party completing the advance directive for the patient. The system shall provide the ability to indicate when advance directives were last reviewed. The system shall provide the ability to record and display the expiration data of the advance directives. The system shall have the ability to provide access to standard care plan, protocol and guideline documents when requested at the time of the clinical encounter. These documents may reside within the system or be provided through links to external sources. The system shall provide the ability to create patientspecific care plan.

R

This may captured using a scanned document or entered in as free text.

DC.1.3.3

2011

N

Important for appropriate use of resources at end of life and may just include a yes, no indication.

AM 16.01, DC.1.3.2

1.09

LT 21.02

This may be recorded in non-structured AM 16.02, DC.1.3.2 data or as discrete data.

1.09

2011

N
DC.1.3.2

LT 21.03

Patient advance directives Patient advance directives Patient advance directives Patient advance directives Care plans, guidelines, protocols

1.09

2011

N
DC.1.3.2

LT 21.04

1.09

R R R
This requirement could be met by including links or access to a text document. Road map would require more comprehensive decision support in the future. This includes the use of clinical trial protocols to ensure compliance. AM 17.01, DC.2.2.1.1 This may be recorded in non-structured AM 16.03, DC.1.3.2 data or as discrete data. Source is WG discussion.

LT 21.05 LT 21.06

LT 22.01

1.34

2011

N

LT 22.02

Care plans, guidelines, protocols

2011

N

This includes the use of clinical trial DC.2.2.1.1 protocols to ensure compliance. It is expected that in the future discrete data elements from other areas of the chart will populate matching fields. This inludes the ability to customize care plans at the patient level. AM 17.03, DC.2.2.1.1

1.34

LT 22.03

Care plans, guidelines, protocols Care plans, guidelines, protocols Care plans, guidelines, protocols Care plans, guidelines, protocols

LT 22.04

The system shall provide the ability to modify patient -specific standard care plan, protocol, and guideline documents obtained from outside sources. The system shall provide the ability to maintain and display multiple component careplans/carepaths per patient. The system shall provide the ability to maintain and display discipline-specific careplans/carepaths. The system shall provide the ability to specify that a careplan applies to multiple disciplines.

1.35

2011

N
This could be accomplished with Source is WG discussion. mulitple care plans or a single careplan that allows for the management of multiple problems. This could include a filter that permits each discipline to see their portion of the careplan. Source is WG discussion.

2.60

2011

NH

LT 22.05

2.61

2011

NH

LT 22.06

Source is WG discussion.

2.60

2011

NH

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 23 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 22.07

Care plans, guidelines, protocols

The system shall provide the ability for goals to be viewed by all disciplines.

Source is WG discussion.

1.38

2011

N

LT 22.08

LT 22.09

LT 22.10

LT 23.01

Care plans, guidelines, protocols Care plans, guidelines, protocols Care plans, guidelines, protocols Medication Administration Medication Administration

The system shall provide the ability for assessment answers to trigger suggested care plans/pathways/interventions. The system shall provide the ability to specify the plan for the next visit. The system shall provide the ability to view the plans for the next visit plans on the subsequent visit. The system shall provide the ability to present the list of medications that are to be administered. The system shall provide the ability to display the timing (e.g. frequency and hour of administration), route of administration, and dose of all medications on the list. 2011 N

RS

This will be required in the LTPAC base Source is WG discussion. certfication in the future.

Source is WG discussion.

RH
Source is WG discussion.

RH
DC.1.8.1

1.61

2011

N
This can be accomplished using free text. DC.1.8.1

LT 23.02

1.62

LT 23.03

Medication Administration Medication Administration Medication Administration

LT 23.04 LT 23.05

The system shall provide the ability to display order directions (SIG) for administration of all medications on the list. The system shall provide the ability to indicate when medication related activities are due. The system shall provide the ability to present information necessary to correctly identify the patient (e.g., bar-coding, wristbands, patient photo, or other means of positive patient identification.) The system shall provide the ability to capture medication administration details, including time of administration, observations, complications, and the reason why a medication was not administered.

2011 2011

N NS

This can be accomplished using free text.

DC.1.8.1

1.61

DC.1.8.1 DC.2.3.2

2.39 2.03

2011

NS

LT 23.06

Medication Administration

Observations and complications can be DC.1.8.1 captured using free text.

2.39

2011

NS

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 24 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 23.07

Medication Administration

LT 23.08

Medication Administration

LT 23.09

Medication Administration Immunization Management

LT 24.01

The system shall provide the ability to capture medication administration details as discrete data, including: (1) the medication name and dose; (2) date and time of administration; (3) route and site; (4) lot number and expiration date; (5) manufacturer; and (6) user ID. The system shall provide the ability to alert providers to potential administration errors (such as wrong patient, wrong drug, wrong dose, wrong route, and wrong time) as it relates to medication and immunization administration. The system shall provide the ability to alert providers to potential medication administration errors at the point of medication administration. The system shall provide the ability to document clinical assessment pertinent to immunization administration. 2011 N

FN 15.01

R

DC.2.3.2

RS

DC.2.3.2

RS
An example is common screening questions/actions asked prior to administering a vaccine, i.e., taking the patient's temperature, asking if there is an allergy to eggs. Free text is acceptable for now, should be discrete data in the future. IP 15.07

2.21

LT 24.02 LT 24.03

Immunization Management Immunization Management

LT 24.04

Immunization Management Immunization Management

LT 24.05

The system shall provide the ability to print the immunization administration record. The system shall provide the ability to record the consent, refusal, or deferral status as it relates to the administration of each immunization at the time of each encounter, including: the date and time; the decision (consent, refusal, or deferral); and name of authorizing individual and status of authorizing individual (e.g. parent, self, legal guardian, medical power of attorney). The system shall provide the ability to capture, in a discrete field, an allergy/adverse reaction to a specific immunization. The system shall provide the ability to capture immunization administration details as discrete data, including: (1) the immunization type and dose; (2) date and time of administration; (3) route and site; (4) lot number and expiration date; (5) manufacturer; and (6) user ID. The system shall provide the ability to inform the clinician when immunizations are recommended. The system shall provide the ability to present information necessary to correctly identify the patient and accurately administer blood products, including patient name, blood product number, amount, route, product expiration date and time of administration.

2011

N

IP 15.11 Free text is acceptable for now, should IP 15.12, PeDSSIG, AAP be discrete data in the future

2.23 2.22

2011

N

FN 16.02

R
FN 16.03

R

LT 24.06 LT 25.01

Immunization Management Blood Administration

R

IP 12.42 DC.2.4.5.1

RS

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 25 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 25.02

Blood Administration Blood Administration Blood Administration

LT 25.03

LT 25.04

The system shall provide the ability to capture validation that the correct match of the patient to the blood product occurred. The system shall provide the ability to capture the blood product number, amount, route, and time of administration. The system shall provide the ability to capture the blood pressure, temperature, pulse, and respirations of the patient receiving the product.

DC.2.4.5.1

RS
DC.2.4.5.1

RS
DC.2.4.5.1

RS

LT 26.01

LT 26.02

LT 26.03

Disease management, preventive services and wellness Disease management, preventive services and wellness Disease management, preventive services and wellness Disease management, preventive services and wellness Disease management, preventive services and wellness

The system shall provide the ability for the provider to override established treatment guidelines. R

The end user can override guidelines when appropriate to a specific clinical situation.

DC.2.5.1

The system shall provide the ability for the user to document the reason(s) for overriding established treatment guideline alerts.

Needed for medico-legal reasons and clinical decision support.

DC.2.5.1

R

The system shall provide the ability to modify the rules or parameters upon which treatment guideline alerts are based.

R

This is necessary for modifications, as DC.2.5.1 guidelines change or practices wish to adhere to more stringent levels, for example, using a HbA1c target of 6.5%, instead of 7%. AM 22.09, DC.2.5.1

LT 26.04

The system shall provide the ability to document that adherence to an established treatment guideline was performed based on activities documented in the record (e.g. vitals signs taken). The system shall provide the ability to individualize alerts to address a patient's specific clinical situation.

R

LT 26.05

R

This is done at the patient level. AM 22.11 Examples include but are not limited to: removing a mammography reminder for woman that has had a mastectomy; removing an annual pap smear alert for a woman who has had a complete hysterectomy; or inactivate an alert for routine colon cancer screening in a patient who is terminally ill.

LT 26.06

Disease management, preventive services and wellness

The system shall provide the ability to identify preventive services, tests, or counseling that are due for an individual patient.

AM 23.01, DC.2.5.2

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 26 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 26.07

LT 26.08

LT 26.09

LT 26.10

Disease management, preventive services and wellness Disease management, preventive services and wellness Disease management, preventive services and wellness Disease management, preventive services and wellness

The system shall provide the ability to display reminders for disease management, preventive, and wellness services in the patient record.

AM 23.02, DC.2.5.2

R

The system shall provide the ability to notify the provider that patients are due or are overdue for disease management, preventive, and wellness services. The system shall provide the ability to produce a list of patients who are due or are overdue for disease management, preventive andwellness services.

AM 23.06, DC.2.5.2

R

For example, getting their flu, pneumonia, or shingles vaccine.

AM 23.07, DC.2.5.2

R

The system shall provide the ability to automatically generate an electronic/online reminder to the patient or the patient's guardian of disease management, preventive, or wellness services coming due or those that are overdue.

R

The term 'automatically' means that the AM 23.10 system is able to generate patient recalls for all due or overdue reminders for an individual patient based on the current date, regardless of whether a user initiates this action, or if the action is triggered by pre-set parameters in the system. The WG will work with Interoperability to determine the appropriate certification year, based on availability of secure messaging criteria. Messages could be sent by the EHR or through a third-party. Electronic/online reminders could include secure email, PHR, or text message.

LT 27.01

Clinical Task Management

The system shall provide the ability to create and assign tasks by user or user role. 2011 O

Examples of tasks are messages, notifications, inbox items, worklist todo's. This task assignment refers to internal users. External tasks would be handled under Ordering category. Examples of tasks are messages, notifications, inbox items, worklist todo's. This task assignment refers to internal users. External tasks would be handled under ordering section.

AM 24.01, DC.3.1.1

2.49

LT 27.02

Clinical Task Management

The system shall provide the ability to present a list of tasks by user or user role. 2011 O

AM 24.02, DC.3.1.1

2.49

LT 27.03 LT 27.04 LT 27.05

Clinical Task Management Clinical Task Management Clinical Task Management Clinical Task Management

The system shall provide the ability to re-assign and route tasks from one user to another user. The system shall provide the ability to designate a task as completed. The system shall provide the ability to remove a task without completing the task. The system shall provide the ability to notify the clinician of overdue medication administrations.

2011 2011

O N
Removing a task eliminates it from an individual user's "to do" list, not from audit logs, etc.

AM 24.03, DC.3.1.1 AM 24.04, DC.3.1.1 AM 24.05, DC.3.1.1

2.49 2.50 2.50

2011

N

LT 27.06

2011

NS RH

IP 17.03

2.39

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 27 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 27.07

Clinical Task Management Clinical Task Management

The system shall provide the ability to notify the ordering clinician concerning orders due to expire. The system shall provide the ability to notify the ordering clinician concerning orders requiring signature (verbal and telephone orders, cosignature). The system shall provide the ability to the provider to redirect the notification concerning orders requiring signature to another provider.

RS RH
For example, verbal,and telephone orders, co-signature.

IP 17.05

LT 27.08

IP 17.08

RS
The provider may know the responsible IP 17.09 provider (mistake or change since order placed).

LT 27.09

Clinical Task Management

RS

An audit trail should be created which records both the original and new responsible clinician. Free text is acceptable. AM 25.01, DC.3.2.1

LT 28.01

Inter-provider communication Inter-provider communication

LT 28.02

The system shall provide the ability to document verbal/telephone communication into the patient record. The system shall provide the ability to support messaging between users.

2.42

2011

N
Results and other patient data could be AM 25.03, DC.3.2.1 included. As clarification, messaging is defined as any text string sent from one person to another in the office. Source is WG discussion.

2.31

2011

N

LT 28.03

Inter-provider communication Provider Information Provider Information

LT 29.01

LT 29.02

LT 29.03

Provider Information

The system shall provide the ability to capture and display documentation by clinicians of their communication with the patient‟s physician. The system shall provide the ability to maintain a directory which identifies the physician by multiple unique identifiers. The system shall provide the ability to capture and maintain, as discrete data elements, the specific role of all providers associated with a specific patient. The system shall provide the ability to capture and maintain, as discrete data elements, the principal physician responsible for the oversight of an individual patient.

2.42

2011

N
IP 02.05, 45 CFR Part 162

ADM.12

2011

N
For example, responsible physician, FN 03.01.01 attending, admitting, primary care provider, consulting, nurse, therapist, or pharmacist. FN 03.02, S.3.4

ADM.02

2011

N

2.04

2011

N

LT 29.04

Provider Information Provider Information

LT 29.05

LT 29.06

Provider Information

The system shall provide the ability to maintain a directory of all clinical personnel who currently use or access the system. The system shall provide the ability to maintain a directory which contains identifiers required for licensed clinicians to support the practice of medicine including at a minimum state medical license, NPI, and UPIN number. The system shall provide the ability for authorized users to update the directory.

AM 27.01, S.1.3.1

2011

N
This directory may be the same as that in criterion LT 29.06 for this functionality. AM 27.02, S.1.3.1

ADM.12, SEC 5.04, 5.09 ADM.12

2011

N

2011

N

Authorized user is not necessarily the same as the Directory Administrator.

AM 27.03, S.1.3.1

SEC 5.41

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 28 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 29.07

Provider Information

The system shall provide the ability to create and maintain a directory of clinical personnel external to the organization who are not users of the system to facilitate communication and information exchange.

2011

N

Referral sources, attending physicians, AM 27.04, S.1.3.1 DME providers, pharmacies, regulatory agencies, Adult Protection and families.

ADM.13

LT 29.08

Provider Information

LT 30.01

The system shall provide the ability to assign clinicians to appropriate teams, where teams are defined as groups of clinicians who share responsibility for covering the same group of patients. Medical Equipment The system shall provide the ability to capture a list of the patient's specialized medical equipment and each prosthetic, orthotic, or implantable device.

IP 02.02, S.1.3.5

R

Free text entry of this information is acceptable.

DC.1.4.5

1.20

2011

N

LT 30.02

Medical Equipment The system shall provide the ability to capture the reason for the specialized medical equipment and each prosthetic, orthotic, or implantable device. Medical Equipment The system shall provide the ability to capture the specific type of specialized medical equipment, prosthetic, orthotic, or implantable device. Medical Equipment The system shall provide the ability to capture in a discrete field that the patient has No Known specialized medical equipment or prosthetic, orthotic, or implantable device for the patient. Medical Equipment The system shall provide the ability to capture information necessary to identify and track the equipment/device as discrete entries. Such information may include, but is not limited to: type, manufacturer, manufacture date, date implanted (or placed into service), model/serial number, anatomical location, etc. Medical Equipment The system shall provide the ability to delete or inactivate the documentation of the specialized medical equipment or prosthetic, orthotic, or implantable devices. Medical Equipment The system shall provide the ability to present a list of the deleted inactivated/discontinued specialized medical equipment or prosthetic, orthotic, or implantable devices and reason for deletion. Medical Equipment The system shall provide the ability to electronically receive and maintain relevant clinical data captured by telemedicine devices in the patient‟s home.

DC.1.4.5

R
DC.1.4.5

LT 30.03

R
DC.1.4.5

LT 30.04

R
DC.1.4.5

LT 30.05

R

LT 30.06

DC.1.4.5

R
DC.1.4.5

LT 30.07

R

LT 30.08

If patient is particpaing in telehealth.

Source is WG discussion.

RH

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 29 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 31.01

Assessment Instrument Assessment Instrument

LT 31.02

The system shall provide the ability to capture all data elements as defined in the most recent federally mandated assessment applicable to the care site. The system shall provide the ability to perform Medicare payment calculations from federally mandated assessment data items in accordance with the most recent algorithms provided by CMS and populate the payment calculation value to the appropriate federally mandated assessment data element.D314 The system shall provide the ability to perform State Medicaid payment calculations from federally mandated assessment data items in accordance with the most recent algorithms provided by the state agency of the jurisdiction in which the system is implemented, and populate the payment calculation value to the appropriate data element as required by jurisdictional law or regulation. The system shall provide the ability to perform data consistency edits as defined in the most recent federally mandated assessment data specification. The system shall provide the ability to calculate Resident Admission Protocols (RAP) or Care Area Assessments (CAA) Triggers (CAT) in accordance with the most recent federally mandated assessment data specification. The system shall provide the ability to capture the clinician assessment process for triggered Care Area Assessments (CAA). Resident Admission Protocols (RAP) or Care Area Triggers (CAT). The system shall provide the ability to implement federally mandated assessment data correction and assessment locking processes as defined in the most recent version of the CMS Correction Policy. The system shall provide the ability to export federally mandated assessment data. The system shall provide the ability to access, view, report, and display all previously completed federally mandated assessments. The system shall provide the ability to indicate datesensitive Core Based Statistical Area (CBSA) codes. The system shall provide the ability to generate a Home Health Certification and Plan of Care with all the required elements (e.g., CMS 485 form). The system shall provide the ability to issue alerts when follow-up federally mandated assessments are due.

2011

NS NH

For example, MDS in nursing homes and OASIS in home health.

DC.1.5.1

ADM.15.01

Example: RUG (Resource Utilizaiton Groups) in Home Health.

DC.1.5.1

ADM.15.07

2011

NS NH

LT 31.03

Assessment Instrument

Applicants might be required to selfDC.1.5.1 attest to compliance in the states where the vendor markets products.

ADM.15.08

2011

NS

LT 31.04

Assessment Instrument

DC.1.5.1

ADM.15.02

2011

NS NH
DC.1.5.1

LT 31.05

Assessment Instrument

ADM.15.04

2011

NS

LT 31.06

Assessment Instrument

DC.1.5.1

ADM.15.04

2011

NS

LT 31.07

Assessment Instrument

For example, MDS in nursing homes and OASIS in home health.

DC.1.5.1

ADM.15.10

2011

NS NH NS NH NS NH
DC.1.5.1 DC.1.5.1

LT 31.08 LT 31.09

Assessment Instrument Assessment Instrument Assessment Instrument

2011 2011

ADM.15.09, ADM.15.10 ADM.15.11

LT 31.10

Source is WG discussion.

1.04.03

2011

NH
Source is WG discussion.

LT 31.11

Assessment Instrument

ADM.15.12

2011

NH
Source is WG discussion.

LT 31.12

Assessment Instrument

2011

NS NH

2.52

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 30 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 31.13 LT 31.14

Assessment Instrument Assessment Instrument Assessment Instrument Assessment Instrument

LT 31.15

The system shall provide the ability to add custom items to an assessment form. The system shall provide the ability to incorporate skip logic during data entry in a federally mandated assessment. The system shall have the ability to save a federally mandated assessment in incomplete form.

2011 2011

N NS NH NS NH NS NH RS RH RS RH RH R RH
The intent of this criteria is to prevent the inappropraite lock of a federally mandated assessment. For example, MDS in nursing homes and OASIS in home health.

Source is WG discussion. Source is WG discussion.

1.33 ADM.15.03

Source is WG discussion.

ADM.15.05

2011

LT 31.16

LT 31.17

LT 31.18

LT 31.19 LT 31.20

LT 31.21 LT 32.01

The system shall provide the ability to prevent submission of a federally mandated assessment when any required element is incomplete. Assessment The system shall provide the ability to create Instrument federally mandated assessment data submission files in accordance with the most recent data specifications. Assessment The system shall provide the ability to flag for Instrument inconsistencies between OASIS, Plan of Care, and treatment performed by providers. Assessment The system shall provide the ability to flag potential Instrument LUPA and PEP situations. Assessment The system shall provide the ability to produce Instrument reports that allow for analysis of utilization and reimbursement. Assessment The system shall provide the ability to track therapy Instrument visit thresholds from OASIS to actual. Report generation The system shall provide the ability to generate reports of clinical and administrative data using either internal or external reporting tools.

Source is WG discussion.

ADM.15.06

2011

DC.1.5.1

Source is WG discussion.

Source is WG discussion. For example, case mix, visits by HHRG, Source is WG discussion. etc.

Source is WG discussion. Needed for pay for performance, quality AM 29.01, S.2.2 improvement activities. All data that is entered in a structured format should be individually reportable.

ADM.10

2011

N

LT 32.02

LT 32.03

LT 32.04 LT 32.05

LT 32.06

LT 32.07

Report generation The system shall provide the ability to generate reports consisting of all or part of an individual patient‟s medical record (e.g. patient summary). Report generation The system shall provide the ability to generate reports regarding multiple patients (e.g. diabetes roster). Report generation The system shall provide the ability to access reports outside the EHR application. Report generation The system shall provide the ability to specify report parameters (sort and filter criteria) based on patient demographic and clinical data (e.g., all male patients over 50 that are diabetic and have a HbA1c value of over 7.0, or that are on a certain medication). Report generation The system shall provide the ability to produce reports based on the absence of a clinical data element (e.g., a lab test has not been performed or a blood pressure has not been measured in the last year). Report generation The system shall provide the ability to save report parameters for generating subsequent reports.

Report format may be plain text.

AM 29.02, S.2.2

ADM.11

2011

N
Any disease registry might be included. AM 29.03, S.2.2

ADM.07

2011 2011

N N
For example, printed output, export to a AM 29.05, S.2.2 file, etc. Minimum demographic data are age and AM 29.04, S.2.2 gender.

R

AM 29.06, S.2.2

R

AM 29.07, S.2.2

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 31 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 32.08

Report generation The system shall provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification. Health record output The system shall provide the ability to define one or more reports as the formal health record for disclosure purposes. 2011 N

It is acceptable if a third-party reporting AM 29.08, S.2.2 tool or application is used.

R
This curtails the ability to print AM 30.01, S.2.2.1 demographics, certain confidential sections, or other items. Report format may be plain text initially. In the future there will be a need for structured reports as interoperability standards evolve. AM 30.02, S.2.2.1

LT 33.01

2.44

LT 33.02

Health record output Health record output Health record output

LT 33.03

LT 33.04

The system shall provide the ability to generate hardcopy or electronic output of part or all of the individual patient's medical record. The system shall provide the ability to generate hardcopy and electronic output for an identified individual by date and/or date range. The system shall provide the ability to create hardcopy and electronic report summary information (procedures, medications, labs, immunizations, allergies, and vital signs).

ADM.11

2011

N
It is not required that output by date or date range includes items that are not date specific. AM 30.03, S.2.2.1

2.55

2011

N

The report that's produced should be AM 30.05, S.2.2.1 organized by section to make it easier to read.

2.56

2011

O

LT 33.05

Health record output

The system shall provide the ability to support for disclosure management in compliance with HIPAA and applicable law.

2011

N

This criterion may be satisfied by AM 30.06 providing the ability to create a free text note in the patient's record. More advanced functionality may be market differentiators or requirements in later years. IP 19.02, S.2.2.1

2.54

LT 33.06

Health record output

The system shall provide the ability to include patient identifying information, as well as time and date report printed, on each page of individual patient-specific reports generated.

2.56

2011

O

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 32 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 33.07

Health record output

The system shall provide the ability to export structured data which removes those identifiers listed in the HIPAA definition of a limited dataset. This export on hardcopy and electronic output shall leave the actual PHI data unmodified in the original record.

R

De-identifying data on hardcopy or AM 30.04, S.2.2.1 electronic output is necessary for research. However, it must be emphasized that this function is not intended to cleanse the text in the note or data in the original record. As per HIPAA Standards for Privacy of Individually Identifiable Health Information, 45 CFR Parts 160 and 164, identifiers that shall be removed are: 1. Names; 2. Postal address information, other than town or city, state and zip code; 3. Telephone numbers; 4. Fax numbers; 5. Electronic mail addresses; 6. Social security numbers; 7. Medical record numbers; 8. Health plan beneficiary numbers; 9. Account numbers; 10. Certificate/license numbers; 11. Vehicle identifiers and serial numbers, including license plate numbers; 12. Device identifiers and serial numbers; 13. Web Universal Resource Locators (URLs); 14. Internet Protocol (IP) address numbers; 15. Biometric identifiers, including finger and voice prints; and 16. Full face photographic images and any comparable images.

LT 34.01

Clinical research

The system shall provide the ability to present protocols for patients enrolled in research studies.

DC.2.2.3

R

LT 34.02

Clinical research

The system shall provide the ability to maintain research study protocols. R

DC.2.2.3

LT 34.03

Clinical research

The system shall provide the ability to indicate whether a patient is enrolled in a clinical trial.

This should be captured as discrete data.

IP 19.09

R
For example, ICD-9 CM, ICD-10 CM, SNOMED or CPT-4 codes. AM 32.01, S.3.2.2

LT 35.01

Administrative

The system shall provide the ability to provide a list of financial and administrative codes.

2011

N

ADM.03

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 33 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 35.02

Administrative

The system shall provide the ability to display a schedule of patient appointments, populated either through data entry in the system itself, or through an external application interoperating with the system. The system shall provide the ability to select an appropriate CPT Evaluation and Management code based on data found in a clinical encounter. The system shall provide the ability to provide assistance with selecting an appropriate CPT Evaluation and Management billing code based on codified clinical information in the encounter.

R

Patient appointments could be doctor visits (regulated in NH), required nursing visits (MDS, OASIS, and supervisory) and ordered visits (home care only. May be accomplished via a link to another application.

AM 28.01, S.1.6

LT 35.03

Administrative

AM 32.02, S.3.2.2

R
Criterion satisfaction will require that the AM 32.03, S.3.2.2 system can automatically count elements in the history and examination documentation to accomplish this calculation. MDM complexity may still require specification by the provider/coder. CPT-4 codes and drug interactions are examples. Any method of updating would be acceptable. Content could be third party or provider-created. AM 35.01, S.3.7.1

LT 35.04

Administrative

RS

LT 36.01

Clinical decision support administration

The system shall provide the ability to update the clinical content or rules utilized to generate clinical decision support reminders and alerts.

R

LT 36.02

LT 36.03

Clinical decision support administration Clinical decision support administration Confidentiality

LT 37.01

The system shall provide the ability to update clinical decision support guidelines and associated reference material. The system shall provide the ability to capture and maintain, as discrete data, the reason for variation from rule-based clinical messages (for example alerts and reminders). The system shall provide the ability to document a patient's dispute with information currently in their chart.

R

Any method of updating would be AM 35.02, S.3.7.1 acceptable. Content could be third party or provider-created. An example is "patient refused." FN 18.02

R
This does not imply that the patient can AM 36.02, I.1.9 document directly in their chart. Some methods include but are not limited to allowing the patient a view only access to their record, or printing a copy of the record for a patient to review. Methods to include the information in the chart could be as a note, a scanned copy of patient comments, an addendum to the note, or other method not described.

2.28

2011

N

LT 37.02

Confidentiality

The system shall provide the ability to identify certain information as confidential and only make that accessible by appropriately authorized users. R

This may be implemented by having a AM 36.04, I.1.9 "confidential" section of the chart. In the future such confidential designation will be required at the data element level, e.g., individual problems on the problem list, medications, allergies, results, etc.

LT 37.03

Confidentiality

The system shall provide the ability to prevent specified user(s) from accessing a designated patient's chart.

R

An example would be to block a user who has a personal relationship with a patient from accessing that patient's chart.

AM 36.05, I.1.9

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 34 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

LT 37.04

Confidentiality

When access to a chart is restricted, the system shall provide the ability to appropriately authorized users to "break the glass" for emergency situations. R

AM 36.06

LT 37.05

Confidentiality

The system shall provide the ability to indicate when "break the glass" access to patient information occurred.

AM 36.08

R

LT 38.01

Data retention, availability and destruction

The system shall provide the ability to archive health record information. R

Archiving is used to mean information stored in a retrievable fashion without defining where or how it is stored.

AM 37.01, I.2.1

LT 38.02

LT 39.01

Data retention, availability and destruction Concurrent use

The system shall provide the ability to retrieve information that has been archived. The system shall provide the ability for multiple users to interact concurrently with the EHR application. The system shall provide the ability for concurrent users to simultaneously view the same record.

R

Retrieval does not imply restoration to current version of the software.

AM 37.03

AM 40.01, Ontario 5.6.1.a

2.35

2011

N
AM 40.02, Ontario 5.6.1.a

LT 39.02

Concurrent use

2.35

2011

N
AM 40.03, Ontario 5.6.1.a

LT 39.03

Concurrent use

LT 39.04

Concurrent use

The system shall provide the ability for concurrent users to view the same clinical documentation or template. The system shall provide the ability to maintain the integrity of clinical data during concurrent access.

2.36

2011

N
The intent of this criterion is to prevent AM 40.04, Ontario 5.6.1.a, I.1.9 users from simultaneously attempting to update a record with resultant loss of data. The test files are designed so that products implementing HL7 v2.5.1 standard will be found compliant. The test identifier will be encoded in LOINC, and will be drawn from among common test codes from the HEDIS subset. See LOINC.org for more about HEDIS. IO-AM 07.01, HL7 v2.5.1, LOINC For more information please refer to the CCHIT 2011 Certification Interoperability Testing Guide MU.P1.G1 MU.P1.EP.O11 IO-AM 07.02, HL7 v2.5.1, LOINC For more information please refer to the CCHIT 2011 Interoperability Testing Guide MU.P1.G1 MU.P1.EP.O11

R

IO-LT 07.01 Laboratory

The system shall provide the ability to receive and store general laboratory results (including the ability to differentiate preliminary results and final results and the ability to process a corrected result) using the HL7 v.2.5.1 ORU message standard.

R

IO-LT 07.02 Laboratory

The system shall provide the ability to receive and store microbiology laboratory results with organisms recorded as free-text. R

The test files are designed so that products implementing HL7 v2.5.1 standard will be found compliant. The test identifier will be encoded in LOINC, and will be drawn from among common test codes from the HEDIS subset. Organisms recorded as free-text in 2011. See LOINC.org for more about HEDIS.

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 35 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

IO-LT 07.04 Laboratory

The system shall provide the ability to receive and store microbiology laboratory results with sensitivity testing coded using LOINC. R

The test files are designed so that products implementing HL7 v2.5.1 standard will be found compliant. The test identifier will be encoded in LOINC, and will be drawn from among common test codes from the HEDIS subset. Organisms recorded as free-text in 2011. See LOINC.org for more about HEDIS.

IO-AM 07.04, HL7 v2.5.1, LOINC For more information please refer to the CCHIT 2011 Certification Interoperability Testing Guide MU.P1.G1 MU.P1.EP.O11

IO-LT 09.06 Medications / ePrescribing IO-LT 09.09 Medications / ePrescribing

The system shall provide the ability to send an electronic prescription to pharmacy. The system shall provide the ability to respond to a request for a resupply to the pharmacy.

RS

NCPDP SCRIPT Standard v10.1 or higher (NEWRX) IO-AM 09.09, Medication Management Interoperability Specification (HITSP v1.0 2008 IS07); NCPDP SCRIPT Standard 8.1 or higher (REFREQ and REFRES) An essential first step prior to sending a query for medication history or formulary information directed at prescription drug coverage. IO-AM 09.13, Medication Management Interoperability Specification (HITSP v1.0 2008 IS07) X12 270/271/ CORE Phase I Rules IO-AM 09.14, Medication Management Interoperability Specification (HITSP v1.0 2008 IS07); NCPDP Formulary and Benefit Standard Implementation Guide v1.0

RS

IO-LT 09.13 Medications / ePrescribing

The system shall provide the ability to send a query to verify prescription drug insurance eligibility and apply response to formulary and benefit files to determine coverage. The system shall provide the ability to capture and display formulary information from pharmacy or PBM (Pharmacy Benefits Manager) by applying eligibility response.

RS

IO-LT 09.14 Medications / ePrescribing

Usually preceded by a query for insurance eligibility to verify potential source of data.

RS

IO-LT 09.15 Medications / ePrescribing

The system shall provide the ability to send a query for medication history to PBM or pharmacy to capture and display medication list from the EHR. The system shall provide the ability to display HITSP C32/CCD documents and file them as intact documents in the EHR. Summary patient record content information will include: patient demographics, medication list, and medication allergy list.

RS
Requires the Document Consumer only to have the ability to display the document as requested. (it may not be able to locally import it in the patient record).

IO-AM 09.15, NCPDP SCRIPT Standard v8.1 or higher (RXHREQ, RXHRES) / NDC codes HITSP IS107 v1.0 - EHRCentric Interoperability Specification; CAP119 Communicate Structured Document Specification; C32 v.2.5 Summary Documents Using HL7 Continuity of Care Document (CCD); C80 v2.0 - Clinical Document and Message Terminology; C83 v2.0 - CDA Content Modules;

IO-LT 10.10 Clinical Documentation

3.02

2011

N

R

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 36 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

IO-LT 11.21 Clinical Documentation

The system shall provide the ability to generate and format patient summary documents per the following specifications: HITSP C32 (v2.3 or v2.5) Summary patient record content information will include: patient demographics, medications, and medication allergies. 2011 The intent is to test the Required (R) fields both documents. N R

Structured entries are optional for the following patient summary sections: immunizations, problem list, procedures, and diagnostic test results Use of the specified vocabularies is encouraged.

Summary Documents Using CCD Component (HITSP v2.3 C32) Consumer Empowerment Interoperability Specification (HITSP v3.0 IS03) -ORHITSP IS107 v1.0 - EHRCentric Interoperability Specification; CAP119 Communicate Structured Document Specification; C32 v.2.5 Summary Documents Using HL7 Continuity of Care Document (CCD); C80 v2.0 - Clinical Document and Message Terminology; C83 v2.0 - CDA Content Modules

3.03, 3.04, 3.05

SC 01.01

Access Control

The system shall enforce the most restrictive set of rights/privileges or accesses needed by users/groups (e.g. System Administration, Clerical, Nurse, Doctor, etc.), or processes acting on behalf of users, for the performance of specified tasks.

2011

N

ISO 17799: 9.1.1.2.b; HIPAA: 164.312(a)(1); 164.308(a)(3)(1) HITSP/TP20 NIST SP 800-53: AC-6 LEAST PRIVILEGE; AC-5 SEPARATION OF DUTIES

SEC 5.14, 5.15, 5.22, 5.25, 5.29

SC 01.02

Access Control

The system shall provide the ability for authorized administrators to assign restrictions or privileges to users/groups. 2011 N

Canadian: Alberta 4.1.3 (EMR); ISO 15408 CC SFR: FMT_MSA; NIST SP 800-53: AC-56 LEAST PRIVILEGE; AC-5 SEPARATION F DUTIES HIPAA: 164.312(a)(1); 164.308(A)(3)(1); HITSP/TP20 Canadian: Ontario 5.3.12.e (System Access Management); ISO 15408 CC SFR: FDP_ACC, FMT_MSA; ASTM: E1985-98; NIST SP 800-53: AC-3 ACCESS AND INFORMATION FLOW CONTROL; SC-3 SECURITY FUNCTION ISOLATION HIPAA: 164.312(a)(1); 164.308(A)(3)(1); HITSP/TP20

SEC 5.19

SC 01.03

Access Control

The system must be able to associate permissions with a user using one or more of the following access controls: 1) user-based (access rights assigned to each user); 2) role-based (users are grouped and access rights assigned to these groups); or 3) context-based (role-based with additional access rights assigned or restricted based on the context of the transaction such as timeof-day, workstation-location, emergency-mode, etc.)

SEC 5.10, 5.14, 5.15, 5.19, 5.22, 5.25, 5.29

2011

N

SC 01.04

Access Control

The system shall support removal of a user‟s privileges without deleting the user from the system. The purpose of the criteria is to provide the ability to remove a user‟s privileges, but maintain a history of the user in the system.

2011

N

HIPAA: 164.308(a)(4)(ii)(C); 164.308(a)(3)(i)(C); HITSP/TP20

SEC 5.41, 5.43, 5.44, 5.46, 5.48, 5.49

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 37 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 01.05

Access Control

SC 01.06

Access Control

SC 02.01

Audit

If role-based access control (RBAC) is supported, the system shall be able to support role based access control that is in compliance with the HL7 Permissions Catalog. If role-based access control (RBAC) is supported, the system must be capable of operating within an RBAC infrastructure conforming to ANSI INCITS 359-2004, American National Standard for Information Technology – Role Based Access Control. The system shall allow an authorized administrator to set the inclusion or exclusion of auditable events in SC 02.03 based on organizational policy & operating requirements/limits. 2011 N

R

HIPAA: 164.308(A)(3); HL7 Permissions Catalog, HITSP/TP20

R

HIPAA: 184.308(A)(3); ANSI INCITS 359-2004, American National Standard for Information Technology - Role Based Access Control; HITSP/TP20 ISO 15408 CC SFR: FAU_SEL; HIPAA 164.312(b); 164.308 (a)(1)(ii)(A), (D); Federal Register Response pages 8347, 8355; NIST SP 800-53 AU-2 AUDITABLE EVENTS (Organization Defined - Based on Risk Assessement) HITSP/TP15

SEC 5.53

SC 02.02

Audit

The system shall support logging to a common audit engine using the schema and transports specified in the Audit Log specification of IHE Audit Trails and Node Authentication (ATNA) Profile. The system shall be able to detect security-relevant events that it mediates and generate audit records for them. At a minimum the events shall include those listed in the Appendix Audited Events. Note: The system is only responsible for auditing security events that it mediates. A mediated event is an event that the system has some active role in allowing or causing to happen or has opportunity to detect. The system is not expected to create audit logs entries for security events that it does not mediate.

R

NIST SP 800-92/SP 800-92, HITSP T15 HIPAA 164.312(a)(1); 164.312(b); 164.308 (a)(1)(ii)(A) and (D); ISO 15408 CC SFR: FAU_GEN; NIST SP 800-53: AU-2 AUDITABLE EVENTS; HIPAA: 164.312(b); 164.312(1); 164.308 (a)(1)(ii)(A) and (D); HITSP/TP15

SC 02.03

Audit

SEC 5.54

2011

N

SC 02.04

Audit

The system shall record within each audit record the following information when it is available: (1) date and time of the event; (2) the component of the system (e.g. software component, hardware component) where the event occurred; (3) type of event (including: data description and patient identifier when relevant); (4) subject identity (e.g. user identity); and (5) the outcome (success or failure) of the event.

2011

N

ISO 15408 CC SFR: FAU_GEN; NIST SP 800-53: AU-3 CONTENT OF AUDIT RECORDS, AU-10 NONREPUDIATION; HIPAA: 164.312(b); HITSP/TP15

SEC 5.55

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 38 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 02.05

Audit

The system shall provide authorized administrators with the capability to read all audit information from the audit records in one of the following two ways: 1) The system shall provide the audit records in a manner suitable for the user to interpret the information. The system shall provide the capability to generate reports based on ranges of system date and time that audit records were collected. 2) The system shall be able to export logs into text format in such a manner as to allow correlation based on time (e.g. UTC synchronization).

Assignable to third party.

ISO 15408 CC SFR: FAU_SAR; NIST SP 800-53: AU-7 AUDIT REDUCTION AND REPORT GENERATION; HIPAA: 164.312(b); HITSP/TP15

SEC 5.55, 7.14

2011

N

SC 02.06

Audit

The system shall be able to support time synchronization using NTP/SNTP, and use this synchronized time in all security records of time.

Assignable to third party.

2011

N

ISO 15408 CC SFR: FPT_STM; NIST SP 800-53: AU-8 TIME STAMPS; HITSP/TP16 HIPAA: 164.312(b)

SEC 6.12, 7.18

SC 02.07

Audit

The system shall have the ability to format for export recorded time stamps using UTC based on ISO 8601. Example: "1994-11-05T13:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. The system shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. The system shall protect the stored audit records from unauthorized deletion. The system shall prevent modifications to the audit records.

R

ISO 15408 CC SFR: FPT_STM; NIST SP 800-53: AU-8 TIME STAMPS; HITSP/TP15 HIPAA: 164.312(b)

SC 02.08

Audit

Assignable to third party.

2011

N

ISO 15408 CC SFR: FAU_SAR, FAU_STG; NIST SP 800-53: AU-9 PROTECTION OF AUDIT INFORMATION; HIPAA: 164.312(a)(1); HITSP/TP15

SEC 5.15, 5.22

SC 03.01

Authentication

The system shall authenticate the user before any access to Protected Resources (e.g. PHI) is allowed, including when not connected to a network e.g. mobile devices.

Assignable to third party.

2011

N

Canadian: Alberta 1.1; ISO 15408 CC SFR: FIA_UAU, FIA_UID; NIST SP 800-53: IA-2 USER IDENTIFICATION AND AUTHENTICATION; HIPAA: 164.312(d)

SEC 5.19, 5.24, 5.31, 5.36, 5.38, 5.43, 7.09

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 39 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 03.02

Authentication

When passwords are used, the system shall support password strength rules that allow for minimum number of characters, and inclusion of alpha-numeric complexity.

Assignable to third party.

2011

N

Canadian: Alberta 7.3.12 (Security) Canadian Ontario 5.3.12.b (System Access Management); ISO 15408 CC SFR: FIA_SOS, FIA_UAU, FIA_UID; ASTM: E1987-98; NIST SP 800-53: IA-2 USER IDENTIFICATION AND AUTHENTICATION (no strength of password); ISO 17799: 9.3.1.d; HIPAA: 164.

SEC 5.11, 5.27, 5.32, 7.05

SC 03.03

Authentication

The system upon detection of inactivity of an interactive session shall prevent further viewing and access to the system by that session by terminating the session, or by initiating a session lock that remains in effect until the user reestablishes access using appropriate identification and authentication procedures. The inactivity timeout shall be configurable.

Assignable to third party.

2011

N

Canadian: Alberta 7.3.14 (Security) Canadian Ontario 5.6.12.a (Workstation Security); ISO 15408 CC SFR: FTA_SSL, FMT_SAE; NIST SP 800-53: AC-7 UNSUCCESSFUL LOGIN ATTEMPTS; AC-11 SESSION LOCK; AC-12 SESSION TERMINATION HIPAA: 164.312(a)(1); 164.312(a)(2)(iii)

SEC 5.26, 5.30, 5.31, 7.12

SC 03.04

Authentication

The system shall enforce a limit of (configurable) consecutive invalid access attempts by a user. The system shall protect against further, possibly malicious, user authentication attempts using an appropriate mechanism (e.g. locks the account/node until released by an administrator, locks the account/node for a configurable time period, or delays the next login prompt according to a configurable delay algorithm).

Assignable to third party.

2011

N

Canadian: Ontario 5.3.12.c (System Access Management); ISO 15408 CC SFR: FIA_AFL, FMT_SAE; NIST SP 800-53: AC-6 UNSUCCESSFUL LOGIN ATTEMPTS, AC-11 SESSION LOCK ; ISO 17799: 9.3.1.e, 9.5.2.e; HIPAA: 164.312(a)(1); 164.308(a)(5)(ii)C; 164.308(a)(6)

SEC 5.12, 5.34, 5.35, 5.36, 7.06

SC 03.05

Authentication

When passwords are used, the system shall provide an administrative function that resets passwords.

Assignable to third party.

2011

N

ISO 15408 CC SFR: FMT_MTD; ISO 17799: 9.2.3.b, (9.3.1.f); HIPAA: 164.312(d); 164.308(5)(ii)(D)

SEC 5.52, 7.15

SC 03.06

Authentication

When passwords are used, user accounts that have been reset by an administrator shall require the user to change the password at next successful logon.

Assignable to third party.

2011

N

ISO 15408 CC SFR: FMT_MTD; ISO 17799: 9.2.3.b, (9.3.1.f); HIPAA: 164.312(d); 164.308(5)(ii)(D)

SEC 5.58, 7.16

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 40 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 03.07

Authentication

The system shall provide only limited feedback information to the user during the authentication. 2011 N

Assignable to third party.

ISO 15408 CC SFR: FIA_UAU; NIST SP 800-53: IA-6 AUTHENTICATOR FEEDBACK; HIPAA: 164.312(d); 164.308(5)(ii)(D)

SEC 5.18, 5.20, 5.44, 7.08

SC 03.08

Authentication

The system shall support case-insensitive usernames that contain typeable alpha-numeric characters in support of ISO-646/ECMA-6 (aka US ASCII). When passwords are used, the system shall allow an authenticated user to change their password consistent with password strength rules (SC 03.02). When passwords are used, the system shall support case-sensitive passwords that contain typeable alpha-numeric characters in support of ISO646/ECMA-6 (aka US ASCII). When passwords are used, the system shall use either standards-based encryption, e.g., 3DES, AES, or standards-based hashing, e.g., SHA1 to store or transport passwords.

Assignable to third party.

2011

N
Assignable to third party.

ISO 15408 CC SFR: FMT_MTD; HIPAA: 164.312(a)(2)(i)

SEC 5.24, 7.11

SC 03.09

Authentication

2011

N
Assignable to third party.

ISO 15408 CC SFR: FMT_MTD; HIPAA: 164.308(a)(5)(ii)(D)

SEC 5.27, 5.32, 7.13

SC 03.10

Authentication

2011

N
Assignable to third party.

Canadian: Ontario 5.3.12 (b); NIST SP 800-63; HIPAA: 164.308(a)(5)(ii)(D)

SEC 5.17, 5.19, 5.24, 7.07

SC 03.11

Authentication

2011

N

Canadian: Ontario 5.3.12.a (System Access Management); ISO 15408 CC SFR: FCS_CKM; NIST SP 800-53: SC-12 CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT; HIPAA: 164.312(e)(1); 164.308(a)(5)(ii)(D) FIPS PUB 197 FIPS PUB 140-2

SEC 6.18, 6.19, 7.23, 7.24

SC 03.12

Authentication

When passwords are used, the system shall prevent the reuse of passwords previously used within a specific (configurable) timeframe (i.e., within the last X days, etc. - e.g. "last 180 days"), or shall prevent the reuse of a certain (configurable) number of the most recently used passwords (e.g. "last 5 passwords").

Assignable to third party.

2011

N

ISO 15408 CC SFR: FMT_MTD; ISO 17799 9.5.4.f; HIPAA 164.312(d); 164.308(a)(5)(ii)(D); NIST SP 800-53: IA5 AUTHENTICATOR MANAGEMENT

SEC 6.01, 7.25

SC 03.13

Authentication

The system shall support two-factor authentication in alignment with NIST 800-63 Level 3 Authentication. Note: This is to support the 21 CFR Parts 1300, 1304, et al. Electronic Prescriptions for Controlled Substances; Proposed Rule published on Friday, June 27, 2008, Federal Register / Vol. 73, No. 125.F11.

R

ISO 15408 CC SFR: FIA_UAU; NIST SP 800-53: IA-2/AC-19, OMB M-06-16; NIST SP 800-63; HIPAA: 164.306(a)(1); 164.308(a)(4)(ii)(B); 164.308(a)(4)(ii)(C)

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 41 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 04.01

Documentation

SC 04.02

Documentation

The system shall include documentation that describes the patch (hot-fix) handling process the vendor will use for EHR, operating system and underlying tools (e.g. a specific web site for notification of new patches, an approved patch list, special instructions for installation, and postinstallation test). The system shall include documentation that explains system error or performance messages to users and administrators, with the actions required. The system shall include documentation of product capacities (e.g. number of users, number of transactions per second, number of records, network load, etc.) and the baseline representative configurations assumed for these capacities (e.g. number or type of processors, server/workstation configuration and network capacity, etc). The system shall include documented procedures for product installation, start-up and/or connection. The system shall include documentation of the minimal privileges necessary for each service and protocol necessary to provide EHR functionality and/or serviceability. The system shall include documentation available to the customer stating whether or not there are known issues or conflicts with security services in at least the following service areas: antivirus, intrusion detection, malware eradication, host-based firewall and the resolution of that conflict (e.g. most systems should note that full virus scanning should be done outside of peak usage times and should exclude the databases.). If the system includes hardware, the system shall include documentation that covers the expected physical environment necessary for proper secure and reliable operation of the system including: electrical, HVAC, sterilization, and work area. The system shall include documentation that itemizes the services (e.g. PHP, web services) and network protocols/ports (e.g. HL-7, HTTP, FTP) that are necessary for proper operation and servicing of the system, including justification of the need for that service and protocol. This information may be used by the healthcare facility to properly configure their network defenses (firewalls and routers).

ISO 15408 CC SFR: AGD_ADM; HIPAA: 164.308(a)(5)(i)(B)

SEC 6.07

2011

N

2011

N

ISO 15408 CC SFR: AGD_ADM; HIPAA: 164.312(c)

SEC 6.08

SC 04.03

Documentation

2011

N

ISO 15408 CC SFR: AGD_ADM; NIST SP 800-53 CM-2; HIPAA: 164.312(c); 164.306(A)(1)

SEC 6.09

SC 04.04

Documentation

2011

N

ISO 15408 CC SFR: ADO_IGS; HIPAA: 164.312(c)

SEC 6.06

SC 04.05

Documentation

2011

N

NIST SP 800-53 AC-5 SEC SEPARATION OF DUTIES; CM7 Least Functionality; HIPAA: 164.312(a)(1); 164.312(a)(2) Canadian: Alberta 7.3.17 (Security); ISO 15408 CC SFR: FPT_TST ISO 15408 CC SFR: AGD_ADM; NIST SP 800-53 SI-3 MALICIOUS CODE PROTECTION; HIPAA: 164.308(a)(5)(i)(B)

6.05

SC 04.06

Documentation

SEC 6.03

2011

N

SC 04.07

Documentation

ISO 15408 CC SFR: AGD_ADM; HIPAA: 164.310(a)(2)

SEC 6.04

2011

N

SC 04.08

Documentation

ISO 15408 CC SFR: AGD_ADM; NIST SP 800-53 AC-5 CM-6; NIST SP 800-70; HIPAA 164.312(a)(1)

SEC 6.05

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 42 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 04.09

Documentation

SC 04.10

Documentation

The system shall include documentation that describes the steps needed to confirm that the system installation was properly completed and that the system is operational. The system shall include documentation available to the customer that provides guidelines for configuration and use of the security controls necessary to support secure and reliable operation of the system, including but not limited to: creation, modification, and deactivation of user accounts, management of roles, reset of passwords, configuration of password constraints, and audit logs.

2011

N
Assignable to third party.

ISO 15408 CC SFR: AGD_ADM; HIPAA: 164.312©

SEC 6.06

ISO 15408 CC SFR: AGD_ADM; HIPAA: 164.312(a) to 164.312(e)

SEC 5.04, 5.09, 6.02, 7.04

2011

N

SC 05.01

Technical Services The software used to install and update the system, independent of the mode or method of conveyance, shall be certified free of malevolent software (“malware”). Vendor may self-certify compliance with this standard through procedures that make use of commercial malware scanning software.

ISO 15408 CC SFR: ADO_DEL; HIPAA 164.308(a)(5)(ii)(B)

SEC 6.11

2011

N

SC 05.02

Technical Services The system shall be configurable to prevent corruption or loss of data already accepted into the system in the event of a system failure (e.g. integrating with a UPS, etc.). Technical Services The system shall support protection of confidentiality of all Protected Health Information (PHI) delivered over the Internet or other known open networks via encryption using triple-DES (3DES) or the Advanced Encryption Standard (AES) and an open protocol such as TLS, SSL, IPSec, XML encryptions, or S/MIME or their successors.

Assignable to third party.

ISO 15408 CC SFR: FPT_RCV; HIPAA 164.312(c)(1)

SEC 6.10, 7.17

2011

N
Assignable to third party. Canadian: Alberta 7.4.6.2 & 8.4.6.2 (Technical); ISO 15408 CC SFR: FCS_COP; FIPS 140-2; NIST SP 800-53: SC-13 CRYPTOGRAPHIC OPERATIONS; HIPAA: 164.312(e)(1); 164.312(a)(2)(iv) HITSP T17, FIPS PUB 140-2

SC 06.01

SEC 6.14, 7.19

2011

N

SC 06.02

Technical Services When passwords are used, the system shall not display passwords while being entered.

Assignable to third party.

2011

N
Assignable to third party.

ISO 15408 CC SFR: FPT_ITC; ISO 17799 9.2.3; HIPAA 164.312(a)(1)

SEC 5.20, 7.10

SC 06.03

Technical Services For systems that provide access to PHI through a web browser interface (i.e. HTML over HTTP) shall include the capability to encrypt the data communicated over the network via SSL (HTML over HTTPS). Note: Web browser interfaces are often used beyond the perimeter of the protected enterprise network

ISO 15408 CC SFR: AGD_ADM; HITSP/TP17; HIPAA: 164.312(e)(1); 164.312(a)(2)(iv)

SEC 6.17, 7.22

2011

N

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 43 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 06.04

Technical Services The system shall support protection of integrity of all Protected Health Information (PHI) delivered over the Internet or other known open networks via SHA1 and an open protocol such as TLS, SSL, IPSec, XML digital signature, or S/MIME or their successors.

Assignable to third party.

2011

N

ISO 15408 CC SFR: FPT_RCV; FIPS 140-2; SP800-53: SC-13 CRYPTOGRAPHIC OPERATIONS; HIPAA: 164.312(e)(1); HITSP T17

SEC 6.15, 7.20

SC 06.05

Technical Services The system shall support ensuring the authenticity of remote nodes (mutual node authentication) when communicating Protected Health Information (PHI) over the Internet or other known open networks using an open protocol (e.g. TLS, SSL, IPSec, XML sig, S/MIME). Technical Services The system, when storing PHI on any device intended to be portable/removable (e.g. thumbdrives, CD-ROM, PDA, Notebook), shall support use of a standards based encrypted format using triple-DES (3DES), or the Advanced Encryption Standard (AES), or their successors. Technical Services The system, prior to access to any PHI, shall display a configurable warning or login banner (e.g. "The system should only be accessed by authorized users"). In the event that a system does not support prelogin capabilities, the system shall display the banner immediately following authorization.

Assignable to third party.

2011

N

ISO 15408 CC SFR: FPT_RCV; HITSP T17; HIPAA: 164.312(d); 164.312(c)(1)

SEC 6.16, 7.21

SC 06.06

2011

N

FIPS 140-2, ISO 15408 CC SFR: FCS_COP, OMB M-0616, SP800-53: AC-19, HITSP T33; HIPAA: 164.312(e)(2)(ii) FIPS PUB 140-2

SEC 6.20, 7.26

SC 06.07

Assignable to third party.

2011

N

CC 2.1 L.4 TOE access banners (FTA_TAB); CC 3.0 FIA_TIN.1 Advisory warning message; NIST SP 800-53 AC-8 System Use Notification HIPAA 164.308(a)(5)(i); 164.308(a)(5)(ii)

SEC 5.13, 5.21

SC 07.01

Inter-Domain

The system shall be able to communicate identity information across domains and web services using standards based user authentication and access control. When the system uses HITSP TP13 (IHE XDS) as a Document Consumer, the system shall be able to use the TP13 “Document Integrity” option. This may be a configurable parameter or may be enabled at all times The system shall be able to generate a backup copy of the application data, security credentials, and log/audit files. 2011 N

R

HITSP/C19, ANSI INCITS 3592004, American National Standard for Information Technology - Role Based Access Control, SAML v2.0; HIPAA 164.312(d) HITSP TP13 (IHE XDS); HIPAA 164.312(c)(1); 164.312(e)(1); 164.312(e)(2);

SC 07.02

Inter-Domain

R

SC 08.01

Backup/Recovery

Assignable to third party.

Canadian: Alberta 7.3.16 (Security); ISO 15408 CC SFR: FDP_ROL, FPT_RCV; HIPAA: 164.310(d)(1)

SEC 5.01, 7.01

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 44 of 45

Roadmap 1

Criteria #

Category

Criteria

Year introduced or last modified

2011 Certification

Roadmap 2

Comments

Criteria Reference

Test Script and Step Number SEC = Security Test Script

SC 08.02

Backup/Recovery

The system restore functionality shall result in a fully operational and secure state. This state shall include the restoration of the application data, security credentials, and log/audit files to their previous state.

Assignable to third party.

2011

N

Canadian: Alberta 7.3.18.9 (Security); ISO 15408 CC SFR: FAU_GEN; NIST SP 800-53: AU-2 AUDITABLE EVENTS; HIPAA: 164.310(d)(1)

SEC 5.06, 5.08, 7.03

SC 08.03

Backup/Recovery

If the system claims to be available 24x7 then the system shall have ability to run a backup concurrently with the operation of the application.

Assignable to third party.

2011

N

Canadian: Alberta 7.4.2.5 (Technica+D1l); ISO 15408 CC SFR: FDP_ROL; HIPAA: 164.310(d)(1)

SEC 5.02, 7.02

Appendix Audited Events 1. start/stop 2. user login/logout 3. session timeout 4. account lockout 5. patient record created/viewed/updated/deleted 6. scheduling 7. query 8. order 9. node-authentication failure 10. signature created/validated 11. PHI export (e.g. print) 12. PHI import 13. security administration events 14. backup and restore

CCHIT Certified 2011 LTPAC Criteria Update v1 1 20110209.xls

Page 45 of 45