Tasks To Do

12345

Tasks To Do

Review unchecked requirementsDecide on disposition of SHOULD/SHALL, MAY/SHOULD, etc. (CCs that were split for EDIS/overall EHR-S)Determine which new functions from EDIS should be addedWrite Statements and Descriptions for New FunctionsResolve comments in Cols. K thru O

EHR-S HL7 FUNCTIONAL MODELProposed New Functions and Conformance Criteria for Release 2.0F / CC

√ ?

DC.1 CC #25 153 221

√

DC.1 CC #26 154 222√

DC.1.1.1 CC #6a 5 5

√

DC.1.1.1 CC #13 190 141

√

DC.1.1.1 CC #14 191 142

√

DC.1.1.1 CC #15 245 6

√

DC.1.1.2 CC #10 6 7

√

1º 2º 3º 4º Row No.

(v2-3)

Row No.

(v3-8)

DC.1 Care Management

DC.1 Care Management

DC.1 Care Management

.1 Record Management

.1 Identify and Maintain a Patient Record

DC.1 Care Management

.1 Record Management

.1 Identify and Maintain a Patient Record

DC.1 Care Management

.1 Record Management

.1 Identify and Maintain a Patient Record

DC.1 Care Management

.1 Record Management

.1 Identify and Maintain a Patient Record

DC.1 Care Management

.1 Record Management

.2 Manage Patient Demographics

DC.1.1.3.4 CC #1 7 9

√

DC.1.1.5 CC #1a 172 235

√

DC.1.1.6 CC #STA

DC.1.1.6 CC #STA

DC.1.7.1 CC #20 8 10

√

DC.1 Care Management

.1 Record Management

.3 Data and Documentation from External Sources

.4 Capture Guidelines and Standards from External Sources

DC.1.1.3.4 CC #STA

DC.1 Care Management

.1 Record Management

.3 Data and Documentation from External Sources

.4 Capture Guidelines and Standards from External Sources

DC.1.1.3.4 CC #DES

DC.1 Care Management

.1 Record Management

.3 Data and Documentation from External Sources

.4 Capture Guidelines and Standards from External Sources

DC.1 Care Management

.1 Record Management

.5 Present Ad Hoc Views of the Health Record

DC.1 Care Management

.1 Record Management

.6 Non-text Data

DC.1 Care Management

.1 Record Management

.6 Non-text Data

DC.1 Care Management

.7 Orders and Referrals Management

.1 Manage Medication Orders

DC.1.7.1 CC #21 9 11

√

DC.1.7.1 CC #20 10 12

√

73√

74√

DC.1.7.1 CC #5 68 75

√

DC.1.7 CC #2 70 77√

DC.1.7.3 CC #6 11 13

√

DC.1.7.3 CC #7 12 14

√

DC.1 Care Management

.7 Orders and Referrals Management

.1 Manage Medication Orders

DC.1 Care Management

.7 Orders and Referrals Management

.1 Manage Medication Orders

DC.1 Care Management

.7 Orders and Referrals Management

.1 Manage Medication Orders

DC.1 Care Management

.7 Orders and Referrals Management

.2 Non-Medication Orders and Referrals Management

DC.1 Care Management

.7 Orders and Referrals Management

.1 Create Order Set Templates

DC.1 Care Management

.7 Orders and Referrals Management

DC.1 Care Management

.7 Orders and Referrals Management

.3 Manage Order Sets

DC.1 Care Management

.7 Orders and Referrals Management

.3 Manage Order Sets

DC.1.7.3 CC #8 13 15

√

DC.1.8.3 CC #18 14 16√

DC.1.8.3 CC #19 15 17

√

DC.1.8.3 CC #20 16 18√

DC.1.8.3 CC #21 17 19 √DC.1.8.3 CC #22 18 20

√

DC.1.8.3 CC #23 19 21

√

DC.1.8.4 CC #6 20 22

√

DC.1.8.5 CC #16 21 23

√

DC.1.8.5 CC #17 22 24

√

DC.1 Care Management

.7 Orders and Referrals Management

.3 Manage Order Sets

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.3 Manage Results

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.3 Manage Results

DC.1 Care Management

.8 Documentation of Care, Measurements

.3 Manage Results

DC.1 Care Management

.8 Documentation of Care, Measurements

.3 Manage Results

DC.1 Care Management

.8 Documentation of Care, Measurements

.3 Manage Results

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.3 Manage Results

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.4 Manage Patient Clinical Measurements

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1.8.5 CC #18 23 25

√

DC.1.8.5 CC #19 24 26

√

DC.1.8.5 CC #20 25 27√

DC.1.8.5 CC #21 26 28

√

DC.1.8.5 CC #22 27 29

√

DC.1.8.5 CC #23 28 30

√

DC.1.8.5 CC #24 29 31

√

DC.1.8.5 CC #25 30 32√

DC.1.8.5 CC #26 31 33 √

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements

.5 Manage Clinical Documents and Notes

DC.1.8.5 CC #27 32 34

√

DC.1.8.5 CC #28 33 35

√

DC.1.8.5 CC #29 34 36

√

DC.1.8.5 CC #30 35 37

√

DC.1.8.5 CC #31 36 38

√

DC.1.8.5 CC #32 37 39

√

DC.1.8.5 CC #33 39 41

√

DC.1.1 CC #STA

DC.1.1 CC #DES

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.8 Documentation of Care, Measurements and Results

.5 Manage Clinical Documents and Notes

DC.1 Care Management

.10 Manage Patient Disposition Documentation

DC.1 Care Management

.10 Manage Patient Disposition Documentation

DC.1.1 CC #1 43 45

√

DC.1.1 CC #2 44 46

√

DC.1.1.1 CC #STA

DC.1.1.1 CC #DES

DC.1.1.1.1 CC #1 40 42

√

DC.1.1.1.1 CC #2 41 43

√

DC.1 Care Management

.10 Manage Patient Disposition Documentation

DC.1 Care Management

.10 Manage Patient Disposition Documentation

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.1 Manage Follow-On Care

DC.1.1.1.1 CC #STA

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.1 Manage Follow-On Care

DC.1.1.1.1 CC #DES

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.1 Manage Follow-On Care

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.1 Manage Follow-On Care

DC.1.1.1.1 CC #3 42 44

√

DC.1.1 CC #STA

DC.1.1 CC #DES

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.1 Manage Follow-On Care

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.2 Manage prescriptions

DC.1.1.1.2 CC #STA

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.2 Manage prescriptions

DC.1.1.1.2 CC #DES

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.3 Manage ED to Hospital Admission

DC.1.1.1.3 CC #STA

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.3 Manage ED to Hospital Admission

DC.1.1.1.3 CC #DES

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.4 Manage Transfers

DC.1.1.1.4 CC #STA

DC.1 Care Management

.10 Manage Patient Disposition Documentation

.1 Manage Discharge Disposition

.4 Manage Transfers

DC.1.1.1.4 CC #DES

DC.1 Care Management

.11 Manage Discharged Patients

DC.1 Care Management

.11 Manage Discharged Patients

DC.2.1.3 CC #tat

√

DC.2.1.3 CC #Des

√

DC.2.1.3 CC #3a

√

DC.2.1.3 CC #4a 46 48

√

DC.2.1.3 CC #5a

√

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential Problems and Trends

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential Problems and Trends

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential Problems

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential Problems and Trends

DC.2.1.3 CC #12 47 49

√

DC.2.1.3 CC #he 48 50

√

DC.2.1.3 CC #11 49 51

√

DC.2.1.3 CC #12 50 52√

DC.2.2.1.1 CC #7 51 53

√

DC.2.2.1.2 CC #9 52 54

√

DC.2.2.2 CC #10 57 55

√

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential Problems and Trends

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision Support

.3 Support for Identification and Notification of Potential

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision

.3 Support for Identification and Notification

DC.2 Clinical Decision Support

.1 Manage Health Information to Provide Decision

.3 Support for Identification and Notification

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.1 Support for Standard Care Plans, Guidelines, Protocols

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.2 Support for Context-Sensitive Care Plans, Guidelines, Protocols

DC.2 Clinical Decision Support

.2 Report Generation

.2 Standard Report Generation

DC.2.2.2 CC #11 58 56

√

DC.2.2.3 CC #9 53 57

√

DC.2.2.3 CC #10 54 58

√

CC # 59

DC.2.2.3 CC #11 55 60

√

DC.2.2.3 CC #12 56 61

√

DC.2.3.1.1 CC #1a 59 62

√

DC.2.3.1.1 CC #1b 63

√

DC.2.3.1.1 CC #1c 64

√

DC.2 Clinical Decision Support

.2 Report Generation

.2 Standard Report Generation

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.3 Support for Research Protocols Relative to Individual Patient Care

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.3 Support for Research Protocols Relative to Individual Patient Care

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.3 Support for Research Protocols Relative to Individual Patient Care

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.3 Support for Research Protocols Relative to Individual

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2.3.1.1 CC #1d 65

√

DC.2.3.1.1 CC #2a 60 66

√

DC.2.3.1.1 CC #2b 67

√

DC.2.3.1.1 CC #2c 68

√

DC.2.3.1.1 CC #2d 69

√

70

√

71

√

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interaction Checking

DC.2.3.1.1 CC #11 

DC.2 Clinical Decision Support

.3 Medication and Immunization Management

.1 Support for Medication and Immunization Ordering

.2 Support for Patient Specific Dosing and Warnings

DC.2.3.1.2 CC #1  

67 72

√

71 78√

79

√

80

√

81√

82

√

83

√

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and

.1 Support for Condition Based Care and

.1 Support for Standard Care Plans, Guidelines,

DC.2.2.1.1 CC #STA

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.1 Support for Standard Care Plans, Guidelines, Protocols

DC.2.2.1.1 CC #DES

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.1 Support for Standard Care Plans, Guidelines, Protocols

DC.2.2.1.1 CC #ALL

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and

.1 Support for Condition Based Care and

.2 Support for Context-Sensitive Care Plans,

DC.2.2.1.2 CC #STA

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines,

.2 Support for Context-Sensitive Care Plans, Guidelines, Protocols

DC.2.2.1.2 CC #DES

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.2 Support for Context-Sensitive Care Plans, Guidelines, Protocols

DC.2.2.1.2 CC #ALL

DC.2.4.1 CC #6 69 76

√

DC.2.7.1 CC #STA 71 84√

DC.2.2.1.2 CC #1-3 85

√

DC.2.7.1 CC #6 72 86

√

DC.2.7.1 CC #7 73 87

√

DC.2.7.1 CC #8 74 88

√

DC.2 Clinical Decision Support

.4 Orders, Referrals, Results and Care Management

.1 Create Order Set Templates

DC.2 Clinical Decision Support

.7 Support for Knowledge Access

.1 Access Healthcare Guidance

DC.2 Clinical Decision Support

.2 Care and Treatment Plans, Guidelines and Protocols

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.2 Support for Context-Sensitive Care Plans, Guidelines, Protocols

DC.2 Clinical Decision Support

.7 Support for Knowledge Access

.1 Access Healthcare Guidance

DC.2 Clinical Decision Support

.7 Support for Knowledge Access

.1 Access Healthcare Guidance

DC.2 Clinical Decision Support

.7 Support for Knowledge Access

.1 Access Healthcare Guidance

DC.3.2.1 CC #7 84 89

√

DC.3.2.1 CC #8 90

√

DC.3.2.2 CC #9 91

√

DC.3.2.2 CC #10 92

√

DC.3.2.2 CC #11 78 93

√

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.1 Support for Inter-Provider Communication

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.1 Support for Inter-Provider Communication

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.2 Support for Provider-Pharmacy Communication

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.2 Support for Provider-Pharmacy Communication

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.2 Support for Provider-Pharmacy Communication

DC.3.2.3 CC #13 81 94

√

DC.3.2.3 CC #14 85 95

√

DC.3.2.5 CC #4 87 96

√

DC.3.2.6 CC #STA

DC.3.2.6 CC #DES

DC.3.2.6 CC #1 88 97

DC.3.2.6 CC #2 90 98

DC.3 Operations Management and Communication

.2 Information Access for Supplemental Use

.3 Support for Communications Between Provider and Patient and/or the Patient Representative

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.3 Support for Communications Between Provider and Patient

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.5 Communication with Medical Devices

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3.2.6 CC #3 91 99

DC.3.2.6 CC #4 93 100

DC.3.2.6 CC #5 95 101

DC.3.2.7 CC #STA 96 102

√

DC.3.2.7 CC #DES 103

√

DC.3.2.7 CC #1 104

√

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3 Operations Management and

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.6 Communication with non-Medical Devices

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Boards

DC.3.2.7.1 CC #STA

105

√

106

√

DC.3.2.7.1 CC #1 97 107

√

DC.3.2.7.1 CC #1 98 108

√

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Boards

DC.3.2.7.1 CC #DES

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Boards

DC.3.2.7.1 CC #TAT

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Boards

DC.3.2.7.1 CC #ESC

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Boards

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Tools

DC.3.2.7.1 CC #2 99 109

√

DC.3.2.7.1 CC #3 100 110

√

DC.3.2.7.1 CC #4 101 111

√

DC.3.2.7.1 CC #5 102 112

√

DC.3.2.7.1 CC #6 103 113

√

DC.3.2.7.1 CC #7 104 114

√

DC.3.2.7.1 CC #10 107 115√

DC.3.2.7.1 CC #11 108 116√

DC.3.2.7.1 CC #12 109 117√

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Tools

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Tools

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/F

.1 Tracking Tools

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Tools

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Tools

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.1 Tracking Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.1 Tracking Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.1 Tracking Tools

DC.3.2.7.1 CC #13 110 118√

DC.3.2.7.2 CC #1 111 119

√

DC.3.2.7.2 CC #2 112 120

√

DC.3.2.7.2 CC #3 112a 121 √DC.3.2.7.2 CC #4 113 122

√DC.3.2.7.2 CC #5 113a 123

√

DC.3.2.8 CC #STA

DC.3.2.8 CC #DES

DC.3.2.8 CC #1 114 124

√

DC.3.2.8 CC #2 114a 125√

DC.3.2.9 CC #STA

DC.3 Operations Management and

.2 Support Clinical Communication

.7 Support for Communications Within an

.1 Tracking Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.2 Transition of Care Tools

DC.3.2.7.2 CC #STA

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.2 Transition of Care Tools

DC.3.2.7.2 CC #DES

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/F

.2 Transition of Care Tools

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.2 Transition of Care Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.2 Transition of Care Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.7 Support for Communications Within

.2 Transition of Care Tools

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.7 Support for Communications Within an Enterprise/Facility

.2 Transition of Care Tools

DC.3 Operations Manage

.2 Support Clinical Communication

.8 Support for Communications Between DC.3

Operations Manage

.2 Support Clinical Communication

.8 Support for Communications Between

DC.3 Operations Management and

.2 Support Clinical Communication

.8 Support for Communications Between Enterprises/

DC.3 Operations Manage

.2 Support Clinical Communication

.8 Support for Communications Between

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.9 Support for Facility to External Agency Communications

DC.3.2.9 CC #DES

DC.3.2.1 CC #STA

DC.3.2.1 CC #DES

DC.3.2.1 CC #1 79 126

DC.3.2.1 CC #2 127

DC.3.2.1 CC #3 80 128

DC.3.2.1 CC #STA

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.9 Support for Facility to External Agency Communications

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.10 Support for Provider-Employer Communications

DC.3 Operations Management and Communi

.2 Support Clinical Communication

.10 Support for Provider-Employer Communications

DC.3 Operations Management and Communication

.2 Care and Treatment Plans, Guidelines and Protocols

.10 Support for Provider-Employer Communications

DC.3 Operations Management and Communication

.2 Care and Treatment Plans, Guidelines and Protocols

.10 Support for Provider-Employer Communications

DC.3 Operations Management and Communication

.2 Care and Treatment Plans, Guidelines and Protocols

.10 Support for Provider-Employer Communications

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.11 Support for Special Interest Personnel Communications

DC.3.2.1 CC #DES

DC.3.2.1 CC #1 129

DC.3.2.1 CC #2 130

DC.3.2.1 CC #3 131

S.1 .4.1 CC #3 181 132

√

DC.3 Operations Management and Communication

.2 Support Clinical Communication

.11 Support for Special Interest Personnel Communications

DC.3 Operations Management and Communication

.2 Care and Treatment Plans, Guidelines and Protocols

.11 Support for Special Interest Personnel Communications

DC.3 Operations Management and Communication

.2 Care and Treatment Plans, Guidelines and Protocols

.11 Support for Special Interest Personnel Communications

DC.3 Operations Management and Communication

.2 Care and Treatment Plans, Guidelines and Protocols

.11 Support for Special Interest Personnel Communications

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 .4.1 CC #4 182 133

√

S.1 .4.1 CC #5 183 134√

S.1 .4.1 CC #6 184 135√

S.1 .4.1 CC #7 185 136√

S.1 .4.1 CC #8 186 137√

S.1 .4.1 CC #9 187 138√

S.1 .4.1 CC #3 188 139

√

S.1 .4.2 CC #6 189 140

√

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.1 Patient Demographics

S.1 Clinical Support

.4 Patient Directory

.2 Patient's Location Within a Facility

S.1 .8 CC #3 163 227

√

S.1 .8 CC #4 164 228√

S.1 .8.1 CC #STA

S.1 .8.1 CC #DES

S.1 .8.1 CC #1: 166 229

√

S.1 .8.2 CC #STA

S.1 .8.2 CC #DES

S.1 .8.2 CC #1 168 231

√

S.1 .8.2 CC #2: 169 232

√

S.1 .8.3 CC #STA

S.1 .8.3 CC #DES

S.1 Clinical Support

.8 Information View

S.1 Clinical Support

.8 Information View

S.1 Clinical Support

.8 Information View

.1 User Interface Management 1: Views

S.1 Clinical Support

.8 Information View

.1 User Interface Management 1: Views

S.1 Clinical Support

.8 Information View

.1 User Interface Management 1: Views

S.1 Clinical Support

.8 Information View

.2 User Interface Management 2: Interface

S.1 Clinical Support

.8 Information View

.2 User Interface Management 2: Interface

S.1 Clinical Support

.8 Information View

.2 User Interface Management 2: Interface

S.1 Clinical Support

.8 Information View

.2 User Interface Management 2: Interface

S.1 Clinical Support

.8 Information View

.3 User Interface Management 3: Entry

S.1 Clinical Support

.8 Information View

.3 User Interface Management 3: Entry

S.1 .8.3 CC #1 170 233√

S.1 .8.3 CC #2 167 230

√

S.1 .8.3 CC # 171 234

√

S.2.1.2 CC #13 242 162

√

S.2 .1.3 CC #STA

S.2 .1.3 CC #DES

S.2 .1.3 CC #1 192 143

√

S.2 .1.3 CC #2 193 144

√

S.1 Clinical Support

.8 Information View

.3 User Interface Management 3: Entry

S.1 Clinical Support

.8 Information View

.3 User Interface Management 3: Entry

S.1 Clinical Support

.8 Information View

.3 User Interface Management 3: Entry

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.2 Performance and Accountability Measures

S.2 Measurement, Analysis, Research and

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research and

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 .1.3 CC #3 194 145

√

S.2 .1.3 CC #4 149 217

√

S.2 .1.3 CC #5 150 218

√

S.2 .1.3 CC #6 151 219

√

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 .1.3 CC #7 152 220

√

S.2 .1.4 CC #STA

S.2 .1.4 CC #DES

S.2 .1.4 CC #1 206 146

√

S.2 .1.4 CC #5 207 147

√

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.3 Support for Process Improvement

S.2 Measurement, Analysis, Research

.1 Measurement, Monitoring, and Analysis

.4 Support for Care System Performance Indicators

S.2 Measurement, Analysis, Research

.1 Measurement, Monitoring, and Analysis

.4 Support for Care System Performance Indicators

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.4 Support for Care System Performance Indicators (Dashboards)

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.4 Support for Care System Performance Indicators (Dashboards)

S.2 .1.4 CC #6 208 148

√

S.2 .1.4 CC #2 209 149

√

S.2 .2.2 CC #8 210 150

√

S.2 .2.2 CC #4 211 151

√

S.2 .2.2 CC #4a 212 152

√

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.4 Support for Care System Performance Indicators (Dashboards)

S.2 Measurement, Analysis, Research and Reports

.1 Measurement, Monitoring, and Analysis

.4 Support for Care System Performance Indicators (Dashboards)

S.2 Measurement, Analysis, Research and Reports

.2 Report Generation

.2 Standard Report Generation

S.2 Measurement, Analysis, Research and Reports

.2 Report Generation

.2 Standard Report Generation

S.2 Measurement, Analysis, Research and Reports

.2 Report Generation

.2 Standard Report Generation

S.2 .2.2 CC #9 213 153

√

S.2 .2.2 CC #10 214 154

√

S.2 .2.2.1 CC #STA

S.3.2.1 CC #3 234a 155√

S.3.2.1 CC #4 234b 156

√

S.3.2.1 CC #5 235a 157

√

S.3.2.1 CC #6 235b 158√

S.3.2.1 CC #7 236a 159

√

S.2 Measurement, Analysis, Research and Reports

.2 Report Generation

.2 Standard Report Generation

S.2 Measurement, Analysis, Research and Reports

.2 Report Generation

.2 Standard Report Generation

S.2 Measurement, Analysis,

.2 Report Generation

.2 Standard Report Generation

.1 ED Benchmarking Reports

S.2 Measurement, Analysis,

.2 Report Generation

.2 Standard Report Generation

.1 ED Benchmarking Reports

S.2 .2.2.1 CC #DES

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding Assistance

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding Assistance

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding Assistance

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding Assistance

S.3.2.1 CC #7 236b 160

√

S.3.2.1 CC #8 241 161√

S.2.1.2 Description 163

√

S.3.2.2 CC #6 243 164

√

S.3.2.2 CC #7 244 165

√

DC.3.2.4 CC #STA

DC.3.2.4 CC #DES

S.3 .2.5 CC #TAT 170

S.3 .2.5 CC #ESC 171

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding Assistance

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.1 Rules-Driven Clinical Coding AssistanceS.3

Administrative and Financial

.2 Information Access for Supplemental Use

.2 Rules-Driven Financial and Administrative Coding Assistance

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.2 Rules-Driven Financial and Administrative Coding Assistance

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.2 Rules-Driven Financial and Administrative Coding Assistance

DC.3 Operations Manage

.2 Information Access for Supplemental Use

.4 Assistance for Coding DeficienciesDC.3

Operations Manage

.2 Information Access for Supplemental Use

.4 Assistance for Coding DeficienciesS.3

Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3.2.5 CC #1 250 172

S.3.2.5 CC #2 251 173

S.3.2.5 CC #3 252 174

S.3.2.5 CC #3 253 175

S.3.2.5 CC #4 254 176

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3.2.5 CC #5 258 177

S.3.2.5 CC #6 259 178

S.3.2.5 CC #7 261 179

S.3.2.5 CC #8 262 180

S.3 .2.6 CC #TAT

S.3 .2.6 CC #ESC

S.3.2.6 CC #1 255 183

S.3.2.6 CC #2 184

S.3.2.6 CC #3 256 185

S.3.2.6 CC #4 260 186

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.5 Support for Provider Training

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and

170, 181

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and

171, 182

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and Privileging

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and Privileging

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and Privileging

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and Privileging

S.3.2.6 CC #5 263 187

S.3.3.5 CC #4 246 166

√

S.3.3.5 CC #5 T 247 167

√

S.3.3.5 CC #6 248 168

√

S.3.3.5 CC #4 249 169

√

IN.1.8 CC #1 177 240√

IN.1.8 CC #2 178 241√

IN.1.8 CC #3 179 242√

IN.1.8 CC #4 180 243√

S.3 Administrative and Financial

.2 Information Access for Supplemental Use

.6 Support for Provider Credentialing and Privileging

S.3 Administrative and Financial

.3 Administrative Transaction Processing

.5 Claims and Encounter Reports for Reimbursement

S.3 Administrative and Financial

.3 Administrative Transaction Processing

.5 Claims and Encounter Reports for Reimbursement

S.3 Administrative and Financial

.3 Administrative Transaction Processing

.5 Claims and Encounter Reports for Reimbursement

S.3 Administrative and Financial

.3 Administrative Transaction Processing

.5 Claims and Encounter Reports for Reimbursement

IN.1 Security

.8 Information Attestation

IN.1 Security

.8 Information Attestation

IN.1 Security

.8 Information Attestation

IN.1 Security

.8 Information Attestation

IN.1.9.1 CC #STA

IN.1.9.1 CC #DES

IN.1.9.2 CC #STA

IN.1.9.2 CC #DES

IN.2.1 CC #he 118 188

√

IN.2.1 CC # 119 189

√

IN.2.1 CC #he 120 190

√

IN.2.1 CC #he 121 191

√

IN.1 Security

.9 Patient Privacy and Confidentiality

.1 Redact patient identifying information.

IN.1 Security

.9 Patient Privacy and Confidentiality

.1 Redact patient identifying information.

IN.1 Security

.9 Patient Privacy and Confidentiality

.2 Protect individual patient identity.

IN.1 Security

.9 Patient Privacy and Confidentiality

.2 Protect individual patient identity.

IN.2 Health Record Information and Management

.1 Data Retention, Availability and Destruction

IN.2 Health Record Information and Management

.1 Data Retention, Availability and Destruction

IN.2 Health Record Information and Management

.1 Data Retention, Availability and Destruction

IN.2 Health Record Information and Management

.1 Data Retention, Availability and Destruction

IN.2.1 CC #ith 122 192

√

CC #ith 123 193 √ CC #ith 124 194

√

CC #ith 125 195

√

IN.2 Health Record Information and Management

.1 Data Retention, Availability and Destruction

IN.2.2 CC #26 126 196

√

IN.2.2 CC #27 127 197

√

IN.2.2 CC #he 128 198

√

IN.2.2 CC #he 129 199

√

IN.2.5.1 CC #STA

IN.2.5.1 CC #DES

IN.2 Health Record Information and Management

.2 Auditable Records

IN.2 Health Record Information and Management

.2 Auditable Records

IN.2 Health Record Information and Management

.2 Auditable Records

IN.2 Health Record Information and Management

.2 Auditable Records

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.1 Store and Manage Unstructured Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.1 Store and Manage Unstructured Health Record Information

IN.2.5.1 CC #10 130 200

√

IN.2.5.1 CC #10 252

√

IN.2.5.2 CC #STA

IN.2.5.2 CC #DES

IN.2.5.3 CC #STA

√

IN.2.5.3 CC #DES

√

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.1 Store and Manage Unstructured Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.1 Store and Manage Unstructured Health Record Information

223 (New)

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.2 Store and Manage Structured Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.2 Store and Manage Structured Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2.5.3 CC #1 173 236

√

IN.2.5.3 CC #2 174 237

√

IN.2.5.3 CC #3 175 238

√

IN.2.5.3 CC #4 176 239

√

IN.2.5.3 CC #5 176 239

√

IN.2.5.4 CC #STA

√

IN.2.5.4 CC #DES

√

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.3 Manage Health Information Record Quality

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2.5.4 CC #1 215 244

√

IN.2.5.4 CC #2 216 245

√

IN.2.5.4 CC #3 217 246

√

IN.2.5.4 CC #4 218 247

√

IN.2.5.4 CC #5 219 248√

IN.2.5.4 CC #6 220 249

√

IN.2.5.4 CC #7 221 250

√

IN.2.5.4 CC #8 222 251

√

IN.2 Health Record Information and Manage

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Manage

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Manage

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2.5.4 CC #9 38 40

√

IN.2.5.5 CC #STA

IN.2.5.5 CC #DES

IN.2.5.5 CC #1

√

IN.2.5.5 CC #2

√

IN.2.5.5 CC #3 82 8

√

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.4 Manage Macros, Templates and Pre-Defined Text

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.5 Locate External Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.5 Locate External Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.5 Locate External Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.5 Locate External Health Record Information

IN.2 Health Record Information and Management

.5 Store and Manage Health Record Information

.5 Locate External Health Record Information

IN.5.1 CC #6 131 201

√

IN.5.1 CC #7 132 202

√

IN.5 Standards-based Interoperability

.1 Interchange Standards

IN.5 Standards-based Interoperability

.1 Interchange Standards

IN.5.1.1 CC #STA

IN.5.1.1 CC #DES

IN.5.5 CC #STA

IN.5.5 CC #DES

IN.5.5.1 CC #STA

IN.5.5.1 CC #DES

IN.5.5.2 CC #STA

IN.5.5.2 CC #DES

IN.5.5.3 CC #STA

IN.5.5.3 CC #DES

IN.6 CC #24 133 203

√

IN.7 CC #he 134 204

√

IN.7 CC #he 135 205

√

IN.7 CC #he 136 206

√

IN.5 Standards-based Interoperability

.1 Interchange Standards

.1 Structured Documents

IN.5 Standards-based Interoperability

.1 Interchange Standards

.1 Structured Documents

IN.5 Standards-based Interoper

.5 EDIS Interoperability

IN.5 Standards-based Interoper

.5 EDIS Interoperability

IN.5 Standards-based Interoper

.5 EDIS Interoperability

.1 Bed Board Interface

IN.5 Standards-based Interoper

.5 EDIS Interoperability

.1 Bed Board Interface

IN.5 Standards-based Interoper

.5 EDIS Interoperability

.2 Electronic Prescribing Interface

IN.5 Standards-based Interoper

.5 EDIS Interoperability

.2 Electronic Prescribing Interface

IN.5 Standards-based Interoper

.5 EDIS Interoperability

.3 Billing Interface

IN.5 Standards-based Interoper

.5 EDIS Interoperability

.3 Billing Interface

IN.6 Business Rules Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 CC #he 137 207

√

IN.7 CC #he 139 208

√

IN.7 CC #he 140 209

√

IN.7 CC #he 142 210

√

IN.7 CC #he 143 211

√

IN.7 CC #he 144 212

√

IN.7 CC #he 145 213

√

IN.7 CC #he 146 214

√

IN.7 CC #he 147 215

√

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 Workflow Management

IN.7 CC #he 148 216

√

CC #1 159 224√

CC #2 160 225√

CC #3 161 226√

CC # 158 223

?

IN.8 CC #DES

√

IN.8.1 CC #STA

√

IN.8.1 CC #DES

√

IN.8.2 CC #STA

√

IN.8.2 CC #DES

√

IN.7 Workflow Management

IN.8 Application Optimization

IN.8 Application Optimization

.1 EHR-S User Feedback

IN.8 Application Optimization

.1 EHR-S User Feedback

IN.8 Application Optimization

.2 Automated System Performance Feedback

IN.8 Application Optimization

.2 Automated System Performance Feedback

IN.8.3 CC #STA

√

IN.8.3 CC #DES

√

IN.8 Application Optimization

.3 Ad-Hoc System Performance Queries

IN.8 Application Optimization

.3 Ad-Hoc System Performance Queries

EHR-S HL7 FUNCTIONAL MODELProposed New Functions and Conformance Criteria for Release 2.0Language for EHR Submission

(This is the Wording to be Submitted to HL7)

.25 The system MAY provide the ability to identify specific categories of data for autopopulation.

.26 The system MAY provide the ability to autopopulate specific categories of pre-identified data.

.6a The system SHOULD update, in near real time, the display of demographic data for previously anonymous patients whose identity is determined.

.13 The system SHALL provide an expedited registration capability in the event of a Disaster Response (e.g. exceptionally large patient volumes or Mass Casualty Events).

.14 The system SHALL provide the ability to reconcile into the patient's health record the information generated during an expedited registration process (e.g. Disaster Response).

.15 The system SHOULD/SHALL provide for anonymized patient registration.

.10 The system SHOULD provide data that can be used for wrist bands to designate patients in certain categories.

STATEMENT: TBD (DC.1.1.3.4) - Capture trusted practice guidance from a variety of external sources.

DESCRIPTION: TBD (DC.1.1.3.4) - Capture and import information provided by external health care organizations as relates to clinical practice guidelines (CPGs), Clarification: External healthcare organizations in this function include, but are not limited to, the following: Patient management, Healthcare delivery, population health/surveillance organizations (e.g. local, regional, national and global Public Health services, PAHO, WHO), and professional, governmental, industrial healthcare optimization initiatives.

.1 The system SHOULD provide the ability to automatically import standard based guidance (e.g. CPGs) in support of professional, governmental, industrial healthcare optimization initiatives.

.1a The system SHALL support the ability for a provider to set filters to search for previous events (encounters, reports, consults, etc.) meeting specified criteria.

STATEMENT: TBD (DC.1.1.6)

STATEMENT: TBD (DC.1.1.6)

.20 The system SHALL provide the ability to generate paper medication prescriptions that the patient can take to a pharmacy for filling.

.21 The system SHALL provide the ability to generate electronic medication prescriptions that can be transmitted to a pharmacy for filling.

.20 The system SHALL provide a medication reconciliation capability

.21  The system SHALL provide the ability to (automatically or manually) determine, update and render the status of medication orders.

.1  The system SHALL provide the ability to (automatically or manually) determine, update and render the status of non-medication orders and referrals

.5 The system SHALL provide a clearly visible indication about the status (e.g. ordered, acknowledged, pending, in transport, completed, etc.) of an order in progress.

.2 The system SHALL support role-based order entry.

.6 The system MAY/SHALL provide integrated Chief Complaint -driven order templates to optimize the provision of patient care upon arrival.

,7 The system MAY/SHALL provide integrated Diagnosis -driven order templates to optimize the provision of patient care at the time of disposition.

.8 The system MAY/SHALL provide integrated Disposition Diagnosis -driven order templates to optimize the provision of patient care at the time of disposition.

.18 The system MAY support automated callbacks to inform the patient of laboratory results that are resulted at a time following their departure.

.19 The system MAY trigger automated callbacks to inform the patient of corrected diagnostic (e.g. laboratory, radiology) results.

.20 The system MAY trigger automated callbacks to inform the patient of corrected radiology results

.21 The system SHALL import preliminary and final reports from ancillary (laboratory, radiology, microbiology) procedures.

.22 The system SHALL update reports from ancillary (e.g., laboratory, radiology, microbiology) procedures.

.23 The system SHALL alert certain health care team members of clinically-significant ancillary procedure report changes (using role-based alerts).

.6 The system SHALL support the inclusion of integrated flowsheets.

.16 The system SHALL provide the capability to identify incomplete records.

.17 The system SHALL (at the time of the decision to discharge or transfer a patient) alert designated principals that clinical documentation (includes physician or nursing assessments, treatments, and interventions) is not completed.

.18 The system SHALL provide the capability to notify appropriate users of incomplete records.

.19 The system SHOULD provide the capability to route incomplete records to the appropriate user(s).

.20 The system SHALL flag missing elements/sections of incomplete records that are routed to user.

.21 The system SHALL provide the ability for a principal to use in a role-based fashion an integrated charting or documentation tool (such as notes, flow-sheets, radiology views, or laboratory views) to facilitate remote, delayed, or in-person consultations.

.22 The system SHOULD provide integrated charting and documentation tools (e.g. notes, flowsheets, lab views) for consultations that incorporate all relevant documentation performed by clinical staff.

.23 The system MAY provide specialized charting tools for patient-specific requirements (e.g. age - neonates, pediatrics, geriatrics; condition - impaired renal function; medication).

.24 The system MAY provide alerts for clinical data that are appropriate for patient-specific requirements (e.g. age - neonates, pediatrics, geriatrics; condition - impaired renal function; medication).

.25 The system SHALL provide medical charting tools optimized for Fast Track/Urgent Care patients.

.26 The system SHALL provide the ability to incorporate medical charting tools for Fast Track/Urgent Care patients.

.27 The system SHALL provide templates optimized for Fast Track/Urgent Care patients.

.28 The system SHALL provide the ability to create templates for Fast Track/Urgent Care patients.

.29 The system SHALL provide the capability to expand lower acuity documentation upon transfer from a Fast Track/Urgent Care to higher level ED settings.

.30 The system SHOULD provide integrated Chief Complaint driven documentation templates to optimize patient care upon arrival.

.31 The system SHOULD provide integrated Diagnosis driven documentation templates to optimize patient care at the time of disposition.

.32 The system SHALL provide integrated Disposition Diagnosis driven documentation templates to optimize patient care at the time of disposition.

.33 The system MAY support the special documentation needed for the clinical care of individuals being transferred to other locations (e.g. jails, nursing homes, specialty hospital).

STATEMENT: TBD (DC.1.10) Manage documentation resulting from the disposition of a patient.

DESCRIPTION: TBD (DC.1.10)

.1 The system SHALL provide the ability to document configurable patient encounter disposition statuses.

.2 The system SHALL provide the ability to display configurable patient encounter Disposition Statuses.

STATEMENT: Manage documentation resulting from the disposition of a patient from a clinical facility.

DESCRIPTION: "Disposition" includes discharge, admission, transfer, death, Left Without Being Seen (LWBS) and other actions.

STATEMENT: TBD (DC.1.10.1.1) Manage documentation regarding follow-on care resulting from the discharge of a patient from a clinical facility

DESCRIPTION: TBD (DC.1.10.1.1)

.1 The system SHALL provide the ability to identify patients document patient for follow-up contact (e.g. Laboratory Callbacks, Radiology Callbacks, Left Without Being Seen)

.2 The system SHALL provide the ability to record log patient follow-up contact activities (e.g. Laboratory Callbacks, Radiology Callbacks, Left Without Being Seen)

STATEMENT: TBD (DC.1.10.1.3)

.3 The system SHALL provide the ability to report on patient follow-up contacts (e.g. Laboratory Callbacks, Radiology Callbacks, Left Without Being Seen)

STATEMENT: TBD (DC.1.10.1.2)

DESCRIPTION: TBD (DC.1.10.1.2)

DESCRIPTION: TBD (DC.1.10.1.3)

STATEMENT: TBD (DC.1.10.1.3)

DESCRIPTION: TBD (DC.1.10.1.4)

STATEMENT: TBD (DC.1.11)

DESCRIPTION: TBD (DC.1.11)

Statement: Identify conditions of clinical interest, identify trends that may lead to significant problems, and provide prompts for consideration.

Description: When personal health information is collected directly during a patient visit, input by the patient, or acquired from an external source (lab results), it is important to be able to identify potential problems and trends that may be condition- or patient-specific (given the individual's personal health profile), or changes warranting further assessment (for example: significant trends [lab results, weight]; a decrease in creatinine clearance for a patient on Metformin, an abnormal increase in INR for a patient on warfarin, an increase in suicidal ideation; presence of .3a The system SHOULD provide the ability to identify patient Conditions of Clinical of Interest.

.4a The system SHOULD provide the ability to create a configurable notification alert for Conditions of Clinical Interest.

.5a The system SHOULD provide the ability to prompt [notify?] the provider on Conditions of Clinical Interest.

.12 The system SHOULD support the ability of the provider provide the ability to configure any configurable Medical Condition of Interest (MCI) alerts.

The system SHOULD alert the care-giver of Medical Conditions of Interest (MCI).

.11 The system SHALL present lab data in numerical (tabular or spreadsheet) form over time to allow for trend analysis .

.12 The system SHALL present lab data in graphical form over time to allow for trend analysis .

.7 The system MAY provide the capability to maintain specialized medical examination protocols for unique physical exposures.

.9 The system SHALL provide the capability to maintain specialized medical treatment protocols for unique physical exposures.

.10 The system SHALL provide the ability to create configurable reports for specific populations/or topics of interest, (e.g. significant chronic conditions, suicidal risk, or for the military/VA: Wounded Warriors or those with Traumatic Brain Injury, etc.)

.11 The system SHALL provide the ability to configure any configurable reports for specific populations/or topics of interest, (e.g. significant chronic conditions, suicidal risk, or for the military/VA: Wounded Warriors or those with Traumatic Brain Injury, etc.)

.9 The system SHOULD support clinical research by identifying patients eligible for known active protocols as defined by inclusion and exclusion criteria.

.10 The system SHOULD provide the ability to alert staff of patient's eligibility for known active clinical research protocols as defined by inclusion and exclusion criteria.

.11 The system SHOULD provide the ability to export data to external clinical research systems.

.12 The system MAY provide the ability to support clinical research by maintaining an integrated patient registry that can be queried.

.1a The system SHALL determine, at the time of drug prescribing, potential drug-drug interaction(s).

.1b The system SHALL determine, at the time of drug dispensing, potential drug-drug interaction(s).

.1c The system MAY determine, at the time of drug administration, potential drug-drug interaction(s).

.1d IF the system determines that a potential drug-drug interaction(s) exists, THEN the system SHALL provide the ability to alert the caregiver, according scope of practice, organizational policy and jurisdictional law.

.2a The system SHALL determine, at the time of drug prescribing, potential drug-allergy interaction(s).

.2b The system SHALL determine, at the time of drug dispensing, potential drug-allergy interaction(s).

.2c The system MAY determine, at the time of drug administration, potential drug-allergy interaction(s).

.2d IF the system determines that a potential drug-allergy interaction(s) exists, THEN the system SHALL provide the ability to alert the caregiver, according scope of practice, organizational policy and jurisdictional law.

.11    The system SHOULD identify contraindications between a drug and patient conditions at the time of medication ordering.

.11 The system SHOULD determine contraindications between a drug and patient condition and characteristics (e.g. gender, age, weight, smoking status, pregnancy status, renal function) at the time of drug ordering.

.1   The system SHALL provide the ability to identify an appropriate drug dosage range, specific for each known patient condition and characteristic (e.g. gender, age, weight, body surface area [BSA], renal function, INR) at the time of drug ordering.

.4 The system SHALL support automatic migration of order entries into relevant systems.

STATEMENT: As per Release 1 … but … ADD Clinical Pathways

DESCRIPTION: As per Release 1 … but … ADD Clinical Pathways

ALL: For all CC that have the phrase " care plans, protocols, and guidelines", add "clinical pathways"

STATEMENT: As per Release 1 … but … ADD Clinical Pathways

DESCRIPTION: As per Release 1 … but … ADD Clinical Pathways

ALL: For all CC that have the phrase "care plans, protocols, and guidelines", add "clinical pathways"

.6 The system SHALL provide an intuitive User Interface (UI) that facilitates entering and addressing (e.g. acting on) orders with a minimum number of keystrokes or mouse gestures.

STATEMENT: As per Release 1 … but … ADD Clinical Practice Guidelines (CPGs)

1-3: For all CC that include the word "evidence-based", add "clinical practice guidelines (CPGs)"

.6 The system SHOULD provide the ability to configure Clinical Practice Guidelines (CPGs) initiation criteria.

.7 The system SHOULD algorithmically determine candidate patients based upon configured CPG initiation criteria.

.8 The system SHOULD render algorithmically identified patients applicable CPGs to the care giver.

.7 The system SHOULD provide the ability to render, manually and/or automatically, patient status (e.g. arrival, admission, discharge, death, etc.) notification to providers and care managers.

.8 IF a patient's status has changed, THEN the system MAY provide the ability to render, manually and/or automatically, patient care plans/instructions to providers and care managers.

.9 The system SHOULD be able to identify medications which will require Pharmacy intervention for administration.

.10 The system SHOULD be able to identify the designated in-house pharmacy that has responsibility for dispensing medications to a specific care area.

.11 The system SHOULD automatically (i.e. without further human intervention), render notification to the appropriate (e.g. Pharmacy of a medication order that requires the Pharmacy department's intervention (e.g. mixing and delivering a non-stock IV medication).

.13 The system SHOULD provide the ability to render notifications, manually and/or automatically, to patients for conditions and results that require follow-up, in accordance with scope of practice, organization policy and jurisdictional law.

.14 The system SHALL provide the ability to render information extracts (e.g. electronic, paper, CD-ROM) to patients.

.4 The system SHOULD provide the ability to capture data, manually and automatically, from medical devices.

STATEMENT: TBD (DC.3.2.6)

DESCRIPTION: TBD (DC.3.2.6)

.1 The system MAY provide the ability to capture health-related data, manually and automatically, from non-medical devices (e.g., digital camera or sound recorder).

.2 The system SHOULD provide the ability to identify health-care related entities (e.g., patient, ward, specimen, device) identified by digital identification technology (DIT) (e.g., bar code, RFID, microdots).

STATEMENT: TBD (DC.3.2.7.1)

.3 The system MAY render digital identification technology (DIT) enabled threshold-triggered inventory notifications.

.4 The system MAY support digital identification technology (DIT) enabled specimen tracking.

.5 The system MAY support digital identification technology (DIT) enabled patient tracking.

STATEMENT: TBD (DC.3.2.7)

DESCRIPTION: TBD (DC.3.2.7)

.1 The system SHOULD provide the ability to communicate salient patient care information (e.g. patient history, patient physical examination), discrete clinical data (e.g. blood pressure, pulse, temperature, pulse oximetry, laboratory data, microbiology data, radiology data), and orders between clinical systems in the facility (i.e. ambulatory, inpatient and ED).

DESCRIPTION: TBD (DC.3.2.7.1)

STATEMENT:

DESCRIPTION:

.1 The system SHOULD display situationally appropriate patient information on status/patient/tracking displays.

.1 The system SHOULD provide data that can be used for status and tracking mechanism (e.g. Tracking display) that displays, as a minimum: patient identification, patient location, medical condition, clinical process status, study status, vital signs, and an inter-staff communication vehicle.

.2 The system SHOULD provide an external status and tracking mechanism (e.g. Tracking display) that displays, as a minimum: patient identification, patient location, medical condition, clinical process status, study status, vital signs, and an inter-staff communication vehicle.

.3 The system SHOULD provide alerts to users via presentation tools (e.g. Tracking displays) for abnormal age-appropriate e.g., (Pediatric and Geriatric) patient parameters (e.g. vital signs, lab results).

.4 The system SHOULD provide the capability to update information directly via Tracking displays (rather than requiring invocation of other notes or windows).

.5 The system SHOULD provide retrospective (historical) reviewing of the ward/department state (e.g., patient distribution and location) at any point in time.

.6 The system SHOULD provide for direct navigation capabilities directly from Tracking/Status Display to relevant parts of the health record.

.7 The system SHOULD provide the ability to present use case based (e.g., role, location or context) appropriate tracking data to a display device.

.10 The system SHALL provide tracking display pre-defined mechanisms to facilitate sorting or triaging waiting patients

.11 The system SHALL provide tracking display customizable mechanisms to facilitate sorting or triaging waiting patients

.12 The system SHALL provide the ability to display pre-defined tracking display views based on multiple criteria sorts.

STATEMENT: TBD (DC.3.2.8)

DESCRIPTION: TBD (DC.3.2.8)

.13 The system SHALL provide the ability to maintain data presented on the Tracking display.

STATEMENT: TBD (DC.3.2.7.2)

DESCRIPTION: TBD (DC.3.2.7.2)

.1 The system SHALL provide the ability to document patient care during transitions between care-givers (e.g. during change of shift, admission).

.2 The system SHALL provide the ability to present transition-of-care related information,

.3 The system SHALL provide the ability to maintain transition-of-care related information,

.4 The system SHALL provide the ability to create workflow events (e.g. patient admission, provider shift change)

.5 The system SHALL provide the ability to configure workflow events (e.g. patient admission, provider shift change)

.1 The system SHALL provide the ability to capture patient transfer information using locally defined forms.

.2 The system SHALL provide the ability to render patient transfer information using locally defined forms.

STATEMENT: TBD (DC.3.2.9)

DESCRIPTION: TBD (DC.3.2.9

STATEMENT: TBD (DC.3.2.10)

DESCRIPTION: TBD (DC.3.2.10)

.1 The system MAY provide the ability to capture patient's employment data as relevant to potential medical conditions.

.2 The system MAY provide the ability to capture data that will assist the user with deciding if a patient is able to fulfill physical job requirements as a result of the patient's medical disposition.

.3 The system MAY provide the ability to support reporting to employers on patients who have incurred an injury or illness that impacts their ability to fulfill physical job requirements as a result of their medical disposition.

STATEMENT: TBD (DC.3.2.11)

DESCRIPTION: TBD (DC.3.2.11)

.1 The system MAY provide the ability to capture patient's employer data if the individual is considered "Special Interest Personnel" (SIP).

.2 The system MAY provide the ability to capture data that will assist the user with deciding if a patient is able to fulfill SIP job requirements as a result of the patient's medical disposition.

.3 The system MAY provide the ability to support reporting to employers on patients who have incurred an injury or illness that impacts their ability to remain in SIP status as a result of their medical disposition.

.3 The system SHALL provide the ability to flag special interest patients.

.5

.6

.7

.8

.9

.4 The system SHOULD provide the ability to capture patient employment information.

.3 The system SHALL provide support for identifying uniquely patients with similar names.

.6 The system SHOULD provide the ability to track special interest patients within the facility.

.3 The system SHALL support role based configuration changes for data entry.

.4 The system SHALL support role based configuration changes for data view.

STATEMENT: TBD (S.1.8.1) User Interface Management 1: Views

DESCRIPTION: TBD (S.1.8.1)

.1: The system MAY provide authorized administrators the ability to tailor the presentation of information according to role-based requirements, department/area preferences, or user preferences.

STATEMENT: TBD (S.1.8.2) User Interface Management 2: Interface

DESCRIPTION: TBD (S.1.8.2)

.1 The system MAY provide authorized administrators the ability to tailor user interfaces according to role-based requirements, department/area preferences, or user preferences.

.2: The system MAY provide authorized users the ability to tailor their user interfaces according to personal preferences according to organizational policy.

STATEMENT: TBD (S.1.8.3) User Interface Management 3: Entry

DESCRIPTION: TBD (S.1.8.3)

,1 The system MAY provide authorized users the ability to manage data via administratively tailored user interfaces.

.2 The system MAY provide authorized users the ability to tailor their presentation of information according to personal preferences according to organizational policy.

.13 The system MAY provide for the generation of near-time real-time performance metrics in accordance with relevant professional, industry and governing standards.

STATEMENT: TBD (S.2.1.3)

DESCRIPTION: TBD (S.2.1.3)

.1 The system MAY provide the ability to capture necessary data (e.g. clinical user feedback) supporting organizational efforts to optimize the EHR System (EHR-S).

.2 The system MAY provide the ability to capture necessary data (e.g. patient satisfaction feedback) supporting organizational efforts to improve the quality of healthcare and patient satisfaction.

.3 The system MAY provide tools to analyze returned patient survey data and render the results to facilitate improvements in provider-patient interactions, healthcare delivery, etc.

.4 The system SHOULD manage realm or organizational relevant health care delivery performance measurements, for example Healthcare Effectiveness Data and Information Set (HEDIS), time to aspirin from arrival, or time to antibiotics in pneumonia.

.5 The system SHOULD analyze realm or organizational relevant health care delivery performance measurements, for example Healthcare Effectiveness Data and Information Set (HEDIS), time to aspirin from arrival, or time to antibiotics in pneumonia.

.6 The system SHOULD manage ad hoc health care delivery performance measurements, for example Healthcare Effectiveness Data and Information Set (HEDIS), time to aspirin from arrival, or time to antibiotics in pneumonia.

STATEMENT: TBD (S.2.1.4)

DESCRIPTION: TBD (S.2.1.4)

.7 The system SHOULD analyze ad hoc health care delivery performance measurements, for example Healthcare Effectiveness Data and Information Set (HEDIS), time to aspirin from arrival, or time to antibiotics in pneumonia.

.1 The system SHALL support data driven feedback mechanisms, (e.g. dashboards, watchboards), that assist in patient management and healthcare delivery.

.5 The system SHALL provide, automatically (i.e. without further human intervention), real-time departmental load metrics.

.6 In Emergency Departments with multiple functional units (Emergency Department (ED), Fast Track (FT), Urgent Care (UC), etc.), the system SHALL provide the ability to capture information about the functional unit that delivered care to the patient.

.2 The system SHOULD support data driven feedback mechanisms, (e.g. dashboards, watchboards), that assist in hospital operations functions.

.8 The system SHOULD provide the ability to generate automated reports as required by industry and regulatory bodies.

.4 The system SHOULD provide the ability to specify and configure reporting parameters (e.g. patient demographic, clinical data, clinical conditions, diagnosis, disposition).

.4a The system SHOULD provide the ability to sort and/or filter reported data (e.g. significant chronic conditions, suicidal risk, or for the military/VA: Wounded Warriors or those with Traumatic Brain Injury).

.9 The system SHOULD provide facility level data access at an organizational level in support of organizational initiatives.

.10 The system SHOULD provide data migration from a facility level to an organizational level to support organizational healthcare optimization initiatives.

STATEMENT: TBD (DC.3.2.11)

DESCRIPTION: TBD (DC.3.2.11)

.3 The system SHALL provide the ability to analyze clinical documents for deficiencies using coding-based rules.

.4 The system SHALL provide the results of document coding deficiencies analysis to the coder.

.5 The system SHALL provide the ability to transmit the results of a coding documentation deficiency analysis to the appropriate user(s) (e.g. the deficient document or a link to same).

.6 The system SHALL provide the ability to integrate the deficiency remediation into the coding workflow.

.7 The system SHOULD provide the ability to present configurable (e.g. with respect to content, time of presentation), standard reports that support clinical documentation coding workflow.

.7 The system SHOULD provide the ability to present configurable (e.g. with respect to content, time of presentation), ad-hoc reports that support clinical documentation coding workflow.

.8 The system SHALL support the capture of critical care time in order to facilitate correctly coding the encounter.

Change in Description: Many regions require regular reporting on the healthcare provided to individuals and populations. These reports may include measures related to process, outcomes, and costs of care and may be used in 'pay for performance' and adherence to best practice guidelines monitoring. These reports may include metrics in accordance with relevant professional, industry and governing standards. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software.

.6 The system SHOULD provide the capability to notify appropriate user(s) about coding-related documentation deficiencies.

.7 The system SHOULD provide the capability to highlight coding-related documentation deficiencies.

STATEMENT: TBD (DC.3.2.4)

DESCRIPTION: TBD (DC.3.2.4)

STATEMENT: TBD (3.2.5)

DESCRIPTION: TBD (3.2.5)

.1 The system SHOULD provide the ability to capture information on clinician training and proficiency requirements, as defined by the applicable professional and governing organizations (e.g. Graduate Medical Education [GME] Program Information File [PIF], for a residency review committee [RRC]).

.2 The system SHOULD provide the ability to report on information on clinician training and proficiency requirements, as defined by the applicable professional and governing organizations (e.g. Graduate Medical Education [GME] Program Information File [PIF], for a residency review committee [RRC]).

.3 The system SHALL support the automated generation of the Program Information File as required by the Residency Review Committee

.3 The system MAY provide the ability to capture and report on role-based information on clinician training.

.4 The system MAY provide the ability to import and export data to external systems for centralized tracking of training.

.5 The system MAY provide or provide the ability for notification to users of enhancements/updates/ new training requirements based on their individual training records.

.6 The system MAY support modifying modify user permissions based upon changes in individual training information.

.7 The system SHOULD provide “just-in-time” training and education “help files”.

.8 The system SHALL remove personal patient identifying information on educationally relevant clinical consults for training and archiving.

STATEMENT: TBD (3.2.6)

DESCRIPTION: TBD (3.2.6)

.1 The system SHOULD provide the ability to capture information on clinician credentialing requirements, as defined by the applicable professional and governing organizations.

.2 The system SHOULD provide the ability to report on information on clinician credentialing requirements, as defined by the applicable professional and governing organizations.

.3 The system SHALL provide Peer Review capabilities to support non-discoverable Peer Review programs as required for maintenance of board certifications, credentials, and privileges.

.4 The system SHOULD provide the ability to standardize credentialing processes/procedures for telehealth activities.

.5 The system SHOULD provide tools to support peer review of relevant telehealth activities/cases (e.g. teleconsultation, home health monitoring, etc.) as appropriate to comply with quality assurance and JCAHO requirements

.4 The system SHALL support configurable reporting for billing offices/departments

.5 The system SHOULD provide the ability to create a configurable reports for billing offices/departments

.6 The system SHOULD provide the ability to configure any configurable reports for billing offices/departments

.4 The systems MAY provide the ability to extract and export data, using either internal or external reporting tools, to support coding of diagnosis, procedure and outcomes.

.1 The system SHOULD support the electronic capture and incorporation of a patient's human signature at the Point of Care.

.2 The system SHOULD support the electronic capture and incorporation of a patient's electronic signature at the Point of Care.

.3 The system SHOULD support the electronic capture and incorporation of a Medical Staff member's human signature at the Point of Care.

.4 The system SHOULD support the electronic capture and incorporation of a Medical Staff member's electronic signature at the Point of Care.

STATEMENT: TBD (IN.1.9.1)

DESCRIPTION: TBD (IN.1.9.1)

STATEMENT: TBD (IN.1.9.2)

DESCRIPTION: TBD (IN.1.9.2)

The system SHALL provide an off-site back-up of the system.

The system SHALL provide the ability to capture information that was created during system downtime.

The system SHOULD provide the ability to integrate information that was created during system downtime.

Within an organization the system SHALL make patient records available.

Within an organization the system with separated instantiations SHALL make patient records available enterprise-wide.

Within an organization with an array of subsystems the system SHALL make patient records available enterprise-wide.

IF information for a given patient resides in a given organization, THEN the system SHALL renderthe latest stuff patient information to the care team in near real timeavailable from the systemavailable from separate instantiationsavailable from separate systems

Within an organization the system SHALL make patient records available enterprise-wide.

Within an organization the system with separated instantiations SHOULD make patient records available enterprise-wide.

Within an organization utilizing an array of medical documentation systems the system MAY support making relevant patient records available enterprise-wide.

.26 The system SHALL provide the capability to track all alerts.

.27 The system SHALL provide the capability to track all acknowledgements of clinically significant report changes

The system SHALL, automatically (i.e. without further human intervention), time & date stamp any amendments to notes.

The system SHALL, automatically (i.e. without further human intervention), track any amendments to notes.

STATEMENT: TBD (IN.2.5.1)

DESCRIPTION: TBD (IN.2.5.1)

.10 The system SHALL provide a robust capability to incorporate multimedia digital objects images (MMDOs)

.10 The system SHOULD provide the ability to convert non-structured captured data into structured data.

STATEMENT: TBD (IN.2.5.2)

DESCRIPTION: TBD (IN.2.5.2)

STATEMENT: Provide checking of spelling and grammar as well as a medical thesaurus.

DESCRIPTION: Users would benefit from a function that enables rapid checking of spelling and grammar, as well as a medical thesaurus function.

.1 The system SHOULD support an integrated realm-based medical spelling function.

.2 The system SHOULD support an integrated realm-based medical thesaurus function.

.3 The system SHOULD support an integrated realm-based grammar function.

.4 The system SHOULD support an integrated realm-based text macro expansion function.

.5 The system SHOULD support a User Help function for data entry management.

STATEMENT: Users should have the ability to create macros, templates and pre-defined text.

DESCRIPTION: This function improves ease of usefulness for the providers. For example, a provider might want to develop his./her own template for patients who come in presenting with lower back pain.

.1 The system SHALL provide the ability for an authorized user to create personally pre-defined text.

.2 The system SHALL provide the ability for an authorized user to create personal templates.

.3 The system SHALL provide the ability for an authorized user to create personal macros for the insertion of pre-defined text.

.4 The system SHALL provide the ability for an authorized user to create personal macros for the insertion of templates.

.5 The system SHALL provide the ability for an authorized user to create enterprise pre-defined text.

.6 The system SHALL provide the ability for an authorized user to create enterprise templates.

.7 The system SHALL provide the ability for an authorized user to create enterprise macros for the insertion of pre-defined text.

.8 The system SHALL provide the ability for an authorized user to create enterprise macros for the insertion of templates.

.9 The system SHALL provide context-sensitive invokable help to guide users through charting steps.

STATEMENT: Health record information that is external to the system may be useful to the Care Team

DESCRIPTION: Prior to actually accessing such information, the existence of such information must be first established, then the location of such data. The user may make a choice to either import a link to the data or may choose to store a link to the data.

.1 The system MAY provide the ability to reference external information (textual and non-textual) via links.

.2 The system MAY provide the ability to render links to structured external health information.

.3 The system MAY provide the ability to render links (i.e. provide "awareness") to non-structured (e.g. images, documents) external health information.

.6 The system SHOULD have the capability to export data to external services and databases in accordance with industry and governmental-mandated (e.g. ONC) standards.

.7 The system SHOULD have the capability to import data from external services and databases in accordance with industry and governmental-mandated (e.g. ONC) standards.

STATEMENT: TBD (IN.5.1.1)

DESCRIPTION: TBD (IN.5.1.1)

STATEMENT: TBD (IN.5.5)

DESCRIPTION: TBD (IN.5.5)

STATEMENT: TBD (IN.5.5.1)

DESCRIPTION: TBD (IN.5.5.1)

STATEMENT: TBD (IN.5.5.2)

DESCRIPTION: TBD (IN.5.5.2)

STATEMENT: TBD (IN.5.5.3)

DESCRIPTION: TBD (IN.5.5.3)

.24 The system MAY present context-sensitive help to guide users through relevant local protocol, guideline, or workflow process steps.

The system SHALL render contextual cues such as user, patient, and station for (local, remote, virtual, or mobile) workstations according to scope of practice, organizational policy or jurisdictional law to promote patient care and safety.

The system SHALL manage concurrent use of a single patient's data by multiple users to promote information integrity.

The system MAY provide the ability for multiple users to simultaneously manage the same patient's data from different workstations.

The system MAY provide the ability for multiple users to simultaneously analyze the same patient's data from different workstations.

The system MAY provide the ability for multiple users to manage the same patient's data at the same workstation while other user(s) also logged into that workstation are also accessing the same record.

The system MAY provide the ability for multiple users to analyze the same patient's data at the same workstation while other user(s) also logged into that workstation are also accessing the same record.

The system MAY provide the ability for a single user logon to manage multiple patients' data simultaneously at a workstation.

The system MAY provide the ability for a single user logon to analyze multiple patients' data simultaneously at a workstation.

The system MAY provide the ability to manage the simultaneous logons of multiple users at a single workstation.

The system MAY provide the ability to manage a single user logging onto multiple workstations.

The system MAY provide the ability to simultaneously open multiple windows/views.

The system MAY provide the ability to switch (i.e. toggle) between windows/views on a single workstation.

The system MAY provide the ability to copy data from one window/view to another window/view on a single workstation without having to close/open any other windows/views.

.1 The system SHALL provide the configurable ability to present all versions of any document(s) that has been amended.

.2 The system SHALL provide the configurable ability to present all versions of any document(s) that has been appended.

.3 The system SHALL provide the configurable ability to present all versions of any document(s) that is being (has been) reviewed.

DESCRIPTION: TBD (IN.8)

STATEMENT: TBD (IN.8.1)

DESCRIPTION: TBD (IN.8.1)

STATEMENT: TBD (IN.8.2)

DESCRIPTION: TBD (IN.8.2)

STATEMENT: TBD (IN.8.3)

DESCRIPTION: TBD (IN.8.3)

EHR-S HL7 FUNCTIONAL MODELProposed New Functions and Conformance Criteria for Release 2.0Notes & Clarifications

Related to DC.1.1.1, #6

Clarification: The minimum data categories included in this requirement are demographics, medication, past medical history, surgical history, obstetrical history, allergy history, family history, immunization history, pediatric history, and social history.

Clarification: In the event of a VIP, DV, assault case, etc.

Clarification: Such categories could patients such as those with allergies, who are high "fall risk", or who are part of a clinical study, or for insurance type, etc.

Note: Linked to S.3.7.4

Clarification: There can arise the need to query/look for information crossing episodes of care or single encounters. This capability allows for this eventuality.

Note: Could be linked to DC.1.7.1 #8.

DELETE. Covered above.

Note: Could be linked to IN.2.2 #19

Clarification: Per the Joint Commission, Medication Reconciliation is the process of comparing a patient's medication orders to all of the medications that the patient has been taking. This reconciliation is done to avoid medication errors such as omissions, duplications, dosing errors, or drug interactions. It should be done at every transition of care in which new medications are ordered or existing orders are rewritten. Transitions in care include changes in setting, service, practitioner or level of care. This process comprises five steps: 1) develop a list of current medications; 2) develop a list of medications to be prescribed; 3) compare the medications on the two lists; 4) make clinical decisions based on the comparison; and 5) communicate the new list to appropriate caregivers and to the patient.

Recommend DELETING DC.1.7.2.1. CC#3 - superseded by the new CC on the left.

Clarification: This includes CPOE (Computerized physician order entry).

Clarification: A "disposition diagnosis" is the diagnosis rendered by the treating provider at the time that the patient is dispositioned from ED/FT/UC. (Emergency-Department / Fast-Track / Urgent-Care)

Clarification: A "disposition diagnosis" is the diagnosis rendered by the treating provider at the time that the patient is dispositioned from ED/FT/UC.

Note: Linked to IN.2.5.4

Note: Linked to IN.2.5.4

Note: Linked to IN.2.5.4

Clarifications:1. A flowsheet is a documentation tool used primarily by nursing staff to capture various types of data for a particular patient while in the ED/FT environment and include items such as vital signs, fluid input/urine output, mental status assessment results, etc.2. Such flowsheets are typically optimized for use cases with high charting loads.3. Specific flowsheets for particular conditions of interest include: Procedural Sedation, STEMI, Stroke, Sepsis, Resuscitation Code, Trauma Code, etc.

Note: Linked to DC.1.8.5 and S.3.1.2 (all)

Clarification: A record is "incomplete" if it is missing mandatory data (e.g. no diagnosis).

Note: Linked to DC.3.1. (Clinical Workflow Tasking)

Clarification: This is a subset of incomplete chart requirements.

Note: Linked to DC.3.1. (Clinical Workflow Tasking)

These should be ED/FT Profile Specific

These should be ED/FT Profile Specific

Clarifications: 1. This requirement talks to sending a notification to a caregiver (e.g. physician, nurse, PA) that a record is incomplete.2. Notification and routing would follow along the lines of, but provide for a distinct functionality from, the coding deficiency requirements.

Clarification:1. This requirement would allow an incomplete record to be electronically linked to an "inbox" or other notification mechanism so that the caregiver does not have to do a search in order to access the record.2. Notification and routing would follow along the lines of, but provide for a distinct functionality from, the coding deficiency requirements.

Changed to a SHOULD by Lenel and Pat on 09/10.

Note: Linked to DC.1.8.4 #6. (Flowsheets) and S.3.1.2 (all)

Reworded and changed to a MAY by Lenel and Pat on 09/10.

Clarification: Optimize means to present charts that list on the X-axis the age of the patient +/- 20% (or so) and the Y-axis with the measure of interest +/- 3 standard deviations.

Note: Linked to DC.1.8.4 #6. (Flowsheets) and S.3.1.2 (all)

Reworded and changed to a MAY by Lenel and Pat on 09/10.

Note: Linked to DC.1.8.4 #6. (Flowsheets), DC.2.5.1 and S.3.1.2 (all)

Per discussion 09/10/10 w/ Lenel and Pat, these should be ED/FT Profile Specific.

Note: Linked to DC.2.1.2

Per discussion 09/10/10 w/ Lenel and Pat, these should be ED/FT Profile Specific.

Note: Linked to DC.2.1.2

Per discussion 09/10/10 w/ Lenel and Pat, these should be ED/FT Profile Specific.

Note: Linked to DC.2.1.2

Downgraded to SHOULD on 9/1/10 by Lenel and Pat.

Note: Linked to DC.2.1.2

Downgraded to SHOULD on 9/1/10 by Lenel and Pat.

Note: Linked to DC.2.2.1.2

Clarification: A "disposition diagnosis" is the diagnosis rendered by the treating provider at the time that the patient is dispositioned from ED/FT/UC.

Note: Linked to DC 2.2.1.2

Reworded and downgraded from SHOULD to MAY on 9/10/10 by Lenel and Pat.

Clarification: This can apply to jailed personnel brought for treatment

Note: Linked to DC.1.10.1

Reworded on 9/10/10 to take out "realm-specific" (Lenel, Pat).

Clarifications:1. Patient encounters can end in many different states and support for these requires that the EHR accommodate, at a minimum, the following possible dispositions: (1) discharge, (2) admission, (3) transfer, (4) death, (5) left without being seen (LWBS), (6) left without treatment (LWOT), (7) elopements, (8) left against medical advice (AMA), (9) patients triaged to other clinics, & (10) administrative errors.2. DC 1.10: Documentation of Encounter Management -- May need to include encounter initiation documentation in addition to encounter conclusion: Gary.Reworded on 9/10/10 to take out "realm-specific" (Lenel, Pat).

Clarification: Manage Administrative resolution of post-encounter follow-up contacts

Discussion on 9/10/10 b/w Lenel, Mark and Pat resulted in temporary decision to keep DC.1.10.1 as part of the overall FM R2, but drilling down functions to the next levels may be too detailed for the moment.

Discussion on 9/10/10 b/w Lenel, Mark and Pat resulted in temporary decision to keep DC.1.10.1 as part of the overall FM R2, but drilling down functions to the next levels may be too detailed for the moment.

Discussion on 9/10/10 b/w Lenel, Mark and Pat resulted in temporary decision to keep DC.1.10.1 as part of the overall FM R2, but drilling down functions to the next levels may be too detailed for the moment.

Discussion on 9/10/10 b/w Lenel, Mark and Pat resulted in temporary decision to keep DC.1.10.1 as part of the overall FM R2, but drilling down functions to the next levels may be too detailed for the moment.

Reworded on 9/10/10 by Lenel and Pat.

Relates to DC 1.7, DC 1.8.3.11 (Results Notification), DC 3.2.3 (Support Clinical Communication),

Relates to: DC 3.3: Manage Administrative Resolution of Patient Post-Encounter Follow-up Contacts

Clarification: In environments like EDs where staff work in shifts, following up on results and patients requires implementation of a systemic process which is independent of specific individuals. Patients may require contact due to study results, discrete data, or patient data that are returned or are evaluated after the patient's encounter disposition. These callbacks are critical for places such as military hospital EDs.

Clarification: Manage Administrative resolution of post-encounter follow-up contacts

PV, MJ (2010-09-13): Change made to Description written in red.

LJ, SH, MJ (2009-09-13): Agreed to new statement wording.1. There are three basic subfunctions needed here: a. Identify problem, b. Notify about a prolem, c. User configures rules for identificationSH, MJ (2009/09/13): Function Statement added "conditions of clinical interest"PV, MJ (2009/09/13): NOTE: Function name changed to "Support for Identification and Notification of Potential Problems and Trends"

This expands on CC #3.

Clarification:

This is a split of CC #4.

Clarification: This requirement allows caregivers to provide or incorporate into the EHR decision rules for alerting for certain medical conditions (e.g. Systemic Inflammatory Response Syndrome or SIRS).This expands on CC #5 and 6

Clarification:

SH (2010/09/13): Conditions of Clinical Interest could include abnormal trends and potential problems. Suggest combining this and the two below into on CC.PV, MJ (2010-09-13): Replace CC #5 with this and the next two CCs.PV, MJ (2010-09-13): A condition of interest could be one that could be of concern to Public Health, biosurveillance, population-based health care or a possible uncommon medical diagnosis. PV, MJ (2010-09-13): Changed alert to notification. LH (2010-06-04): Should go under DC 2.Clinical Decision Support, 1.3 Support for Identification of Potential Problems and Trends

DELETE THIS ONE. See CC#5.a above.

DELETE THIS.

Child #2 of above requirement

PV, MJ (2010-09-13): This CC ought to be deleted as supporting configurable alerts includes the ability for a provider to make those configurations. Need to discuss with group.PV, MJ (2010-09-13): Strike Medical from Conditions of Interest.LH (2010-06-04): Should go under DC 2.Clinical Decision Support, 1.3 Support for Identification of Potential Problems and Trends

Clarification: Numerical data is often presented in tables. The term "flowsheet" as used in the HL7 Basic Profile should be replaced with table or spreadsheet.

LJ (2010-09-13): Downgrade to MAYPV (2010-09-13): Feels this may be getting too specific. May want to add to Description as example.NOTE: Related to DC.1.6.1Clarification: Protocols SHALL include, but not be limited to, chemical exposure (e.g. nerve agents, blister agents, hydrofluoric acid, heavy metal exposures), biologic agents, radiation hazards, and enhanced explosives threats (CBRNE).

LJ (2010-09-13): Downgrade to MAYPV (2010-09-13): Feels this may be getting too specific. May want to add to Description as example.NOTE: Related to DC.1.6.1Clarification: Protocols SHALL include, but not be limited to, chemical exposure (e.g. nerve agents, blister agents, hydrofluoric acid, heavy metal exposures), biologic agents, radiation hazards, and enhanced explosives threats (CBRNE).

See also S.2.2.2 CC#3 and S.2.2.3 CC#3.

The description at left is not a new CC, but should be placed into the function description of S.2.2.3 as examples.

See also S.2.2.2 CC#3 and S.2.2.3 CC#3.

Replace DC.2.3.1.1 CC#1 with these 4 CCs.

Replace DC.2.3.1.1 CC#1 with these 4 CCs.

Replace DC.2.3.1.1 CC#1 with these 4 CCs.

See also S.2.2.2 CC#3 and S.2.2.3 CC#3.

The description at left is not a new CC, but should be placed into the function description of S.2.2.3 as examples.

Clarification: Via collection/survey tools based on preset study inclusion criteria in a chart (such as patient age, sex, chief complaint).

Need to add a new SUPPORT function that addresses the management of clinical research protocols. See also DC.2.2.3 (Support for Research Protocols.) This new function would be helpful in allowing users to search for, capture and perhaps enroll patients in new protocols.

Replace DC.2.3.1.1 CC#1 with these 4 CCs.

Replace DC.2.3.1.1 CC#2 with these 4 CCs.

Replace DC.2.3.1.1 CC#1 with these 4 CCs.

.1b The system SHALL determine, at the time of dispensing, potential drug-allergy interaction(s).

.1c The system MAY determine, at the time of administration, potential drug-allergy interaction(s).

This is a REWRITE of DC.2.3.1.1, CC#11.: .11 The system SHOULD determine contraindications between a drug and patient condition and characteristics (e.g. gender, age, weight, smoking status, pregnancy status, renal function) at the time of drug ordering.

This is a REWRITE of DC.2.3.1.2, CC#1.

ADD Clinical Pathways

ADD Clinical Pathways

ADD Clinical Pathways

ADD Clinical Pathways

DELETE THIS. Covered in IN.5.3.See recommended rewrite of "The system SHALL support migration of entered orders into relevant ancillary/execution systems without human intervention."Clarification: Minimizes errors induced by human transcription of orders from one electronic system into another.Clarification: "Relevant" systems include ancillary and execution systems

Note: Bring in the concept of "evidence-based" of CPGs and of configurability, also include the examples from the original description. Expand DC 2.2.1.1 & 2.2.1.2. see also DC 2.7 -- "...patient specific data such as age, gender, developmental stage, their health profile, patient history, patient physical examination, discrete clinical data (e.g. blood pressure, pulse, temperature, pulse oximetry, laboratory data, microbiology data, radiology data) and any site-specific considerations."

Note: Bring in the concept of "evidence-based" of CPGs and of configurability, also include the examples from the original description. Expand DC 2.2.1.1 & 2.2.1.2. see also DC 2.7 -- "...patient specific data such as age, gender, developmental stage, their health profile, patient history, patient physical examination, discrete clinical data (e.g. blood pressure, pulse, temperature, pulse oximetry, laboratory data, microbiology data, radiology data) and any site-specific considerations."

ADD Clinical Practice Guidelines (CPGs)

The 8/31/10 group recommends that this CC be DELETED as it is difficult, if not impossible, to test.

Clarification: "Intuitive use is an interaction event of a user with an unknown or sporadically used system or object, which happens by spontaneous application of unconsciously transferred and adapted knowledge and thus is accompanied by a feeling of very low mental effort"1. "The process of Usability Testing, however, can assess the intuitiveness of a user interface in an objective manner"2.

1 - "Intuitively Usable User-Interface Concepts – Safety and Reliability for Usage of New Functions and Systems", Mohs & Oehme, Adjunct Proceedings of the First International Conference on Automotive User Interfaces and Interactive Vehicular Applications (Automotive UI 2009), Sep 21-22 2009, Essen, Germany.2 - http://cfg.cit.cornell.edu/design/concepts.html

Note: Bring in the concept of "evidence-based" CPGs and of configurability, also include the examples from the original description. Expand DC 2.2.1.1 & 2.2.1.2. see also DC 2.7 -- "...patient specific data such as age, gender, developmental stage, their health profile, patient history, patient physical examination, discrete clinical data (e.g. blood pressure, pulse, temperature, pulse oximetry, laboratory data, microbiology data, radiology data) and any site-specific considerations."

NOTE: Configure is not a currently accepted HL7 EHR-S word. It is an action verb that describes the ability for a user to determine parameters for what data may be accessed or how it is displayed. For example, a user might decide to show a list of patients sorted by alphabetical order but later decide to show the list in reverse alphabetical order.

See also DC.2.6.2

See also DC.2.6.3

See also DC.1.7.1

See also DC.1.7.1

See also DC.1.7.1

Clarification: This should be accomplished via telephone, mail, email, secure messaging. The notifications are to include radiology and laboratory results

Clarification: Information with respect to this criterion includes for example, vital signs (heart rate, BP, temperature, pulse, respirations) that can come either from devices (BP, thermometer) or direct observation of the patient. Medical devices include those that can obtain (1) vital signs (temperature, pulse/heart rate, and pulse oximeter), (2) visual acuity, (3) accucheck, (4) EKG monitor/12 lead EKG machine, (5) Point of Care Testing Devices (e.g. iStat Labs), (6) breathalyzers, & (7) laboratory systems.

Will need to continue discussion. At the 8/31/10 meeting in DC the group initially decided that this group of 5 CCs need to be part of a new Support function. See also S1.3 and S1.4 for current treatment of provider and patient location information. We foresee a Support functions for identification and also for tracking are needed. Will need to discuss with Gary and John.

Will need to continue discussion. At the 8/31/10 meeting in DC the group initially decided that this group of 5 CCs need to be part of a new Support function. See also S1.3 and S1.4 for current treatment of provider and patient location information. We foresee a Support functions for identification and also for tracking are needed. Will need to discuss with Gary and John.

Will need to continue discussion. At the 8/31/10 meeting in DC the group initially decided that this group of 5 CCs need to be part of a new Support function. See also S1.3 and S1.4 for current treatment of provider and patient location information. We foresee a Support functions for identification and also for tracking are needed. Will need to discuss with Gary and John.

Will need to continue discussion. At the 8/31/10 meeting in DC the group initially decided that this group of 5 CCs need to be part of a new Support function. See also S1.3 and S1.4 for current treatment of provider and patient location information. We foresee a Support functions for identification and also for tracking Will need to continue discussion. At the 8/31/10 meeting in DC the group initially decided that this group of 5 CCs need to be part of a new Support function. See also S1.3 and S1.4 for current treatment of provider and patient location information. We foresee a Support functions for identification and also for tracking are needed. Will need to discuss with Gary and John.

Note: This would be a new function DC.3.2.7 (Support for Communication Within an Enterprise/Facility.)

Clarifications: (This should be part of the function Description):1. Status/patient/tracking displays are different terms that refer to a visual display on a monitor that can sit on a desktop or be mounted on a wall or elsewhere that provides information about patients in a department, such as Emergency Department.2. These displays should only render data in compliance with scope of practice, organizational policy and jurisdictional law (prime candidate to be promoted as overarching criteria.)3. Situationally appropriate reflects the concern that some data displays, while not required but desirable, may not be suitable for display due to ED/FT visitors seeing such displays.

Clarification: Due to the dynamic nature of the ED with rapid movement of patients through the system and the acuity of the sickest patients, timely transmission of information (including but not restricted to patient identification, patient location, medical condition, clinical process status, study status, vital signs, and an inter-staff communication vehicle) is critical to both the successful delivery of optimal care, assisting the clinical, ancillary, and administrative staff in the delivery of optimal medical care.

Clarification: This will facilitate our situational awareness and understanding of ward/department utilization and its impact on patient care.

Clarification: Examples includes forms needed for transfers of care to a nursing home facility or to a prison.

Clarification: Examples includes forms needed for transfers of care to a nursing home facility or to a prison.

Clarification: This data typically would include the patient's job type and perhaps brief description of the job.

Note: Linked to DC.1.1.2 and DC.1.1.3

Note: Linked to DC.2.1.2 and DC.2.2.1

Clarification: Such reporting needs to be within the bounds of patient privacy regulations and laws. This is important in the military for "medical readiness" and civilian employers whose employees may have a job-limiting condition as a result of injury or illness.

Note: Linked to S.1.4.1 and S.2.2.1

Clarifications: 1. Special Interest Personnel include individuals such as firemen, policemen, emergency responders, pilots, divers, transportation workers, for which there are specific medical standards required to be met to be considered fit for duty.2. In addition to employment data as noted in DC.3.2.10 CC#1, employer data would include contact information for the patient's supervisor or supervising office. This data is essential in providing rapid notification of an employee's status, whose condition may temporarily or permanently remove them from SIP status and/or might affect manning levels.

Note: Linked to DC.1.1.2, DC.1.1.3 and S.3.2.10

Note: Linked to DC.2.1.2 and DC.2.2.1

Clarification: Linked to DC.1.1.2 and DC.1.1.3Note: Linked to S.1.4.1 and S.2.2.1

Note: In the military this would be captured for Special Duty Status patients (pilots, divers, etc) or combat wounded servicemen. In civilian settings Very Important People (VIPs) or hospital staff might be tracked, etc.

Replaced by DC.3.2.10

Replaced by DC.3.2.10

Replaced by DC.3.2.10

Replaced by DC.3.2.10

Replaced by DC.3.2.10

CHANGE IN DESCRIPTION FOR S.1.4.1: The minimum demographic data set must include the data required by realm-specific laws governing health care transactions and reporting. For example, this may include data input of death status information, or may include support to identify multiple names, such as updating from Baby Girl Doe, to neonate's given name, or employment information. Other demographic data, including employment information, can be particularly relevant for patients who may have incurred an occupational injury or illness, and/or have job duties (e.g. specialty duty personnel such as policemen, rescue personnel, aviators, certain military personnel, etc.) whose new condition may limit the patient's abilities to work in that capacity.

Clarification: This is necessary to reduce errors when interpreting lab results, prescribing medications, etc. This is particularly relevant for Tracking display functionalities where realm based display constraints limit the amount of patient information which can be shown. These reduced information sets may increase the likelihood of confusing patient identities.

Note: Linked to Tracking displays: DC 3.2.7

Clarification: In cases where of a domestic violence is involved it may be very important to flag 2 patients and then make sure that they are not placed in adjacent rooms. This is also important in the case of confused or head injured combat injured service members who need additional assistance. Note: In the military this would be captured for Sensitive duty status patients.

Child #1 of requirement above.

Note: Linked to S.3.1.1

Child #2 of requirement above.

Note: Linked to S.3.1.1

Clarification: Metrics are in accordance with relevant professional, industry and governing standards for Emergency Departments.

Clarification: "Necessary data" may be locally, regionally or nationally identified and relates to items such as performance metrics and "ease-of-use" statistics.

Note: This function and Conformance Criteria likely need to be expanded significantly.

Clarification: Allows visibility of provider-patient interactions, systemic problems, etc.

Clarification: "Necessary data" may be locally, regionally or nationally identified and relates to items such as performance metrics and "ease-of-use" statistics.

Note: This function and Conformance Criteria likely need to be expanded significantly.

Clarification: "Necessary data" may be locally, regionally or nationally identified and relates to items such as performance metrics and "ease-of-use" statistics.

Note: This function and Conformance Criteria likely need to be expanded significantly.

Clarification: "Necessary data" may be locally, regionally or nationally identified and relates to items such as performance metrics and "ease-of-use" statistics.

Note: This function and Conformance Criteria likely need to be expanded significantly.

Clarification: "Necessary data" may be locally, regionally or nationally identified and relates to items such as performance metrics and "ease-of-use" statistics.

Note: This function and Conformance Criteria likely need to be expanded significantly.

Clarifications: Feedback mechanisms include clinical, organizational, and business dashboards

Clarification: Needed to help optimize ED staffing and protocols (e.g. abbreviated admissions processes, etc.) and facilitate patient flow at high volume times.

.6 In Emergency Departments with multiple functional units (Emergency Department (ED), Fast Track (FT), Urgent Care (UC), etc.), the system SHALL provide the ability to capture information about the functional unit that delivered care to the patient.

Clarification: Such metrics could include patient volume per day, LWBS rate, average LoS, admission rate, etc., staffing levels. In the US, this would also include reporting to the Joint Commission (formerly JCAHO) on specific processes.

Clarification: In the US, one example would be for the Joint Commission (formerly JCAHO).

Note: This is NOT a NEW HL7 CC, but a CHANGE to the currently existing S.2.2.2 #4.

Clarification: This is a child of the CC/requirement S.2.2.2 #4 above.

Related to S.2.2.2

Clarification: Professional, governmental, industrial healthcare optimization initiatives

Clarification: Healthcare organizations include, but are not limited to, the following: Patient management, Healthcare delivery, population health/surveillance organizations (e.g. local, regional, national and global Public Health services, PAHO, WHO), and professional, governmental, industrial healthcare optimization initiatives.

Note: This is related to S.3.2.1, #2. (Rules-Driven Clinical Coding Assistance)

Clarification: This helps the coders to find deficiencies such as certain elements not having been entered into a patient's encounter (e.g. vital signs, diagnosis, etc.)Note: This is related to S.3.2.1, #2. (Rules-Driven Clinical Coding Assistance)

Clarification: This helps the coders to find deficiencies such as certain elements not having been entered into a patient's encounter (e.g. vital signs, diagnosis, etc.)

Clarification: Notification and routing would follow along the lines of, but provide for a distinct functionality from, the incomplete records requirements.

Clarification: Notification and routing would follow along the lines of, but provide for a distinct functionality from, the incomplete records requirements.

Related to S.2.2.2

Clarification: This is important in order to keep track of nurse and physician time in an ER directly seeing and treating critically ill patients.

Clarification: Notification and routing would follow along the lines of, but provide for a distinct functionality from, the incomplete records requirements.

Clarification: This would allow a user to quickly identify when there is/are element(s) that are missing that preclude supporting coding.

Clarification: The set of GME metrics is defined by professional and governing organizations.

Clarification: This requirement deals with the data that needs to be captured for the PIF to be reported to the RRC.

DELETE this requirement?

Clarification: This requirement deals with the data that needs to be captured for the PIF to be reported to the RRC.

Clarification: Metrics would be specific to trainees and authorized clinical staff providing training. They should include procedure logging, encounter logging, clinical hours, acuity log, admissions logging, ICU admission logging,

Clarification: This is needed to ensure that medical providers who move to different facilities within an enterprise only need to undergo system training once (with refresher courses as needed).

Clarification: This is needed to ensure that medical providers who move to different facilities within an enterprise only need to undergo system training once (with refresher courses as needed).

Clarification: This means a user can be denied access to use the system or portions thereof if he/she has not completed required training.

MHS TC 225.59Not specifically mentioned in HL7.

Note: This is likely as technical implementation requirement, but ought to be kept as this does describe a functional need.

MHS TC 225.60Not specifically mentioned in HL7.

Note: This is likely as technical implementation requirement, but ought to be kept as this does describe a functional need.

Clarification: Metrics would be specific to all providers practicing in the facility. They should include procedure logging, encounter logging, clinical hours, acuity log, admissions logging, ICU admission logging,

Clarification: Metrics would be specific to all providers practicing in the facility. They should include procedure logging, encounter logging, clinical hours, acuity log, admissions logging, ICU admission logging,

MHS TC 225.58Not specifically mentioned in HL7

MHS TC 225.62

Delete (as of 8/27/10).

Delete (as of 8/27/10).

Delete (as of 8/27/10).

See also S.2.2.2 & IN.2.4

Note: Linked to IN.1.7 & IN.1.8

Note: Linked to IN.1.7 & IN.1.8

Note: Linked to IN.1.7 & IN.1.8

Note: Linked to IN.1.7 & IN.1.8

IF the system manages life support care information, THEN the system SHOULD continuously export pre-designated life support care information as required for continuous clinical operations during failover for patients receiving life-support care according to scope of practice, organizational policy, and/or jurisdictional law.

Clarification: At minimum this needs to include scanning in paper documents and storing into the record as an electronic file.

Clarification: It needs to be decided at what level and which data needs to be integrated in a computable fashion. This may depend on technology such as Natural Language Processing.

This is the core criteria telling engineers that they need to make

For example if a physician is using the EHR and reading the patient chart and decides that (s)he needs to review the patient's radiographs, then the system should make that patient's radiographs and interpretations existing in the PACS system available. *In DC 1.1.3.1 we need to better job in the desciption and the conformance criteria of spelling our the context sensitive querying and linking of patient information. **Criteria #7&8 need to be reviewed regarding the storage aspect. You don't want to store a radiograph series (like a high definition CT series with and without contrast and a 3D reconstruction) from the PACS into the EHR DB. ***All of DC 1.1.1-1.1.3 is not workflow specific or facilitiating, instead it speaks to the scope of analogue or digital data collection (recieving, storing) for the patient record. Then from 1.1.4 it begins speaking to processing the data to faciliate workflow in a patient-centric clinical context. Clinical Context Object Workgroupt/Workstation (CCOW). **** Starting at 1.1.4 we need renumber. ***** 1.1.1-1.1.3: These are the Rules of Engagement (ROE) for Data Management/Records Handling. These are the functions that are needed to populate the record. ****** 1.1.4-1.1.x: This is point where the clinical staff begins to interact with the data. These are the functional criteria for how the system should present/provide information to the clinical staff. ROE for Data

This needs to be linked to RMES work if they have already come up with the wording. We have to be able to track all generated alerts. Then we have to be able to see when the alerts were acknowledged. This has huge implications for auditing records especially in the case of poor patient outcomes.

This needs to be linked to RMES work if they have already come up with the wording. We have to be able to track all generated report changes. Then we have to be able to see when the changes were acknowledged. This has huge implications for auditing records especially in the case of poor patient outcomes.

This needs to be linked to RMES work if they have already come up with the wording. We have to be able to track all generated report changes. Then we have to be able to see when the changes were acknowledged. This has huge implications for auditing records especially in the case of poor patient outcomes.

This needs to be linked to RMES work if they have already come up with the wording. We have to be able to track all generated report changes. Then we have to be able to see when the changes were acknowledged. This has huge implications for auditing records especially in the case of poor patient outcomes.

Clarification: MMDOs include digital images, movies, and sound files. * This could go into 1.1.3, i.e. capturing external data. ** Images are really an intrinsic part of the record.

Clarification: An example of this would be scanned in documents. By using OCR or other technologies, it is possible to capture elements of each "page" and to index and catalog the document so that it now becomes more easily discoverable.

The system SHALL provide the ability for an authorized user to create personally pre-defined text blocks, e.g. macros.

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Note: Should be consistent with IN.2.5.4 (User Interface Support)

2010-09-08 (MJ): Still need to nail this down

2010-09-08 (MJ): Still need to nail this down

Clarifications:1. Non-textual digital files include pictures (e.g. photos, radiographs), sound files, video files, scanned documents, .wav files, etc.).2. "Awareness" is the ability for a user to perform a search for certain data (e.g. in this case non-textual digital files) and receive in return a list (e.g. directory list, thumbnails, icons, etc.) of such data, but not actually accessing the data for viewing. For example, in querying a patient's non-textual files, a user might want

Clarification: This requirement is intended to support NHIN. For example, data should be exchangeable with RHIOs, VA & DoD, Public Health agencies, etc. This import/export capability shall be utilized to provide clinicians with access to medical information on patients who are not otherwise seen within the enterprise (i.e. whose medical records are not maintained within the enterprise system). Critically, this capability shall also be pointed at providing non-ED physicians with visibility to beneficiaries whose emergency care requirements bring them into the community.

Note: Linked to DC.3.2.7 and DC.3.2.8

Clarification: This requirement is intended to support NHIN. For example, data should be exchangeable with RHIOs, VA & DoD, Public Health agencies, etc. This import/export capability shall be utilized to provide ED clinicians with access to medical information on patients who are not otherwise seen within the enterprise (i.e. whose medical records are not maintained within the enterprise system). Critically, this capability shall also be pointed at providing non-ED physicians with visibility to beneficiaries whose emergency care requirements bring them into the community.

Note: Should be consistent with IN.2.5.4 (User Interface Support) * The scenario is that the staff is doing an admission and after completing a specific step (i.e. filling out a note) would like to know what step is next, i.e. call someone or complete another note.

Clarification: Typically this would be accomplished via multiple workstations. See requirements below for a single workstation.

Clarification: This requirement allows more than one user to have access to the same patient's records from the same workstation.NOTE: For two or more users working on the record for the SAME patient, there needs to be strict rules and version control for how the data is captured.

Clarification: This requirement allows more than one user to have access to the same patient's records from the same workstation.NOTE: For two or more users working on the record for the SAME patient, there needs to be strict rules and version control for how the data is captured.

Clarification: A user should be able to work on more than one patient record on a workstation without leaving another record.

Clarification: A user should be able to work on more than one patient record on a workstation without leaving another record.

Clarification: This requirement allows more than one user to have access to the same or different patients' records from the same workstation.NOTE: For two or more users working on the record for the SAME patient, there needs to be strict rules and version control for how the data is captured.

Clarification: A single user (e.g. doctor) can be called from one bed to another bed for a sick patient. Delivering timely (i.e. lifesaving) care precludes having the doctor run around to log out of other stations in order log in and now take care of a unstable patient.

Clarification: This is analogous to standard Window functions that allow users to have open multiple instantiations of an application and/or several application.

Clarification: This is analogous to standard Window functions that allow users to have open multiple instantiations of an application and/or several application.

Clarification: This is analogous to standard Window functions that allow users to have open multiple instantiations of an application and/or several application.

Where does this Go?

Note: Could be linked to IN.2.2 #15

Note: Could be linked to IN.2.2 #16

Note: Could be linked to IN.2.2 #17

2010-09-08 (JR): Patient Safety is not part of the functional model. Patient safety is already addressed in the current model by guidelines and protocols in DC.2. Need to run by Peter.

This WAS down at the end of IN.8 Only has a description. Probably was to be the new description for IN.8

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

System performance is outside the scope of the current HL7 Functional Model. Expect additional clarifying text in Overview Chapter 2.1.

EHR-S HL7 FUNCTIONAL MODELProposed New Functions and Conformance Criteria for Release 2.0Dr. Park Description

This function maximizes the clinical workflow, by reducing the overhead required for data entry. It also increases the data fidelity, by decreasing the human element of data corruption. The minimum data…

John and Jane Doe: The system will provide for automated or manual update for the Doe charts when the patient’s identity is determined.

Shall provide a mass casualty module with registration capability for the event of overwhelming patient volumes

Shall provide a mass casualty module with registration capability for the event of overwhelming patient volumes

The system SHALL provide for anonymized patient registration, in the event of a VIP, DV, assault case, etc.

Wrist Bands: The system should provide for wrist bands with different colors to highlight allergies and falls risks, etc.

Real-time Dashboards: The system will provide real-time clinical dashboards to assist in patient management.

Links to prior admissions: All current visits should provide automatic linkages to prior visits (active or archived)

Discharge Scripts: The solution will provide for the automated generation (either paper or electronic) of medication prescriptions which the patient can take or have transmitted to a civilian (non-MTF) pharmacy to have filled.

Shall provide for medication reconciliation in the system

Discharge Scripts: The solution will provide for the automated generation (either paper or electronic) of medication prescriptions which the patient can take or have transmitted to a civilian (non-MTF) pharmacy to have filled.

CPOE: Order status in progress, e.g. ordered, acknowledged, pending, in transport, completed, etc. should be clearly and easily visible to all system users and have a role base support.

The system SHALL support computerized physician/provider order entry (CPOE).

Shall provide for integrated Chief Complaint and Diagnosis based documentation and order templates to optimize patient care, documentation, and management

Shall provide for integrated Chief Complaint and Diagnosis based documentation and order templates to optimize patient care, documentation, and management

Lab Results: The system SHALL support automated Callback mechanisms to assure patients are informed of changes in management warranted by positive cultures and other late lab results.Radiology Results: The system SHALL support automated Callback mechanisms to assure patients are informed of changes in management warranted by corrected radiology reads.Radiology Results: The system SHALL support automated Callback mechanisms to assure patients are informed of changes in management warranted by corrected radiology reads.Radiology Results: The system SHALL automatically import both final and wet (preliminary) reads provided by radiology.

Integrated flowsheets optimized for use cases with high charting loads (Procedural Sedation, STEMI, Stroke, Sepsis, Resuscitation Code, Trauma Code, etc) will be provided to assist the nursing staff.

The system SHALL provide the capability for a user to readily identify his or her stored incomplete records and to determine, for each such record, what documentation needs to be completed.

The system SHALL provide alert prior to pt transfer or discharge regarding treatments/interventions without nursing reassessments documented.

The system SHALL provide the capability for a user to readily identify his or her stored incomplete records and to determine, for each such record, what documentation needs to be completed.

Consultants: Shall provide integrated charting tools for consultants that are optimized with single point of entry (data conservation).

Consultants: Shall provide integrated charting tools for consultants that are optimized with single point of entry (data conservation).

Shall provide for extremes of age optimized charting tools in recognition that children and geriatric populations have specific needs and pose unique challenges to their providers

Shall provide for extremes of age optimized charting tools in recognition that children and geriatric populations have specific needs and pose unique challenges to their providers

Shall provide for integrated Chief Complaint and Diagnosis based documentation and order templates to optimize patient care, documentation, and management

Shall provide for integrated Chief Complaint and Diagnosis based documentation and order templates to optimize patient care, documentation, and management

Medical ProfilesThe system SHALL support the documentation of confinement physicals.

Discharge Planning should accommodate the following Dispositions: (1) AMA, (2) elopements, (3) death, (4) transfers, (5) discharges, (6) left without being seen patients, and (7) patients triaged to other clinics.

Callbacks: The system SHALL provide a multidisciplinary mechanism with supporting charting to follow-up and provide aggregated reporting on these high risk patients.

Callbacks: The system SHALL provide a multidisciplinary mechanism with supporting charting to follow-up and provide aggregated reporting on these high risk patients.

Callbacks: The system SHALL provide a multidisciplinary mechanism with supporting charting to follow-up and provide aggregated reporting on these high risk patients.

The system SHALL compile various data points to provide alerts for various conditions of interest, including but not limited to SIRS criteria.

The system SHALL compile various data points to provide alerts for various conditions of interest, including but not limited to SIRS criteria.

The system SHALL compile various data points to provide alerts for various conditions of interest, including but not limited to SIRS criteria.

The system SHALL compile various data points to provide alerts for various conditions of interest, including but not limited to SIRS criteria.

The system SHALL compile various data points to provide alerts for various conditions of interest, including but not limited to SIRS criteria.

Lab data shall be presented with visualization of lab values over time to allow for trend analysis (both in numerical values and graphical representation)

Lab data shall be presented with visualization of lab values over time to allow for trend analysis (both in numerical values and graphical representation)

Support clinical research via data collection/survey tools that can be triggered intelligently based on preset study inclusion criteria in a chart (such as pt age, sex, chief complaint or manually fired from a "research" menu item) these research data collected need their own reporting suite based on the clinical question being asked. This will need real time support as studies are developed in the future.

Support clinical research via data collection/survey tools that can be triggered intelligently based on preset study inclusion criteria in a chart (such as pt age, sex, chief complaint or manually fired from a "research" menu item) these research data collected need their own reporting suite based on the clinical question being asked. This will need real time support

Support clinical research via data collection/survey tools that can be triggered intelligently based on preset study inclusion criteria in a chart (such as pt age, sex, chief complaint or manually fired from a "research" menu item) these research data collected need their own reporting suite based on the clinical question being asked. This will need real time support support clinical research by supporting a patient registry with and integrated querying tool.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

From HL7 FM Release 1

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

Medication Interactions: The system SHALL support real time medication interactions and allergies checks with alerts in the event that an interaction/allergy has been triggered.

CPOE SHALL provide automated transcription/migration of orders entered in the CPOE functionality into legacy and support systems in order for minimize errors induced by human transcription of orders from one electronic system into another.

Evidence Based Medicine: The system SHALL support automated evidence based medicine prompting based on H&P, studies, risk factors, differential diagnosis, etc. as indicated to recommend appropriate clinical pathways/guidelines.

Evidence Based Medicine: The system SHALL support automated evidence based medicine prompting based on H&P, studies, risk factors, differential diagnosis, etc. as indicated to recommend appropriate clinical pathways/guidelines.

CPOE SHALL provide an efficient and intuitive User Interface (UI) to facilitate entering and addressing orders with a minimum number of keystrokes or mouse gestures.

Evidence Based Medicine: The system SHALL support automated evidence based medicine prompting based on H&P, studies, risk factors, differential diagnosis, etc. as indicated to recommend appropriate clinical pathways/guidelines.

automated notification to PCMs that their patient has been seen and dispositioned from the ER. This notification message should include discharge and follow-up plans and instructions.

automated notification to PCMs that their patient has been seen and dispositioned from the ER. This notification message should include discharge and follow-up plans and instructions.

Pharmacy: Shall provide for automated notification to pharmacy when medications requiring their intervention for dispensing are ordered.

Pharmacy: Shall provide for automated notification to pharmacy when medications requiring their intervention for dispensing are ordered.

Pharmacy: Shall provide for automated notification to pharmacy when medications requiring their intervention for dispensing are ordered.

automated notification to patients for conditions requiring follow-up

Export Data: The system SHALL have ability to provide paper and/or pdf copies at the time of discharge to accompany patients.

The system SHALL provide the capability to auto import (via interface) data from the following medical devices: (1) vital signs equipment (temperature, pulse/heart rate, and pulse oximeter), (2) visual acuity, (3) accucheck, (4) EKG monitor/12 lead EKG machine, (5) Point of Care Testing Devices (e.g. iStat Labs), & (6) breathalyzers,

The system SHALL support the use of bar code technology to support inventory tracking with alerts for resupply issues

The system SHALL support the use of bar code technology to support inventory tracking with alerts for resupply issues

The system SHALL support the use of bar code technology to support inventory tracking with alerts for resupply issues

The system SHALL support the use of bar code technology to track laboratory specimens

The system SHALL provide the ability to communicate ED care information to the inpatient care system

The tracking displays will provide warnings when patient parameters (like vital signs or lab results) return abnormal.

The tracking displays will provide warnings when patient parameters (like vital signs or lab results) return abnormal.

The tracking displays will provide warnings when patient parameters (like vital signs or lab results) return abnormal.

Tracking displays will provide the capability to update information directly through them, rather than requiring invocation of other notes or windows.

Tracking displays: An Administrative View SHALL be able available to allow for retrospective viewing of ED (including Triage, Waiting Room, and Urgent/Fast Track) status at prior points in time. This will enhance our situational awareness and understanding of ED utilization and it’s impact on patient care.

The tracking display SHALL provide for direct navigation to relevant parts of the EDIS

Tracking displays will provide real-time data on outstanding (pending) care issues for the patient, such as labs, radiology studies and feedback when study results are accessioned in the system

The tracking displays SHALL provide a mechanism for staff to sort/triage waiting patients

The tracking displays SHALL provide a mechanism for staff to sort/triage waiting patients

The tracking displays SHALL provide for multiple levels of dependent sorting

Tracking displays will provide the capability to update information directly through them, rather than requiring invocation of other notes or windows.

Turnover Tool: The system SHALL support the documenting, tracking and workflow requirements for turnover patients.

Turnover Tool: The system SHALL support the documenting, tracking and workflow requirements for turnover patients.

Turnover Tool: The system SHALL support the documenting, tracking and workflow requirements for turnover patients.

Turnover Tool: The system SHALL support the documenting, tracking and workflow requirements for turnover patients.

Turnover Tool: The system SHALL support the documenting, tracking and workflow requirements for turnover patients.

Transfer of Care: The system SHALL support the use of MHS (or locally) required forms for patient transfer documentation.

Transfer of Care: The system SHALL support the use of MHS (or locally) required forms for patient transfer documentation.

Operational Readiness: SHALL provide reports to hospital administration on impact of emergency services provided upon local command readiness.

Operational Readiness: SHALL provide reports to hospital administration on impact of emergency services provided upon local command readiness.

Operational Readiness: SHALL provide reports to hospital administration on impact of emergency services provided upon local command readiness.

Operational Readiness: SHALL provide reports to hospital administration on impact of emergency services provided upon local command readiness.

Operational Readiness: SHALL provide reports to hospital administration on impact of emergency services provided upon local command readiness.

Operational Readiness: SHALL provide reports to hospital administration on impact of emergency services provided upon local command readiness.

Hospital (MTF) Metrics: the system SHALL provide for the ability to identify and track “Command Interest,” “Wounded Warrior,” etc. patients.

Shall identify the unit (by UIC) for all active duty members

The system SHALL provide support for identifying uniquely patients when there are patients with similar names and who are at risk for medication administration errors, etc.

Hospital (MTF) Metrics: the system SHALL provide for the ability to identify and track “Command Interest,” “Wounded Warrior,” etc. patients.

S1.8: User Interface Management 1: Views

S1.8: User Interface Management 2: Interfaces

S1.8: User Interface Management 2: Interfaces

Shall support a distributed data architecture, vies a vies Oracle 10, to allow information on patients seen anywhere in the MTF to be accessible in real-time to treating providers.

Shall support a distributed data architecture, vies a vies Oracle 10, to allow information on patients seen anywhere in the MTF to be accessible in real-time to treating providers.

S1.8: User Interface Management 3: Entry

S1.8: User Interface Management 1: Views

S1.8: User Interface Management 3: Entry

Departmental Metrics: SHALL provide departmental staff with automated real time departmental metrics including all industry standards, those published by the American College of Emergency Medicine, those published by the Joint Commission (formerly JCAHO), others specified by the MHS.

Software Optimization/Enhancement Monitoring Metrics: SHALL provide an mechanism to supply necessary data support the iterative MHS level initiative for ongoing emergency department informatics system and healthcare optimization

Patient Satisfaction: System SHALL support electronic patient satisfaction survey tools and provide tools for the automated analysis of returned data to allow visibility upon provider-patient interactions, systemic problems, etc.

Patient Satisfaction: System SHALL support electronic patient satisfaction survey tools and provide tools for the automated analysis of returned data to allow visibility upon provider-patient interactions, systemic problems, etc.

Process Optimization/Enhancement Monitoring Metrics: SHALL provide an mechanism to supply necessary data support the iterative MHS level initiative for ongoing emergency department informatics system and healthcare optimization

Process Optimization/Enhancement Monitoring Metrics: SHALL provide an mechanism to supply necessary data support the iterative MHS level initiative for ongoing emergency department informatics system and healthcare optimization

Process Optimization/Enhancement Monitoring Metrics: SHALL provide an mechanism to supply necessary data support the iterative MHS level initiative for ongoing emergency department informatics system and healthcare optimization

Process Optimization/Enhancement Monitoring Metrics: SHALL provide an mechanism to supply necessary data support the iterative MHS level initiative for ongoing emergency department informatics system and healthcare optimization

Departmental Metrics: SHALL provide departmental staff with automated real time departmental load metrics to help optimize staffing and protocols (i.e. abbreviated admissions or discharge processes, etc.) to facilitate patient flow at high volume times.

Hospital (MTF) Metrics: SHALL provide the hospital administrative staff with automated real time departmental metrics

the Joint Commission (formerly JCAHO) Mitigation Reports: SHALL provide the departmental and hospital administrative staff with automated departmental reports which redress issues identified of interest by the Joint Commission (formerly JCAHO).

ED Specialty Specific Metrics: SHALL support and provide data migration from MTF level to service level and MHS level to support tri-service ED consultant/specialty leader healthcare optimization initiatives

ED Specialty Specific Metrics: SHALL support and provide data migration from MTF level to service level and MHS level to support tri-service ED consultant/specialty leader healthcare optimization initiatives

The system SHALL support coding of the ED encounter based upon captured discrete data elements, by providing the user with feedback regarding coding-related documentation deficiencies and by providing the coder with a The system SHALL support coding of the ED encounter based upon captured discrete data elements, by providing the user with feedback regarding coding-related documentation deficiencies and by providing the coder with a summary of coding-related data elements that were documented during the ED encounter

The system SHALL support coding of the ED encounter based upon captured discrete data elements, by providing the user with feedback regarding coding-related documentation deficiencies and by providing the coder with a summary of coding-related data elements that were The system SHALL support coding of the ED encounter based upon captured discrete data elements, by providing the user with feedback regarding coding-related documentation deficiencies and by providing the coder with a Coding: SHALL provide real-time reports and data extraction with views created to support human coders where present

Coding: SHALL provide real-time reports and data extraction with views created to support human coders where present

Coding: SHALL support automated reporting of critical care time per visit to providers and coders.

The system SHALL support coding of the ED encounter based upon captured discrete data elements, by providing the user with feedback regarding coding-related documentation deficiencies and by providing the coder with a summary of coding-related data elements that were documented during the ED encounter

The system SHALL support coding of the ED encounter based upon captured discrete data elements, by providing the user with feedback regarding coding-related documentation deficiencies and by providing the coder with a summary of coding-related data elements that were documented during the ED encounter

The system SHOULD provide the ability to capture and report on information on clinician credentialing requirements, as defined by the applicable professional and governing organizations (e.g. program information file for a residency review commmittee. Training and proficiency.

The system SHOULD provide the ability to capture and report on information on clinician training and proficiency requirements, as defined by the applicable professional and governing organizations (e.g. metric for graduate medical education. information file for a residency review committee)

GME: Shall provide automated Residency Review Committee & Program Information File reporting

GME: Shall provide trainee and attending specific metrics including procedure logging, encounter logging, clinical hours, acuity log, admissions logging, ICU admission logging,

Training: The system will maintain a centralized (MHS level) training credentials database to facilitate notification to users of enhancements and updates along with training requirements.

Training: The system will maintain a centralized (MHS level) training credentials database to facilitate notification to users of enhancements and updates along with training requirements.

Peer Review: Notes and Reporting Tools will be provided to support and facilitate confidential (non-discoverable) peer review programs as required for Board Certification Maintenance.

Peer Review: Notes and Reporting Tools will be provided to support and facilitate confidential (non-discoverable) peer review programs as required for Board Certification Maintenance.

Peer Review: Notes and Reporting Tools will be provided to support and facilitate confidential (non-discoverable) peer review programs as required for Board Certification Maintenance.

Coding: SHALL provide real-time reports and data extraction to support third party billing offices

Coding: SHALL provide real-time reports and data extraction to support third party billing offices

Coding: SHALL provide real-time reports and data extraction to support third party billing offices

Coding: SHALL provide real-time reports and data extraction to support third party billing offices

Electronic Signatures for Consents: The system should support capture and incorporation of patient and Medical Staff signatures at the Point of Care.

Electronic Signatures for Consents: The system should support capture and incorporation of patient and Medical Staff signatures at the Point of Care.

Electronic Signatures for Consents: The system should support capture and incorporation of patient and Medical Staff signatures at the Point of Care.

Electronic Signatures for Consents: The system should support capture and incorporation of patient and Medical Staff signatures at the Point of Care.

Shall provide for an off-site back-up of the system to mitigate against a catastrophic local event.

Shall provide for an off-site back-up of the system to mitigate against a catastrophic local event.

Failover: Shall provide for an analog back-up system in the event of a catastrophic system failure

Failover: Shall provide for an analog back-up system in the event of a catastrophic system failure

Shall support a distributed data architecture, vies a vies Oracle 10, to allow information on patients seen anywhere in the MTF to be accessible in real-time to treating providers.

Amended/Appended Notes: The system SHALL automatically time/date stamp these modifications.

Amended/Appended Notes: The system SHALL automatically time/date stamp these modifications.

This is a critical need for the military and might be a SHALL.

Spelling: the system should have an integrated medical spelling and grammar checking functionality in place.

Spelling: the system should have an integrated medical spelling and grammar checking functionality in place.

Spelling: the system should have an integrated medical spelling and grammar checking functionality in place.

Spelling: the system should have an integrated medical spelling and grammar checking functionality in place.

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Macro text insertion: The system will provide for customizable personal and enterprise level templated macro insertion capability

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Help: Invokable online help shall be provided to guide users through charting and ED business processes steps

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Discussed 2010-09-07 (John Ritter, Lenel James, Mark Janczewski)

Connectivity: The system shall have the capability to import and export data to and from external services and DBs (e.g. CDR, VistA, etc.). This functionality shall support both automated data migration to and from pre-designated services and sources or upon “ad hoc request” from external sources in compliance with Office of the National Coordinator standards, which are defined and represented within the National Health Information Network program. This connectivity capability shall be utilized to provide MHS ED clinicians with access to medical information on civilian humanitarian patients and on beneficiaries who are not otherwise seen within the MHS MTF system, i.e. whose medical records are not maintained within AHLTA. Critically, this capability shall also be pointed at providing non-MHS ED physicians (including the VA) with visibility to MHS beneficiaries whose emergency care requirements take them into the community.

Note: Linked to DC.3.2.7 and DC.3.2.8

Connectivity: The system shall have the capability to import and export data to and from external services and DBs (e.g. CDR, VistA, etc.). This functionality shall support both automated data migration to and from pre-designated services and sources or upon “ad hoc request” from external sources in compliance with Office of the National Coordinator standards, which are defined and represented within the National Health Information Network program. This connectivity capability shall be utilized to provide MHS ED clinicians with access to medical information on civilian humanitarian patients and on beneficiaries who are not otherwise seen within the MHS MTF system, i.e. whose medical records are not maintained within AHLTA. Critically, this capability shall also be pointed at providing non-MHS ED physicians (including the VA) with visibility to MHS beneficiaries whose emergency care requirements take them into the community.

Help: Invokable online help shall be provided to guide users through charting and ED business processes steps

Overarching statement for the user-station-record Conf Criteria below

The system shall provide the capability for multiple users to simultaneously access, enter, and modify information about and within the same patient encounter record.

Single user logged into 2 machines at the same time.

The system shall provide the capability for multiple users to simultaneously access, enter, and modify information about and within the same patient encounter record.

The system shall provide the capability for multiple users to simultaneously access, enter, and modify information about and within the same patient encounter record.

The system shall provide the capability for multiple users to simultaneously access, enter, and modify information about and within the same patient encounter record.

Software should support opening multiple instances of the software upon a PC.

Software should support opening multiple instances of the software upon a PC.

Software should support opening multiple instances of the software upon a PC.

User Interface will support opening multiple windows and views and support switching (toggling) and copying between them at will. In other words, not requiring closing them to move between them.

User Interface will support opening multiple windows and views and support switching (toggling) and copying between them at will. In other words, not requiring closing them to move between them.

User Interface will support opening multiple windows and views and support switching (toggling) and copying between them at will. In other words, not requiring closing them to move between them.

Amended/Appended Notes: The system SHALL allow the user to easily review prior versions of the note.

Amended/Appended Notes: The system SHALL allow the user to easily review prior versions of the note.

Amended/Appended Notes: The system SHALL allow the user to easily review prior versions of the note.

DESC: Clinical data is only fully interpretable when viewed in the context of the entire supporting documentation. All versions of modified documents are thus necessary when reviewing a clinical encounter. Examples of where full reconstruction and forensic analysis are required of the staff include the following: quality assurance, legal proceedings, peer review, and teaching reviews.

EHR-S HL7 FUNCTIONAL MODELProposed New Functions and Conformance Criteria for Release 2.0 1st is for EHR-S, 2nd for EDIS

Out-Of-Cycle notes (2010-06-09) HL7 WGM Notes SHALL/ SHOULD/ MAY

overarching criteria at DC1 level. #REF!

#VALUE!

link to S 1.4.1 #VALUE!

link to S 1.4.1 #VALUE!

S.3.3.1 Enrollment of Patients SHOULD/ SHALL

SHOULD

NEW Function: IN.9.1 (Presentation Configuration)

The system SHALL provide the ability, through a controlled method, to merge or link dispersed information for an individual patient upon recognizing the identify of the patient. PLEASE UPDATE FUNCTION DESCRIPTION TO INCLUDE UPDATE CONCEPT

DC.1.1.1 Identify and Maintain a Patient Record

NEW Function S.1.9 (Support Healthcare Management for Disaster Response)

NEW Function S.1.9 (Support Healthcare Management for Disaster Response)

This is part of DC.1.1.1 - The system SHOULD provide the ability to create a recordfor a patient when the identity of the patient needs to be anonymous (e.g. VIP, assault, domestic violence).

The system SHOULD provide support data that can be used for wrist bands to designate patients in certain categories. (change to support)

DC.1.1.2 Manage Patient Demographics

0

0

think this exists, will review SHOULD

SHOULD

0

0

maybe exists? DC.1.7.1 #20 SHALL

NEW Function: DC.1.1.3.4 (Capture Guidelines and Standards from External Sources)

S2.2.3.4 (?): add a criteria to allow you to search for precious events meeting specified criteria.

NEW Function: IN.9.1 (Presentation Configuration) #4

almost positive exists DC.1.7.1 #21 SHALL

look at child health DC.1.7.1 SHALL

DC 2.4.1.#5 SHALL

DC 2.4.1.#7 SHALL

fine, added May/Shall, arrival in () DC 1.7.3 SHALL

DC 1.7.3 SHALLfine, added May/Shall, make this working diagnosis

fine, added May/Shall DC 1.7.3 SHALL

may want to move to alert/notification section SHOULD

may want to move to alert/notification section SHOULD

may want to move to alert/notification section SHOULD

DC.1.8.3 #18. SHALL

DC.1.8.3 #19. SHALL

prob yes DC.1.8.3 #20. SHALL

needs to be added DC.1.8.4 #6. SHALL

DC.1.8.5 #16. SHALL

DC.1.8.5 #17. SHALL

LH (2010-06-04):DC.1.8.3 Manage Results

LH (2010-06-04):DC.1.8.3 Manage Results

LH (2010-06-04):DC.1.8.3 Manage Results - it is unclear if this covers rad results too.

may already exist, doesn't need without any human intervention. Incorporate prelim and final resultsmay already exist, doesn't need without any human intervention. Incorporate prelim and final results

needs language clarification, needs to define incomplete record

The IN chapter needs to include a section on "completeness of records". **needs some work

happy DC.1.8.5 #18. SHALL

DC.1.8.5 #19. SHOULD

put on ballot as a shall and see what happens DC.1.8.5 #20. SHALL

DC 1.8.5 SHALL

DC 1.8.5 #VALUE!

DC 1.8.6 #VALUE!

DC 1.8.7 #VALUE!

DC 1.8.5 SHALL

DC 1.8.5 SHALL

conditional yes? Link to support care documentation

Consider using an approved Action-Verb (in place of the term "Use").

create a small child fx that specifies the functions of those tools. Then describe cleanly the definition the role tasks of a U.S. Consulting physician (vis the attending physician; There will be a link to the RBAC

DC 1.8.5 SHALL

DC 1.8.5 SHALL

DC 1.8.5 SHALL

DC 1.8.5 #VALUE!

DC 1.8.5 #VALUE!

DC 1.8.5 SHALL

DC.1.8.5 #21. #VALUE!

#REF!

SHALL

NEW Function S.3.8.1 (Support for Provider Training)

NEW Function S.3.8.1 (Support for Provider Training)

SHALL

SHALL

SHALL

SHALL

Note: This would be a new function DC.1.10 (Manage ED Disposition)

Note: This would be a new function DC.1.10 (Manage ED Disposition)

NEW Function DC.1.10 (Manage ED Disposition) .1 (Manage ED Discharge) .1 (Manage follow-On Care)

NEW Function: DC.1.10 (Manage ED Disposition) .1 (Manage ED Discharge) .1 (Manage follow-On Care)

SHALLNote: This would be a new function DC.1.10 (Manage ED Disposition) .1 (Manage ED Discharge) .1 (Manage follow-On Care)

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD/ SHALL

LH (2010-06-04):DC 2.Clinical Decision Support 1.3 Support for Identification of Potential Problems and Trends

LH (2010-06-04):DC 2.Clinical Decision Support 1.3 Support for Identification of Potential Problems and Trends LH (2010-06-04):DC 2.Clinical Decision Support 1.3 Support for Identification of Potential Problems and Trends

SHOULD/ SHALL

SHOULD/ SHALL

DC.2.1.3 SHALL

DC.2.1.3 SHALL

DC.2.2.1.1 #7. #VALUE!

DC.2.2.1.2 #9. SHALL

S.2.2.2.#10 SHALL

LH (2010-06-04):DC 2.Clinical Decision Support 1.3 Support for Identification of Potential Problems and Trends

LH (2010-06-04):DC 2.Clinical Decision Support 1.3 Support for Identification of Potential Problems and Trends

S.2.2.2.#11 SHALL

SHOULD

SHOULD

SHOULD

SHOULD

SHALL

SHALL

#VALUE!

DC.2.2.3 Support for Research Protocols Relative to Individual Patient Care

DC.2.2.3 Support for Research Protocols Relative to Individual Patient Care

DC.2.2.3 Support for Research Protocols Relative to Individual Patient Care

DC.2.2.3 Support for Research Protocols Relative to Individual Patient Care

DC.2.3.1.1 Support for Drug Interaction Checking

DC.2.3.1.1 Support for Drug Interaction Checking

DC.2.3.1.1 Support for Drug Interaction Checking

SHALL

SHALL

SHALL

#VALUE!

SHALL

DC.2.3.1.1 Support for Drug Interaction Checking

DC.2.3.1.1 Support for Drug Interaction Checking

DC.2.3.1.1 Support for Drug Interaction Checking

DC.2.3.1.1 Support for Drug Interaction Checking

DC.2.3.1.1 Support for Drug Interaction Checking

DC 2.4.1.#4 SHALL

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD/ SHALL

DC.2.7.1 Access Healthcare Guidance

DC.2.7.1 Access Healthcare Guidance

DC.2.7.1 Access Healthcare Guidance

DC.2.7.1 Access Healthcare Guidance

DC.2.7.1 Access Healthcare Guidance

DC.2.7.1 Access Healthcare Guidance

DC 2.4.1.#6 SHALL

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD

SHOULD

SHOULD

DC.2.7.1 Access Healthcare Guidance

DC.2.7.1 Access Healthcare Guidance

LH (2010-06-04):Same as the one above

LH (2010-06-04):Same as the one above

LH (2010-06-04):Same as the one above

#REF!

#REF!

#VALUE!

#VALUE!

#VALUE!

DC.3.2.1 Support for Inter-Provider Communication

DC.3.2.1 Support for Inter-Provider Communication

DC.3.2.2 Support for Provider-Pharmacy Communication

DC.3.2.2 Support for Provider-Pharmacy Communication

DC.3.2.2 Support for Provider-Pharmacy Communication

DC 3.2.3 #13 SHOULD

SHALL

#VALUE!

#VALUE!

#VALUE!

DC.3.2.3 Support for Communications Between Provider and Patient and/or the Patient Representative

DC.3.2.5 Communication with Medical Devices

DC.3.2.5 Communication with Medical Devices

NEW function DC.3.2.6 (Communication with non-Medical Devices)

SHOULD

SHOULD

SHOULD

SHOULD/ SHALL

SHOULD/ SHALL

SHOULD/ SHALL

NEW function DC.3.2.6 (Communication with non-Medical Devices)

NEW function DC.3.2.6 (Communication with non-Medical Devices)

NEW function DC.3.2.6 (Communication with non-Medical Devices)

Note: This would be a new function DC.3.2.7 (Support for Communication Within an Enterprise/Facility.)

Note: This would be a new function DC.3.2.7 (Support for Communication Within an Enterprise/Facility.)

Note: This would be a new function DC.3.2.7 (Support for Communication Within an Enterprise/Facility.)

SHOULD/ SHALL

SHOULD/ SHALL

#VALUE!

#VALUE!

Note: This would be a new function DC.3.2.7 (Support for Communication Within an Enterprise/Facility.)

Note: This would be a new function DC.3.2.7 (Support for Communication Within an Enterprise/Facility.)

NEW Function: DC.3.2.7.1 (Tracking Boards)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools) (LINKS to the new proposed S1.4.1.#43

SHOULD

#VALUE!

#VALUE!

#VALUE!

#VALUE!

#VALUE!

SHALL

SHALL

SHALL

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

SHALL

SHALL

SHALL

SHALL

SHALL

SHALL

SHALL

SHALL

DC 3.2.7.1 (NEW FUNCTION (Tracking Tools)

DC 3.2.7.2 NEW FUNCTION (Transition of Care Tools)

DC 3.2.7.2 NEW FUNCTION (Transition of Care Tools)

DC 3.2.7.2 NEW FUNCTION (Transition of Care Tools)

DC 3.2.7.2 NEW FUNCTION (Transition of Care Tools)

DC 3.2.7.2 NEW FUNCTION (Transition of Care Tools)

NEW Function: DC 3.2.8 (Support for Communications Between Enterprises/Facilities)

NEW Function: DC 3.2.8 (Support for Communications Between Enterprises/Facilities)

#VALUE!

#VALUE!

#VALUE!

NEW Function: DC.3.2.10 (Support for Provider-employer Communication)

NEW Function: DC.3.2.10 (Support for Provider-employer Communication)

NEW Function: DC.3.2.10 (Support for Provider-employer Communication)

#VALUE!

#VALUE!

#VALUE!

please link to DC 1.1.2 S.1.4.1.#3 (Demographics) SHALL

NEW Function: DC.3.2.11 (Support for Special Interest Personnel)

NEW Function: DC.3.2.11 (Support for Special Interest Personnel)

NEW Function: DC.3.2.11 (Support for Special Interest Personnel)

S.1.4.1, #4. #VALUE!

needs a home. (link to S1.4.1 & DC 1.1.2) S.1.4.1 #3. SHALL

:), add clarification into the description SHALL

accepted 6/11/10. Link to DC1.1.2.(Need to expand this to cover the rest of the demographic buckets: name, family info, address...)

S.1.4.2. (Tracking Special Interest Patients within a facility) #6

:) move to S1.8.2 (Modify) SHALL

:) move to S1.8.1 (View) SHOULD

NEW Function: IN.9.1 (Presentation Configuration) #2

NEW Function: IN.9.1 (Presentation Configuration) #3

SHOULD

SHOULD

#REF!

Maybe, depending on "automatic", without human intervention, input from other authors and adding clarifying, already covered in general terms for S.2.1.2 Performance & S.2.2.2 Standard rpt - is a profile detail. ADD to the S.2.1.2 Descriptions: New sentence 2. "These reports may include measures related to process, outcomes, costs of care and may be used in 'pay for performance' and

S.2.1.2.#4

:) :) ** ((NEW FUNCTION S2.1.3 Clinical Process Improvement)) Needs a statement and description

NEW Function: IN.8.1 (EHR-S User Feedback)

:) :) ** ((NEW FUNCTION S2.1.3 Clinical Process Improvement)) Needs a statement and description

S.2.1.1 Outcome Measures and Analysis

#REF!

SHOULD

SHOULD

SHOULD

S.2.1.1 Outcome Measures and Analysis

:) Sue when you get here. This is really a new function in supportive. There is already retrospective decision support. This starting in IN8, but is really not application optimization it's business process improvement. There is a child in there which says you are taking the data to do retrospective DS, however this information can help re-engineer the business or clinical process.

New Function: S2.1.3 (Business or Clinical Process Improvement)

NOTE: This refers to care delivery performance measures. Not technical hardware performance.

New Function: S2.1.3 (Business or Clinical Process Improvement)

NOTE: This refers to care delivery performance measures. Not technical hardware performance.

New Function: S2.1.3 (Business or Clinical Process Improvement)1.

#VALUE!

SHALL

S.2.1.2.#5 #VALUE!

NOTE: This refers to care delivery performance measures. Not technical hardware performance. *The measures being captured, analyzed, and reviewed will tell the healthcare team how they are performing. In the event that these measures are falling below the target, the changes required to improve the outcomes are likely to involve software and/or business process changes or enhancements which will would validated following implementation. **These criteria ought to further refine the CDS in support.

New Function: S2.1.3 (Business or Clinical Process Improvement)

DESC: Need a description of the dashboard/watchboard function and it's value

NEW Function: S.2.1.4 (Real-time Mechanisms) these are really clinical management dashboards. They are care system clinical performance indicators

The DESC must highlight the fact the new dimension of institution and timeliness must be added.

S.2.1.2.#6 #VALUE!

#VALUE!

S.2.2.2.#8 SHOULD

#VALUE!

S.2.2.2.#4a #VALUE!

.6 The system SHALL provide the ability to capture information about the functional subunit that delivered care to the patient in health care settings with multiple functional subunits (e.g. Emergency Departments with a Fast Track, Operating Rooms with Anesthesia Preop Holds and Post Anesthesia Care Units, Medicine Services with multiple wards).

.2 The system SHALL support data driven feedback mechanisms, (e.g. dashboards, watchboards), that assist in hospital operations functions.

S.2.2.2.#7 - move to 2.1.4. #2 these are really administrative/hospital management dashboards. They are care system administrative performance indicators

Original HL7 CC 2.2.2, #4.   The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.

S.2.2.2. #9 SHOULD

S.2.2.2. #10 SHOULD

#REF!

#REF!

#REF!

#REF!

#REF!

S.3.2.1 (Rules-Driven Clinical Coding Assistance) #3.

S.3.2.1 (Rules-Driven Clinical Coding Assistance) #3.

S.3.2.1 (Rules-Driven Clinical Coding Assistance) #4.

S.3.2.1 (Rules-Driven Clinical Coding Assistance) #4.

S.3.2.1 (Rules-Driven Clinical Coding Assistance) #5.

#REF!

S 3.2.1.#7 SHOULD

Instead of new function . SHOUL

SHALL

S.3.8.2 #2. #REF!

S.3.8.2 #2. #REF!

S.3.2.1 (Rules-Driven Clinical Coding Assistance) #5.

This is part of S.2.1.2 Performance measures. The system SHOULD support the capture and reporting of clinician time per episode of care. The system MAY support

NEW Function: S.3.2.4 (Deficiency Handling)

The systems SHOULD provide the ability to capture and report on coding-related documentation deficiencies. (See also link to DC.3.1.1 Task Assignment and Routing)

NEW Function: S.3.2.4 (Deficiency Handling)

SHALL

#VALUE!

SHOULD

#VALUE!

#VALUE!

A new function under S.3.2 Infor for Supplemental Use - LJ The system SHOULD provide the ability to capture and report on information on clinician credentialing requirements, as defined by the applicable professional and governing organizations (e.g. program information file for a residency review commmittee. Training and proficiency.

NEW Function S.3.8.1 (Support for Provider Training)

A new function under S.3.2 Infor for Supplemental Use - LJ The system SHOULD provide the ability to capture and report on information on clinician training and proficiency requirements, as defined by the applicable professional and governing organizations (e.g. metric for graduate medical education. information file for a residency review committee)

NEW Function S.3.8.1 (Support for Provider Training)

A new function under S.3.2 Infor for Supplemental Use - LJ

NEW Function S.3.8.1 (Support for Provider Training)

A new function under S.3.2 Infor for Supplemental Use - LJ The system MAY provide the ability to capture and report on role-based information on clinician credentialing requirements, Training and proficiency.

NEW Function S.3.8.1 (Support for Provider Training)

A new function under S.3.2 Infor for Supplemental Use - LJ The system MAY provide the ability to import and export data to external systems for centralized training tracking.

New function S.3.8 (Provider Training, Credentialing and Privileging) .1 (Training)

S.3.8.2 #2. #REF!

S.3.8.2 #2. #REF!

S.3.8.2 #2. #REF!

S.3.8.2 #2. #REF!

S.3.8.2 #2. #REF!

A new function under S.3.2 Infor for Supplemental Use - LJ

New function S.3.8 (Provider Training, Credentialing and Privileging) .2 (C&P)

A new function under S.3.2 Infor for Supplemental Use - LJ

New function S.3.8 (Provider Training, Credentialing and Privileging) .2 (C&P)

A new function under S.3.2 Infor for Supplemental Use - LJ

A new function under S.3.2 Infor for Supplemental Use - LJ

A new function under S.3.2 Infor for Supplemental Use - LJ

A new function under S.3.2 Infor for Supplemental Use - LJ

A new function under S.3.2 Infor for Supplemental Use - LJ

A new function under S.3.2 Infor for Supplemental Use - LJ

S3.3.5.#4 SHOULD/ SHALL

S3.3.5.#5 #VALUE!

S3.3.5.#6 #REF!

S3.3.5.#7 #VALUE!

IN 1.8.8 SHOULD

IN 1.8.9 SHOULD

IN 1.8.10 SHALL

IN 1.8.11 #VALUE!

A new function under S.3.2 Infor for Supplemental Use - LJ

Not needed - LJ, already in S.3.1.3 But add a see also to S.2.2.2 Std rpts)

Not needed - LJ, already in S.3.1.3 But add a see also to S.2.2.2 Std rpts)

Not needed - LJ, already in S.3.1.3 But add a see also to S.2.2.2 Std rpts)

May not be needed - LJ, already in S.3.1.3 But add a see also to S.2.2.2 Std rpts) The systems MAY provide the ability to extract and export data, usingeither internal or external reporting tools, to support coding of diagnosis, procedure and outcomes. (see also S.2.2.2 & IN.2.4)

NEW Function IN.9.4 (User Interface with Devices)

NEW Function IN.9.4 (User Interface with Devices)

NEW Function IN.9.4 (User Interface with Devices)

NEW Function IN.9.4 (User Interface with Devices)

to a remote location SHOULD

SHOULD

SHALL

SHOULD

IN.2.1 Data Retention, Availability and Destruction

The system SHALL export information to support continuous operations, business continuity, and/or failover requirements

IN.2.1 Data Retention, Availability and Destruction

Note: coordinate this language with the RMES Functional Profile.

IN.2.1 Data Retention, Availability and Destruction

Note: coordinate this language with the RMES Functional Profile. See IN.2.5.8

IN.2.1 Data Retention, Availability and Destruction

RESUME HERE SHALL

This is the core conformance criteria.

Moot

IN.2.1 Data Retention, Availability and Destruction

IN.2.2 #26. SHALL

IN.2.2 #27. SHALL

IN 2.2 SHALL

IN 2.2 SHALL

IN.2.5.1 #10. SHALL

S 3.1.5 #REF!

S4: Language Support S.4.1 SHOULD

S4: Language Support S.4.2 SHOULD

S4: Language Support S.4.3 SHOULD

S4: Language Support S.4.4 SHOULD

S4: Language Support S.4.4 SHOULD

NEW Function: IN.9.3 (Spelling and Grammar Check)

NEW Function: IN.9.3 (Spelling and Grammar Check)

NEW Function: IN.9.3 (Spelling and Grammar Check)

NEW Function: IN.9.3 (Spelling and Grammar Check)

NEW Function: IN.9.3 (Spelling and Grammar Check)

S.3.1.5 SHALL

S.3.1.5 SHALL

S.3.1.5 SHALL

S.3.1.5 SHALL

S.3.1.5 SHALL

S.3.1.5 SHALL

S.3.1.5 #REF!

S.3.1.5 #REF!

DC.1.8.5 #16. SHALL

0

0

DC.3.2.1 #7 #VALUE!

DC.3.2.1 #7 #VALUE!

DC.3.2.1 #7 #VALUE!

IN5.1 #6 SHOULD

IN5.1 #7 SHOULD

The system SHOULD render data to support realm, region, and local health information exchanges in accordance with industry and governmental-mandated (e.g. NEHTA, ONC) (1) content format, (2) reference terminology, (3) security & privacy, and (4) information exchange standards. *THIS IS A KEY STANDARD*

The system SHOULD support capture data from realm, region, and local health information exchanges in accordance with industry and governmental-mandated (e.g. NEHTA, ONC) (1) content format, (2) reference terminology, (3) security & privacy, and (4) information exchange standards. *THIS IS A KEY STANDARD*

:) IN.6 #24. #VALUE!

cues

Multi Users Single Record

IN.7 #VALUE!user issues 1 - Multi User Multi Station Single Record

IN.7 #VALUE!

IN.7 #VALUE!

IN.7 #VALUE!

IN.7 #VALUE!

IN.7 #VALUE!

user issues 4 - Multi Users Single Station IN.7 SHOULD

user 10 - Single User Multi Stations #VALUE!

windows issues 1 IN.7 #VALUE!

windows issue 2 IN.7 SHOULD

user issues 2 - Multi User Multi Station Single Record

user issues 5 - Mult Users Single Station Single Record

user issues 6 - Mult Users Single Station Single Record

user issues 9 - Single User Single Station Multi Records

user issues 9 - Single User Single Station Multi Records

windows issue 3 IN.7 SHOULD

SHALL

#REF!

NEW Function IN.9.1. SHALL

Is this in RMES? S2.2.1.CC8 (Does this move to DC, per Don)

NEW Function: IN.9.1 (Presentation Configuration)

Is this in RMES? S2.2.1.CC9 (Does this move to DC, per Don)

NEW Function: IN.9.1 (Presentation Configuration)

Is this in RMES? S2.2.1.CC10 (Does this move to DC, per Don)

153

153

9

174

175

227

10

11

163

12

13

14

72

74

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

43

232

233

47

48

44

45

46

1

1

50

50

50

51

52

53

54

55

56

61 GLD - Seems to be covered by S.2.2 and sub-sections.

62 GLD - Seems to be covered by S.2.2 and sub-sections

57

58 GLD - Add new Conformance Criteria to DC.2.2.3.

59 GLD - S.2.2.2 & S.2.2.3, both CC #3, have this covered.

60 GLD - Add new Conformance Criteria to DC.2.2.3.

63 GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

63 GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

63 GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

63 GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

63 GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

64 GLD - As per WGM notes, is covered by DC.2.3.1.1, particularly CC #3.

64 GLD - As per WGM notes, is covered by DC.2.3.1.1, particularly CC #3.

63 GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

71

75

75

75

75

75

75

73

75

75

76

77

78

88

88

82

82

82

85

89

91

92

94

95

97

99

100

100

100

100

100

101

102

103

104

105

106

107

108

111

112

113

114

115

116

116

117

117

118

118

83

83

84

83

84

84

170

171

172

173

161

162

224

148

176

177

149

149

150

151

189

190

191

192

193

194

195

196

216

216

217

217

218

218

223

225

226

237

237

232

233

234

235

236

237

237

237

237

237

228

229

230

231

166

167

168

169

122

122

123

124

125

126

127

128

129

130

205

164

164

165

165

165

197

198

199

200

201

202

203

204

42

86

86

86

131

132

133

134

135

138

139

143

143

142

144

145

146

147

157

158

159

GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

GLD - As per WGM notes, is covered by DC.2.3.1.1, particularly CC #3.

GLD - As per WGM notes, is covered by DC.2.3.1.1, particularly CC #3.

GLD - As per WGM notes, is covered by DC.2.3.1.1, starting with CC #1.

HL7 EHR-S FUNCTIONAL MODEL - BASIC

Name

DC.1 Care Management

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

IDCode

Stm

t. /

D

sc

rp.

/ R

qm

t.

D

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1 Care Management###

DC.1.1

DC.1.1

DC.1.1 ###

DC.1.1.1

DC.1.1.1

DC.1.1.1 ###

Record Management

S

D

Identify and Maintain a Patient Record

S

D

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.1 ###

DC.1.1.2 Manage Patient Demographics

S

DC.1.1.2

DC.1.1.2 ###

DC.1.1.2 ###

DC.1.1.2 ###

DC.1.1.2 ###

DC.1.1.2 ###

DC.1.1.2 ###

DC.1.1.2 ###

DC.1.1.2

DC.1.1.2

DC.1.1.3

DC.1.1.3 ###

DC.1.1.3

DC.1.1.3.1

D

Data and Documentation from External Sources

D

Capture Data and Documentation from External Clinical Sources

S

DC.1.1.3.1

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1 ###

DC.1.1.3.1

DC.1.1.3.1

DC.1.1.3.2

D

Capture Patient-Originated Data

S

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.2 ###

DC.1.1.3.2 ###

DC.1.1.3.2 ###

DC.1.1.3.2 ###

DC.1.1.3.2 ###

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.2

DC.1.1.3.3

DC.1.1.3.3

D

D

D

Capture Patient Health Data Derived from Administrative and Financial Data and Documentation

S

D

DC.1.1.3.3

DC.1.1.3.3 ###

DC.1.1.3.3

DC.1.1.3.3

DC.1.1.3.3

DC.1.1.3.3

DC.1.1.3.3

DC.1.1.4

DC.1.1.4

DC.1.1.4 ###

S

Produce a Summary Record of Care

S

D

DC.1.1.4 ###

DC.1.1.4 ###

DC.1.1.4 ###

DC.1.1.5

DC.1.1.5

DC.1.1.5 ###

DC.1.1.5 ###

DC.1.1.5 ###

DC.1.1.5 ###

DC.1.1.5 ###

DC.1.2

Present Ad Hoc Views of the Health Record

S

D

Manage Patient History

S

DC.1.2

DC.1.2 ###

DC.1.2 ###

DC.1.2 ###

DC.1.2 ###

DC.1.2 ###

DC.1.2 ###

DC.1.2 ###

DC.1.3 ###

DC.1.3 ###

DC.1.3.1

DC.1.3.1

D

Preferences, Directives, Consents and Authorizations

Manage Patient and Family Preferences

S

D

DC.1.3.1 ###

DC.1.3.1 ###

DC.1.3.1 ###

DC.1.3.2

DC.1.3.2

DC.1.3.2 ###

DC.1.3.2 ###

DC.1.3.2 ###

DC.1.3.2 ###

DC.1.3.2 ###

DC.1.3.2 ###

DC.1.3.2 ###

Manage Patient Advance Directives

S

D

DC.1.3.2 ###

DC.1.3.2 ###

DC.1.3.3

DC.1.3.3

DC.1.3.3 ###

DC.1.3.3

DC.1.3.3 ###

DC.1.3.3 ###

DC.1.3.3 ###

DC.1.3.3 ###

DC.1.3.3 ###

DC.1.3.3 ###

DC.1.3.3 ###

Manage Consents and Authorizations

S

D

S

DC.1.3.3 ###

DC.1.3.3

DC.1.3.3

DC.1.4 Summary Lists ###

DC.1.4 ###

DC.1.4.1

DC.1.4.1

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

Manage Allergy, Intolerance and Adverse Reaction List

S

D

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1 ###

DC.1.4.1

DC.1.4.1

DC.1.4.1

DC.1.4.2

DC.1.4.2

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2 ###

Manage Medication List

S

D

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2 ###

DC.1.4.2

DC.1.4.2

DC.1.4.3

DC.1.4.3

DC.1.4.3 ###

DC.1.4.3 ###

DC.1.4.3 ###

Manage Problem List

S

D

DC.1.4.3 ###

DC.1.4.3 ###

DC.1.4.3 ###

DC.1.4.3 ###

DC.1.4.3 ###

DC.1.4.3

DC.1.4.3

DC.1.4.4

DC.1.4.4

DC.1.4.4 ###

DC.1.4.4

DC.1.4.4

DC.1.5

DC.1.5

Manage Immunization List

S

D

Manage Assessments

S

D

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5 ###

DC.1.5

DC.1.6 ###

DC.1.6.1

DC.1.6.1

Care Plans, Treatment Plans, Guidelines, and Protocols

Present Guidelines and Protocols for Planning Care

S

D

DC.1.6.1 ###

DC.1.6.1 ###

DC.1.6.1 ###

DC.1.6.1 ###

DC.1.6.1 ###

DC.1.6.1

DC.1.6.2

DC.1.6.2

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2 ###

Manage Patient-Specific Care and Treatment Plans

S

D

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2 ###

DC.1.6.2

DC.1.6.2

DC.1.7 ###

DC.1.7.1

DC.1.7.1

Orders and Referrals Management

Manage Medication Orders

S

D

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1 ###

DC.1.7.1

DC.1.7.1

DC.1.7.1

DC.1.7.2 ###

DC.1.7.2.1

DC.1.7.2.1

DC.1.7.2.1 ###

Non-Medication Orders and Referrals Management

Manage Non-Medication Patient Care Orders

S

D

DC.1.7.2.1 ###

DC.1.7.2.1 ###

DC.1.7.2.1 ###

DC.1.7.2.1 ###

DC.1.7.2.1 ###

DC.1.7.2.1 ###

DC.1.7.2.1 ###

DC.1.7.2.2

DC.1.7.2.2

DC.1.7.2.2 ###

DC.1.7.2.2

DC.1.7.2.2 ###

DC.1.7.2.2 ###

DC.1.7.2.2 ###

DC.1.7.2.2 ###

DC.1.7.2.2

DC.1.7.2.2

Manage Orders for Diagnostic Tests

S

D

S

DC.1.7.2.3

DC.1.7.2.3

DC.1.7.2.3 ###

DC.1.7.2.3

DC.1.7.2.3

DC.1.7.2.3

DC.1.7.2.4 Manage Referrals

DC.1.7.2.4

DC.1.7.2.4 ###

DC.1.7.2.4 ###

DC.1.7.2.4 ###

DC.1.7.2.4 ###

DC.1.7.2.4 ###

Manage Orders for Blood Products and Other Biologics

S

D

S

D

DC.1.7.2.4 ###

DC.1.7.2.4 ###

DC.1.7.2.4 ###

DC.1.7.3 Manage Order Sets

DC.1.7.3

DC.1.7.3 ###

DC.1.7.3 ###

DC.1.7.3 ###

DC.1.7.3

DC.1.7.3

DC.1.8 ###

DC.1.8.1

DC.1.8.1

S

D

Documentation of Care, Measurements and Results

Manage Medication Administration

S

D

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1 ###

DC.1.8.1

DC.1.8.2

DC.1.8.2

Manage Immunization Administration

S

D

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2 ###

DC.1.8.2

DC.1.8.3 Manage Results S

DC.1.8.3

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

DC.1.8.3 ###

D

DC.1.8.3

DC.1.8.3

DC.1.8.4

DC.1.8.4

DC.1.8.4 ###

DC.1.8.4 ###

DC.1.8.4 ###

DC.1.8.4

DC.1.8.4

DC.1.8.5

DC.1.8.5

DC.1.8.5 ###

Manage Patient Clinical Measurements

S

D

Manage Clinical Documents and Notes

S

D

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###

DC.1.8.5 ###DC.1.8.5

DC.1.8.5

DC.1.8.6

DC.1.8.6

DC.1.8.6 ###

DC.1.8.6 ###

Manage Documentation of Clinician Response to Decision Support Prompts

S

D

DC.1.8.6 ###

DC.1.9

DC.1.9

DC.1.9 ###

DC.1.9 ###

DC.1.9 ###

DC.1.9 ###

DC.1.9 ###

DC.1.9 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

Generate and Record Patient-Specific Instructions

S

D

Clinical Decision Support

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2 ###

DC.2

DC.2.1 ###

DC.2.1 ###

DC.2.1 ###

DC.2.1 ###

DC.2.1

DC.2.1.1

DC.2.1.1

DC.2.1.1 ###

Manage Health Information to Provide Decision Support

Support for Standard Assessments

S

D

DC.2.1.1 ###

DC.2.1.1 ###

DC.2.1.1 ###

DC.2.1.1 ###

DC.2.1.1 ###

DC.2.1.1

DC.2.1.1

DC.2.1.2

DC.2.1.2

DC.2.1.2 ###

DC.2.1.2 ###

Support for Patient Context- Driven Assessments

S

D

DC.2.1.2 ###

DC.2.1.2 ###

DC.2.1.2 ###

DC.2.1.2

DC.2.1.2

DC.2.1.3

DC.2.1.3

DC.2.1.3 ###

DC.2.1.3 ###

DC.2.1.3 ###

DC.2.1.3 ###

DC.2.1.3 ###

Support for Identification of Potential Problems and Trends

S

D

DC.2.1.3 ###

DC.2.1.3 ###

DC.2.1.3

DC.2.1.3

DC.2.1.4

DC.2.1.4

DC.2.1.4 ###

DC.2.1.4 ###

DC.2.1.4 ###

DC.2.1.4 ###

DC.2.1.4 ###

DC.2.1.4 ###

Support for Patient and Family Preferences

S

D

DC.2.1.4 ###

DC.2.1.4 ###

DC.2.2 ###

DC.2.2 ###

DC.2.2

DC.2.2.1 ###

DC.2.2.1 ###

DC.2.2.1.1

DC.2.2.1.1

DC.2.2.1.1 ###

DC.2.2.1.1 ###

DC.2.2.1.1 ###

Care and Treatment Plans, Guidelines and Protocols

Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

Support for Standard Care Plans, Guidelines, Protocols

S

D

DC.2.2.1.1 ###

DC.2.2.1.1

DC.2.2.1.1

DC.2.2.1.2

DC.2.2.1.2

DC.2.2.1.2 ###

DC.2.2.1.2 ###

DC.2.2.1.2 ###

DC.2.2.1.2 ###

DC.2.2.1.2 ###

DC.2.2.1.2 ###

DC.2.2.1.2 ###

DC.2.2.1.2

Support for Context-Sensitive Care Plans, Guidelines, Protocols

S

D

DC.2.2.2

DC.2.2.2

DC.2.2.2 ###

DC.2.2.2 ###

DC.2.2.2 ###

DC.2.2.2 ###

DC.2.2.2

DC.2.2.2

DC.2.2.2

DC.2.2.3

DC.2.2.3

Support Consistent Healthcare Management of Patient Groups or Populations

S

D

Support for Research Protocols Relative to Individual Patient Care

S

D

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.3 ###

DC.2.2.4 Support Self-Care

DC.2.2.4

DC.2.2.4 ###

DC.2.2.4 ###

DC.2.2.4 ###

DC.2.2.4

DC.2.2.4

S

D

DC.2.2.4

DC.2.2.4

DC.2.3 ###

DC.2.3 ###

DC.2.3 ###

DC.2.3

DC.2.3.1 ###

DC.2.3.1.1

DC.2.3.1.1

DC.2.3.1.1 ###

DC.2.3.1.1 ###

DC.2.3.1.1 ###

DC.2.3.1.1 ###

DC.2.3.1.1 ###

Medication and Immunization Management

Support for Medication and Immunization Ordering

Support for Drug Interaction Checking

S

D

DC.2.3.1.1 ###

DC.2.3.1.1 ###

DC.2.3.1.1 ###

DC.2.3.1.1 ###

DC.2.3.1.1

DC.2.3.1.1

DC.2.3.1.1

DC.2.3.1.2

DC.2.3.1.2

DC.2.3.1.2 ###

DC.2.3.1.2 ###

DC.2.3.1.2 ###

DC.2.3.1.2 ###

Support for Patient Specific Dosing and Warnings

S

D

DC.2.3.1.2 ###

DC.2.3.1.2 ###

DC.2.3.1.2 ###

DC.2.3.1.2 ###

DC.2.3.1.2 ###

DC.2.3.1.2

DC.2.3.1.2

DC.2.3.1.3

DC.2.3.1.3

DC.2.3.1.3 ###

DC.2.3.1.3 ###

DC.2.3.1.3 ###

DC.2.3.1.3

DC.2.3.1.3

Support for Medication Recommendations

S

D

DC.2.3.2

DC.2.3.2

DC.2.3.2 ###

DC.2.3.2 ###

DC.2.3.2 ###

DC.2.3.2 ###

DC.2.3.2 ###

DC.2.3.2 ###

DC.2.3.2 ###

DC.2.3.2 ###

Support for Medication and Immunization Administration

S

D

DC.2.3.2

DC.2.3.2

DC.2.4 ###

DC.2.4 ###

DC.2.4 ###

DC.2.4

DC.2.4.1

DC.2.4.1

DC.2.4.1 ###

DC.2.4.1 ###

DC.2.4.1 ###

DC.2.4.1 ###

DC.2.4.1 ###

DC.2.4.1 ###

DC.2.4.1 ###

Orders, Referrals, Results and Care Management

Create Order Set Templates

S

D

DC.2.4.1

DC.2.4.1

DC.2.4.2

DC.2.4.2

DC.2.4.2 ###

DC.2.4.2

DC.2.4.2

DC.2.4.3 ###

DC.2.4.3 ###

DC.2.4.3

DC.2.4.3

DC.2.4.3

Support for Non-Medication Ordering

S

D

Support for Result Interpretation

S

D

DC.2.4.3

DC.2.4.3

DC.2.4.4 ###

DC.2.4.4.1

DC.2.4.4.1

DC.2.4.4.1 ###

DC.2.4.4.1 ###

DC.2.4.4.1 ###

DC.2.4.4.1 ###

DC.2.4.4.1

DC.2.4.4.1

DC.2.4.4.2

DC.2.4.4.2

DC.2.4.4.2 ###

DC.2.4.4.2

Support for Referrals

Support for Referral Process

S

D

Support for Referral Recommendations

S

D

DC.2.4.4.2

DC.2.4.5 ###

DC.2.4.5.1

DC.2.4.5.1

DC.2.4.5.1 ###

DC.2.4.5.1 ###

DC.2.4.5.1

DC.2.4.5.1

DC.2.4.5.1

DC.2.4.5.2

DC.2.4.5.2

DC.2.4.5.2 ###

DC.2.4.5.2 ###

Support for Care Delivery

Support for Safe Blood Administration

S

D

Support for Accurate Specimen Collection

S

D

DC.2.4.5.2 ###

DC.2.4.5.2 ###

DC.2.4.5.2 ###

DC.2.5 ###

DC.2.5 ###

DC.2.5 ###

DC.2.5 ###

DC.2.5

DC.2.5.1

DC.2.5.1

DC.2.5.1 ###

DC.2.5.1 ###

DC.2.5.1 ###

DC.2.5.1 ###

DC.2.5.2

Support for Health Maintenance: Preventive Care and Wellness

Present Alerts for Preventive Services and Wellness

S

D

DC.2.5.3

DC.2.5.2

DC.2.5.2

DC.2.5.2 ###

DC.2.5.2 ###

DC.2.5.2 ###

DC.2.5.2 ###

DC.2.5.2 ###

DC.2.5.2

DC.2.5.2

DC.2.6 ###

DC.2.6 ###

DC.2.6

Notifications and Reminders for Preventive Services and Wellness

S

D

Support for Population Health

DC.2.6.1

DC.2.6.1

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.1 ###

DC.2.6.2

Support for Epidemiological Investigations of Clinical Health Within a Population.

S

D

Support for Notification and Response

S

DC.2.6.2

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

DC.2.6.2 ###

D

DC.2.6.2 ###

DC.2.6.3

DC.2.6.3

DC.2.6.3 ###

DC.2.6.3 ###

DC.2.6.3 ###

DC.2.6.3 ###

DC.2.6.3 ###

DC.2.6.3 ###

###

DC.2.7.1

Support for Monitoring Response Notifications Regarding a Specific Patient’s Health

S

D

DC.2.7 Support for Knowledge Access

DC.2.7 S

Access Healthcare Guidance

D

DC.2.7.1 ###

DC.2.7.1 ###

DC.2.7.1 ###

DC.2.7.1 ###

DC.2.7.1

DC.2.7.1

DC.2.7.2

DC.2.7.2 ###

DC.2.7.2 ###

DC.2.7.2 ###

S

Patient Knowledge Access

D

DC.2.7.2 ###

DC.2.7.2 ###

DC.2.7.2 ###

DC.2.7.2 ###

DC.2.7.2 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

Operations Management and Communication

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 ###

DC.3 S

DC.3

DC.3.1

DC.3.1

DC.3.1.1

DC.3.1.1 ###

DC.3.1.1 ###

DC.3.1.1 ###

DC.3.1.1 ###

Clinical Workflow Tasking

D

S

Clinical Task Assignment and Routing

D

DC.3.1.1 ###

DC.3.1.1 ###

DC.3.1.1 ###

DC.3.1.1 ###

DC.3.1.1 ###

DC.3.1.1

DC.3.1.1

DC.3.1.1

DC.3.1.2

DC.3.1.2 ###

DC.3.1.2 ###

DC.3.1.2 ###

DC.3.1.2 ###

DC.3.1.3

S

Clinical Task Linking

D

Clinical Task Tracking

D

DC.3.1.3 ###

DC.3.1.3 ###

DC.3.1.3 ###

DC.3.1.3 ###

DC.3.1.3 ###

DC.3.1.3

DC.3.1.3

DC.3.1.3

DC.3.2

DC.3.2

DC.3.2

S

Support Clinical Communication

D

S

DC.3.2.1

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1 ###

DC.3.2.1

DC.3.2.2

DC.3.2.2 ###

Support for Inter-Provider Communication

D

S

Support for Provider -Pharmacy Communication

D

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2 ###

DC.3.2.2

DC.3.2.3

S

Support for Communications Between Provider and Patient and/or the Patient Representative

D

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 ###

DC.3.2.3 S

DC.3.2.3

DC.3.2.4

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

Patient, Family and Care Giver Education

D

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4 ###

DC.3.2.4

DC.3.2.4

DC.3.2.5

DC.3.2.5 ###

DC.3.2.5 ###

DC.3.2.5 ###

DC.3.2.5 ###

S.1 Clinical Support ###

S.1 ###

S.1

S.1

S

Communication with Medical Devices

D

S

S.1.1

S.1.1 ###

S.1.1

S.1.1

S.1.1

S.1.2

S.1.2 ###

S.1.2 ###

S.1.2 ###

S.1.2

S.1.2

S.1.2

S.1.3 ###

S.1.3

S.1.3.1

Registry Notification

D

S

Donor Management Support

D

S

Provider Information

S

Provider Access Levels

D

S.1.3.1 ###

S.1.3.1 ###

S.1.3.1 ###

S.1.3.1

S.1.3.1

S.1.3.1

S.1.3.2

S.1.3.2

S.1.3.2

S.1.3.2

S.1.3.3

S.1.3.3

S.1.3.3

S

Provider's Location Within Facility

D

S

Provider's On Call Location

D

S

S.1.3.3

S.1.3.4

S.1.3.4

S.1.3.4

S.1.3.4

S.1.3.5

S.1.3.5 ###

S.1.3.5

S.1.3.5

S.1.3.5

Provider's Location(s) or Office(s)

D

S

Team/Group of Providers Registry or Directory

D

S

S.1.3.6

S.1.3.6 ###

S.1.3.6

S.1.3.6

S.1.3.6

S.1.3.7

S.1.3.7 ###

S.1.3.7 ###

S.1.3.7 ###

S.1.3.7

S.1.3.7

Provider Caseload/Panel

D

Provider Registry or Directory

D

S

S.1.3.7

S.1.3.7

S.1.3.7

S.1.4 Patient Directory

S.1.4

S.1.4.1

S.1.4.1 ###

S.1.4.1 ###

S.1.4.1

S.1.4.2

S.1.4.2 ###

S.1.4.2 ###

D

S

Patient Demographics

D

S

Patient's Location Within a Facility

D

S.1.4.2 ###

S.1.4.2

S.1.4.2

S.1.4.2

S.1.4.2

S.1.4.2

S.1.4.3

S.1.4.3 ###

Patient's Residence for the Provision and Administration of Services

D

S.1.4.3

S.1.4.3

S.1.4.3

S.1.4.3

S.1.4.3

S.1.4.4

S.1.4.4

S.1.4.4

S.1.4.4

S.1.5

Patient Bed Assignment

D

S

De-Identified Data Request Management

D

S.1.5 ###

S.1.5 ###

S.1.5

S.1.6 Scheduling

S.1.6 ###

S.1.6 ###

S.1.6 ###

S.1.6

S.1.6

S

D

S

S.1.7

S.1.7 ###

S.1.7 ###

S.1.7

S.1.7

S.1.8 Information View

S.1.8 ###

S.1.8 ###

S.1.8

S.2 ###

S.2 ###

Healthcare Resource Availability

D

S

D

Measurement, Analysis, Research and Reports

S.2 ###

S.2 ###

S.2

S.2

S.2.1

S.2.1

S.2.1.1

S.2.1.1 ###

S.2.1.1 ###

S.2.1.1 ###

S.2.1.1 ###

S.2.1.1 ###

S.2.1.1 ###

S.2.1.1

S.2.1.1

S

Measurement, Monitoring, and Analysis

D

S

Outcome Measures and Analysis

D

S

S.2.1.1

S.2.1.1

S.2.1.2

S.2.1.2 ###

S.2.1.2 ###

S.2.1.2

S.2.1.2

S.2.1.2

S.2.2 Report Generation

S.2.2 ###

S.2.2 ###

S.2.2

Performance and Accountability Measures

D

S

D

S

S.2.2.1

S.2.2.1 ###

S.2.2.1 ###

S.2.2.1 ###

S.2.2.1 ###

S.2.2.1 ###

S.2.2.1 ###

S.2.2.1 ###

S.2.2.1

S.2.2.2

Health Record Output

D

S

Standard Report Generation

D

S.2.2.2 ###

S.2.2.2 ###

S.2.2.2 ###

S.2.2.2

S.2.2.2

S.2.2.2

S.2.2.2

S.2.2.2

S.2.2.3

S

Ad Hoc Query and Report Generation

D

S.2.2.3 ###

S.2.2.3 ###

S.2.2.3 ###

S.2.2.3 ###

S.2.2.3

S.2.2.3

S.2.2.3

S.2.2.3

S.3 ###

S.3 ###

S.3

Administrative and Financial

S

S.3

S.3.1

S.3.1 ###

S.3.1

S.3.1.1 Specialized Views

S.3.1.1 ###

S.3.1.1

S.3.1.1

S.3.1.1

Encounter/Episode of Care Management

D

S

D

S

S.3.1.2

S.3.1.2 ###

S.3.1.2 ###

S.3.1.2 ###

S.3.1.2

S.3.1.2

S.3.1.2

S.3.1.3

S.3.1.3 ###

S.3.1.3 ###

S.3.1.3

Encounter Specific Functionality

D

S

Automatic Generation of Administrative and Financial Data from Clinical Record

D

S

S.3.1.4

S.3.1.4 ###

S.3.1.4 ###

S.3.1.4 ###

S.3.1.5

S.3.1.5 ###

S.3.1.5 ###

Support Remote Healthcare Services

D

Other Encounter and Episode of Care Support

D

S.3.1.5

S.3.2

S.3.2

S.3.2

S.3.2.1 ###

S.3.2.1 ###

S.3.2.1 ###

S.3.2.1

S.3.2.2 ###

S.3.2.2 ###

S

Information Access for Supplemental Use

D

S

D

Rules-Driven Clinical Coding Assistance

D

Rules-Driven Financial and Administrative Coding Assistance

S.3.2.2 ###

S.3.2.2 ###

S.3.2.2 ###

S.3.2.2

S.3.2.2

S.3.2.3 ###

S.3.2.3 ###

S.3.2.3 ###

S.3.2.3

S.3.2.3

S.3.2.3

S

D

Integrate Cost/Financial Information

S

D

S.3.2.3

S.3.3 ###

S.3.3 ###

S.3.3 ###

S.3.3.1 ###

S.3.3.1

Administrative Transaction Processing

Enrollment of Patients

S

S.3.3.1

S.3.3.1

S.3.3.2 ###

S.3.3.2 ###

S.3.3.2 ###

S.3.3.2 ###

S.3.3.2 ###

S.3.3.2 ###

S.3.3.2

S.3.3.2

S.3.3.2

D

Eligibility Verification and Determination of Coverage

S

D

S.3.3.2

S.3.3.3 ###

S.3.3.3 ###

S.3.3.3

S.3.3.3

S.3.3.3

S.3.3.3

S.3.3.4 ###

S.3.3.4 ###

S.3.3.4

S.3.3.4

S.3.3.4

Service Authorizations

S

D

Support of Service Requests and Claims

S

D

S.3.3.4

S.3.3.5 ###

S.3.3.5

S.3.3.5

S.3.3.5

S.3.3.5

S.3.3.6

S.3.3.6

S.3.3.6

S.3.3.6

S.3.4 ###

Claims and Encounter Reports for Reimbursement

S

D

Health Service Reports at the Conclusion of an Episode of Care.

S

D

Manage Practitioner/Patient Relationships

S.3.4 ###

S.3.4

S.3.4

S.3.4

S.3.4

S.3.4

S.3.4

S.3.5 ###

S.3.5 ###

S.3.5.1 ###

S

D

Subject to Subject Relationship

Related by Genealogy

S.3.5.1

S.3.5.1

S.3.5.1

S.3.5.1

S.3.5.2

S.3.5.2

S.3.5.2

S.3.5.3

S.3.5.3

S.3.5.3

S.3.5.4

S.3.5.4

S.3.5.4

S.3.5.4

S.3.6 Acuity and Severity###

S

D

Related by Insurance

S

D

Related by Living Situation

S

Related by Other Means

S

D

S.3.6

S.3.6

S.3.6

S.3.6

S.3.7

S.3.7

S.3.7.1 ###

S.3.7.1 ###

S.3.7.1 ###

S.3.7.1

S

D

Supportive Function Maintenance

S

D

Clinical Decision Support System Guidelines Updates

S

S.3.7.1

S.3.7.2

S.3.7.2

S.3.7.2

S.3.7.2

S.3.7.3 ###

S.3.7.3 ###

S.3.7.3 ###

S.3.7.3 ###

S.3.7.3

S.3.7.3

S.3.7.4

D

Patient Education Material Updates

S

D

Patient Reminder Information Updates

S

D

Public Health Related Updates

S

S.3.7.4

IN.1 Security ###

IN.1 ###

IN.1

IN.1

IN.1.1 ###

IN.1.1 ###

IN.1.1 ###

IN.1.1 ###

IN.1.1

D

S

D

Entity Authentication

S

IN.1.1 ###

IN.1.2

IN.1.2 ###

IN.1.2 ###

IN.1.2 ###

IN.1.2 ###

IN.1.2 ###

IN.1.2 ###

Entity Authorization.

D

IN.1.2 ###

IN.1.2 ###

IN.1.2 ###

IN.1.2

IN.1.2

IN.1.3 ###

IN.1.3 ###

IN.1.3

IN.1.3

IN.1.4 ###

IN.1.4 ###

IN.1.4 ###

IN.1.4

S

D

Entity Access Control

S

D

Patient Access Management

IN.1.4

IN.1.5 Non-Repudiation ###

IN.1.5 ###

IN.1.5 ###

IN.1.5

IN.1.5

IN.1.6 ###

IN.1.6 ###

IN.1.6 ###

IN.1.6

IN.1.6

D

S

D

Secure Data Exchange

S

D

IN.1.7 ###

IN.1.7

IN.1.7

IN.1.8 ###

IN.1.8 ###

IN.1.8 ###

IN.1.8 ###

Secure Data Routing

S

D

Information Attestation

IN.1.8 ###

IN.1.8

IN.1.8

IN.1.9 ###

IN.1.9 ###

IN.1.9 ###

IN.1.9 ###

IN.1.9 ###

IN.1.9 ###

IN.1.9 ###

IN.1.9 ###

S

D

Patient Privacy and Confidentiality

IN.1.9

IN.1.9

IN.2

IN.2 ###

IN.2.1 ###

IN.2.1 ###

IN.2.1 ###

IN.2.1

IN.2.1 ###

IN.2.1 ###

S

D

Health Record Information and Management

S

Data Retention, Availability and Destruction

D

IN.2.1 ###

IN.2.1 ###

IN.2.1 ###

IN.2.1 ###

IN.2.1

IN.2.1

IN.2.2 Auditable Records###

IN.2.2 ###

S

D

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2 ###

IN.2.2

IN.2.2

IN.2.3 Synchronization ###

IN.2.3 ###

IN.2.3 ###

IN.2.3 ###

IN.2.3

IN.2.3

S

D

S

D

IN.2.4 ###

IN.2.4 ###

IN.2.4

IN.2.4

IN.2.4 ###

IN.2.4 ###

IN.2.4 ###

IN.2.4 ###

IN.2.4 ###

IN.2.4 ###

IN.2.4 ###

IN.2.4

IN.2.4

Extraction of Health Record Information

S

D

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5 ###

IN.2.5.1 ###

IN.2.5.1 ###

Store and Manage Health Record Information

Manage Unstructured Health Record Information

IN.2.5.1

IN.2.5.1

IN.2.5.1 ###

IN.2.5.1 ###

IN.2.5.1 ###

IN.2.5.1 ###

IN.2.5.1 ###

IN.2.5.1

IN.2.5.1

IN.2.5.2 ###

IN.2.5.2 ###

S

D

Manage Structured Health Record Information

IN.2.5.2 ###

IN.2.5.2

IN.2.5.2

IN.2.5.2 ###

IN.2.5.2 ###

IN.2.5.2 ###

IN.2.5.2 ###

IN.2.5.2 ###

IN.2.5.2 ###

IN.2.5.2

IN.2.5.2

S

D

IN.3

IN.3 ###

IN.3 ###

IN.3

IN.3

IN.3

IN.3

IN.3 ###

IN.3 ###

IN.3 ###

IN.3 ###

Registry and Directory Services

D

IN.3 ###

IN.3 ###

IN.3 ###

IN.3 ###

IN.3

IN.3

IN.4 ###

IN.4 ###

IN.4 ###

IN.4

IN.4.1 ###

S

D

Standard Terminologies and Terminology Services

S

Standard Terminologies and Terminology Models

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1 ###

IN.4.1

IN.4.1 ###

IN.4.2

IN.4.2 ###

IN.4.2 ###

IN.4.2 ###

IN.4.2 ###

IN.4.2

IN.4.2

IN.4.2

IN.4.2

S

Maintenance and Versioning of Standard Terminologies

D

IN.4.2

IN.4.2

IN.4.2

IN.4.2 ###

IN.4.3 ###

IN.4.3 ###

IN.4.3 ###

IN.4.3 ###

IN.4.3 ###

IN.4.3 ###

IN.4.3

IN.4.3

IN.5 ###

IN.5 ###

Terminology Mapping

S

D

Standards-based Interoperability

IN.5

IN.5

IN.5.1 ###

IN.5.1

IN.5.1 ###

IN.5.1 ###

IN.5.1 ###

IN.5.1 ###

IN.5.1 ###

IN.5.1 ###

IN.5.1 ###

S

D

Interchange Standards

S

IN.5.1 ###

IN.5.1 ###

IN.5.1 ###

IN.5.1

IN.5.1 ###

IN.5.2

IN.5.2 ###

IN.5.2

IN.5.2 ###

IN.5.2 ###

S

Interchange Standards Versioning and Maintenance

D

S

IN.5.2 ###

IN.5.2 ###

IN.5.2 ###

IN.5.2 ###

IN.5.2 ###

IN.5.2

IN.5.2

S

D

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3 ###

IN.5.3

IN.5.3 ###

IN.5.3 ###

IN.5.4

IN.5.4 ###

IN.5.4 ###

IN.5.4 ###

Standards-based Application Integration

S

Interchange Agreements

D

IN.5.4 ###

IN.5.4 ###

IN.5.4 ###

IN.5.4 ###

IN.5.4

IN.5.4

IN.6 ###

IN.6 ###

IN.6 ###

S

D

Business Rules Management

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6

IN.6

IN.6

IN.6

IN.6

IN.6

IN.6

IN.6

IN.6

IN.6

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.6 ###

IN.7 ###

IN.7 ###

IN.7 ###

IN.7 ###

IN.7 ###

IN.7 ###

IN.7 ###

IN.7

IN.7

IN.7

Workflow Management

IN.7

IN.7

IN.7

IN.7

IN.7

IN.7

IN.7

IN.7

HL7 EHR-S FUNCTIONAL MODEL - BASIC

Statement / Description

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

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

Integral to these care management activities is an underlying system foundation that

Statement:

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

Statement: Identify and maintain a single patient record for each patient.

Description: A single record is needed for legal purposes, as well as to organize it unambiguously for the provider. Health information is captured and linked to the patient record. Static data elements as well as data elements that will change over time are maintained. The patient is uniquely identified, after which the record is tied to that patient. Combining information on the same patient, or separating information where it was inadvertently captured for the wrong patient, helps maintain health information for a single patient. In the process of creating a patient record, it is at times advantageous to replicate identical information across multiple records, so that such data does not have to be re-entered. For example, when a parent registers children as new patients, the address, guarantor, and insurance data may be propagated in the children’s records without having to re-enter them.

Statement: Capture and maintain demographic information. Where appropriate, the data should be clinically relevant and reportable.

Description: Contact information including addresses and phone numbers, as well as key demographic information such as date of birth, time of birth, gestation, gender, and other information is stored and maintained for unique patient identification, reporting purposes and for the provision of care. Patient demographics are captured and maintained as discrete fields (e.g., patient names and addresses) and may be enumerated, numeric or codified. Key patient identifiers are shown on all patient information output (such as name and ID# on each screen of a patient’s record). The system will track who updates demographic information, and when the demographic information is updated.

Description: External sources are those outside the EHR system, including clinical, administrative, and financial information systems, other EHR systems, PHR systems, and data received through health information exchange networks.

Statement: Incorporate clinical data and documentation from external sources.

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

Statement: Capture and explicitly label patient originated data, link the data source with the data, and support provider authentication for inclusion in patient health record.

Data about the patient may be appropriately provided by:

1. the patient2. a surrogate (parent, spouse, guardian) or 3. an informant (teacher, lawyer, case worker). An electronic health record may provide the ability for direct data entry by any of these.

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

Patient-originated data may also be captured by devices and transmitted for inclusion into the electronic health record.Data entered by any of these must be stored with source information. A provider must authenticate patient-originated data included in the patient’s legal health record.

Statement: Capture and explicitly label patient health data derived from administrative or financial data; and link the data source with that data.

Description: It is critically important to be able to distinguish patient health data derived from administrative or financial data from clinically authenticated data.

Sources of administrative and financial data relating to a patient’s health may provide this data for entry into the health record or be given a mechanism for entering this data directly. The data must be explicitly labeled as derived from administrative or financial data, and information about the source must be linked with that data.

Patient health data that is derived from administrative or financial data may be provided by: 1. the patient2. a provider3. a payer, or 4. entities that transmit or process administrative or financial data. Since this data is non-clinical, it may not be authenticated for inclusion in the patient’s legal health record. Registration data, which may contain demographic data and pertinent positive and negative histories, is an example of administrative and financial data that may be captured.

Statement: Present a summarized review of a patient's comprehensive EHR, subject to jurisdictional laws and organizational policies related to privacy and confidentiality.

Description: Create summary views and reports at the conclusion of an episode of care. Create service reports at the completion of an episode of care such as, but not limited to, discharge summaries and public health reports, without additional input from clinicians.

Statement: Subject to jurisdictional laws and organizational policies related to privacy and confidentiality, present customized views and summarized information from a patient's comprehensive EHR. The view may be arranged chronologically, by problem, or other parameters, and may be filtered or sorted.

Description: A key feature of an electronic health record is its ability to support the delivery of care by enabling prior information to be found and meaningfully displayed. EHR systems should facilitate search, filtering, summarization, and presentation of available data needed for patient care. Systems should enable views to be customized, for example, specific data may be organized chronologically, by clinical category, or by consultant, depending on need. Jurisdictional laws and organizational policies that prohibit certain users from accessing certain patient information must be supported.

Statement: Capture and maintain medical, procedural/surgical, social and family history including the capture of pertinent positive and negative histories, patient-reported or externally available patient clinical history.

Description: The history of the current illness and patient historical data related to previous medical diagnoses, surgeries and other procedures performed on the patient, and relevant health conditions of family members is captured through such methods as patient reporting (for example interview, medical alert band) or electronic or non-electronic historical data. This data may take the form of a pertinent positive such as: "The patient/family member has had..." or a pertinent negative such as "The patient/family member has not had..." When first seen by a health care provider, patients typically bring with them clinical information from past encounters. This and similar information is captured and presented alongside locally captured documentation and notes wherever appropriate.

Statement: Capture and maintain patient and family preferences.

Description: Patient and family preferences regarding issues such as language, religion, spiritual practices and culture – may be important to the delivery of care. It is important to capture these so that they will be available to the provider at the point of care.

Statement: Capture and maintain patient advance directives.

Description: Patient advance directives and provider DNR orders are captured as well as the date and circumstances under which the directives were received, and the location of any paper records or legal documentation (e.g. the original) of advance directives as appropriate.

Statement: Create, maintain, and verify patient decisions such as informed consent for treatment and authorization/consent for disclosure when required.

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

There may be several documents active at any one time that may govern a patient’s care. Both clinical and administrative consents and authorizations are considered part of this function. A consent or authorization includes patient authorization for re-disclosure of sensitive information to third parties. Consents/Authorizations for printing should include appropriate standardized forms for patients, guardians, foster parents. The system must appropriately present forms for adolescents according to privacy rules.

Some states may mandate assent. Assent is agreement by the patient to participate in services when they are legally unable to consent (e.g., an adolescent, an adult with early dementia).

Statement: Create and maintain patient-specific allergy, intolerance and adverse reaction lists.

Description: Allergens, including immunizations, and substances are identified and coded (whenever possible) and the list is captured and maintained over time. All pertinent dates, including patient-reported events, are stored and the description of the patient allergy and adverse reaction is modifiable over time. The entire allergy history, including reaction, for any allergen is viewable.

The list(s) includes all reactions including those that are classifiable as a true allergy, intolerance, side effect or other adverse reaction to drug, dietary or environmental triggers. Notations indicating whether item is patient reported and/or provider verified are maintained.

Statement: Create and maintain patient-specific medication lists.

Description: Medication lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. All pertinent dates, including medication start, modification, and end dates are stored. The entire medication history for any medication, including alternative supplements and herbal medications, is viewable. Medication lists are not limited to medication orders recorded by providers, but may include, for example, pharmacy dispense/supply records, patient-reported medications and additional information such as age specific dosage.

Statement: Create and maintain patient- specific problem lists.

Description: A problem list may include, but is not limited to: Chronic conditions, diagnoses, or symptoms, functional limitations, visit or stay-specific conditions, diagnoses, or symptoms. Problem lists are managed over time, whether over the course of a visit or stay or the life of a patient, allowing documentation of historical information and tracking the changing character of problem(s) and their priority. The source (e.g. the provider, the system id, or the patient) of the updates should be documented. In addition all pertinent dates are stored. All pertinent dates are stored, including date noted or diagnosed, dates of any changes in problem specification or prioritization, and date of resolution. This might include time stamps, where useful and appropriate. The entire problem history for any problem in the list is viewable.

Statement: Create and maintain patient-specific immunization lists.

Description: Immunization lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. Details of immunizations administered are captured as discrete data elements including date, type, manufacturer and lot number. The entire immunization history is viewable.

Statement: Create and maintain assessments.

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

Statement: Present organizational guidelines for patient care as appropriate to support planning of care, including order entry and clinical documentation.

Description: Guidelines, and protocols presented for planning care may be site specific, community or industry-wide standards.

Statement: Provide administrative tools for healthcare organizations to build care plans, guidelines and protocols for use during patient care planning and care.

Description: Care plans, guidelines or protocols may contain goals or targets for the patient, specific guidance to the providers, suggested orders, and nursing interventions, among other items. Tracking of implementation or approval dates, modifications and relevancy to specific domains or context is provided. Transfer of treatment and care plans may be implemented electronically using, for example, templates, or by printing plans to paper.

Statement: Create prescriptions or other medication orders with detail adequate for correct filling and administration. Provide information regarding compliance of medication orders with formularies.

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

When a clinician places an order for a medication, that order may or may not comply with a formulary specific to the patient’s location or insurance coverage, if applicable. Whether the order complies with the formulary should be communicated to the ordering clinician at an appropriate point to allow the ordering clinician to decide whether to continue with the order. Formulary-compliant alternatives to the medication being ordered may also be presented.

Statement: Capture and track patient care orders. Enable the origination, documentation, and tracking of non-medication patient care orders.

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

Each item ordered includes the appropriate detail, such as order identification and instructions. Orders should be communicated to the correct service provider for completion.

Statement: Enable the origination, documentation, and tracking of orders for diagnostic tests.

Description: Orders for diagnostic tests (e.g. diagnostic radiology, blood test) are captured and tracked including new, renewal and discontinue orders. Each order includes appropriate detail, such as order identification, instructions and clinical information necessary to perform the test. Orders and supporting detailed documentation shall be communicated to the service provider for completion of the diagnostic test(s).

Some systems may contain instructions, but in some settings, instructions may be provided from external sources (e.g., handouts).

Statement: Communicate with appropriate sources or registries to manage orders for blood products or other biologics.

Description: Interact with a blood bank system or other source to support orders for blood products or other biologics including discontinuance orders. Use of such products in the provision of care is captured. Blood bank or other functionality that may come under jurisdictional law or other regulation (e.g. by the FDA in the United States) is not required; functional communication with such a system is required.

Statement: Enable the origination, documentation and tracking of referrals between care providers or healthcare organizations, including clinical and administrative details of the referral, and consents and authorizations for disclosures as required.

Description: Documentation and tracking of a referral from one care provider to another is supported, whether the referred to or referring providers are internal or external to the healthcare organization. Guidelines for whether a particular referral for a particular patient is appropriate in a clinical context and with regard to administrative factors such as insurance may be provided to the care provider at the time the referral is created.

Statement: Provide order sets based on provider input or system prompt.

Description: Order sets, which may include medication and non-medication orders, allow a care provider to choose common orders for a particular circumstance or disease state according to standards or other criteria. Recommended order sets may be presented based on patient data or other contexts.

Statement: Present providers with the list of medications that are to be administered to a patient, necessary administration information, and capture administration details.

Description: In a setting in which medication orders are to be administered by a provider rather than the patient, the necessary information is presented including: the list of medication orders that are to be administered; administration instructions, times or other conditions of administration; dose and route, etc. The system shall securely relate medications to be administered to the unique identity of the patient (see DC.1.1.1). Additionally, the provider can record what actually was or was not administered, whether or not these facts conform to the order. Appropriate time stamps for all medication related activity are generated.

For some settings that administer complete sets of medications from a variety of providers’ orders, it may be useful to provide an additional check for possible drug-drug or other interactions.

Statement: Capture and maintain discrete data concerning immunizations given to a patient including date administered, type, manufacturer, lot number, and any allergic or adverse reactions. Facilitate the interaction with an immunization registry to allow maintenance of a patient’s immunization history.

Description: During an encounter, recommendations based on accepted immunization schedules are presented to the provider. Allergen and adverse reaction histories are checked prior to giving the immunization. If an immunization is administered, discrete data elements associated with the immunization including date, type, manufacturer and lot number are recorded. Any new adverse or allergic reactions are noted. If required, a report is made to the public health immunization registry.

Statement: Present, annotate, and route current and historical test results to appropriate providers or patients for review. Provide the ability to filter and compare results.

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

Statement: Capture and manage patient clinical measures, such as vital signs, as discrete patient data.

Description: Patient measures such as vital signs are captured and managed as discrete data to facilitate reporting and provision of care. Other clinical measures (such as expiratory flow rate, size of lesion, etc.) are captured and managed, and may be discrete data.

Statement: Create, addend, correct, authenticate and close, as needed, transcribed or directly-entered clinical documentation and notes.

Description: Clinical documents and notes may be unstructured and created in a narrative form, which may be based on a template, graphical, audio, etc.. The documents may also be structured documents that result in the capture of coded data. Each of these forms of clinical documentation is important and appropriate for different users and situations.

Statement: Capture the decision support prompts and manage decisions to accept or override decision support prompts.

Description: Clinician actions in response to decision support prompts are captured and can be managed at the patient level or aggregated for organizational trending.

Statement: Generate and record patient-specific instructions related to pre- and post-procedural and post- discharge requirements.

Description: When a patient is scheduled for a test, procedure, or discharge, specific instructions about diet, clothing, transportation assistance, convalescence, follow-up with physician, etc., may be generated and recorded, including the timing relative to the scheduled event.

Statement: Offer prompts to support the adherence to care plans, guidelines, and protocols at the point of information capture.

Description: When a clinician fills out an assessment, data entered triggers the system to prompt the assessor to consider issues that would help assure a complete/accurate assessment. A simple demographic value or presenting problem (or combination) could provide a template for data gathering that represents best practice in this situation, e.g. Type II diabetic review, fall and 70+, rectal bleeding, etc.

Statement: Offer prompts based on patient-specific data at the point of information capture for assessment purposes.

Description: When a clinician fills out an assessment, data entered is matched against data already in the system to identify potential linkages. For example, the system could scan the medication list and the knowledge base to see if any of the symptoms are side effects of medication already prescribed. Important diagnoses could be brought to the doctor’s attention, for instance ectopic pregnancy in a woman of child bearing age who has abdominal pain.

Statement: Identify trends that may lead to significant problems, and provide prompts for consideration.

Description: When personal health information is collected directly during a patient visit, input by the patient, or acquired from an external source (lab results), it is important to be able to identify potential problems and trends that may be patient-specific, given the individual's personal health profile, or changes warranting further assessment. For example: significant trends (lab results, weight); a decrease in creatinine clearance for a patient on metformin, an abnormal increase in INR for a patient on warfarin, an increase in suicidal ideation; presence of methamphetamines; or absence of therapeutic levels of antidepressants.

Statement: Support the integration of patient and family preferences into clinical decision support.

Description: Decision support functions should permit consideration of patient/family preferences and concerns, such as with language, religion, culture, medication choice, invasive testing, and advance directives. Such preferences should be captured in a manner that allows for their integration with the health record and easy retrieval from the health record. Preferences may be specified across all treatment plans or specifically to a treatment plan.

Statement: Support the use of appropriate standard care plans, guidelines and/or protocols for the management of specific conditions.

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

Statement: Identify and present the appropriate care plans, guidelines and/or protocols for the management of patient specific conditions that are identified in a patient clinical encounter.

Description: At the time of the clinical encounter (problem identification), recommendations for tests, treatments, medications, immunizations, referrals and evaluations are presented based on evaluation of patient specific data such as age, gender, developmental stage, their health profile, and any site-specific considerations. These may be modified on the basis of new clinical data at subsequent encounters.

Statement: Provide the ability to identify and consistently manage healthcare, over time and across populations or groups of patients, that share diagnoses, problems, functional limitations, treatment, medications, and demographic characteristics that may impact care, e.g. population management, disease management, wellness management or care management.

Description:

Populations or groups of patients that share diagnoses (such as diabetes or hypertension), problems, functional limitations, treatment, medication, and demographic characteristics such as race, ethnicity, religion, socio-economic status that may impact care are identified for the clinician. The clinician is advised and assisted with management of these patients to optimize the clinician’s ability to provide appropriate care. For example, a clinician is alerted to racial, cultural, religious, socio-economic, living situation and functional accommodations of the patient that are required to provide appropriate care. A further example-- the clinician may be notified of eligibility for a particular test, therapy, or follow-up; availability of supportive resources in the community; or results from audits of compliance of these populations with disease management protocols.

Statement: Provide support for the management of patients enrolled in research protocols.

Description: The clinician is presented with appropriate protocols for patients participating in research studies, and is supported in the management and tracking of study participants.

Statement: Provide the patient with decision support for self-management of a condition between patient-provider encounters.

Description: Patients with specific conditions need to follow self-management plans that may include schedules for home monitoring, lab tests, and clinical check ups; recommendations about nutrition, physical activity, tobacco use, etcetera; and guidance or reminders about medications.

Information to support self-care may be appropriately provided to: 1. the patient2. a surrogate (parent, spouse, guardian), or 3. others involved directly in the patients self care

Statement: Identify drug interaction warnings time of medication ordering.

Description: The clinician is alerted to drug-drug, drug-allergy, and drug-food interactions at levels appropriate to the health care setting and with respect to the patient condition. These alerts may be customized to suit the user or group.

If the patient’s condition is one where, in order to view the necessary components of the health record, patient authorization or consent is required, then the system should show the medication but mask the condition for which the medication is prescribed until the required consent or authorization is available. In an emergent situation, where all health information is required to provide the most effective treatment, and it is not possible to obtain an authorization or consent, the system should provide an override function to allow access to the diagnosis or problem for which a medication was ordered. This may vary based on jurisdictional law.

Statement: Identify and present appropriate dose recommendations based on known patient- conditions and characteristics at the time of medication ordering.

Description: The clinician is alerted to drug-condition interactions and patient specific contraindications and warnings e.g. pregnancy, breast-feeding or occupational risks, hepatic or renal insufficiency. The preferences of the patient may also be presented e.g. reluctance to use an antibiotic. Additional patient parameters, such as age, gestation, Ht, Wt, BSA, shall also be incorporated.

Statement: The system should provide recommendations and options in medication and monitoring on the basis of patient diagnosis, cost, local formularies or therapeutic guidelines and protocols.

Description: Offer alternative medications on the basis of practice standards (e.g. cost or adherence to guidelines), a generic brand, a different dosage, a different drug, or no drug (watchful waiting). Suggest lab order monitoring as indicated by the medication or the medical condition to be affected by the medication. Support expedited entry of series of medications that are part of a treatment regimen, i.e. renal dialysis, Oncology, transplant medications, etc.

Statement: Alert providers to potential administration errors (such as wrong patient, wrong drug, wrong dose, wrong route and wrong time) in support of safe and accurate medication administration and support medication administration workflow.

Description: To reduce medication errors at the time of administration of a medication, the patient is positively identified; checks on the drug, the dose, the route and the time are facilitated. Documentation is a by-product of this checking; administration details and additional patient information, such as injection site, vital signs, and pain assessments, are captured.

Access to drug monograph information may be provided to allow providers to check details about a drug and enhance patient education. Workflow for medication administration is supported through prompts and reminders regarding the “window” for timely administration of medications.

Statement: Create, capture, maintain and display order set templates based on patient data or preferred standards or other criteria.

Description: Order set templates, which may include medication orders, allow a care provider to choose common orders for a particular circumstance or disease state according to standards or other criteria. Recommended order sets may be presented based on patient data or other contexts.

Statement: Display and request provider validation of information necessary for non-medication orders that make the order pertinent, relevant and resource-conservative at the time of provider order entry.

Description: Possible order entry support includes, but is not limited to: notification of missing results required for the order, suggested corollary orders, notification of duplicate orders, institution-specific order guidelines, guideline-based orders/order sets, order sets, order reference text, patient diagnosis specific recommendations pertaining to the order. Also, warnings for orders that may be inappropriate or contraindicated for specific patients (e.g. X-rays for pregnant women) are presented.

Non-medication orders include orders such as:●    supplies such as 4x4’s and ACE bandages●    non-medical devices such as TTY phones for the hearing impaired●    groups of supplies or kits common to an organization●    simple durable medical equipment (DME) such as crutches or walkers●    complex DME such as wheelchairs and hospital beds●    therapies and other services that may require a referral and/or an authorization for insurance coverage

Statement: Evaluate results and notify provider of results within the context of the patient’s healthcare data.

Description: Possible result interpretations include, but are not limited to: abnormal result evaluation/notification, trending of results (such as discrete lab values), evaluation of pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam), evaluation of incoming results against active medication orders.

Statement: Evaluate referrals within the context of a patient’s healthcare data.

Description: When a healthcare referral is made, health information, including pertinent clinical and behavioral health results, demographic and insurance data elements (or lack thereof) are presented to the provider. Standardized or evidence based protocols for appropriate workup prior to referral may be presented.

Statement: Evaluate patient data and recommend that a patient be referred based on the specific patient's healthcare data.

Description: Entry of specific patient conditions may lead to recommendations for referral e.g. for smoking cessation counseling if the patient is prescribed a medication to support cessation screening or assessment for behavioral health conditions.

Statement: Provide checking in real-time for potential blood administration errors.

Description: To reduce errors at the time of blood product administration, the patient is positively identified. Additionally, checks on blood product identification, amount to be delivered, route and time of administration are captured, and alerts are provided as appropriate.

Statement: Provide checking to ensure accurate specimen collection is supported.

Description: To ensure the accuracy of specimen collection, the patient and specimen are positively identified. The provider is notified in real-time of potential collection errors such as wrong patient, wrong specimen type, wrong means of collection, wrong site, and wrong date and time.

The provider may wish to provide reminders to the patient based on the alert.

Statement: At the point of clinical decision making, identify patient specific suggestions/reminders, screening tests/exams, and other preventive services in support of routine preventive and wellness patient care standards.

Description: At the time of an encounter, the provider or patient is presented with due or overdue activities based on protocols for preventive care and wellness. Examples include but are not limited to, routine immunizations, adult and well child care, age and gender appropriate screening exams, such as PAP smears.

Statement: Between healthcare encounters, notify the patient and/or appropriate provider of those preventive services, tests, or behavioral actions that are due or overdue.

Description: The provider can generate notifications to patients regarding activities that are due or overdue and these communications can be captured. Examples include but are not limited to time sensitive patient and provider notification of: follow-up appointments, laboratory tests, immunizations or examinations. The notifications can be customized in terms of timing, repetitions and administration reports. E.g. a PAP test reminder might be sent to the patient two months prior to the test being due, repeated at three month intervals, and then reported to the administrator or clinician when nine months overdue.

Statement: Support internal and external epidemiological investigations of clinical health of aggregate patient data for use in identifying health risks from the environment and/or population in accordance with jurisdictional law.

Description: Standardized surveillance performance measures that are based on known patterns of disease presentation can be identified by aggregating data from multiple input mechanisms. For example, elements include, but are not limited to patient demographics, resource utilization, presenting symptoms, acute treatment regimens, laboratory and imaging study orders and results and genomic and proteomic data elements. Identification of known patterns of existing diseases involves aggregation and analysis of these data elements by existing relationships. However, the identification of new patterns of disease requires more sophisticated pattern recognition analysis. Early recognition of new patterns requires data points available early in the disease presentation. Demographics, ordering patterns and resource use (e.g., ventilator or intensive care utilization pattern changes) are often available earlier in the presentation of non-predictable diseases. Consumer-generated information is also valuable with respect to surveillance efforts.

Statement: Upon notification by an external, authoritative source of a health risk within the cared for population, alert relevant providers regarding specific potentially at-risk patients with the appropriate level of notification.

A care provider now has the ability to decide how patients are notified, if necessary.

Description: After receiving a notice of a health risk within a cared-for population from public health authorities or other external authoritative sources:

1.       Identify and notify individual care providers or care managers that a risk has been identified and requires attention; and

2.       Provide suggestions on the appropriate course of action.

For example, this function may be used after detection of a local outbreak of hepatitis A, advising providers of the at-risk population and potential prophylactic treatment.

A second example might be the dissemination of new care guidelines for elderly patients with a specific chronic disease.Notifications to clinicians or patients may occur by telephone, email, FAX or other methods.

Statement: In the event of a health risk alert and subsequent notification related to a specific patient, monitor if expected actions have been taken, and execute follow-up notification if they have not.

Description: Identifies that expected follow-up for a specific patient event (e.g., follow up to error alerts or absence of an expected lab result) has not occurred and communicate the omission to appropriate care providers in the chain of authority. The notification process requires a security infrastructure that provides the ability to match a care provider’s clinical privileges with the clinical requirements of the notification.

Statement: Provide pertinent information from available evidence-based knowledge, at the point of care, for use in healthcare decisions and care planning.

Description: The information available regarding disease, disease processes, diagnostic testing, pharmaceuticals, treatment patterns and all aspects of healthcare is constantly changing. The practitioner should be able to access a wide variety of sources that provide relevant, accurate information about any given subject. Examples of resources include, but are not limited to: evidence on treatment of specific medical conditions, maintenance of wellness, drug or device trials, context-specific information available through online journals, printed resources such as books and specialty organizations resources. For example, when a condition is diagnosed the provider might be directed to relevant resources that give updated clinical research, useful pharmaceutical combinations, surgical techniques, products or other information useful in the management of the specific condition under consideration.

Statement: Provide the ability to access reliable information about wellness, disease management, treatments, peer support groups and related information that is relevant for a specific patient.

Description: An individual will be able to find reliable information to research a health question, follow up from a clinical visit, identify treatment options, or other health information needs. The information may be linked directly from entries in the health record, or may be accessed through other means such as key word search. The information may be provided as part of the EHR system but may also include patient information from external databases or specific websites.

Statement: Schedule and manage tasks with appropriate timeliness.

Description: Since the electronic health record will replace the paper chart, tasks that were based on the paper artifact must be effectively managed in the electronic environment. Functions must exist in the EHR-S that support electronically any workflow that previously depended on the existence of a physical artifact (such as the paper chart, a phone message slip) in a paper based system. Tasks differ from other more generic communication among participants in the care process because they are a call to action and target completion of a specific workflow in the context of a patient's health record (including a specific component of the record). Tasks also require disposition (final resolution). The initiator may optionally require a response. For example, in a paper based system, physically placing charts in piles for review creates a physical queue of tasks related to those charts. This queue of tasks (for example, a set of patient phone calls to be returned) must be supported electronically so that the list (of patients to be called) is visible to the appropriate user or role for disposition. Tasks are time-limited (or finite). The state transition (e.g. created, performed and resolved) may be managed by the user explicitly or automatically based on rules. For example, if a user has a task to signoff on a test result, that task should automatically be marked complete by the EHR when the test result linked to the task is signed in the system. Patients Statement: Assignment, delegation and/or transmission of tasks to the appropriate parties.

Description: Tasks are at all times assigned to at least one user or role for disposition. Whether the task is assignable and to whom the task can be assigned will be determined by the specific needs of practitioners in a care setting. Task-assignment lists help users prioritize and complete assigned tasks. For example, after receiving communication (e.g. a phone call or e-mail) from a patient, the triage nurse routes or assigns a task to return the patient's call to the physician who is on call. Task creation and assignment may be automated, where appropriate. An example of a system-triggered task is when lab results are received electronically; a task to review the result is automatically generated and assigned to a clinician. Task assignment ensures that all tasks are disposed of by the appropriate person or role and allows efficient interaction of entities in the care process.

Statement: Linkage of tasks to patients and/or a relevant part of the electronic health record.

Description: Clinical tasks must include information or provide an electronic link to information that is required to complete the task. For example, this may include a patient location in a facility, a patient’s contact information, or a link to new lab results in the patient’s EHR.

An example of a well defined task is "Dr. Jones must review Mr. Smith's blood work results." Efficient workflow is facilitated by navigating to the appropriate area of the record to ensure that the appropriate test result for the correct patient is reviewed. Other examples of tasks might involve fulfillment of orders or responding to patient phone calls.

Statement: Track tasks to facilitate monitoring for timely and appropriate completion of each task.

Description: In order to reduce the risk of errors during the care process due to missed tasks, the provider is able to view and track un-disposed tasks, current work lists, the status of each task, unassigned tasks or other tasks where a risk of omission exists. The timeliness of certain tasks can be tracked, or reports generated, in accordance with relevant law and accreditation standards. For example, a provider is able to create a report to show test results that have not been reviewed by the ordering provider based on an interval appropriate to the care setting.

Statement:

Description: Healthcare requires secure communications among various participants: patients, doctors, nurses, chronic disease care managers, pharmacies, laboratories, payers, consultants, and etcetera. An effective EHRS supports communication across all relevant participants, reduces the overhead and costs of healthcare-related communications, and provides automatic tracking and reporting. The list of communication participants is determined by the care setting and may change over time. Because of concerns about scalability of the specification over time, communication participants for all care settings or across care settings are not enumerated here because it would limit the possibilities available to each care setting and implementation. However, communication between providers and between patients and providers will be supported in all appropriate care settings and across care settings. Implementation of the EHRS enables new and more effective channels of communication, significantly improving efficiency and patient care. The communication functions of the EHRS will eventually change the way participants collaborate and distribute the work of patient care.

Statement: Support exchange of information between providers as part of the patient care process, and the appropriate documentation of such exchanges. Support secure communication to protect the privacy of information as required by federal or jurisdictional law.

Description: Communication among providers involved in the care process can range from real time communication (for example, fulfillment of an injection while the patient is in the exam room), to asynchronous communication (for example, consult reports between physicians). Some forms of inter-practitioner communication will be paper based and the EHR-S must be able to produce appropriate documents.

The system should provide for both verbal and written communication. These exchanges would include but not limited to consults, and referrals as well as possible exchanges within the office as part of the provision and administration of patient care (for example, the communication of new information obtained within the office environment during the process of administration of a tetanus shot while the patient is in the exam room).

The system should support the creation and acceptance of paper artifacts where appropriate.

Statement: Provide features to enable secure bi-directional communication of information electronically between practitioners and pharmacies or between practitioner and intended recipient of pharmacy orders.

Description: When a medication is prescribed, the order is routed to the pharmacy or other intended recipient of pharmacy orders. This information is used to avoid transcription errors and facilitate detection of potential adverse reactions. If there is a question from the pharmacy, that communication can be presented to the provider with their other tasks.

The transmission of prescription data between systems should conform to realm acceptable messaging standards. As an example, specific standards in the United States include the most recent versions of criteria from Health Level 7 (HL7), X12N, and/or the National Council for Prescription Drug Programs (NCPDP); and those of the National Electronic Claims Standard (NeCST) in Canada. It is anticipated that other realms may list other acceptable messaging standards.

Statement: Facilitate communications between providers and patients and/or the patient representatives.

Description: Providers are able to communicate with patients and others, capturing the nature and content of electronic communication, or the time and details of other communication. Examples: ·   When test results arrive, the clinician may wish to email the patient that test result was normal (details of this communication are captured).·   A patient may wish to request a refill of medication by emailing the physician.·   Patients with asthma may wish to communicate their peak flow logs/diaries to their provider.·   Hospital may wish to communicate with selected patients about a new smoking cessation program.

Statement: Facilitate access to educational or support resources pertinent to, and usable by, the patient or patient representative.

Description: The provider or patient is presented with a library of educational materials. Material may be made available in the language or dialect understood by the patient or representative. Material should be at the level of the patient or representative’s level of understanding and sensory capability. Special needs are documented. Material may be disseminated via a mode available to and acceptable by the patient e.g., printed, electronically or otherwise. The review of material between the clinician and the patient, and the patient’s understanding of the review, is documented when desired by the clinician. The patient or patient’s representatives are able to obtain educational information independently without formal review with the clinician if desired.

Statement: Support communication and presentation of data captured from medical devices.

Description: Communication with medical devices is supported as appropriate to the care setting such as an office or a patient’s home. Examples include: vital signs/pulse-oximeter, anesthesia machines, home diagnostic devices for chronic disease management, laboratory machines, bar coded artifacts (medicine, immunizations, demographics, history, and identification), etc.

Statement: Enable the automated transfer of formatted demographic and clinical information to and from local disease specific registries (and other notifiable registries) for patient monitoring and subsequent epidemiological analysis.

Description: The user can export personal health information to disease specific registries, other notifiable registries such as immunization registries, through standard data transfer protocols or messages. The user can update and configure communication for new registries.

Statement: Provide capability to capture or receive, and share needed information on potential donors and recipients.

Description: The user is able to capture or receive information on potential donors and recipients (for products such as blood, organs, eggs, sperm, or stem cells). The user can make this information available to internal and external donor matching agencies.

Statement: Maintain, or provide access to, current provider information.

Statement: Provide a current registry or directory of practitioners that contains data needed to determine levels of access required by the system.

Description: Provider information may include any credentials, certifications, or any other information that may be used to verify that a practitioner is permitted to use or access authorized data.

Statement: Provide provider location or contact information on a facility's premises.

Description: The identification of provider’s location within a facility may facilitate the handling of critical care situations. This may include the location of on site practitioners by name or immediate required specialty. A real-time tracking system may provide automatic update of such information.

Statement: Provide provider location or contact information when on call.

Description: The provider immediate contact information. This may include on call practitioners on a facility’s premises as well as on call contact information after scheduled working hours.

Statement: Provide locations or contact information for the provider in order to direct patients or queries.

Description: Providers may have multiple locations or offices where they practice. The system should maintain information on the primary location, any secondary locations, as well as the scheduled hours at each location. Information maintained may include web sites, maps, office locations, etc.

Statement: Provide access to a current directory, registry or repository of information on Teams or Groups of providers in accordance with relevant laws, regulations, and organization or internal requirements.

Description: An organization may assign caregivers to teams that need to be registered as such. In another scenario, an organization might contract with a group of providers. The group would be listed by the group name or individually or both. A caregiver might be part of more than 1 team or group. All of these factors need to be supported. Information includes, but is not limited to; full name, address or physical location, and a 24x7 telecommunications address (e.g. phone or pager access number).

Statement: Provide access to a provider's caseload or panel information.

Description: An organization might employ the concept of caseload or panel of patients to facilitate continuity of care and distribution of work.

A caregiver may have, or be accountable for, zero to multiple defined caseloads or panels of members/patient/clients within the organization.

Information about the caseload or panel includes such things as whether or not a new member/patient/client can be added.

A member/patient may be provided access to a listing of caregivers with open caseloads or panels to select a provider.

Statement: Provide access to a current directory, registry or repository of provider information in accordance with relevant laws, regulations, and organization or internal requirements.

Description: A system maintains or has access to provider information needed in the provision of care. This is typically a directory, registry or repository. Information includes, but is not limited to; full name, specialty, credentials, address or physical location, and a 24x7 telecommunications address (e.g. phone or pager access number).

Views of the information are tailored to the user's security level and access need. For example, a nursing supervisor may need access to a provider's home phone. A member/patient wishing to select a primary care provider has a narrower view that would not include personal access information.

Statement: Provide a current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions.

Description: The patient directory may capture information including but not limited to, full name, address or physical location, alternate contact person, primary phone number, and relevant health status information. The view of this information may vary based on purpose. Several specific directory views are described in the following functions.

Statement: Support interactions with other systems, applications, and modules to enable the maintenance of updated demographic information in accordance with realm-specific recordkeeping requirements.

Description: The minimum demographic data set must include the data required by realm-specific laws governing health care transactions and reporting. For example, this may include data input of death status information, or may include support to identify multiple names, such as updating from Baby Girl Doe, to neonate's given name.

Statement: Provide the patient's location information within a facility's premises.

Description: This function is intended to support maintaining and/or providing access to information on the patient's location during an episode of care. This function can be as simple as displaying the assigned bed for a patient (i.e. Adam W2-Reb 214). It can also be a function that supports real-time information on the patient location as they receive ancillary services in other parts of a facility (physical therapy or diagnostic imaging).

Note: For standard reports like an ER Log or Census, see the Standard reports S.2.2. - The system should support viewing a patient’s specific location in terms that may include campus, building, wing, unit, room, bed. - The system should support jurisdictional laws related to patient consent on disclosure.- The patient location information should also be available when the provider is not in the patient record. As such, the systems may need to provide a query feature on patient location information.- The system may support the identification of the patient by alternate identifying names.

Statement: Provide the patient's residence information for the provision and administration of services to the patient, patient transport, and as required for public health reporting.

Description: This function is intended to support the provision of services to patients at their place of residence. Examples include but are not limited to the following:

- Visiting nurse may be providing care to a new mother and baby at their place of residence.- A patient with a mobility problem may require transport to and from a clinic appointment.- Support identification of multiple residences for a patient like a child with multiple guardians (divorced parents with joint custody) or adults with Winter/Summer residences.

Statement: Support interactions with other systems, applications, and modules to ensure that the patient's bed assignments within the facility optimize care and minimize risks e.g. of exposure to contagious patients.

Description: Access to a list of available beds is important to safely manage the care of patients whose bed requirements may change based on change in condition or risk factors. For example, a patient may need a room with special equipment or to be close to the nursing station or to be in a private room.

Statement: Provide patient data in a manner that meets local requirements for de-identification.

Description: When an internal or external party requests patient data and that party requests de-identified data (or is not entitled to identified patient information, either by law or custom), the user can export the data in a fashion that meets requirements for de-identification in that locale or realm.

An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review.

A random re-identification key may be added to the data, to support re-identification for the purpose of alerting providers of potential patient safety issues. For example, if it is discovered that a patient is a risk for a major cardiac event, the provider could be notified of this risk, allowing the provider to identify the patient from the random key.

Statement: Support interactions with other systems, applications, and modules to provide the necessary data to a scheduling system for optimal efficiency in the scheduling of patient care, for either the patient or a resource/device.

Description: The system may support user access to scheduling systems as required. Relevant clinical or demographic information required in the scheduling process could be linked to the task.

Statement: Support the collection and distribution of local healthcare resource information, through interactions with other systems, applications, and modules, to enable planning and response to extraordinary events such as local or national emergencies.

Description: In times of identified local or national emergencies and upon request from authorized bodies, provide current status of healthcare resources including, but not limited to, available beds, providers, support personnel, ancillary care areas and devices, operating theaters, medical supplies, vaccines, and pharmaceuticals. The intent is to enable the authorized body to distribute or re-distribute either resources or patient load to maximize efficient healthcare delivery. In addition, these functions may also be used for internal assessment and planning purposes by facility administrators.

Statement: Support user-defined information views.

Description: Views of the information can be tailored for or by the user (or department or "job classification”) for their presentation preferences, within local or facility established rules. For example, a nursing supervisor may elect or prefer to see summary data on all patients as the default view.

Description:

Statement: Support measurement and monitoring of care for relevant purposes.

Statement: Support the capture and subsequent export or retrieval of data necessary for the reporting on patient outcome of care by population, facility, provider or community.

Description: Many regions require regular reporting on the healthcare provided to individuals and populations. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software. The system may also provide the functionality to prompt for the collection of necessary information at the appropriate time in a patient encounter if such collection need can be properly defined in a supportive workflow.

e.g. Requesting specific information for reporting of emergency services such as gun shot, suspected abuse, communicable diseases etc, or for the collection of additional research data for specific a specific diagnosis.

Statement: Support the capture and subsequent export or retrieval of data necessary to provide quality, performance, and accountability measurements which providers, facilities, delivery systems, and communities are held accountable.

Description: Many regions require regular reporting on the healthcare provided to individuals and populations. These reports may include measures related to process, outcomes, costs of care, may be used in 'pay for performance' monitoring and adherence to best practice guidelines. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software.

Statement: Support the export of data or access to data necessary for report generation and ad hoc analysis.

Description: Providers and administrators need access to data in the EHR-S for the generation of both standard and ad hoc reports. These reports may be needed for clinical, administrative, and financial decision-making, as well as for patient use. Reports may be based on structured data and/or unstructured text from the patient's health record.

Statement: Support the definition of the formal health record, a partial record for referral purposes, or sets of records for other necessary disclosure purposes.

Description: Provide hardcopy and electronic output that fully chronicles the healthcare process, supports selection of specific sections of the health record, and allows healthcare organizations to define the report and/or documents that will comprise the formal health record for disclosure purposes. A mechanism should be provided for both chronological and specified record element output. This may include defined reporting groups (i.e. print sets). For example: Print Set A = Patient Demographics, History & Physical, Consultation Reports, and Discharge Summaries. Print Set B = all information created by one caregiver. Print Set C = all information from a specified encounter. An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review. The system has the capability of providing a report or accounting of disclosures by patient that meets in accordance with scope of practice, organizational policy and jurisdictional law.

Statement: Provide report generation features using tools internal or external to the system, for the generation of standard reports.

Description: Providers and administrators need access to data in the EHR-S for clinical, administrative, financial decision-making, audit trail and metadata reporting, as well as to create reports for patients. Many systems may use internal or external reporting tools to accomplish this (such as Crystal Report).

Reports may be based on structured data and/or unstructured text from the patient's health record.Users need to be able to sort and/or filter reports. For example, the user may wish to view only the diabetic patients on a report listing patients and diagnoses.

Statement: Provide support for ad hoc query and report generation using tools internal or external to the system.

Description: Providers and administrators need to respond quickly to new requirements for data measurement and analysis. This may be as a result of new regulatory requirements or internal requirements. This requires that users be able to define their own query parameters and retain them. The data may be found in both structured and unstructured data.

Providers and administrators also need to query for the absence of specific clinical or administrative data. For example, the Quality Control department may be reviewing whether or not the protocol for management of Diabetes Mellitus is being followed. If the protocol calls for fasting blood sugars every 3 months at minimum, the investigator might need to run an across-patient query locating patients with diabetes who do not show an FBS result within the last 3 months.

Statement: Support the definition of Manage and document the health care needed and delivered during an encounter/episode of care.

Description: Using data standards and technologies that support interoperability, encounter management promotes patient-centered/oriented care and enables real time, immediate point of service, point of care by facilitating efficient work flow and operations performance to ensure the integrity of: (1) the health record, (2) public health, financial and administrative reporting, and (3) the healthcare delivery process

This support is necessary for direct care functionality that relies on providing user interaction and workflows, which are configured according to clinical protocols and business rules based on encounter specific values such as care setting, encounter type (inpatient, outpatient, home health, etc.), provider type, patient's EHR, health status, demographics, and the initial purpose of the encounter.

Statement: Present specialized views based on the encounter-specific values, clinical protocols and business rules.

Description: The system user is presented with a presentation view and system interaction appropriate to the context with capture of encounter-specific values, clinical protocols and business rules. This "user view" may be configurable by the user or system technicians. As an example, a mobile home health care worker using wireless laptop at the patient's home would be presented with a home health care specific workflow synchronized to the current patient's care plan and tailored to support the interventions appropriate for this patient, including chronic disease management protocols.

Statement: Provide assistance in assembling appropriate data, supporting data collection and processing output from a specific encounter.

Description: Workflows, based on the encounter management settings, will assist (with triggers alerts and other means) in determining and supporting the appropriate data collection, import, export, extraction, linkages and transformation. As an example, a pediatrician is presented with diagnostic and procedure codes specific to pediatrics. Business rules enable automatic collection of necessary data from the patient's health record and patient registry. As the provider enters data, workflow processes are triggered to populate appropriate transactions and documents. For example, data entry might populate an eligibility verification transaction or query the immunization registry.

Statement: Provide patients clinical data to support administrative and financial reporting.

Description: A user can generate a bill based on health record data. Maximizing the extent to which administrative and financial data can be derived or developed from clinical data will lessen provider reporting burdens and the time it takes to complete administrative and financial processes such as claim reimbursement. This may be implemented by mapping of clinical terminologies in use to administrative and financial terminologies.

Statement: Support remote health care services such as tele-health and remote device monitoring by integrating records and data collected by these means into the patient's record for care management, billing and public health reporting purposes.

Description: Enables remote treatment of patients using monitoring devices, and two way communications between provider and patient or provider and provider. Promotes patient empowerment, self-determination and ability to maintain health status in the community. Promotes personal health, wellness and preventive care. For example, a diabetic pregnant Mom can self-monitor her condition from her home and use web TV to report to her provider. The same TV-internet connectivity allows her to get dietary and other health promoting information to assist her with managing her high-risk pregnancy.

Statement: Where not covered above, provide the means to manage and organize the documentation of the health care needed and delivered during an encounter/episode of care.

Description: Using data standards and technologies that support interoperability, encounter management promotes patient- centered/oriented care and enables real time, immediate point of service, point of care by facilitating efficient work flow and operations performance to ensure the integrity of: (1) the health record, (2) public health, financial and administrative reporting, and (3) the healthcare delivery process. This support is necessary for direct care functionality that relies on providing user interaction and workflows, which are configured according to clinical protocols and business rules based on encounter specific values such as care setting, encounter type (inpatient, outpatient, home health, etc.), provider type, patient's record, health status, demographics, and the initial purpose of the encounter.

Statement: Support extraction, transformation and linkage of information from structured data and unstructured text in the patient's health record for care management, financial, administrative, and public health purposes.

Description: Using data standards and technologies that support interoperability, information access functionalities serve primary and secondary record use and reporting with continuous record availability and access that ensure the integrity of (1) the health record, (2) public health, financial and administrative reporting, and (3) the healthcare delivery process.

Statement: Make available all pertinent patient information needed to support coding of diagnoses, procedures and outcomes.

Description: The user is assisted in coding information for clinical reporting reasons. For example, a professional coder may have to code the principal diagnosis in the current, applicable ICD as a basis for hospital funding. All diagnoses and procedures during the episode may be presented to the coder, as well as the applicable ICD hierarchy containing these codes.

Statement: Provide financial and administrative coding assistance based on the structured data and unstructured text available in the encounter documentation.

Description: The user is assisted in coding information for billing or administrative reasons. For example, in the US Domain, the HIPAA 837 Professional claim requires the date of the last menstrual cycle for claims involving pregnancy. To support the generation of this transaction, the provider would need to be prompted to enter this date when the patient is first determined to be pregnant, then making this information available for the billing process.

Statement: Support interactions with other systems, applications, and modules to enable the use of cost management information required to guide users and workflows.

Description: The provider is alerted or presented with the most cost-effective services, referrals, devices and etc., to recommend to the patient. This may be tailored to the patient's health insurance/plan coverage rules. Medications may be presented in order of cost, or the cost of specific interventions may be presented at the time of ordering.

Statement: Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care.

Description: Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care.

·   The EHR system shall capture the patient health-related information needed for administrative and financial purposes including reimbursement.·   Captures the episode and encounter information to pass to administrative or financial processes (e.g. triggers transmissions of charge transactions as by-product of on-line interaction including order entry, order statusing, result entry, documentation entry, medication administration charting).·   Automatically retrieves information needed to verify coverage and medical necessity. ·   As a byproduct of care delivery and documentation: captures and presents all patient information needed to support coding. Ideally performs coding based on documentation.·   Clinically automated revenue cycle - examples of reduced denials and error rates in claims. ·   Clinical information needed for billing is available on the date of service.·   Physician and clinical teams do not perform additional data entry / tasks exclusively to support administrative or financial processes.

Statement: Support interactions with other systems, applications, and modules to facilitate enrollment of uninsured patients into subsidized and unsubsidized health plans, and enrollment of patients who are eligible on the basis of health and/or financial status in social service and other programs, including clinical trials.

Description: Expedites determination of health insurance coverage, thereby increasing patient access to care. The provider may be alerted that uninsured patients may be eligible for subsidized health insurance or other health programs because they meet eligibility criteria based on demographics and/or health status. For example: a provider is notified that the uninsured parents of a child enrolled in S-CHIP may now be eligible for a new subsidized health insurance program; a provider of a pregnant patient who has recently immigrated is presented with information about eligibility for subsidy. Links may be provided to online enrollment forms. When enrollment is determined, the health coverage information needed for processing administrative and financial documentation, reports or transactions is captured.

Statement: Support interactions with other systems, applications, and modules to enable eligibility verification for health insurance and special programs, including verification of benefits and pre-determination of coverage.

Description: Retrieves information needed to support verification of coverage at the appropriate juncture in the encounter workflow. Improves patient access to covered care and reduces claim denials. When eligibility is verified, the system would capture eligibility information needed for processing administrative and financial documentation, reports or transactions - updating or flagging any inconsistent data. In addition to health insurance eligibility, this function would support verification of registration in programs and registries, such as chronic care case management and immunization registries. A system would likely verify health insurance eligibility prior to the encounter, but would verify registration in case management or immunization registries during the encounter.

Statement: Support interactions with other systems, applications, and modules to enable the creation of requests, responses and appeals related to service authorization, including prior authorizations, referrals, and pre-certification.

Description: Retrieves information needed to support verification of medical necessity and prior authorization of services at the appropriate juncture in the encounter workflow. Improves timeliness of patient care and reduces claim denials.

Statement: Support interactions with other systems, applications, and modules to support the creation of health care attachments for submitting additional clinical information in support of service requests and claims.

Description: Retrieves structured and unstructured data, including but not limited to lab data, imaging data, device monitoring data, and text based data, based on rules or requests for additional clinical information, in support of service requests or claims, at the appropriate juncture in the encounter workflow.

Statement: Support interactions with other systems, applications, and modules to enable the creation of claims and encounter reports for reimbursement.

Description: Retrieves information needed to support claims and encounter reporting. This reporting occurs at the appropriate juncture in the encounter workflow in a manual or automated fashion. For example this could occur at an initial, interim or final billing. The system may also present the information that is provided for audit and review by local authorities.

Statement: Support the creation of health service reports at the conclusion of an episode of care. Support the creation of health service reports to authorized health entities, for example public health, such as notifiable condition reports, immunization, cancer registry and discharge data that a provider may be required to generate at the conclusion of an episode of care.

Description: Effective use of this function means that providers do not perform additional data entry to support health management programs and reporting.

Statement: Identify relationships among providers treating a single patient, and provide the ability to manage patient lists assigned to a particular provider.

Description: This function addresses the ability to access and update current information about the relationships between caregivers and the patients. This information should be able to flow seamlessly between the different components of the system, and between the EHR system and other systems. Business rules may be reflected in the presentation of, and the access to this information. The relationship among providers treating a single patient will include any necessary chain of authority/responsibility.

- Example: In a care setting with multiple providers, where the patient can only see certain kinds of providers (or an individual provider); allow the selection of only the appropriate providers. - Example: The user is presented with a list of people assigned to a given practitioner and may alter the assignment as required - to a group, to another individual or by sharing the assignment.

Statement: Document relationships between patients and others to facilitate appropriate access to their health record on this basis if appropriate.

Description: A user may assign the relationships between patients and others to facilitate access to their health record. Some example may include parent, relatives, a legal guardian, health care surrogate or payer.

Statement: Provide information on relationships by genealogy.

Description:

Description:

Description: Relationships by genealogy may include genetic mother, next of kin, or family members. Appropriate consents must be acquired prior to the collection of use of this information.

Statement: Support interactions with other systems, applications, and modules to provide information on relationships by insurance (domestic partner, spouse, and guarantor).

Statement: Provide information on relationships by living situation (in same household).

Statement: Provide information on relationships by other means.

Description: Other relationships that may need to be recorded would include but not be limited to surrogate mother, guardian, a person authorized to see health records, health care surrogate, and persons who may be related by epidemiologic exposure.

Statement: Provide the data necessary to support and manage patient acuity/severity for illness/risk-based adjustment of resource.

Description:

Description: Research has been done on nurse staffing and patient outcomes; the impact of organizational characteristics on nurse staffing patterns, patient outcomes, and costs; and the impact of nurses’ experience on patient outcomes. The research indicates that nurse staffing has a definite and measurable impact on patient outcomes, medical errors, length of stay, nurse turnover, and patient mortality. Acuity data helps determine what is, indeed, appropriate staffing – as modified by the nurses’ level of experience, the organization’s characteristics, and the quality of clinical interaction between and among physicians, nurses, and administrators. Also, acuity and severity data is routinely the evidential basis most frequently cited by staff when recommending clinical staffing changes.

Statement: Update EHR supportive content using a manual or automated process.

Statement: Facilitate and/or perform updates of clinical decision support system guidelines and associated reference material.

Description: Clinical decision support rules may be applied to the system using a manual process. As standards are developed to represent these rules, an automated update will be recommended. Any process to update decision support rules should include the verification of the appropriateness of the rules to the system. This may include but not be limited to authenticity of the source, the currency of the version, and any necessary approvals before updates can take place.

Statement: Receive and validate formatted inbound communications to facilitate and/or perform updating of patient education material.

Description: Materials may include information about a diagnosis, recommended diets, associated patient health organizations, or web links to similar educational information. These materials may be provided electronically and may require validation prior to inclusion in the system.

Statement: Receive and validate formatted inbound communications to facilitate updating of patient reminder information from external sources such as Cancer or Immunization Registries.

Description: Information from outside groups, such as immunization groups, public health organizations, etc. may periodically send updates to patient care providers. The system should be capable of generating patient reminders based on the recommendations of these organizations. Patient reminders could be provided to patients by a number of means including phone calls, or mail. A record of such reminders may become part of a patient’s record. Examples of reminders could include a recommended immunization, prophylactic guidelines for MVP, patient self-testing for disease, etc.

Statement: Receive and validate formatted inbound communications to facilitate updating of public health reporting guidelines.

Description: Information and reporting requirements from outside groups, such as public health organizations, may be made available to patient care providers. Examples may include requirements to report on new disease types, or changes to reporting guidelines. The information in these public health updates may be applied to the system so that appropriate data can be collected and reported to comply with requirements.

Statement: Secure the access to an EHR-S and EHR information. Manage the sets of access control permissions granted within an EHR-S. Prevent unauthorized use of data, data loss, tampering and destruction.

Description: To enforce security, all EHR-S applications must adhere to the rules established to control access and protect the privacy of EHR information. Security measures assist in preventing unauthorized use of data and protect against loss, tampering and destruction. An EHR-S must be capable of including or interfacing with standards-conformant security services to ensure that any Principal (user, organization, device, application, component, or object) accessing the system or its data is appropriately authenticated, authorized and audited in conformance with local and/or jurisdictional policies.

An EHR-S should support Chains of Trust in respect of authentication, authorization, and privilege management, either intrinsically or by interfacing with relevant external services.

Statement: Authenticate EHR-S users and/or entities before allowing access to an EHR-S.

Description: Both users and applications are subject to authentication. The EHR-S must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include: - username/ password - digital certificate- secure token- biometrics

Statement: Manage the sets of access-control permissions granted to entities that use an EHR-S (EHR-S Users). Enable EHR-S security administrators to grant authorizations to users, for roles, and within contexts. A combination of these authorization categories may be applied to control access to EHR-S functions or data within an EHR-S, including at the application or the operating system level.

Description: EHR-S Users are authorized to use the components of an EHR-S according to their identity, role, work-assignment, location and/or the patient’s present condition and the EHR-S User’s scope of practice within a legal jurisdiction.

,- User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is a patient defined denial of access to all or part of a record to a particular party for privacy related reasons. Another user based authorization is for a tele-monitor device or robotic access to an EHR-S for prescribed directions and other input. - Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device (tele-monitor or robotic); or a nurse, dietician, administrator, legal guardian, and auditor.

- Context-based Authorization is defined by ISO 10181-3 Technical Framework for Access Control Standard as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For example, an EHR-S might only allow supervising providers’ context authorization to attest to entries proposed by residents under their supervision.

In addition to the ISO standard, context authorization for an EHR-S is extended to satisfy special circumstances such as, work assignment, patient consents and authorizations, or other healthcare-related factors. A context-based example is a patient-granted authorization to a specific third party for a limited period to view specific EHR records.

Description:

Another example is a right granted for a limited period to view those, and only those, EHR records connected to a specific topic of investigation.

Statement: Verify and enforce access control to all EHR-S components, EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource.

Description: Entity Access Control is a fundamental function of an EHR-S. To ensure that access is controlled, an EHR-S must perform authentication and authorization of users or applications for any operation that requires it and enforce the system and information access rules that have been defined.

Statement: Enable a healthcare delivery organization to allow and manage a patient’s access to the patient’s personal health information.

A healthcare delivery organization will be able to manage a patient’s ability to view his or her EHR based on scope of practice, organization policy or jurisdictional law. Typically, a patient has the right to view his or her EHR and the right to place restrictions on who can view parts or the whole of that EHR. For example, in some jurisdictions, minors have the right to restrict access to their data by parents/guardians.

One example of managing a patient’s access to his or her data is by extending user access controls to patients.

Statement: Limit an EHR-S user’s ability to deny (repudiate) the origination, receipt, or authorization of a data exchange by that user.

Description: An EHR-S allows data entry and data access to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non repudiation guarantees that the source of the data record can not later deny that it is the source; that the sender or receiver of a message cannot later deny having sent or received the message. For example, non-repudiation may be achieved through the use of a:

- Digital signature, which serves as a unique identifier for an individual (much like a written signature on a paper document).

- Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent and/or received) and

- Timestamp, which proves that a document existed at a certain date and time. Date and Time stamping implies the ability to indicate the time zone where it was recorded (time zones are described in ISO 8601 Standard Time Reference).

Statement: Secure all modes of EHR data exchange.

Description: Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation as well as both destination and source authentication when necessary. For example, it may be necessary to encrypt data sent to remote or external destinations. A secure data exchange requires that there is an overall coordination regarding the information that is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within an EHR-S or external to an EHR-S.

Statement: Route electronically exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

Description: An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP addresses or recordings of DNS names. For dynamic determination of known sources and destinations systems can use authentication mechanisms as described in IN.1.1. For example, the sending of a lab order from the EHRS to a lab system within the same organization usually uses a simple static setup for routing. In contrast sending a lab order to a reference lab outside of the organization will involve some kind of authentication process.

In general, when the underlying network infrastructure is secure (e.g. secure LAN or VPN) the simple static setup is used.

Statement: Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with incoming or outgoing information.

Description: The purpose of attestation is to show authorship and assign responsibility for an act, event, condition, opinion, or diagnosis. Every entry in the health record must be identified with the author and should not be made or signed by someone other than the author. (Note: A transcriptionist may transcribe an author's notes and a senior clinician may attest to the accuracy of another's statement of events.) Attestation is required for (paper or electronic) entries such as narrative or progress notes, assessments, flow sheets, and orders. Digital signatures may be used to implement document attestation. For an incoming document, the record of attestation is retained if included. Attestation functionality must meet applicable legal, regulatory and other applicable standards or requirements.

Statement: Enable the enforcement of the applicable jurisdictional and organizational patient privacy rules as they apply to various parts of an EHR-S through the implementation of security mechanisms.

Description: Patients’ privacy and the confidentiality of EHRs are violated if access to EHRs occurs without authorization.  Violations or potential violations can impose tangible economic or social losses on affected patients, as well as less tangible feelings of vulnerability and pain.   Fear of potential violations discourages patients from revealing sensitive personal information that may be relevant to diagnostic and treatment services.  Rules for the protection of privacy and confidentiality may vary depending upon the vulnerability of patients and the sensitivity of records.  Strongest protections should apply to the records of minors and the records of patients with stigmatized conditions.  Authorization to access the most sensitive parts of an EHR is most definitive if made by the explicit and specific consent of the patient. Please see the definition of masking in the glossary.

-Retaining inbound documents as originally received (unaltered);

Statement: Manage EHR information across EHR-S applications by ensuring that clinical information entered by providers is a valid representation of clinical notes; and is accurate and complete according to clinical rules and tracking amendments to clinical documents. Ensure that information entered by or on behalf of the patient is accurately represented.

Description: Since EHR information will typically be available on a variety of EHR-S applications, an EHR-S must provide the ability to access, manage and verify accuracy and completeness of EHR information, maintain the integrity and reliability of the data, and provide the ability to audit the use of and access to EHR information.

Statement: Retain, ensure availability, and destroy health record information according to scope of practice, organizational policy, or jurisdictional law. This includes:

-Retaining all EHR-S data and clinical documents for the time period designated by policy or legal requirement;

-Ensuring availability of information for the legally prescribed period of time to users and patients; and -Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally prescribed retention period.Description: Discrete and structured EHR-S data, records and reports must be: -Made available to users in a timely fashion; -Stored and retrieved in a semantically intelligent and useful manner (for example, chronologically, retrospectively per a given disease or event, or in accordance with business requirements, local policies, or legal requirements);-Retained for a legally prescribed period of time; and -Destroyed in a systematic manner in relation to the applicable retention period.

An EHR-S must also allow an organization to identify data/records to be destroyed, and to review and approve destruction before it occurs. In such a case it should pass along record destruction date information along with existing data when providing records to another entity.

Statement: Provide audit capabilities for system access and usage indicating the author, the modification (where pertinent), and the date and time at which a record was created, modified, viewed, extracted, or deleted. Date and Time stamping implies the ability to indicate the time zone where it was recorded (time zones are described in ISO 8601 Standard Time Reference). Auditable records extend to information exchange, to audit of consent status management (to support DC.1.3.3) and to entity authentication attempts. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for an EHR-S.

Description: Audit functionality extends to security audits, data audits, audits of data exchange, and the ability to generate audit reports. Audit capability settings should be configurable to meet the needs of local policies. Examples of audited areas include:

- Security audit, which logs access attempts and resource usage including user login, file access, other various activities, and whether any actual or attempted security violations occurred- Data audit, which records who, when, and by which system an EHR record was created, updated, translated, viewed, extracted, or (if local policy permits) deleted. Audit-data may refer to system setup data or to clinical and patient management data- Information exchange audit, which records data exchanges between EHR-S applications (for example, sending application; the nature, history, and content of the information exchanged); and information about data transformations (for example, vocabulary translations, reception event details, etc.)

- Audit reports should be flexible and address various users' needs. For example, a legal authority may want to know how many patients a given healthcare provider treated while the provider's license was suspended. Similarly, in some cases a report detailing all those who modified or viewed a certain patient record- Security audit trails and data audit trails are used to verify enforcement of business, data integrity, security, and access-control rules-There is a requirement for system audit trails for the following events:

- Audit reports should be flexible and address various users' needs. For example, a legal authority may want to know how many patients a given healthcare provider treated while the provider's license was suspended. Similarly, in some cases a report detailing all those who modified or viewed a certain patient record- Security audit trails and data audit trails are used to verify enforcement of business, data integrity, security, and access-control rules-There is a requirement for system audit trails for the following events:

> Loading new versions of, or changes to, the clinical system; > Loading new versions of codes and knowledge bases; > Taking and restoring of backup; > Changing the date and time where the clinical system allows this to be done; > Archiving any data; > Re-activating of an archived patient record; > Entry to and exiting from the clinical system; > Remote access connections including those for system support and maintenance activities

Statement: Maintain synchronization involving: -Interaction with entity directories;-Linkage of received data with existing entity records; -Location of each health record component; and -Communication of changes between key systems.

Description: An EHR-S may consist of a set of components or applications; each application manages a subset of the health information. Therefore it is important that, through various interoperability mechanisms, an EHR-S maintains all the relevant information regarding the health record in synchrony. For example, if a physician orders an MRI, a set of diagnostic images and a radiology report will be created. The patient demographics, the order for MRI, the diagnostic images associated with the order, and the report associated with the study must all be synchronized in order for the clinicians to view the complete record.

Statement: Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions may be used to exchange data and provide reports for primary and ancillary purposes.

Description: An EHR-S enables an authorized user, such as a clinician, to access and aggregate the distributed information, which corresponds to the health record or records that are needed for viewing, reporting, disclosure, etc. An EHR-S must support data extraction operations across the complete data set that constitutes the health record of an individual and provide an output that fully chronicles the healthcare process. Data extractions are used as input to patient care coordination between facilities, organizations and settings. In addition, data extractions can be used for administrative, financial, research, quality analysis, and public health purposes.

Specific examples include:- text message to physician- patient photo- letter from family- scanned image of insurance card- dictated report (voice recording)

Description:

Statement: Store and manage health record information as structured and unstructured data

Description: Unstructured health record information is information that is not divided into discrete fields AND not represented as numeric, enumerated or codified data.

General examples of unstructured health record information include:- text- word processing document- image- multimedia

Structured health record information is divided into discrete fields, and may be enumerated, numeric or codified.

Examples of structured health information include: - patient address (non-codified, but discrete field)- diastolic blood pressure (numeric) - coded result observation- coded diagnosis- patient risk assessment questionnaire with multiple-choice answers

Context may determine whether or not data are unstructured, e.g., a progress note might be standardized and structured in some EHR-S (e.g., Subjective/Objective/Assessment/Plan) but unstructured in others.

Managing healthcare data includes capture, retrieval, deletion, correction, amendment, and augmentation. Augmentation refers to providing additional information regarding the healthcare data, which is not part of the data itself, e.g. linking patient consents or authorizations to the healthcare data of the patient.

Statement: Create, capture, and maintain unstructured health record information.

Statement: Create, capture, and maintain structured health record information.

Description: Structured health record information is divided into discrete fields, and may be enumerated, numeric or codified.

Examples of structured health information include: - patient address (non-codified, but discrete field)- diastolic blood pressure (numeric) - coded result observation- coded diagnosis- patient risk assessment questionnaire with multiple-choice answers

Context may determine whether or not Context may determine whether or not data are unstructured, e.g., a progress note might be standardized and structured in some EHRS (e.g., Subjective/Objective/Assessment/Plan) but unstructured in others.

Statement: Enable the use of registry services and directories to uniquely identify, locate and supply links for retrieval of information related to:- patients and providers for healthcare purposes; - payers, health plans, sponsors, and employers for administrative and financial purposes; - public health agencies for healthcare purposes, and- healthcare resources and devices for resource management purposes.

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

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

An example of local registry usage is an EHR-S application sending a query message to the Hospital Information System to retrieve a patient’s demographic data.

Description:

Statement: Support semantic interoperability through the use of standard terminologies, standard terminology models and standard terminology services.

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

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

Statement: Employ standard terminologies to ensure data correctness and to enable semantic interoperability (both within an enterprise and externally).Support a formal standard terminology model.

Description: Semantic interoperability requires standard terminologies combined with a formal standard information model. An example of an information model is the HL7 Reference Information model.

Examples of terminologies that an EHR-S may support include: LOINC, SNOMED, ICD-9, ICD-10, and CPT-4.

A terminology provides semantic and computable identity to its concepts.

Terminologies are use-case dependent and may or may not be realm dependent. For example, terminologies for public health interoperability may differ from those for healthcare quality, administrative reporting, research, etc.

Formal standard terminology models enable common semantic representations by describing relationships that exist between concepts within a terminology or in different terminologies, such as exemplified in the model descriptions contained in the HL7 Common Terminology Services specification.

The clinical use of standard terminologies is greatly enhanced with the ability to perform hierarchical inference searches across coded concepts. Hierarchical Inference enables searches to be conducted across sets of coded concepts stored in an EHR-S. Relationships between concepts in the terminology are used in the search to recognize child concepts of a common parent. For example, there may be a parent concept, "penicillin containing preparations" which has numerous child concepts, each of which represents a preparation containing a specific form of penicillin (Penicillin V, Penicillin G, etc). Therefore, a search may be conducted to find all patients taking any form of penicillin preparation.

Clinical and other terminologies may be provided through a terminology service internal or external to an EHR-S. An example of a terminology service is described in the HL7 Common Terminology Services specification.

Statement: Enable version control according to customized policies to ensure maintenance of utilized standards.

This includes the ability to accommodate changes to terminology sets as the source terminology undergoes its natural update process (new codes, retired codes, redirected codes). Such changes need to be cascaded to clinical content embedded in templates, custom formularies, etc., as determined by local policy.

Description: Version control allows for multiple sets or versions of the same terminology to exist and be distinctly recognized over time.

Terminology standards are usually periodically updated, and concurrent use of different versions may be required. Since the meaning of a concept can change over time, it is important that retrospective analysis and research maintains the ability to relate changing conceptual meanings. If the terminology encoding for a concept changes over time, it is also important that retrospective analysis and research can correlate the different encodings to ensure the permanence of the concept. This does not necessarily imply that complete older versions of the terminology be kept in the EHR-S, only access to the changes needs to be maintained.

It should be possible to retire deprecated versions when applicable business cycles are completed while maintaining obsolescent code sets. An example use of this is for possible claims adjustment throughout the claim's lifecycle.

Statement: Map or translate one terminology to another as needed by local, regional, national, or international interoperability requirements

Description: The ability to map or translate one terminology to another is fundamental to an organization in an environment where several terminologies are in play with overlapping concepts.

It is a common occurrence that data is captured using one terminology, but is shared using another terminology. For example, within a healthcare organization there may be a need to map overlapping terminology concepts (e.g. between an EHRS and an external laboratory system, ore between an EHRS and a billing system).

Realm specific (including local, regional, national or international) interoperability requirements can also determine the need for terminology mapping, and in many cases terminology mapping services can be used to satisfy these requirements.

Statement: Provide automated health care delivery processes and seamless exchange of clinical, administrative, and financial information through standards-based solutions.

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

A variety of interaction modes are typically supported such as:-Unsolicited Notifications, e.g. a patient has arrived for a clinic appointment-Query/Response e.g., Is Adam Everyman known to the system? Yes, MRN is 12345678.

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

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

Statement: Support the ability to operate seamlessly with other systems, either internal or external, that adhere to recognized interchange standards. “Other systems” include other EHR Systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

Description: An organization typically uses a number of interchange standards to meet its external and internal interoperability requirements. It is fundamental that there be a common understanding of rules regarding connectivity, information structures, formats and semantics. These are known as “interoperability or interchange standards”. Data exchange which may be between internal systems or modules, or external to the organization, is to occur in a manner which is seamless to the user. For example, if data interchange involves double entry, or manual cut-and-paste steps by the user, it is not considered seamless.

Representation of EHR content is transmitted in a variety of interchange formats such as: HL7 Messages, Clinical Document Architecture (CDA) and other HL7 Structured Documents, X12N healthcare transactions, and Digital Imaging and Communication in Medicine (DICOM) format.

Support for multiple interaction modes is needed to respond to differing levels of immediacy and types of exchange. For example, messaging is effective for many near-real time, asynchronous data exchange scenarios but may not be appropriate if the end-user is requesting an immediate response from a remote application.

-Service Request and Response, e.g., Laboratory Order for “Fasting Blood Sugar” and a response containing the results of the test.-Information Interchange between organizations (e.g. in a RHIO, or in a National Health System) -Structured/discrete clinical documents, e.g., Clinical Note-Unstructured clinical document, e.g., dictated surgical note

Standard terminology is a fundamental part of interoperability and is described in section IN.4. Using a formal explicit information model further optimizes interoperability. An example of an information model is the HL7 Reference Information Model (RIM). Organizations typically need to deal with more than one information model and may need to develop a mapping or a meta-model.

Statement: Enable version control according to local policies to ensure maintenance of utilized interchange standards.Version control of an interchange standard implementation includes the ability to accommodate changes as the source interchange standard undergoes its natural update process.

Description: The life cycle of any given standard results in changes to its requirements. It is critical that an organization know the version of any given standard it uses and what its requirements and capabilities are.

For example, if the organization migrates to an HL7 v2.5 messaging standard, it may choose to take advantage of new capabilities such as specimen or blood bank information. The organization may find that certain fields have been retained for backwards compatibility only or withdrawn altogether. The EHR-S needs to be able to handle all of these possibilities.

Standards typically evolve in such a way as to protect backwards compatibility. On the other hand, sometimes there is little, or no, backwards compatibility when an organization may need to replace an entire standard with a new methodology. An example of this is migrating from HL7 v2 to HL7 v3.

Interchange standards that are backward compatible support exchange among senders and receivers who are using different versions. Version control ensures that those sending information in a later version of a standard consider the difference in information content that can be interchanged effectively with receivers, who are capable of processing only earlier versions. That is, senders need to be aware of the information that receivers are unable to capture and adjust their business processes accordingly.

> Version control enables multiple versions of the same interchange standard to exist and be distinctly recognized over time.> Since interchange standards are usually periodically updated, concurrent use of different versions may be required.> Large (and/or federated) organizations typically need to use different versions of an interchange standard to meet internal organizational interoperability requirements.> For example, the enterprise-wide standard might use HL7 v2.5 for Lab messages, but some regions of the enterprise might be at a lower level.

It should be possible to retire deprecated interchange standards versions when applicable business cycles are completed while maintaining obsolete versions. An example use of this is for possible claims adjustment throughout the claim’s life cycle.When interchange standards change over time, it is important that retrospective analysis and research correlate and note gaps between the different versions’ information structures to support the permanence of concepts over time. An example use of this is the calculation of outcome or performance measures from persisted data stores where one version of a relevant interchange standard, e.g., CDA Release 1 captures the relevant data, e.g., discharge data, differently than CDA Release 2.

Description:

For example:

Statement: Enable standards-based application integration with other systems.

When an organization wishes to integrate its applications, they must use standardized methods. Standards-based application integration may be achieved in a variety of ways.

-desktop visual integration may be achieved via HL7 Clinical Context Object Workgroup (CCOW) standards-workflow functions may be integrated via The Workflow Management Coalition (WfMC) standards-EHRS may be integrated in an Enterprise Information System Architecture via Service Oriented Architecture (SOA) standards

It is recognized that these examples are very disparate and used for very different purposes.

The method used depends on the organization’s approach to application integration. An organization could conceivably use multiple integration approaches.

Statement: Support interactions with entity directories to determine the address, profile and data exchange requirements of known and/or potential partners.

Use the rules of interaction specified in the partner’s interchange agreement when exchanging information.Description: Systems that wish to communicate with each other, must agree on the parameters associated with that information exchange. Interchange Agreements allow an EHR-S to describe those parameters/criteria.

An EHR-S can use the entity registries to determine the security, addressing, and reliability requirements between partners.

An EHR-S can use this information to define how data will be exchanged between the sender and the receiver.

Discovery of interchange services and capabilities can be automatic.

For example:- A new application can automatically determine a patient demographics source using a Universal Description and Discovery Integration (UDDI) for source discovery, and retrieve the Web Services Description Language (WSDL) specification for binding details.

- Good Health Hospital is a member of AnyCounty LabNet, for sharing laboratory results with other partners. Good Health Hospital periodically queries LabNet's directory (UDDI) to determine if additional information providers have joined LabNet. When new information providers are discovered, the Good Health IT establishes the appropriate service connections based upon the Service Description (WSDL).

Statement: Manage the ability to create, update, delete, view, and version business rules including institutional preferences. Apply business rules from necessary points within an EHR-S to control system behavior. An EHR-S audits changes made to business rules, as well as compliance to and overrides of applied business rules.

Description: EHR-S business rule implementation functions include: decision support, diagnostic support, workflow control, and access privileges, as well as system and user defaults and preferences.

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

Examples of applied business rules include:

- Sending an update to an immunization registry when a vaccination is administered;

- Limiting access to mental health information to authorized providers;

- Suggesting diagnosis based on the combination of symptoms (flu-like symptoms combined with widened mediastinum suggesting anthrax); - Classifying a pregnant patient as high risk due to factors such as age, health status, and prior pregnancy outcomes;

- Establishing system level defaults such as for vocabulary data sets to be implemented.; and - Establishing user level preferences such as allowing the use of health information for research purposes.

-Distribution of information to and from internal and external parties; -Support for task-management as well as parallel and serial task distribution;-Support for notification and task routing based on system triggers; and

Statement: Support workflow management functions including both the management and set up of work queues, personnel lists, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Description: Workflow management functions that an EHR-S supports include:

-Support for task assignments, escalations and redirection in accordance with business rules. Workflow definitions and management may be implemented by a designated application or distributed across an EHR-S.

See Also/Comments

S.3.1.4

S.1.4.1

S.2.2.1

S.3.1.2

S.3.1.5

IN.2.1

IN.2.3

S.1.4.1

S.2.2.2

IN.2.2

IN.2.4

IN.1.5

IN.1.6

IN.1.7

IN.1.8

IN.2.1

IN.2.2

IN.4.2

IN.4.3

IN.5.1

IN.5.2

IN.1.4

IN.2.5.1

IN.2.5.2

DC.1.1.2

DC.1.2

S.1.4.1

S.2.2.1

IN.1.9

IN.2.4

S.1.8

IN.6

IN.2.5.1

IN.2.5.2

IN.2.4

IN.5.1

S.2.2.3

IN.2.5.1

IN.5.2

S.3.1.1

IN.2.5.2

IN.5.4

IN.1.3

IN.4.1

IN.1.6

IN.4.2

IN.1.7

IN.4.3

IN.1.9

S.2.2.1

IN.5.2

S.3.5 IN.5.4

IN.1.7

IN.2.5.1

IN.2.5.2

IN.4.1

IN.4.2

IN.4.3IN.5.1

DC.2.1.4

S.3.7.1

IN.6

IN.2.5.1

IN.2.5.2

S.3.5.1

S.3.5.3

S.3.5.4

IN.1.5

IN.1.8

IN.1.9

IN.2.2

IN.2.5.1

IN.2.5.2

IN.6

DC.1.1.3

S.2.2.2

S.3.5.1

S.3.5.4

IN.1.5

IN.1.8

IN.1.9

IN.2.2

IN.2.4

IN.2.5.1

IN.2.5.2

IN.6

S.2.2.2

IN.2.5.1

IN.2.4

IN.2.5.2

DC.2.3.1.1

S.2.2.1

S.2.2.3

S.3.7.1

IN.2.5.1

IN.2.5.2

IN.4.1

IN.4.2

IN.4.3

IN.6

S.2.2.1IN.2.5.1

IN.2.5.2

IN.4.1

IN.4.2

IN.4.3

IN.6

IN.5.1

IN.5.2

IN.5.4

DC.2.1.3

S.2.2.1

S.3.3.5

IN.2.4

IN.2.5.1

IN.6

IN.2.5.2

IN.4.1

IN.4.2

IN.4.3

DC.1.5

IN.5.1

DC.1.6.2

IN.5.2

IN.6DC.1.10.1

DC.2.1.1

DC.2.1.2

DC.2.2.1

S.2.2.1

IN.1.6

IN.2.5.1

IN.2.5.2

IN.4.1

IN.4.2IN.4.3

DC.1.1.2

DC.2.2.1.1

IN.6

DC.2.2.1.2

DC.2.2.2

DC.2.2.3

DC.2.7.1

S.3.7.1

DC.3.1.1

DC.3.1.2

DC.3.1.3

IN.2.2

IN.2.5.1

IN.6

IN.2.5.2

DC.2.3.1.1

DC.2.3.1.2

DC.2.3.1.3

DC.2.4.2

DC.3.2.2

S.2.2.1

S.3.3.2

S.3.7.2

IN.2.4

IN.2.5.2

IN.4.1

IN.4.2

IN.4.3

IN.5.1

IN.5.2

IN.6

IN.5.4

DC.2.4.1

DC.2.4.2

S.2.2.1

IN.6

IN.6

S.3.3.3

S.3.7.1

IN.1.6

IN.1.7

IN.2.5.1

IN.2.5.2

DC.2.4.5.2

S.2.2.1

S.3.7.1IN.1.6

IN.1.7

IN.2.5.1

IN.2.5.2

S.1.1

S.1.2

DC.2.4.5.1

DC.1.9.3

IN.2.5.2

DC.2.4.4.1

DC.2.4.4.2

S.1.3.1a

S.1.3.5

S.3.3.2

S.3.3.3

IN.6

IN.1.6

IN.1.7

IN.2.5.1

DC.2.4.1

IN.2.5.1

IN.2.5.2

DC.1.1.1

IN.2.4

DC.2.3.1.1

IN.2.5.1

IN.6

S.1.1

DC.2.3.1.2

IN.2.5.2

DC.2.3.2

S.2.2.1

S.2.2.3

IN.1.1

IN.1.2

IN.1.3

IN.1.7

IN.1.9

DC.1.3.2

IN.5.1

IN.5.2

IN.6S.2.2.2

S.3.7.1

IN.1.6

IN.1.7

IN.2.4

IN.2.5.1

IN.2.5.2

IN.3.1

IN.3.2

IN.4.1IN.4.2

IN.4.3

DC.2.4.3

IN.6

S.2.2.1

S.3.7.1

IN.1.6

IN.1.7

IN.2.4

IN.2.5.1

IN.2.5.2

IN.2.5.1

IN.2.5.2

IN.2.2

IN.2.5.1

IN.2.5.2

IN.6

S.3.7.1

IN.2.5.1

IN.2.5.2

IN.6

DC.2.2.4

IN.2.2

DC.2.7.2

DC.3.2.3

DC.3.2.4

S.3.7.2

S.3.7.3

IN.1.8

DC.1.4

DC.1.5

S.3.7.1

IN.6

IN.2.3

IN.2.4

DC.1.4

DC.1.5

S.3.7.1

IN.2.3

IN.6

IN.6

IN.2.4

DC.1.4

DC.1.5

S.3.7.1

S.3.7.2

S.3.7.4

IN.6

DC.1.1.4

DC.2.2.1.2

DC.1.6.1

DC.2.2.2

DC.1.6.2

S.3.7.1

DC.1.6.3

S.3.7.2

DC.1.11.1

S.3.7.4

DC.1.11.2

DC.2.2.1.1

DC.1.2

DC 1.6.1

IN.6

DC 1.3.1

DC 1.4

DC 1.5

DC 1.6

DC.1.6.1

DC.1.6.3

S.2.2.1

IN.2.4

IN.6

S.1.1

S.1.5

DC.2.2.1.2

S.2.2.2IN.2.2

IN.4.1

IN.4.2

IN.6

IN.7

S.2.2.2

IN.4.3

S.3.3.1

IN.5.1

IN.1.1

IN.5.2

IN.1.2

IN.5.4

IN.1.3

IN.1.9IN.2.2IN.2.4

DC.1.1.4

DC.1.11.1

S.3.7.1

S.3.7.2

S.3.7.3

IN.1.4IN.1.9

IN.6

S.3

IN.6

IN.2.4

IN.6

DC.2.3.1.1

IN.6

DC 2.3.1.2

S.3.3.2

IN.6

DC.1.3.3

DC.1.7.2

DC.1.10.1

DC.2.7.1

S.1.4.1

S.2.2.2

S.3.7.1

IN.2.3

IN.2.4

IN.6

DC.1.9.3

S.2.2.2

S.3.7.1

IN.1.1

IN.1.2

IN.1.3

IN.6

S.3.3.3

S.2.2.2

S.3.7.1

IN.2.4

IN.6

IN.6

IN.6

S.1.3.1a

S.1.3.5

S.2.2.2

S.3.3.2IN.2.4

S.3.7.1

S.1.2

IN.6

IN.6

DC.1.10.2

S.2.2.1

S.1.4.1

S.2.2.1

IN.1.6

IN.1.7

IN.6

IN.1.9

IN.2.3IN.2.4

DC.2.5.1

DC.2.5.2

DC.2.6.2

IN.6

S.3.7.2

S.3.7.4

S.1.5

S.2.1.1

S.2.1.2

S.2.2.2

S.2.2.3

IN.1.6

IN.1.9

IN.2.2

IN.2.3

IN.2.4

S.1.3.6

N.1.7

S.2.2.2

S.3.7.1

S.3.7.4IN.1.6

IN.2.4

IN.3.1IN.3.2

IN.4.1

IN.4.2

IN.4.3

IN.5.1

IN.5.2

IN.5.4

IN.6DC.1.6.1

DC.1.6.2

S.1.3.6

S.1.4.1

S.2.2.2

S.2.2.3

S.3.7.4IN.2.4

S.3.7.1

IN.6

IN.6

S.3.7.4

IN.5.1

IN.5.2

IN.5.3

IN.5.4

DC.3.2.4

IN.5.4

DC.3.4.9

S.3.7.1

S.3.7.2

S.3.7.4

IN.1.4

IN.5.1IN.5.3

IN.6

S.1.3.1a

S.1.3.5

S.1.7

IN.7

S.1.6

S.1.3.1

S.1.4.1

IN.2.3

S.1.4.2

S.1.4.4

S.2.2.2

IN.7

S.2.2.3

IN.2.4

DC.1.1.3

IN.1.9

DC.1.9.5

IN.2.2.

S.1.3.1a

IN.3.1

S.1.3.2

IN.5.1

S.1.3.3

IN.5.2

S.1.3.4

S.2.2.2

IN.1.5

IN.1.6

IN.1.7

S.3.7.1

IN.5.2

IN.1.5

IN.5.3

IN.6

IN.7

IN.1.6

IN.5.4

IN.1.7

IN.1.9

IN.2.2

IN.3.1

IN.4.1

IN.4.2

IN.4.3

IN.5.1

DC.1.1.3

IN.1.7

IN.6

DC.1.11.3

IN.1.9

S.1.3.6

IN.2.2

S.1.4.1

S.3.5.1

S.3.5.3

S.3.5.4

S.3.7.1

S.3.7.2

S.3.7.3

S.3.7.4

IN.1.5

IN.1.6

DC.2.1.4

DC 3.2.3

S.3.5.1

S.3.5.3

S.3.5.4

S.3.7.1

S.3.7.2

S.3.7.4

IN.1.4

N.1.1

IN.7

IN.1.6

IN.1.7

IN.1.9

IN.2.2

IN.1.9

IN.5.2

IN.1.2

IN.4.1

IN.5.3

IN.1.3

IN.4.2

IN.1.6

IN.4.3

IN.1.7

IN.5.1

IN.4

IN.2.4,

IN.5.4

IN.4.1,

IN.4.2,

IN.5.1,

IN.5.2,

IN.1.7

IN.2.4

IN.1.3

IN.2.3

IN.3

IN.2.3

IN.3

IN.2.3

IN.2.3

IN.3

DC.1.7.2.4

DC.3.1.1

DC.3.1.3

IN.2.3

IN.2.4

IN.1.3

IN.2.1

S.1.4

DC.1.1.1

IN.1.4

DC.1.3.3

S.3.7.3

IN.2.3

DC 1.1.2

S.1.7

IN.6

IN.3IN.1.6

IN.6.1

IN.7

IN.1.7

IN.4.3

IN.1.8

IN.5.1

IN.2.2

IN.5.4

DC.3.1

DC.3.2.1

IN.2.3

IN.4.1

S.1.4.4

IN.1.6

IN.5.1

IN.5.4

IN.2.4IN.2.5.1

IN.2.5.2

IN.6

S.3.6.2

IN.4.3

S.3.6

S.1.5

S.3.6

DC.2.6.3

DC.2.6.2

IN.5.4

DC.2.6.3

IN.6DC.1.1.4

DC.1.4

IN.1.2

IN.2.5.1

IN.2.5.2

IN.4.1

IN.4.3

IN.5.1

IN.5.4

IN.1.9

IN.2.5.1

IN.2.5.2

IN.4.1

IN.4.3

IN.2.5.1

IN.2.5.2

IN.1.9,IN.2.4

DC.2.2.1.2

S.1.3.7

IN.7

DC.3.1.1

IN.4.2

IN.4.3

S.3.2.2

IN.4.1

IN.4.2

IN.4.3

DC.1.1

DC.1.7.3

IN.1.4

IN.2.3

DC.1.3.3

DC.3.2.1

IN.1.6

IN.2.5.1

DC.1.7.2.1

DC.3.2.3

IN.1.7

IN.2.5.2

DC.1.7.2.2

DC.3.2.5

IN.2.2

DC.3.1

DC.3.2

IN.2.3

IN.7

IN.6

IN.4.1

IN.4.2

IN.4.3

S.3.1.3

IN.2.5.1

IN.6

IN.7

IN.6

IN.2.5.2IN.4.1

IN.4.3

DC.1.7.1

DC.1.7.2.4

IN.4.3

DC.2.2.3

IN.1.6

IN.1.7

IN.2.3

IN.5.1

IN.5.3

IN.5.4

DC.1.1.3.1

IN.5.4

IN.2.5.1

IN.2.5.2

S.2.2

IN.7

IN.2.5.1

IN.2.5.2

DC.2.6.3

S.2.2

S.1.3.4

IN.2.4

S.1.4.1

IN.1.5

IN.1.3

IN.2.2

DC.1.1.3.1

DC.1.3.3

S.2.1.2

IN.6

DC.2.6.3

IN.5.1

DC.2.7.1

IN.5.3

IN.2.2

IN.5.4

IN.4.1

IN.6

IN.4.3

DC.3.2.4

DC.2.2.4

IN.2.2

DC.2.3.2

IN.5.2

DC.2.5.1

DC.2.5.2

DC.3.2.3

S.1.4.1

IN.4.3

IN.5.2

IN.1.3

S.1.3.1

IN.1.1

IN.2.2

IN.1.1

IN.1.2

IN.6

IN.1.7

S.2.2

IN.3

S.3.1

S.3.7

DC.2.2

Filter setsRequirement / Conformance Criteria Allergy

1

1

1

1

1

1

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL conform to function IN.1.3 (Entity Access Control).

4.       IF the system is used to enter, modify or exchange data, THEN the system SHALL conform to function IN.1.5 (Non-Repudiation), to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

5.       IF the system exchanges data outside of a secure network, THEN the system SHALL conform to Function IN.1.6 (Secure Data Exchange), to ensure that the data are protected.

6.       IF the system exchanges data outside of a secure network, THEN the system SHALL conform to Function IN.1.7 (Secure Data Routing), to ensure that the exchange occurs only among authorized senders and receivers.

1

1

1

1

1

1

1

1

1

1

1

1

7.       IF the system is used to enter or modify data in the health record, THEN the system SHALL conform to function IN.1.8 (Information Attestation), to show authorship and responsibility for the data.

8.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

9.       The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction).

10.    The system SHOULD conform to function IN.2.3 (Synchronization).

11.    IF the system is used to extract data for analysis and reporting, THEN the system SHALL conform to function IN.2.4 (Extraction of Health Record Information), to support data extraction across the complete health record of an individual.

12.    IF the system stores unstructured data, THEN the system SHALL conform to function IN.2.5.1 (Manage Unstructured Health Record Information), to ensure data integrity through all changes.

13.    IF the system stores structured data, THEN the system SHALL conform to function IN.2.5.2 (Manage Structured Health Record Information), to ensure data integrity through all changes.

14.    The system SHOULD conform to function IN.3 (Registry and Directory Services).

15.    IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.1 (Standard Terminologies and Terminology Models), to support semantic interoperability.

16.    IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.2 (Maintenance and Versioning of Standard Terminologies), to preserve the semantics of coded data

17.    The system SHOULD conform to function IN.4.3 (Terminology Mapping).

18.    IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.1 (Interchange Standards), to support interoperability.

1

1

1

1

1

1

19.    IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.2 (Interchange Standards Versioning and Maintenance), to accommodate the inevitable evolution of i

20.    The system SHOULD conform to function IN.5.3 (Standards-based Application Integration).

21.    IF the system exchanges data with other systems outside itself, THEN the system SHALL conform to function IN.5.4 (Interchange Agreements), to define how the sender and receiver will exchange data.

22.    The system SHOULD conform to function IN.6 (Business Rules Management).

23.    The system SHOULD conform to function IN.7 (Workflow Management).

24.    The system SHALL conform to function S.2.2.1 (Health Record Output).

1.       The system SHALL create a single logical record for each patient.

1

2.       The system SHALL provide the ability to create a record for a patient when the identity of the patient is unknown.

3.       The system SHALL provide the ability to store more than one identifier for each patient record.

4.       The system SHALL associate key identifier information (e.g., system ID, medical record number) with each patient record.

5.       The system SHALL provide the ability to uniquely identify a patient and tie the record to a single patient.

6.       The system SHALL provide the ability, through a controlled method, to merge or link dispersed information for an individual patient upon recognizing the identity of the patient.

7.       IF health information has been mistakenly associated with a patient, THEN the system SHALL provide the ability to mark the information as erroneous in the record of the patient in which it was mistakenly associated and represent that information as erroneous in all outputs containing that information.

8.       IF health information has been mistakenly associated with a patient, THEN the system SHALL provide the ability to associate it with the correct patient.

9.       The system SHALL provide the ability to retrieve parts of a patient record using a primary identifier, secondary identifiers, or other information which are not identifiers, but could be used to help identify the patient.

10.    The system SHOULD provide the ability to obsolete, inactivate, nullify, destroy and archive a patient's record in accordance with local policies and procedures, as well as applicable laws and regulations.

11.    IF related patients register with any identical data, THEN the system SHOULD provide the ability to propagate that data to all their records.

12.    The system SHALL conform to function IN.2.2 (Auditable Records).

1

1

1

1

1.       The system SHALL capture demographic information as part of the patient record.

2.       The system SHALL store and retrieve demographic information as discrete data.

3.       The system SHALL provide the ability to retrieve demographic data as part of the patient record.

4.       The system SHALL provide the ability to update demographic data.

5.       The system SHOULD provide the ability to report demographic data.

6.       The system SHOULD store historical values of demographic data over time.

7.       The system SHALL present a set of patient identifying information at each interaction with the patient record.

8.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

9.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHALL provide the ability to capture external data and documentation.

2.       IF lab results are received through an electronic interface, THEN the system SHALL receive and store the data elements into the patient record.

3.       IF lab results are received through an electronic interface, THEN the system SHALL display them upon request.

4.       The system SHOULD provide the ability to receive, store and display scanned documents as images.

5.       The system MAY provide the ability to store imaged documents or reference the imaged documents via links to imaging systems.

6.       The system SHOULD provide the ability to receive, store and present text-based externally-sourced documents and reports.

7.       The system SHOULD provide the ability to receive, store and display clinical result images (such as radiologic images) received from an external source.

8.       The system SHOULD provide the ability to receive, store and display other forms of clinical results (such as wave files of EKG tracings) received from an external source.

9.       The system SHOULD provide the ability to receive, store and present medication details from an external source.

10.    The system SHOULD provide the ability to receive, store and present structured text-based reports received from an external source.

11.    The system SHOULD provide the ability to receive, store and present standards-based structured, codified data received from an external source.

1.       The system SHALL capture and explicitly label patient- originated data.

2.       IF the system provides the ability for direct entry by the patient, THEN the system SHALL explicitly label the data as patient entered.

3.       The system SHALL capture and label the source of clinical data provided on behalf of the patient.

4.       The system SHALL present patient-originated data for use by care providers.

5.       The system SHALL provide the ability for a provider to verify the accuracy of patient-originated data for inclusion in the patient record.

6.       The system SHOULD provide the ability to view or comment, but not alter, patient-originated data.

1.       The system SHALL provide the ability to capture and label patient health data derived from administrative or financial data.

2.       The system SHALL provide the ability to capture and link data about the source of patient health data derived from administrative and financial data with that patient data.

3.       The system SHALL provide the ability to present labeled patient health information derived from administrative or financial data and the source of that data for use by authorized users.

4.       The system SHOULD provide the ability to view or comment on patient health information derived from administrative or financial data.

5.       The system SHOULD provide the ability to request correction of the administrative or financial data.

1.       The system SHALL present summarized views and reports of the patient’s comprehensive EHR.

2.       The system SHOULD include at least the following in the summary: problem list, medication list, allergy and adverse reaction list.

1

1

1

1

1

3.       The system SHOULD conform to function S.3.3.6 (Health Service Reports at the Conclusion of an Episode of Care).

4.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

5.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHALL provide the ability to create views that prohibit patients from accessing certain information according to organizational policy, scope of practice, and jurisdictional law.

2.       The system SHOULD provide the ability to create customized views of summarized information based on sort and filter controls for date or date range, problem, or other clinical parameters.

3.       The system SHOULD provide the ability to access summarized information through customized views based on prioritization of chronology, problem, or other pertinent clinical parameters.

4.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

5.       The system SHALL conform to function IN.2.2 (Auditable Records).

1

1

1

1.       The system SHALL provide the ability to capture, update and present current patient history including pertinent positive and negative elements.

2.       The system SHOULD provide the ability to capture and present previous external patient histories.

3.       The system MAY provide the ability to capture the relationship between patient and others.

4.       The system SHALL capture the complaint, presenting problem or other reason(s) for the visit or encounter.

5.       The system SHOULD capture the reason for visit/encounter from the patient's perspective.

6.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

7.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

1

1

1.       The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions patient preferences such as language, religion, spiritual practices and culture.

2.       The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions family preferences such as language, religion, spiritual practices and culture.

3.       The system SHOULD conform to function DC.2.1.4 (Support for Patient and Family Preferences), and incorporate patient and family preferences into decision support systems.

1.       The system SHALL provide the ability to indicate that advance directives exist for the patient.

2.       The system SHALL provide the ability to indicate the type of advance directives completed for the patient such as living will, durable power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order”.

3.       The system SHOULD provide the ability to capture, present, maintain and make available for clinical decisions patient advance directives documents and “Do Not Resuscitate” orders.

4.       The system SHOULD conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and capture scanned patient advance directive documents and “Do Not Resuscitate” orders.

5.       The system SHOULD provide the ability to indicate when advanced directives were last reviewed.

6.       The system SHOULD provide the ability to indicate the name and relationship of the party completing the advance directive for the patient.

7.       The system SHALL time and date stamp advance directives.

1

1

8.       The system SHOULD provide the ability to document the location and or source of any legal documentation regarding advance directives.

9.       The system SHOULD conform to function DC.2.1.4 (Support for Patient and Family Preferences).

1.       The system SHALL provide the ability to indicate that a patient has completed applicable consents and authorizations.

2.       The system SHALL provide the ability to indicate that a patient has withdrawn applicable consents and authorizations.

3.       The system SHOULD conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and capture scanned paper consent and authorization documents.

4.       The system SHOULD provide the ability to view and complete consent and authorization forms on-line.

5.       The system MAY provide the ability to generate printable consent and authorization forms.

6.       The system MAY display the authorizations associated with a specific clinical activity, such as treatment or surgery, along with that event in the patient's electronic chart.

7.       The system MAY provide the ability to display consents and authorizations chronologically.

1

1

1

1

1

1

1

1

1

1

1

8.       The system SHOULD provide the ability to document an assent for patients legally unable to consent.

9.       The system SHALL provide the ability to document the source of each consent, such as the patient or the patient’s personal representative if the patient is legally unable to provide it.

10.    The system SHOULD provide the ability to document the patient’s personal representative’s level of authority to make decisions on behalf of the patient.

1.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHALL provide the ability to capture true allergy, intolerance, and adverse reaction to drug, dietary or environmental triggers as unique, discrete entries.

2.       The system SHOULD provide the ability to capture the reason for entry of the allergy, intolerance or adverse reaction.

3.       The system SHALL provide the ability to capture the reaction type.

4.       The system SHOULD provide the ability to capture the severity of a reaction.

5.       The system SHALL provide the ability to capture a report of No Known Allergies (NKA) for the patient.

6.       The system SHOULD provide the ability to capture a report of No Known Drug Allergies (NKDA) for the patient.

1

1

1

1

1

1

1

1

7.       The system SHOULD provide the ability to capture the source of allergy, intolerance, and adverse reaction information.

8.       The system SHALL provide the ability to deactivate an item on the list.

9.       The system SHALL provide the ability to capture the reason for deactivation of an item on the list.

10.    The system MAY present allergies, intolerances and adverse reactions that have been deactivated.

11.    The system MAY provide the ability to display user defined sort order of list.

12.    The system SHOULD provide the ability to indicate that the list of medications and other agents has been reviewed.

13.    They system SHALL provide the ability to capture and display the date on which allergy information was entered.

14.    The system SHOULD provide the ability to capture and display the approximate date of the allergy occurrence.

1.       The system SHALL provide the ability to capture patient-specific medication lists.

2.       The system SHALL display and report patient-specific medication lists.

3.       The system SHALL provide the ability to capture the details of the medication such as ordering date, dose, route, and SIG (description of the prescription, such as the quantity) when known.

4.       The system SHOULD provide the ability to capture other dates associated with medications such as start and end dates.

5.       The system SHALL provide the ability to capture medications not reported on existing medication lists or medication histories.

6.       The system SHALL provide the ability to capture non-prescription medications including over the counter and complementary medications such as vitamins, herbs and supplements.

7.       The system SHALL present the current medication lists associated with a patient.

8.       The system SHOULD present the medication history associated with a patient.

9.       The system SHALL present the medication, prescriber, and medication ordering dates when known.

10.    The system SHALL provide the ability to mark a medication as erroneously captured and excluded from the presentation of current medications.

11.    The system SHALL provide the ability to print a current medication list for patient use.

12.    The system MAY provide the ability to capture information regarding the filling of prescriptions (dispensation of medications by pharmacies or other providers).

1.       The system SHALL capture, display and report all active problems associated with a patient.

2.       The system SHALL capture, display and report a history of all problems associated with a patient.

3.       The system SHALL provide the ability to capture onset date of problem.

4.       The system SHOULD provide the ability to capture the chronicity (chronic, acute/self-limiting, etc.) of a problem.

5.       The system SHALL provide the ability to capture the source, date and time of all updates to the problem list.

6.       The system SHALL provide the ability to deactivate a problem.

7.       The system MAY provide the ability to re-activate a previously deactivated problem.

8.       The system SHOULD provide the ability to display inactive and/or resolved problems.

9.       The system SHOULD provide the ability to manually order/sort the problem list.

10.    The system MAY provide the ability to associate encounters, orders, medications, notes with one or more problems.

1.       The system SHALL capture, display and report all immunizations associated with a patient

2.       The system SHALL record as discrete data elements data associated with any immunization given including date, type, lot number and manufacturer

3.       The system SHOULD prepare a report of a patient ‘s immunization history upon request for appropriate authorities such as schools or day-care centers

1

1

1.       The system SHALL provide the ability to create assessments.

2.       The system SHOULD provide the ability to use standardized assessments where they exist.

3.       The system SHOULD provide the ability to document using standard assessments germane to the age, gender, developmental state, and health condition as appropriate to the EHR user’s scope of practice.

4.       The system SHOULD provide the ability to capture data relevant to standard assessment.

5.       The system SHOULD provide the ability to capture additional data to augment the standard assessments relative to variances in medical conditions.

6.       The system SHOULD provide the ability to link data from a standard assessment to a problem list.

7.       The system SHOULD provide the ability to link data from a standard assessment to an individual care plan.

8.       The system MAY provide the ability to link data from external sources, laboratory results, and radiographic results to the standard assessment.

9.       The system SHOULD provide the ability to compare documented data against standardized curves and display trends.

10.    The system SHOULD conform to function IN.1.4 (Patient Access Management).

11.    The system SHALL conform to function IN.2.2 (Auditable Records).

1

1

1

1

1.       The system SHALL provide the ability to present current guidelines and protocols to clinicians who are creating plans for treatment and care.

2.       The system SHOULD provide the ability to search for a guideline or protocol based on appropriate criteria (such as problem).

3.       The system SHOULD provide the ability to present previously used guidelines and protocols for historical or legal purposes.

4.       IF decision support prompts are used to support a specific clinical guideline or protocol, THEN the system SHALL conform to function DC.1.8.6 (Manage Documentation of Clinician Response to Decision Support Prompts).

5.       The system SHALL conform to function DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols).

6.       The system SHOULD conform to function IN.2.2 (Auditable Records).

1.       The system SHALL provide the ability to capture patient-specific plans of care and treatment.

2.       The system SHALL conform to DC.1.6.1 (Present Guidelines and Protocols for Planning Care) and provide the ability to use locally or non-locally developed templates, guidelines, and protocols for the creation of patient-specific plans of care and

3.       The system SHALL provide the ability to use previously developed care plans as a basis for the creation of new plans of care and treatment.

1

1

1

1

1

4.       The system SHALL provide the ability to track updates to a patient’s plan of care and treatment including authors, creation date, version history, references, local sources and non-local sources in accordance with scope of practice, organizational policy and jurisdictional law.

5.       The system SHOULD provide the ability to coordinate order sets with care plans.

6.       The system SHOULD provide the ability to derive order sets from care plans.

7.       The system SHOULD provide the ability to derive care plans from order sets.

8.       The system SHALL provide the ability to transfer plans of care and treatment to other care providers.

9.       The system SHOULD conform to function DC.3.1.1 (Clinical Task Assignment and Routing) and incorporate care plan items in the tasks assigned and routed.

10.    The system SHOULD conform to function DC.3.1.2 (Clinical Task Linking) and incorporate care plan items in the tasks linked.

11.    The system SHOULD conform to function DC.3.1.3 (Clinical Task Tracking) and incorporate care plan items in the tasks tracked.

12.    The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHALL conform to function IN.2.2 (Auditable Records).

1

1

1.       The system SHALL provide the ability to create prescription or other medication orders with the details adequate for correct filling and administration captured as discrete data.

2.       The system SHALL capture user and date stamp for all prescription related events.

3.       The system SHALL conform to function DC.1.4.2 (Manage Medication List) and update the appropriate medication list with the prescribed medications (in case of multiple medication lists).

4.       The system SHALL provide a list of medications to search, including both generic and brand name.

5.       The system SHALL provide the ability to maintain a discrete list of orderable medications.

6.       The system SHALL conform to function DC.1.7.2.1 (Manage Non-Medication Patient Care Orders) and provide the ability to order supplies associated with medication orders in accordance with scope of practice, organizational policy or jurisdictional

7.       The system MAY make common content available for prescription details to be selected by the ordering clinician.

8.       The system MAY provide the ability for the ordering clinician to create prescription details as needed.

9.       The system MAY make available common patient medication instruction content to be selected by the ordering clinician.

10.    The system MAY provide the ability to include prescriptions in order sets.

11.    The system MAY provide a list of frequently-ordered medications by diagnosis by provider which could include the full details of the medication, including SIG, quantity, refills, DAW, etc.

12.    The system MAY provide the ability to select drugs by therapeutic class and/or indication.

1

1

1

1

13.    The system MAY conform to function S.3.3.2 (Eligibility Verification and Determination of Coverage) and display the results of electronic prescription eligibility and health plan/payer formulary checking.

14.    The system MAY provide the ability to re-prescribe medication by allowing a prior prescription to be reordered without re-entering previous data (e.g. administration schedule, quantity).

15.    The system SHOULD provide the ability to re-prescribe a medication from a prior prescription using the same dosage but allow for editing of details adequate for correct filling and administration of medication (e.g. dose, frequency, body weight).

16.    The system SHOULD conform to function DC.2.3.1.1 (Support for Drug Interaction Checking) and check and report allergies, drug-drug interactions, and other potential adverse reactions, when new medications are ordered.

17.    The system SHOULD conform to function DC.2.3.1.2 (Support for Patient Specific Dosing and Warnings) and check and report other potential adverse reactions, when new medications are ordered.

18.    The system SHOULD provide the ability to create prescriptions in which the weight-specific dose is suggested.

19.    The system SHOULD conform to function DC.2.3.1.3 (Support for Medication Recommendations).

1

1

1.       The system SHALL provide the ability to capture non-medication patient care orders for an action or item

2.       The system SHALL provide the ability to capture adequate order detail for correct order fulfillment

3.       The system SHALL track the status of the ordered action or item

4.       The system SHOULD provide the ability to capture patient instructions necessary for correct order fulfillment

5.       The system SHOULD provide the ability to present patient instructions necessary for correct order fulfillment

6.       The system SHOULD provide the ability to communicate the order to the correct recipient(s) for order fulfillment

7.       The system SHALL conform to DC.2.4.2 (Support for Non-Medication Ordering)

1.       The system SHALL provide the ability to capture orders for diagnostic tests.

2.       The system SHALL provide the ability to capture adequate order detail for correct diagnostic test fulfillment.

3.       The system SHALL provide the ability to track the status of diagnostic test(s).

4.       The system SHOULD provide the ability to capture and present patient instructions relevant to the diagnostic test ordered.

5.       The system SHALL communicate orders to the service provider of the diagnostic test.

6.       The system SHOULD communicate supporting detailed documentation to the correct service provider of the diagnostic test.

7.       The system SHALL conform to DC.2.4.2 (Support for Non-Medication Ordering).

1

1.       The system SHALL provide the ability to interface with systems of blood banks or other sources to manage orders for blood products or other biologics.

2.       The system SHALL provide the ability to capture use of such products in the provision of care.

3.       The system SHOULD conform to function S.1.1 (Registry Notification).

1.       The system SHALL provide the ability to capture and communicate referral(s) to other care provider (s), whether internal or external to the organization.

2.       The system SHALL provide the ability to capture clinical details as necessary for the referral.

3.       The system SHALL provide the ability to capture administrative details (such as insurance information, consents and authorizations for disclosure) as necessary for the referral.

4.       The system SHALL present captured referral information.

5.       The system SHOULD provide the ability to capture completion of a referral appointment.

1

1

6.       The system SHOULD provide diagnosis based clinical guidelines for making a referral.

7.       The system MAY provide order sets for referral preparation.

8.       The system SHALL provide the ability to document transfer of care according to organizational policy, scope of practice, and jurisdictional law.

1.       The system SHALL provide the ability to present order set(s).

2.       The system SHALL provide the ability to order at the patient level from presented order sets.

3.       The system SHALL provide the ability to record each component of an order set that is ordered.

4.       The system SHALL conform to function DC.2.4.1 (Support for Order Sets).

5.       The system MAY provide the ability for a provider to choose from among the order sets pertinent to a certain disease or other criteria.

1.       The system SHALL conform to function IN.2.2 (Auditable Records)

1

1

1

1

1.       The system SHALL present the list of medications to be administered.

2.       The system SHALL display the timing, route of administration, and dose of all medications on the list.

3.       The system SHOULD display instructions for administration of all medications on the list.

4.       The system MAY notify the clinician when specific doses are due.

5.       The system MAY conform to function DC.2.3.1.1 (Support for Drug Interaction Checking) and check and report allergies, drug-drug interactions, and other potential adverse reactions, when new medications are about to be given.

6.       The system MAY conform to function DC.2.3.1.2 (Support for Patient Specific Dosing and Warnings) and check and report other potential adverse reactions, when new medications are about to be given.

7.       The system SHALL provide the ability to capture medication administration details – including timestamps, observations, complications, and reason if medication was not given – in accordance with organizational policy, scope of practice, and jurisdictional law.

8.       The system SHALL securely relate interventions to be administered to the unique identity of the patient.

1

1

1

1

1

1

1

1

1

1 1

1

1

1.       The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules.

2.       The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.

3.       The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.

4.       The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer.

5.       The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).

6.       The system SHALL record as discrete data elements data associated with any immunization.

7.       The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization.

8.       The system SHALL provide the ability to update the immunization schedule.

9.       The system SHOULD provide the ability to prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.

10.    The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists).

11.    The system SHOULD transmit required immunization information to a public health immunization registry.

12.    The system SHOULD receive immunization histories from a public health immunization registry.

1.       The system SHALL provide the ability to present numerical and non-numerical current and historical test results to the appropriate provider.

2.       The system SHALL provide the ability to filter results for a unique patient.

3.       The system SHALL provide the ability to filter results by factors that supports results management, such as type of test and date range.

4.       The system SHOULD indicate normal and abnormal results depending on the data source.

5.       The system SHOULD provide the ability to filter lab results by range, e.g. critical, abnormal or normal.

6.       The system SHOULD display numerical results in flow sheets, graphical form, and allow comparison of results.

7.       The system SHALL provide the ability to group tests done on the same day.

8.       The system SHOULD notify relevant providers (ordering, copy to) that new results have been received.

9.       The system SHOULD provide the ability for the user, to whom a result is presented, to acknowledge the result.

10.    The system SHOULD provide the ability to route results to other appropriate care providers, such as nursing home, consulting physicians, etc.

11.    The system MAY route results to patients by methods such as phone, fax, electronically or letter.

12.    The system SHOULD provide the ability for providers to pass on the responsibility to perform follow up actions to other providers.

13.    The system MAY provide the ability for an authorized user to group results into clinically logical sections.

14.    The system SHOULD trigger decision support algorithms from the results.

15.    IF the system contains the electronic order, THEN the results SHALL be linked to a specific order.

16.    The system MAY provide the ability for providers to annotate a result.

17.    The system MAY display a link to an image associated with results.

1.       IF required by the scope practice, THEN the system SHALL capture patient vital signs such as blood pressure, temperature, heart rate, respiratory rate, and severity of pain as discrete elements of structured or unstructured data.

2.       IF required by the scope of practice, THEN the system SHALL capture psychiatric symptoms and daily functioning as structured or unstructured data.

3.       The system SHOULD capture other clinical measures such as peak expiratory flow rate, size of lesions, oxygen saturation, height, weight, and body mass index as discrete elements of structured or unstructured data.

4.       The system SHOULD compute and display percentile values when data with normative distributions are entered.

5.       The system MAY provide normal ranges for data based on age and other parameters such as height, weight, ethnic background, gestational age.

1.       The system SHALL provide the ability to capture clinical documentation (henceforth "documentation") including original, update by amendment in order to correct, and addenda.

1

2.       The system SHALL provide the ability to capture free text documentation.

3.       The system MAY present documentation templates (structured or free text) to facilitate creating documentation.

4.       The system SHALL provide the ability to view other documentation within the patient's logical record while creating documentation.

5.       The system SHOULD provide the ability to associate documentation for a specific patient with a given event, such as an office visit, phone communication, e-mail consult, lab result, etc.

6.       The system SHOULD provide the ability to associate documentation with problems and/or diagnoses.

7.       The system SHALL provide the ability to update documentation prior to finalizing it.

8.       The system SHALL provide the ability to finalize a document or note.

9.       The system SHALL provide the ability to attribute record and display the identity of all users contributing to or finalizing a document or note, including the date and time of entry (see appropriate criteria in IN.2.2 (Auditable Records)).

10.    The system SHALL present captured documentation.11.    The system MAY provide the ability to filter, search or sort notes.

12.    The system SHOULD provide documentation templates for data exchange.

1.       The system SHALL provide the ability to capture clinical decision support prompts and user decisions to accept or override those prompts.

2.       The system SHALL provide the ability to record the reason for variation from the decision support prompt.

1

1

1

1

1

3.       The system SHOULD provide the ability to display recorded variances upon request by authorized users of the EHR.

1.       The system SHALL provide the ability to generate instructions pertinent to the patient for standardized procedures.

2.       The system SHALL provide the ability to generate instructions pertinent to the patient based on clinical judgment.

3.       The system SHALL provide the ability to include details on further care such as follow up, return visits and appropriate timing of further care.

4.       The system SHALL provide the ability to record that instructions were given to the patient.

5.       The system SHALL provide the ability to record the actual instructions given to the patient or reference the document(s) containing those instructions.

6.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL conform to function IN.1.3 (Entity Access Control).

4.       IF the system is used to enter, modify or exchange data, THEN the system SHALL conform to function IN.1.5 (Non-Repudiation), to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

1

1

1

1

1

1

1

1

1

1

1

5.       IF the system exchanges data outside of a secure network, THEN the system SHALL conform to function IN.1.6 (Secure Data Exchange), to ensure that the data are protected.

6.       IF the system exchanges outside of a secure network, THEN the system SHALL conform to function IN.1.7 (Secure Data Routing), to ensure that the exchange occurs only among authorized senders and receivers.

7.       IF the system is used to enter or modify data in the health record, THEN the system SHALL conform to function IN.1.8 (Information Attestation), to show authorship and responsibility for the data.

8.       The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction).

9.       The system SHOULD conform to function IN.2.3 (Synchronization).

10.    IF the system is used to extract data for analysis and reporting, THEN the system SHALL conform to function IN.2.4 (Extraction of Health Record Information), to support data extraction across the complete health record of an individual.

11.    IF the system stores unstructured data, THEN the system SHALL conform to function IN.2.5.1 (Manage Unstructured Health Record Information), to ensure data integrity through all changes.

12.    IF the system stores structured data, THEN the system SHALL conform to function IN.2.5.2 (Manage Structured Health Record Information), to ensure data integrity through all changes.

13.    IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.1 (Standard Terminologies and Terminology Models), to support semantic interoperability.

14.    IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.2 (Maintenance and Versioning of Standard Terminologies), to preserve the semantics of coded data

15.    The system SHOULD conform to function IN.4.3 (Terminology Mapping).

1

1

1

1

1

1

1

1

1

1

16.    IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.1 (Interchange Standards), to support interoperability.

17.    IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.2 (Interchange Standards Versioning and Maintenance), to accommodate the inevitable evolution of i

18.    The system SHOULD conform to function IN.5.3 (Standards-based Application Integration).

19.    IF the system exchanges data with other systems outside itself, THEN the system SHALL conform to function IN.5.4 (Interchange Agreements), to define how the sender and receiver will exchange data.

20.    The system SHOULD conform to function IN.6 (Business Rules Management).

21.    The system SHOULD conform to function IN.7 (Workflow Management).

1.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

2.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

3.       The system SHALL conform to function IN.2.2 (Auditable Records).

4.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to access the standard assessment in the patient record.

1

1

2.       The system SHALL provide the ability to access to health standards and practices appropriate to the EHR user’s scope of practice.

3.       The system SHOULD provide the ability to compare elements of assessments captured by the clinician and those available as best practices and/or evidence based resources.

4.       The system MAY provide the ability to derive supplemental assessment data from evidence based standard assessments, practice standards, or other generally accepted, verifiable, and regularly updated standard clinical sources.

5.       The system SHOULD provide prompts based on practice standards to recommend additional assessment functions.

6.       The system SHOULD conform to function DC.1.4.3 (Manage Problem List) and provide the ability to update the problem list by activating new problems and de-activating old problems as identified by conduct of standard assessments.

7.       The system SHOULD provide the ability to create standard assessments that correspond to the problem list.

8.       The system SHOULD conform to function DC 2.1.2 (Support for Patient Context-driven Assessments).

1.       The system SHALL provide the ability to access health assessment data in the patient record

2.       The system SHOULD provide the ability to compare assessment data entered during the encounter and the accessed health evidence based standards and best practices

1

1

1

1

3.       The system SHOULD provide the ability to compare health data and patient context-driven assessments to practice standards in order to prompt additional testing, possible diagnoses, or adjunctive treatment

4.       The system SHOULD provide the ability to correlate assessment data and the data in the patient specific problem list

5.       The system SHALL conform to function DC 2.1.1 (Support for Standard Assessments)

6.       The system SHALL conform to function DC.1.5 (Manage Assessments)

7.       The system SHOULD conform to function DC.1.4.3 (Manage Problem List)

1.       The system SHALL conform to function DC.1.5 (Manage Assessments) and provide the ability to access standard assessment data in the patient record.

2.       The system SHOULD provide the ability to access health standards and practices appropriate to the EHR user’s scope of practice at the time of the encounter.

3.       The system SHOULD provide the ability to compare patient context-driven assessments and additional health information to best practices in order to identify patient specific growth or development patterns, health trends and potential health problems.

4.       The system SHOULD provide the ability to configure rules defining abnormal trends.

5.       The system SHOULD prompt the provider with abnormal trends.

1

1

1

6.       The system SHOULD prompt the provider for additional assessments, testing or adjunctive treatment.

7.       The system SHOULD conform to function DC.1.8.6 (Manage Documentation of Clinician Response to Decision Support Prompts).

8.       The system MAY provide the ability to integrate health information contained in the record with appropriate teaching materials.

9.       The system SHOULD conform to function DC 2.2.1.2 (Support for Context-sensitive Care Plans, Guidelines, Protocols).

1.       The system SHALL conform to DC.1.3.1 (Manage Patient and Family Preferences).

2.       The system SHALL provide for the ability to capture and manage patient and family preferences as they pertain to current treatment plans.

3.       The system SHALL provide the ability to update care guidelines and options relating to documented patient and family preferences, including standards of practice e.g. treatment options for individuals who refuse blood transfusions.

4.       The system SHOULD provide the ability to compare care guidelines and options relating to documented patient and family preferences, including standards of practice.

5.       The system SHOULD prompt the provider for testing and treatment options based on patient and family preferences and provide the ability to compare to standard practice.

6.       The system MAY provide the ability to integrate preferences with appropriate teaching materials.

1

1

1

1

1

7.       The system SHOULD provide the ability to integrate necessary documentation of preferences, such as living wills, specific consents or releases.

8.       The system SHALL conform to function DC.1.3.2 (Manage Patient Advance Directives).

1.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

2.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL conform to function DC.1.6.1 (Present Guidelines and Protocols for Planning Care) and provide the ability to access standard care plans, protocols and guidelines when requested within the context of a clinical encounter.

2.       The system MAY provide the ability to create and use site-specific care plans, protocols, and guidelines.

3.       The system MAY provide the ability to make site-specific modifications to standard care plans, protocols, and guidelines obtained from outside sources.

1

1

1

1

1

4.       The system SHOULD identify, track and provide alerts, notifications and reports about variances from standard care plans, guidelines and protocols.

5.       The system SHALL conform to DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols).

6.       The system SHALL conform to DC.2.1.1 (Support for Standard Assessments).

1.       The system SHALL provide the ability to access care and treatment plans that are sensitive to the context of patient data and assessments.

2.       The system MAY provide the ability to capture care processes across the continuum of care.

3.       The system MAY present care processes from across the continuum of care.

4.       The system MAY provide the ability to document the choice of action in response to care plan suggestions.

5.       The system SHOULD identify, track and provide alerts, notifications and reports about variances from standard care plans, guidelines and protocols.

6.       The system SHALL conform to function DC.2.2.1.1 (Support for Standard Care Plans, Guidelines, Protocols).

7.       The system SHALL conform to function DC.2.1.1 (Support for Standard Assessments).

8.       The system SHALL conform to function DC.2.1.2 (Support for Patient Context-Driven Assessments).

1

1

1

1.       The system SHALL conform to DC.2.2.1.2 (Support for Context-Sensitive Care Plans, Guidelines, Protocols).

2.       The system SHALL provide the ability to identify patients eligible for healthcare management protocols based on criteria identified within the protocol.

3.       The system SHOULD provide the ability to include or exclude a patient from an existing healthcare management protocol group.

4.       The system SHOULD provide the ability to audit compliance of selected populations and groups that are the subjects of healthcare management protocols.

5.       The system SHALL conform to function S.2.2.2 (Standard Report Generation).

6.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1

1

1

1

1

1

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

2.       The system SHALL provide the ability to maintain research study protocols.

3.       The system SHOULD conform to function S.3.3.1 (Enrollment of Patients), to enable participation in research studies.

4.       The system SHOULD provide the ability to identify and track patients participating in research studies.

5.       The system MAY provide the ability to capture appropriate details of patient condition and response to treatment as required for patients enrolled in research studies.

6.       The system SHALL conform to function S.2.2.2 (Standard Report Generation).

7.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

8.       IF research protocols require standardized transmission of data to/from a registry or directory, THEN the system SHALL conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to present patient guidance and reminders appropriate for self-management of clinical conditions.

2.       The system SHALL provide the ability to manage and/or develop patient guidance and reminders related to specific clinical conditions.

3.       The system SHOULD conform to function DC.1.1.3.2 (Capture of Patient Originated Data).

4.       The system SHOULD conform to function DC.1.3.1 (Manage Patient and Family Preferences).

1

1

1

1

1

1

1

1

1

1

1

1

5.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

6.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

3.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL check for and alert providers to interactions between prescribed drugs and medications on the current medication list.

2.       The system SHALL relate medication allergies to medications to facilitate allergy checking decision support for medication orders.

3.       The system SHOULD provide the ability to document that a provider was presented with and acknowledged a drug interaction warning.

4.       The system SHALL provide the ability to prescribe a medication despite alerts for interactions and/or allergies being present.

1

1

1 1

1

1

1

1

5.       The system MAY provide the ability to set the severity level at which warnings should be displayed.

6.       The system SHOULD provide the ability to check for duplicate therapies.

7.       The system SHOULD conform to DC.1.8.6 (Manage Documentation of Clinician Response to Decision Support Prompts) and provide the ability to document why a drug interaction warning was overridden.

8.       The system MAY check for interactions between prescribed drugs and food detailing changes in a drug's effects potentially caused by food (including beverages) consumed during the same time period.

9.       The system SHOULD check for drug-lab interactions, to indicate to the prescriber that certain lab test results may be impacted by a patient’s drugs.

10.    The system SHOULD provide the ability to check medications against a list of drugs noted to be ineffective for the patient in the past.

11.    The system SHOULD identify contraindications between a drug and patient conditions at the time of medication ordering.

1.       The system SHALL provide the ability to identify an appropriate drug dosage range, specific for each known patient condition and parameter at the time of medication ordering.

2.       The system SHALL provide the ability to automatically alert the provider if contraindications to the ordered dosage range are identified.

3.       The system SHALL provide the ability for the provider to override a drug dosage warning.

4.       The system SHOULD provide the ability to document reasons for overriding a drug alert or warning at the time of ordering.

1

1

1

5.       The system SHOULD transmit documented reasons for overriding a drug alert to the pharmacy to enable communication between the clinician and the pharmacist.

6.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

7.       IF the maximum daily doses are known, THEN the system SHALL apply the maximum dose per day in dosing decision support.

8.       The system SHOULD compute drug doses, based on appropriate dosage ranges, using the patient’s body weight.

9.       The system SHOULD provide the ability to specify an alternative “dosing weight” for the purposes of dose calculation.

10.    The system SHOULD perform drug dosage functions using any component of a combination drug (e.g., acetaminophen-hydrocodone).

11.    The system SHOULD provide the ability to record the factors used to calculate the future dose for a given prescription.

1.       The system SHOULD conform to function DC 2.3.1.2 (Support for Patient-Specific Dosing and Warnings).

2.       The system SHOULD present recommendations for medication regimens based on findings related to the patient diagnosis.

3.       The system SHALL present alternative treatments in medications on the basis of practice standards, cost, formularies, or protocols.

4.       The system SHOULD present suggested lab monitoring as appropriate to a particular medication.

5.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

1

1.       The system SHALL present information necessary to correctly identify the patient and accurately administer medications and immunizations such as patient name, medication name, strength, dose, route and frequency.

2.       The system SHALL 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 immunizations administration.

3.       The system SHOULD alert providers to potential medication administration errors at the point of medication administration.

4.       The system SHALL provide the ability to capture all pertinent details of the medication administration including medication name, strength, dose, route, time of administration, exceptions to administration, and administrator of the medication.

5.       IF required by the EHR user’s scope of practice, THEN the system SHALL capture the administrator of the immunization and the immunization information identified in DC.1.8.2 (Manage Immunization Administration), Conformance Criteria #4 (The system

6.       The system MAY generate documentation of medication or immunization administration as a by-product of verification of patient, medication, dose, route and time.

7.       The system SHOULD prompt or remind providers regarding the date/time range for timely administration of medications.

1

1

1

1

8.       The system MAY suggest alternative administration techniques based on age, developmental stage, weight, physiological status, mental status, educational level, and past physical history of the patient.

9.       The system MAY conform to function DC.2.7.1 (Access Healthcare Guidance) and provide to the ability for a provider to access drug monograph information.

1.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

3.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to create order set templates.

2.       The system SHALL provide the ability to maintain order set templates, including version control.

3.       The system MAY provide the ability to create order set templates from provider input.

4.       The system MAY capture order sets based on patient data that may be provided by the provider or that may be in accordance with preferred standards.

5.       The system MAY provide the ability to create order set templates for known conditions for a particular disease.

6.       The system SHALL present the order set templates to the provider.

7.       The system MAY record the basis of the practice standards or criteria for the creation of the order set templates.

1

1

8.       The system MAY provide the ability to relate order set templates to aid decision support for certain diseases.

9.       The system SHALL conform to DC.1.7.3 (Manage Order Sets).

1.       The system SHALL identify required order entry components for non-medication orders.

2.       The system SHALL present an alert at the time of order entry, if a non-medication order is missing required information.

3.       The system SHOULD present an alert via warnings of orders that may be inappropriate or contraindicated for specific patients at the time of provider order entry.

4.       The system SHOULD conform to function S.3.3.3. (Service Authorizations).

1.       The system SHALL present alerts for a result that is outside of a normal value range.

1

2.       The system SHOULD provide the ability to trend results.

3.       The system MAY provide the ability to evaluate pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam).

1.       The system SHALL provide the ability to include clinical and administrative data (e.g. insurance information) as part of the referral process.

2.       The system SHALL provide the ability to include test and procedure results with a referral.

3.       The system MAY provide the ability to include standardized or evidence based protocols with the referral.

4.       The system SHOULD allow clinical, administrative data, and test and procedure results to be transmitted to the referral clinician.

5.       The system SHALL conform to function S.2.2.1 (Health Record Output).

1.       The system SHALL present recommendations for potential referrals based on diagnosis(es).

2.       The system SHALL present recommendations for potential referrals based on patient condition (e.g. for smoking cessation counseling if the patient is prescribed a medication to support cessation).

1

1

1

3.       The system SHOULD conform to IN.1.4 (Patient Access Management).

1.       The system SHALL present information necessary to correctly identify the patient and accurately administer blood products including patient name, blood product number, amount, route, product expiration date and time of administration.

2.       The system SHALL capture validation of the correct matching of the patient to the blood product.

3.       The system SHALL capture the blood product number, amount, route and time of administration.

4.       The system SHALL conform to function DC.1.8.4 (Manage Patient Clinical Measurements) and capture the blood pressure, temperature, pulse, respirations of the patient receiving the product.

5.       The system SHALL conform to function S.2.2.1 (Health Record Output).

1.       The system SHALL provide the ability to present information necessary to correctly identify the patient and accurately identify the specimen to be collected including, but not limited to, patient name, specimen type, specimen source, means of collection, date and time.

2.       The system SHALL report variation between the type of specimen order placed and actual specimen received.

1

1

1

1

1

3.       The system SHALL capture the details of specimen collection.

4.       The system SHALL conform to function S.2.2.1 (Health Record Output).

5.       The system SHOULD notify the provider in real-time of a variation between the type of specimen order placed and the actual specimen received.

1.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

2.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

3.       The system SHALL conform to function IN.2.2 (Auditable Records).

4.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to establish criteria for the identification of preventive care and wellness services based on patient demographics (e.g. age, gender).

2.       The system SHOULD provide the ability to modify the established criteria that trigger the alerts.

3.       The system SHOULD present recommended preventative or wellness services needed based upon clinical test results.

4.       The system SHALL present alerts to the provider of all patient specific preventive services that are due.

5.       The system MAY provide the ability to produce a list of all alerts along with the scheduled date and time for the preventive service.

1

1

6.       The system MAY provide the ability to produce a history of all alerts that were generated for the patient in the record.

1.       The system SHOULD generate timely notifications to patients including services, tests or actions that are due or overdue.

2.       The system SHOULD capture a history of notifications.

3.       The system SHOULD provide the ability to track overdue preventive services.

4.       The system SHOULD provide notification of overdue preventative services in the patient record.

5.       The system MAY provide the ability to configure patient notifications (such as repetitions or timing of the activity).

6.       The system SHOULD provide the ability to update content of notifications, guidelines, reminders and associated reference materials.

7.       The system MAY provide the ability to manage the lifecycle of the states of the notifications and reminders.

1.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

2.       The system SHALL conform to function IN.2.2 (Auditable Records).

1

1.       The system SHALL provide the ability to aggregate patient information based on user-identified criteria.

2.       The system SHALL apply local privacy and confidentially rules when assembling aggregate data to prevent identification of individuals by unauthorized parties.

3.       The system SHOULD provide the ability to use any demographic or clinical information as criteria for aggregation.

4.       The system SHOULD present aggregate data in the form of reports for external use.

5.       The system SHOULD provide the ability to save report definitions for later use.

6.       The system MAY present aggregate data in an electronic format for use by other analytical programs.

7.       The system MAY provide the ability to derive statistical information from aggregate data.

8.       IF biosurveillance or other epidemiological investigations require standardized transmission of data to/from a registry or directory, THEN the system SHALL conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to identify individual care providers or care managers within a cared for population.

2.       The system SHALL provide the ability to prepare a response notification to the care providers or care managers.

3.       The system SHALL provide the ability to capture notification of a health risk within a cared-for population from public health authorities or other external authoritative sources as either free-text or a structured message.

4.       The system SHOULD provide the ability to coordinate with local and national programs to disseminate notifications of health risk to individual care providers or care-managers.

5.       The system MAY provide the ability to notify patients, directly or indirectly, who are described by the health risk alert.

6.       The system SHOULD present suggestions to the care provider indicating an appropriate course of action.

7.       The system SHALL provide the ability to notify public health authorities or other external authoritative sources of a health risk within a cared for population in accordance with scope of practice, organizational policy and jurisdictional law.

1

1

1

1

8.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL present specific actions to be taken at the patient level for a health risk alert.

2.       The system SHALL notify appropriate care providers of specific patient actions required by a health risk alert.

3.       The system SHALL provide the ability to identify those patients who have not received appropriate action in response to a health risk alert.

4.       The system SHOULD provide the ability to report on the omission of an appropriate response to the health risk alert in specific patients.

5.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

6.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHOULD conform to function IN.3 (Registry and Directory Services)

1

1

1.       The system SHALL provide the ability to access evidence-based healthcare recommendations, with documentation of sources

2.       The system SHOULD provide the ability to access evidenced-based documentation appropriate for the care provider to render a timely judgment.

3.       The system MAY provide the ability to access external evidence-based documentation.

4.       The system SHALL conform to function DC.2.2.1.1 (Support for Standard Care Plans, Guidelines, Protocols).

5.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

1.       The system SHALL provide the ability to access information about wellness, disease management, treatments, and related information that is relevant for a specific patient.

2.       The system MAY provide the ability to access information related to a health question directly from data in the health record or other means such as key word search.

1

1

1

1

1

1

1

1

1

1

1

1

1

3.       The system MAY provide the ability to access patient educational information from external sources.

4.       IF the information is external-based, THEN the system MAY provide the ability to identify links specific to the information.

5.       The system SHALL conform to function IN.1.4 (Patient Access Management).

6.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

7.       The system SHALL conform to function IN.2.2 (Auditable Records).

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL conform to function IN.1.3 (Entity Access Control).

4.       IF the system exchanges data across entity boundaries within an EHR-S or external to an EHR-S, THEN the system SHALL conform to function IN.1.6 (Secure Data Exchange) to ensure that the data are protected.

5.       IF the system exchanges data with other sources or destinations of data, THEN the system SHALL conform to function IN.1.7 (Secure Data Routing) to ensure that the exchange occurs only among authorized senders and ““receivers”.

6.       IF the system is used to enter or modify data in the health record, THEN the system SHALL conform to function IN.1.8 (Information Attestation) to show authorship and responsibility for the data.

7.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

8.       The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction).

9.       The system SHALL conform to function IN.2.2 (Auditable Records).

10.    The system SHOULD conform to function IN.2.3 (Synchronization).

1

1

1

1

1

1

1

1

1

1

1

11.    IF the system is used to extract data for analysis and reporting, THEN the system SHALL conform to function IN.2.4 (Extraction of Health Record Information) to support data extraction across the complete health record of an individual.

12.    IF the system stores unstructured data, THEN the system SHALL conform to function IN.2.5.1, (Manage Unstructured Health Record Information), to ensure data integrity through all changes.

13.    IF the system stores structured data, THEN the system SHALL conform to function IN.2.5.2 (Manage Structured Health Record Information) to ensure data integrity through all changes.

14.    IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.1 (Standard Terminologies and Terminology Models) to support semantic interoperability.

15.    IF the system processes data for which generally accepted standard terminologies have been established, THEN the system SHALL conform to function IN.4.2 (Maintenance and Versioning of Standard Terminologies) to preserve the semantics of coded data

16.    The system SHOULD conform to function IN.4.3 (Terminology Mapping).

17.    IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.1 (Interchange Standards) to support interoperability.

18.    IF the system exchanges data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function IN.5.2 (Interchange Standards Versioning and Maintenance) to accommodate the inevitable evolution of in

19.    The system SHOULD conform to function IN.5.3 (Standards-based Application Integration).

20.    IF the system exchanges data with other systems outside itself, THEN the system SHALL conform to function IN.5.4 (Interchange Agreements) to define how the sender and receiver will exchange data.

21.    The system SHOULD conform to function IN.6 (Business Rules Management).

122.    The system SHOULD conform to function IN.7 (Workflow Management).

1.       The system SHALL provide the ability for users to create manual clinical tasks.

2.       The system SHALL provide the ability to automate clinical task creation.

3.       The system SHALL provide the ability to manually modify and update task status (e.g. created, performed, held, canceled, pended, denied, and resolved).

1

4.       The system MAY provide the ability to automatically modify or update the status of tasks based on workflow rules.

5.       The system SHOULD provide the ability to assign, and change the assignment of, tasks to individuals or to clinical roles.

6.       The system MAY provide the ability to manage workflow task routing to multiple individuals or roles in succession and/or in parallel.

7.       The system MAY provide the ability to prioritize tasks based on urgency assigned to the task.

8.       The system MAY provide the ability to restrict task assignment based on appropriate role as defined by the entity.

9.       The system MAY provide the ability to escalate clinical tasks as appropriate to ensure timely completion.

10.    IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

11.    The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to link a clinical task to the component of the EHR required to complete the task.

2.       The system SHALL conform to function IN.1.5 (Non-Repudiation).

1

1

1

1.       The system SHALL provide the ability to track the status of tasks.

2.       The system SHALL provide the ability to notify providers of the status of tasks.

3.       The system SHOULD provide the ability to sort clinical tasks by status.

4.       The system MAY provide the ability to present current clinical tasks as work lists.

5.       The system SHOULD provide the ability to define the presentation of clinical task lists.

6.       IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

7.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHOULD conform to function IN.3 (Registry and Directory Services).

1.       The system SHALL provide the ability to document in the patient record verbal/telephone communication between providers.

2.       The system SHALL provide the ability to incorporate scanned documents from external providers into the patient record.

3.       The system MAY provide the ability to communicate using real-time messaging.

4.       The system SHOULD provide the ability to communicate clinical information (e.g. referrals) via email or other electronic means.

5.       The system MAY provide the ability to transmit electronic multi-media data types representing pictures, sound clips, or video as part of the patient record.

6.       The system SHALL conform to function IN.1.5 (Non-Repudiation).

1

1

1.       The system SHALL conform to function DC.1.7.1 (Manage Medication Orders) and provide the ability to order medications.

2.       The system SHALL electronically communicate orders between the prescriber, provider and pharmacy, as necessary, to initiate, change, or renew a medication order.

3.       The system SHALL receive any acknowledgements, prior authorizations, renewals, inquiries and fill notifications provided by the pharmacy or other participants in the electronic prescription and make it available for entry in the patient record.

4.       The system SHOULD provide the ability to electronically communicate current realm-specific standards to pharmacies.

5.       The system MAY provide the ability for providers and pharmacies to communicate clinical information via e-mail or other electronic means, on both general and specific orders.

6.       The system MAY provide the ability to use secure real-time messaging.

7.       The system MAY provide the ability to include workflow tasks as part of communication to the provider.

8.       IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

1

1.       The system SHALL provide the ability to capture documentation of communications between providers and patients and/ or the patient representatives.

2.       The system SHALL provide the ability to incorporate scanned documents.

3.       The system SHALL provide the ability to document communication originating with the patient or patient representative (e.g. date, entity, details of communication).

4.       The system SHOULD provide the ability to communicate between providers and patients or their representative using a secure internet connection.

5.       The system SHALL provide the ability to manage documentation regarding family member or patient representative authorizations to receive patient related health information.

6.       The system SHOULD alert providers to the presence of patient or patient representative originated communications.

7.       The system SHOULD provide the ability to alert patients or patient representative to provider absences (e.g. vacations) and recommend rerouting of the information or request.

8.       The system MAY provide the ability to notify providers of events and new treatment options.

9.       The system MAY provide the ability to remind the patient or patient representative of events related to their care (e.g. upcoming appointments) as agreed upon by the patient and/or the patient representative.

10.    The system SHALL conform to function IN.1.4 (Patient Access Management).

111.    IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

1.       The system SHALL provide the ability to access to a library of educational material for health concerns, conditions, and/or diagnosis.

2.       The system SHALL provide the ability to communicate applicable educational materials to the patient and/or patient representative.

3.       The system MAY provide the ability to deliver multilingual educational material.

4.       The systems MAY provide the ability to deliver patient educational materials using alternative modes to accommodate patient sensory capabilities.

5.       The system MAY provide the ability to access to external educational materials.

6.       The system MAY provide the ability to use rules-based support to identify the most pertinent educational material, based on the patient health status, condition and/or diagnosis.

7.       The system MAY provide the ability to document who received the educational material provided, the patient, or the patient representative.

1

1

1

1

1

1

8.       The system MAY provide the ability to document that the educational material was reviewed with the patient and/or patient representative and their comprehension of the material.

9.       The system MAY provide the ability to identify age-appropriate and/or reading-ability appropriate educational materials for the patient and/or patient representative.

10.    The system MAY provide the ability for direct access to the educational material available, by patients and/or patient representatives.

11.    The system SHALL conform to function IN.1.4 (Patient Access Management).

12.    IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Non-Repudiation) to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

1.       The system SHALL provide the ability to collect accurate electronic data from medical devices according to realm-specific applicable regulations and/or requirements.

2.       The system SHOULD provide the ability to present information collected from medical devices as part of the medical record as appropriate.

3.       The system SHOULD conform to function IN.1.4 (Patient Access Management).

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL conform to function IN.1.3 (Entity Access Control).

1.       The system SHOULD automatically transfer formatted demographic and clinical information to local disease specific registries (and other notifiable registries).

2.       The system MAY provide the ability to automate the retrieval of formatted demographic and clinical information from local disease specific registries (and other notifiable registries).

3.       The system SHOULD provide the ability to add, change, or remove access to registries.

1.       The system MAY provide the ability to document demographic and clinical information needed for the donation.

2.       The system MAY receive demographic and clinical information about potential donors.

3.       The system MAY receive demographic and clinical information about the donation.

4.       The system MAY share documented demographic and clinical information about potential donors with appropriate outside parties.

5.       The system MAY share documented demographic and clinical information about the donation with appropriate outside parties.

1.       The system SHOULD provide a registry or directory of all personnel who currently use or access the system.

2.       The system SHOULD contain, in the directory, the realm-specific legal identifiers required for care delivery such as the practitioner's license number

3.       The system SHOULD provide the ability to add, update, and inactivate entries in the directory so that it is current.

4.       The system SHOULD contain, in the directory, the information necessary to determine levels of access required by the system security functionality.

5.       The system MAY provide a directory of clinical personnel external to the organization that are not users of the system to facilitate documentation communication and information exchange.

1.       The system SHOULD provide the ability to input or create information on provider location or contact information on a facility's premises.

2.       The system SHOULD provide the ability to add, update, or inactivate information on provider's location or contact information on a facility's premises, so that it is current.

1.       The system SHOULD provide the ability to input or create information on provider location or contact information when on call.

1

1

2.       The system SHOULD provide the ability to add, update, or obsolete information on a provider's on call location or contact information, so that it is current.

1.       The system SHOULD contain information necessary to identify primary and secondary practice locations or offices of providers to support communication and access.

2.       The system SHOULD provide the ability to add, update and obsolete information on the provider's primary and secondary practice locations or offices.

1.       The system SHOULD provide the ability to access a current directory, registry or repository of Teams or Groups of providers in accordance with relevant laws, regulations, and organization or internal requirements.

2.       The system SHOULD conform to IN.3 (Registry and Directory Services), Conformance Criteria # 13 (The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource management purposes).

3.       The system SHOULD conform to S.3.4 (Manage Practitioner/Patient Relationships), Conformance Criteria #2 (The system SHALL provide the ability to specify the role of each provider associated with a patient such as encounter provider, primary care

1

1

1.       The system SHALL provide the ability to access a provider's caseload or panel information.

2.       The system SHALL provide the ability to add, update, and remove access to panel information such as status.

3.       The system SHOULD conform to function S.3.4 (Manage Practitioner/Patient Relationships).

1.       The system SHOULD conform to IN.3 (Registry and Directory Services), Conformance Criteria #7 (The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care).

2.       The system SHALL contain provider information (such as full name, specialty, address and contact information), in accordance with scope of practice, organizational policy and jurisdictional law.

3.       The system SHALL provide the ability to add, update, and remove access to entries in the registry or directory so that it is current.

4.       The system MAY provide a directory of clinical personnel external to the organization that are not users of the system to facilitate documentation.

5.       The systems SHOULD provide the ability to restrict the view of selected elements of the registry or directory information, subject to the user's security level and access needs.

1.       The system MAY add and update patient demographic information through interaction with other systems, applications and modules.

2.       The system MAY accept and retrieve patient demographic information as required by realm specific laws governing health care transactions and reporting.

1.       IF the patient has an assigned location, THEN the system SHALL provide the ability to identify and display/view the patient’s assigned location.

2.       The system SHOULD support consents as they apply to the release of patient location information according to scope of practice, organization policy, or jurisdictional laws.

3.       The system MAY provide the ability to identify the patient’s current, real-time location, unambiguously, within a facility.

4.       The system MAY provide the ability to query patient location information.

5.       The system MAY provide the ability to query patient location by alternate identifying names.

1.       The system SHOULD provide the ability to identify the patient’s primary residence.

2.       The system MAY provide the ability to identify the patient’s secondary or alternate residence.

3.       The system MAY provide the ability to enter and update patient information related to the provision of service.

4.       The system SHOULD provide the ability to enter and update patient information related to transport, such as, mobility status, special needs and facility access (stairs, elevator, wheelchair access).

5.       The system SHOULD provide the ability to enter and update patient residence information as necessary for public health reporting.

1.       The system SHOULD support interactions as required to support patient bed assignment internal or external to the system.

2.       The system MAY provide patient information to an external system to facilitate bed assignment that optimizes care and minimizes risk.

1

1

1.       The system SHALL conform to IN.1.9 (Patient Privacy and Confidentiality) and provide de-identified views of data in accordance with scope of practice, organizational policy and jurisdictional law.

2.       The system SHOULD conform to IN.2.4 (Extraction of Health Record Information), Conformance Criteria #3 (The system SHOULD provide the ability to de-identify extracted information).

1.       The system MAY provide the ability to access scheduling features, either internal or external to the system, for patient care resources.

2.       The system MAY provide the ability to access scheduling features, either internal or external to the system, for patient care devices.

3.       The system MAY incorporate relevant clinical or demographic information in the scheduling process.

4.       The system MAY pass relevant clinical or demographic information to support efficient scheduling with other system.

1

1

1.       The system MAY collect information on healthcare resource availability through interactions with other systems, applications, and modules.

2.       The system MAY provide the ability to access information on healthcare resource availability for internal assessment and planning purposes. Healthcare resources may include, but is not limited to available beds, providers, support personnel, ancillary care areas and devices, operating theaters, medical supplies, vaccines, and pharmaceuticals.

3.       The system MAY provide the ability to export information on healthcare resource availability to authorized external parties.

1.       The system MAY provide authorized administrators the ability to tailor the presentation of information for preferences of the user, department/area or user type.

2.       The system MAY provide authorized users the ability to tailor their presentation of information for their preferences.

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

1

1

1

1

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL conform to function IN.1.3 (Entity Access Control).

4.       The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality).

5.       The system SHALL conform to function IN.2.4 (Extraction of Health Record Information).

1.       The system SHOULD provide the ability to export or retrieve data required to evaluate patient outcomes.

2.       The system MAY provide data detailed by physician, facility, facility subsection, community or other selection criteria.

3.       The system SHOULD provide the ability to define outcome measures for specific patient diagnosis.

4.       The system SHOULD provide the ability to define outcome measures to meet various regional requirements.

5.       The system SHOULD provide for the acceptance and retrieval of unique outcome data defined to meet regional requirements.

6.       The system MAY provide the ability to define report formats for the export of data. This formatted data could be viewed, transmitted electronically or printed.

1

1

7.       The system MAY provide the ability to define prompts in the clinical care setting that would request information needed to comply with regional requirements when specific triggers are met.

8.       The system MAY export data or provide a limited query access to data through a secure data service.

1.       The system SHOULD provide the ability to export or retrieve data required to assess health care quality, performance and accountability.

2.       The system SHOULD provide the ability to define multiple data sets required for performance and accountability measures.

3.       The system MAY provide the data export in a report format that could be displayed, transmitted electronically or printed.

4.       The system MAY export data or provide a limited query access to data through a secure data service.

1.       The system SHALL conform to function IN.2.2 (Auditable Records) in accordance with scope of practice, organizational policy and jurisdictional law.

2.       The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction).

1.       The system SHALL provide the ability to generate reports consisting of all and part of an individual patient’s record.

2.       The system SHOULD provide the ability to define the records or reports that are considered the formal health record for disclosure purposes.

3.       The system SHOULD provide the ability to generate reports in both chronological and specified record elements order.

4.       The system SHOULD provide the ability to create hardcopy and electronic report summary information (procedures, medications, labs, immunizations, allergies, vital signs).

5.       The system MAY provide the ability to specify or define reporting groups (i.e. print sets) for specific types of disclosure or information sharing.

6.       The system SHOULD provide the ability to include patient identifying information on each page of reports generated.

7.       The system SHOULD provide the ability to customize reports to match mandated formats.

1.       The system SHOULD provide the ability to generate reports of structured clinical and administrative data using either internal or external reporting tools.

2.       The system MAY provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools.

3.       The system SHOULD provide the ability to export reports generated.

4.       The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.

5.       The system (or an external application, using data from the system) MAY provide the ability to save report parameters for generating subsequent reports.

6.       The system (or an external application, using data from the system) MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification.

1

1

1.       The system SHOULD provide the ability to generate ad hoc query and reports of structured clinical and administrative data through either internal or external reporting tools.

2.       The system MAY provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools.

3.       The system SHOULD provide the ability to export reports generated.

4.       The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.

5.       The system MAY provide the ability to save report parameters for generating subsequent reports.

6.       The system MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification.

7.       The system MAY provide the ability to produce reports, using internal or external reporting tools, based on the absence of a clinical data element (e.g., a lab test has not been performed in the last year).

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

13.       The system SHALL conform to function IN.1.3 (Entity Access Control).

1.       The system SHOULD provide the ability to define presentation filters that are specific to the types of encounter. These specifics may include care provider specialty, location of encounter, date of encounter, associated diagnosis.

2.       The system MAY provide the ability to define presentation filters that are specific to the patent demographics.

3.       The system SHOULD provide the ability to tailor a "user view".

1.       The system SHALL provide workflow support for data collection appropriate for care setting.

2.       The system SHOULD provide the ability to create and modify data entry workflows.

3.       The system SHOULD provide the ability to extract appropriate information from the patient record as necessary to document the patient encounter.

4.       The system SHOULD provide a reduced set of diagnostic and procedure codes appropriate for the care setting.

5.       The system MAY initiate secondary reporting workflows as a result of information entered into the encounter.

1.       The system SHOULD provide the ability to define the data required for each external administrative and financial system.

2.       The system SHOULD export appropriate data to administrative and financial systems.

1.       The system SHOULD provide the ability to capture patient data from remote devices and integrate that data into the patient's record.

2.       The system SHOULD provide authorized users two-way communication between local practitioner and remote patient, or local practitioner to remote practitioner.

1.       The system SHALL provide the ability to organize patient data by encounter.

2.       The system SHOULD accept and append patient encounter data from external systems, such as diagnostic tests and reports.

3.       The system SHALL provide the ability to create encounter documentation by one or more of the following means: direct keyboard entry of text; structured data entry utilizing templates, forms, pick lists or macro substitution; dictation with subsequent transcription of voice to text, either manually or via voice recognition system.

4.       The system SHOULD provide the ability to define presentation filters that are specific to the types of encounter. These specifics may include care provider specialty, location of encounter, date of encounter, associated diagnosis.

1.       The system SHALL provide the ability to access pertinent patient information needed to support coding of diagnosis, procedures and outcomes.

2.       The system MAY assist with the coding of diagnoses, procedures and outcomes based on provider specialty, care setting and other information that may be entered into the system during the encounter.

1.       The system SHALL maintain financial and administrative codes.2.       The system SHOULD provide the ability to retrieve data from the electronic health record as required to simplify the coding of financial and administrative documentation.

3.       The system MAY support rules driven prompts to facilitate the collection of data in the clinical workflow that is required for administrative and financial coding.

4.       The system MAY assist with the coding of required administrative and financial documents based on provider specialty, care setting and other information that may be entered into the system during the encounter.

5.       The system MAY internally generate administrative and financial coding such as place of service, type of facility, tax rates, etc.

1.       The system MAY provide the ability to retrieve formularies, preferred providers, and other information, from internal or external sources, that are associated with a patient’s health care plan and coverage so that the provider can offer cost effective alternatives to patients.

2.       The system MAY provide the ability to retrieve or request information about exemptions on coverage limitations and guidelines.

3.       The system MAY provide the ability to retrieve and provide expected patient out-of- pocket cost information for medications, diagnostic testing, and procedures, from internal or external sources, that are associated with a patients health care plan and coverage.

4.       The system MAY alert the provider of care where formularies, preferred provider and other information indicate the health plan requires an alternative.

15.       The system SHOULD conform to S.3.3.3 (Service Authorizations) to integrate support of prior authorization processes.

1.       The system SHOULD provide the ability to retrieve subsidized and unsubsidized health plan options from internal or external sources to allow for presentation of alternatives for health care coverage to patients.

2.       The system MAY provide the ability to retrieve health plan enrollment criteria to match patients health and financial status.

1.       The system SHOULD provide the ability to input patient health plan eligibility information for date(s) of service.

2.       The system MAY provide authorized users the ability to input patient health plan coverage dates.

3.       The system MAY provide the ability to input general benefit coverage information for patients.

4.       The system SHOULD provide for the retention of eligibility date(s) of service, coverage dates, general benefits and other benefit coverage documentation for service rendered.

5.       The system MAY provide the ability to transfer electronic eligibility information from internal and external systems.

6.       The system MAY provide the ability to access information received through electronic prescription eligibility checking.

7.       The system MAY provide authorized users the ability to collect and retain patient registration in special programs such as but not limited to: registries and case management.

8.       The system MAY provide the ability to check for inconsistencies in the information recorded.

1.       The system SHOULD provide the ability to input service authorizations relevant to the service provided including the source, dates, and service(s) authorized.

2.       The system SHOULD provide the ability to input referrals relevant to the service provided including the source, date and service(s) referred.

3.       The system MAY provide the ability to transfer and/or collect electronic, computer readable data on service authorization information, including specific data if mandated by local authority.

4.       The system MAY provide the ability to transfer and/or collect electronic, computer readable data on service referral information, including specific data if mandated by local authority.

1.       The system SHALL provide the ability to view available, applicable clinical information to support service requests.

2.       The system SHALL provide the ability to view available, applicable clinical information to support claims.

3.       The system MAY provide available, applicable clinical information to support service requests in computer readable formats.

4.       The system MAY provide available, applicable clinical information to support claims in computer readable formats.

1.       The system SHALL provide the ability to view available, applicable information needed to enable the creation of claims and encounter reports for reimbursement.

2.       The system SHALL provide the ability to capture and present available, applicable data as required by local authority for audit and review.

3.       The system MAY provide available, applicable data in a computer readable form when needed to enable the creation of claims and encounter reports for reimbursement.

1.       The system MAY prompt providers for data needed for end of care reporting during the continuum of care to reduce the need for end of care data collection.

2.       The system SHOULD create service reports at the completion of an episode of care such as but not limited to; discharge summaries, public health reports, etc. using data collected during the encounter.

1.       The system SHALL provide the ability to identify all providers by name associated with a specific patient encounter.

2.       The system SHALL provide the ability to specify the role of each provider associated with a patient such as encounter provider, primary care provider, attending, resident, or consultant.

3.       The system SHALL provide the ability to identify all providers who have been associated with any encounter for a specific patient.

4.       The system SHOULD provide authorized users the ability to add and update information on the relationship of provider to patient.

5.       The system MAY provide the ability to view patient lists by provider.

6.       The system SHALL provide the ability to specify primary or principal provider(s) responsible for the care of a patient within a care setting.

1.       The system SHALL provide the ability to collect and maintain genealogical relationships.2.       The system SHALL provide the ability to identify persons related by genealogy.

3.       The system SHOULD provide the ability to collect and maintain patient consents required to allow patient records to be viewed for the purposes of a genealogical family member’s family medical history.

1.       The system MAY provide the ability to identify persons related by insurance plan.

1.       The system MAY provide the ability to identify patients related by living situation.

1.       The system MAY provide the ability to identify patients related by employer and work location for purposes of epidemiological exposure and public health analysis and reporting.

2.       The system SHOULD provide the ability to identify persons with Power of Attorney for Health Care or other persons with the authority to make medical decisions on behalf of the patient.

1.       The system SHOULD provide the ability to collect appropriate existing data to support the patient acuity/severity processes for illness/risk-based adjustment of resources.

2.       The system MAY provide the ability to export appropriate data to support the patient acuity/severity processes for illness/risk-based adjustment of resources.

3.       The system MAY prompt the user to provide key data needed to support acuity/severity processes.

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

2.       The system SHOULD validate that the most applicable version is utilized for the update, and capture the date of update.

3.       The system MAY track and retain the version used when guidelines are provided in a patient encounter.

1.       The system MAY provide the ability to capture and update material that may be printed and provided to the patient at the point of care.

2.       The system MAY provide the ability to validate the material prior to update.

1.       The system MAY provide the ability to add patient reminders for patients based on the recommendations of public health authorities or disease specific associations.

2.       The system MAY provide the ability to automatically associate patient reminders with patients meeting specific phenotypic criteria such as age, gender, diagnosis, etc.

3.       The system MAY provide the ability to display patient reminders, manually process, and record associated telephone contacts.

4.       The system MAY provide the ability to automatically generate patient reminders for mailing to patients.

1.       The system MAY provide the ability to capture and update public health reporting guidelines.

2.       The system MAY provide the ability to validate the material prior to update.

1.       The system SHALL authenticate principals prior to accessing an EHR-S application or EHR-S data.

2.       The system SHALL prevent access to EHR-S applications or EHR-S data to all non-authenticated principals.

3.       The system SHOULD provide the ability to implement a Chain of Trust agreement.

1

4.       IF other appropriate authentication mechanisms are absent, THEN the system SHALL authenticate principals using at least one of the following authentication mechanisms: username/password, digital certificate, secure token or biometrics.

1.       The system SHALL provide the ability to create and update sets of access-control permissions granted to principals.

2.       The system SHALL conform to function IN.2.2 (Auditable Records) for the purpose of recording all authorization actions.

1

1

1

3.       The system SHALL provide EHR‑S security administrators with the ability to grant authorizations to principals according to scope of practice, organizational policy, or jurisdictional law.

4.       The system SHALL provide EHR‑S security administrators with the ability to grant authorizations for roles according to scope of practice, organizational policy, or jurisdictional law.

5.       The system SHALL provide EHR‑S security administrators with the ability to grant authorizations within contexts according to scope of practice, organizational policy, or jurisdictional law.

6.       The system MAY provide the ability to define context for the purpose of principal authorization based on identity, role, work assignment, present condition, location, patient consent, or patient’s present condition.

7.       The system MAY provide the ability to define context based on legal requirements or disaster conditions.

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL provide the ability to define system and data access rules.

4.       The system SHALL enforce system and data access rules for all EHR-S resources (at component, application, or user level, either local or remote).

1.       The system SHALL conform to function IN.1.3 (Entity Access Control) in order for a healthcare delivery organization to manage a patient’s access to his or her healthcare information.

1

1

1

1.       The system SHALL time stamp initial entry, modification, or exchange of data, and identify the actor/principal taking the action as required by users' scope of practice, organizational policy, or jurisdictional law.

2.       The system SHALL provide additional non-repudiation functionality where required by users' scope of practice, organizational policy, or jurisdictional law.

3.       The system MAY conform to function IN.2.2 (Auditable Records) to prevent repudiation of data origination, receipt, or access.

4.       The system MAY conform to function IN.1.8 (Information Attestation) to ensure the integrity of data exchange and thus prevent repudiation of data origination or receipt.

1.       The system SHALL secure all modes of EHR data exchange.

2.       The system SHOULD conform to function IN.1.7 (Secure Data Routing).

3.       The system MAY provide the ability to obfuscate data.

4.       The system SHALL encrypt and decrypt EHR data that is exchanged over a non-secure link.

5.       The system SHALL support standards-based encryption mechanisms when encryption is used for secure data exchange.

1

1

1

1

1.       The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations and only over secure networks.

2.       The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to function IN.1.1 (Entity Authentication)).

3.       The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to the status of destinations and sources.

1.       The system SHALL conform to function IN.1.1 (Entity Authentication).

2.       The system SHALL conform to function IN.1.2 (Entity Authorization).

3.       The system SHALL provide the ability to associate any attestable content added or changed to an EHR with the content's author (for example by conforming to function IN.2.2 (Auditable Records).

4.       The system SHALL provide the ability for attestation of attestable EHR content by the content's author.

1

1

1

1

1

5.       The system SHALL indicate the status of attestable data which has not been attested.

6.       The system MAY provide the ability for attestation of EHR content by properly authenticated and authorized users different from the author as required by users’ scope of practice, organizational policy, or jurisdictional law.

7.       The system MAY provide the ability to use digital signatures as the means for attestation.

1.       The system SHALL provide the ability to fully comply with the requirements for patient privacy and confidentiality in accordance with a user's scope of practice, organizational policy, or jurisdictional law.

2.       The system SHALL conform to function IN.1.1 (Entity Authentication).

3.       The system SHALL conform to function IN.1.2 (Entity Authorization).

4.       The system SHALL conform to function IN.1.3 (Entity Access Control).

5.       The system SHOULD conform to function IN.1.5 (Non-Repudiation).

6.       The system SHOULD conform to function IN.1.6 (Secure Data Exchange).

7.       The system SHOULD conform to function IN.2.2 (Auditable Records).

8.       The system SHALL provide the ability to maintain varying levels of confidentiality in accordance with users' scope of practice, organizational policy, or jurisdictional law.

9.       The system SHALL provide the ability to mask parts of the electronic health record (e.g. medications, conditions, sensitive documents) from disclosure according to scope of practice, organizational policy or jurisdictional law.

10.    The system SHALL provide the ability to override a mask in emergency or other specific situations according to scope of practice, organizational policy or jurisdictional law.

1.       The system SHALL provide the ability to store and retrieve health record data and clinical documents for the legally prescribed time.

2.       The system SHALL provide the ability to retain inbound data or documents (related to health records) as originally received (unaltered, inclusive of the method in which they were received) for the legally organizationally prescribed time in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

1

1

3.       The system SHALL retain the content of inbound data (related to health records) as originally received for the legally prescribed time.

4.       The system SHOULD provide the ability to retrieve both the information and business context data within which that information was obtained.

5.       The system SHOULD provide the ability to retrieve all the elements included in the definition of a legal medical record.

6.       The system MAY provide the ability to identify specific EHR data/records for destruction, review and confirm destruction before it occurs and implement function IN.2.2 (Auditable Records).

7.       The system MAY provide the ability to destroy EHR data/records so that all traces are irrecoverably removed according to policy and legal retentions periods.

8.       The system SHOULD pass along record destruction date information (if any) along with existing data when providing records to another entity.

1.       The system SHALL provide audit capabilities for recording access and usage of systems, data, and organizational resources.

2.       The system SHALL conform to function IN.1.1 (Entity Authentication).

3.       The system SHALL provide audit capabilities indicating the time stamp for an object or data creation.

4.       The system SHALL provide audit capabilities indicating the time stamp for an object or data modification in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

5.       The system SHALL provide audit capabilities indicating the time stamp for an object or data extraction in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

6.       The system SHALL provide audit capabilities indicating the time stamp for an object or data exchange.

7.       The system SHOULD provide audit capabilities indicating the time stamp for an object or data view.

1

8.       The system SHALL provide audit capabilities indicating the time stamp for an object or data deletion in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

9.       The system SHALL provide audit capabilities indicating the author of a change in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

10.    The system SHOULD provide audit capabilities indicating the viewer of a data set.

11.    The system MAY provide audit capabilities indicating the data value before a change.

12.    The system MAY provide audit capabilities to capture system events at the hardware and software architecture level.

13.    The system SHALL conform to function IN.1.3 (Entity Access Control) to limit access to audit record information to appropriate entities in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

14.    The system SHALL provide the ability to generate an audit report.

15.    The system SHALL provide the ability to view change history for a particular record or data set in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

16.    The system SHOULD provide the ability to record system maintenance events for loading new versions of, or changes to, the clinical system.

17.    The system SHOULD provide the ability to record system maintenance events for loading new versions of codes and knowledge bases.

18.    The system SHOULD provide the ability to record changing the date and time where the clinical system allows this to be done.

19.    The system SHOULD provide the ability to record system maintenance events for creating and restoring of backup.

20.    The system SHOULD provide the ability to record system maintenance events for archiving any data.

21.    The system SHOULD provide the ability to record system maintenance events for re-activating of an archived patient record.

1

1

22.    The system SHOULD provide the ability to record system maintenance events for entry to and exit from the EHR system.

23.    The system SHOULD provide the ability to record system maintenance events for remote access connections including those for system support and maintenance activities.

24.    The system SHOULD utilize standardized time keeping (for example using the IHE consistent time profile).

25.    The system SHOULD provide the ability to record and report upon audit information using a standards-based audit record format (for example RFC 3881).

1.       The system SHALL conform to function IN.5.1 (Interchange Standards).

2.       The system SHOULD conform to function IN.3 (Registry and Directory Services) to enable the use of registries and directories.

3.       The system SHOULD provide the ability to link entities to external information.

4.       The system SHOULD store the location of each known health record component in order to enable authorized access to a complete logical health record if the EHR is distributed among several applications within the EHR-S.

1

1

1.       The system SHALL provide the ability to extract health record information.

2.       The system SHOULD conform to function IN.1.6 (Secure Data Exchange) to provide secure data exchange capabilities.

3.       The system SHOULD provide the ability to de-identify extracted information.

4.       The system SHOULD conform to function IN.5.1 (Interchange Standards) to enable data extraction in standard-based formats.

5.       The system SHOULD provide the ability to perform extraction operations across the complete data set that constitutes the health record of an individual within the system.

6.       The system MAY provide the ability to perform extraction operations whose output fully chronicles the healthcare process.

7.       The system SHOULD provide the ability to extract data for administrative purposes.

8.       The system SHOULD provide the ability to extract data for financial purposes.

9.       The system SHOULD provide the ability to extract data for research purposes.

10.    The system SHOULD provide the ability to extract data for quality analysis purposes.

11.    The system SHOULD provide the ability to extract data for public health purposes.

1

1.       The system SHALL capture unstructured health record information as part of the patient EHR.

2.       The system SHALL retrieve unstructured health record information as part of the patient EHR.

3.       The system SHALL provide the ability to update unstructured health record information.

4.       The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy unstructured health record information.

5.       The system SHOULD provide the ability to report unstructured health record information.

6.       The system MAY track unstructured health record information over time.

7.       The system SHALL provide the ability to append corrected unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied.

8.       The system SHALL provide the ability to append unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied.

9.       The system SHALL provide the ability to append augmented unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied.

1

1.       The system SHALL capture structured health record information as part of the patient EHR.

2.       The system SHALL retrieve structured health record information as part of the patient EHR.

3.       The system SHALL provide the ability to update structured health record information.

4.       The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy structured health record information.

5.       The system SHOULD provide the ability to report structured health record information.

6.       The system MAY track structured health record information over time.

7.       The system SHOULD provide the ability to retrieve each item of structured health record information discretely within patient context.

8.       The system SHALL provide the ability to append corrected structured health record information to the original structured health record information. A specific type of implementation is not implied.

9.       The system SHALL provide the ability to append structured health record information to the original structured health record information. A specific type of implementation is not implied.

10.    The system SHALL provide the ability to append augmented structured health record information to the original structured health record information. A specific type of implementation is not implied.

1

11

1

1.       The system SHALL provide the ability to use registry services and directories.

2.       The system SHOULD provide the ability to securely use registry services and directories.

3.       The system SHALL conform to function IN.5.1 (Interchange Standards) to provide standard data interchange capabilities for using registry services and directories.

4.       The system SHOULD communicate with local registry services through standardized interfaces.

5.       The system SHOULD communicate with non-local registry services (that is, to registry services that are external to an EHR-S) through standardized interfaces.

6.       The system SHOULD provide the ability to use registries or directories to uniquely identify patients for the provision of care.

7.       The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care.

8.       The system MAY provide the ability to use registries or directories to retrieve links to relevant healthcare information regarding a patient.

9.       The system MAY provide the ability to use registries to supply links to relevant healthcare information regarding a patient.

10.    The system MAY provide the ability to use registries or directories to identify payers, health plans, and sponsors for administrative and financial purposes.

11.    The system MAY provide the ability to use registries or directories to identify employers for administrative and financial purposes.

12.    The system MAY provide the ability to use registries or directories to identify public health agencies for healthcare purposes.

13.    The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource management purposes.

1.       The system SHALL provide the ability to use standard terminologies to communicate with other systems(internal or external to the EHR-S).

2.       The system SHALL provide the ability to validate that clinical terms and coded clinical data exists in a current standard terminology.

3.       The system SHOULD provide the ability to exchange healthcare data using formal standard information models and standard terminologies.

4.       The system SHOULD provide the ability to use a formal standard terminology model.

5.       The system SHOULD provide the ability to use hierarchical inference searches e.g., subsumption across coded terminology concepts that were expressed using standard terminology models.

6.       The system SHOULD provide the ability to use a terminology service (internal or external to the EHR-S).

7.       IF there is no standard terminology model available, THEN the system MAY provide a formal explicit terminology model.

1.       The system SHALL provide the ability to use different versions of terminology standards.

2.       The system SHALL provide the ability to update terminology standards.

3.       The system MAY relate modified concepts in the different versions of a terminology standard to allow preservation of interpretations over time.

4.       The system SHOULD provide the ability to interoperate with systems that use known different versions of a terminology standard.

5.       The system SHOULD provide the ability to deprecate terminologies.

6.       The system MAY provide the ability to deprecate individual codes within a terminology.

7.       The system SHALL provide the ability to cascade terminology changes where coded terminology content is embedded in clinical models (for example, templates and custom formularies) when the cascaded terminology changes can be accomplished unambiguously.

8.       Changes in terminology SHALL be applied to all new clinical content (via templates, custom formularies, etc.).

1.       The system SHALL provide the ability to use a terminology map.

2.       The system SHOULD provide the ability to use standard terminology services for the purposes of mapping terminologies.

3.       The system MAY provide the ability for a user to validate a mapping.

4.       The system MAY provide the ability to create a terminology map.

1

1.       The system SHALL provide the ability to use interchange standards as required by realm specific and/or local profiles.

2.       The system SHALL provide the ability to seamlessly perform interchange operations with other systems that adhere to recognized interchange standards.

3.       The system SHALL conform to functions under header IN.4 (Standard Terminologies and Terminology Services) to support terminology standards in accordance with a users' scope of practice, organizational policy, or jurisdictional law.

4.       IF there is no standard information model available, THEN the system MAY provide a formal explicit information model in order to support the ability to operate seamlessly with other systems.

5.       The system SHOULD provide the ability to exchange data using an explicit and formal information model and standard, coded terminology.

1.       The system SHALL provide the ability to use different versions of interchange standards.

2.       The system SHALL provide the ability to change (reconfigure) the way that data is transmitted as an interchange standard evolves over time and in accordance with business needs.

3.       The system SHOULD provide the ability to deprecate an interchange standard.

4.       The system SHOULD provide the ability to interoperate with other systems that use known earlier versions of an interoperability standard.

1.       The system SHALL provide the ability to support standards-based application integration.

1

1.       The system SHALL use interchange agreement descriptions when exchanging information with partners.

2.       The system SHOULD use interchange agreement description standards (when available).

3.       The system MAY conform to function IN.3 (Registry and Directory Services) to interact with entity directories to determine the address, profile and data exchange requirements of known and/or potential partners.

4.       The system MAY provide the ability to automatically discover interchange services and capabilities.

1

1

1.       The system SHALL provide the ability to manage business rules.

2.       The system SHOULD provide the ability to create, import, or access decision support rules to guide system behavior.

3.       The system SHOULD provide the ability to update decision support rules.

4.       The system SHOULD provide the ability to customize decision support rules and their components.

5.       The system SHOULD provide the ability to inactivate, obsolete, or destroy decision support rules.

6.       The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to decision support rules.

7.       The system SHOULD provide the ability to create diagnostic support rules to guide system behavior.

8.       The system SHOULD provide the ability to update diagnostic support rules.

9.       The system MAY provide the ability to customize diagnostic support rules and their components.

10.    The system SHOULD provide the ability to inactivate, obsolete, or destroy diagnostic support rules.

11.    The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to diagnostic support rules.

12.    The system SHOULD provide the ability to create workflow control rules to guide system behavior.

13.    The system SHOULD provide the ability to update workflow control rules.

1

1

1

14.    The system MAY provide the ability to customize workflow control rules and their components.

15.    The system SHOULD provide the ability to inactivate, obsolete, or destroy workflow control rules.

16.    The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to workflow control rules.

17.    The system MAY provide the ability to create access privilege rules to guide system behavior.

18.    The system MAY provide the ability to update access privilege rules.

19.    The system MAY provide the ability to customize access privilege rules and their components.

20.    The system MAY provide the ability to inactivate, obsolete, or destroy access privilege rules.

21.    The system MAY conform to function IN.2.2 (Auditable Records) to audit all changes to access privilege rules.

22.    The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to other business rules.

23.    The system SHOULD support the ability to selectively export business rules.

1.       The system SHOULD use workflow-related business rules to direct the flow of work assignments.

2.       The system SHOULD provide the ability to create workflow (task list) queues.

3.       The system SHOULD provide the ability to manage workflow (task list) queues.

4.       The system MAY provide the ability to manage human resources (i.e., personnel lists) for workflow queues.

5.       The system MAY use system interfaces that support the management of human resources (i.e., personnel lists).

6.       The system MAY use system interfaces that support the management of workflow (task lists) queues.

7.       The system MAY provide the ability to distribute information to and from internal and external parties.

8.       The system MAY provide the ability to route notifications and tasks based on system triggers.

9.       The system MAY dynamically escalate workflow according to business rules.

10.    The system MAY dynamically redirect workflow according to business rules.

11.    The system MAY dynamically reassign workflow according to business rules.

Filter setsMedication

Demographic

Referrals Care Plan Lab

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1 1

1 1

1 1

1 1

1 1

1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

111

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

Filter setsRadiology

1

Statement / Description

1

1

1

1

1

1

1

1

1

1

1

1

1111

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1 1

1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1 1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

11

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

11

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1111111

1

1

1

1

1

1

1

1

1

1

11

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

111

1

1

1

1

1

1

1

1

1

1

1

11

11

1

1

1

1

1

1

1

1

1

1

1

1

11

1

1

11

1

1

1

1111

1

ID# NameDC.1 H Care Management

DC.1.1 H Record Management

DC.1.1.1 F

Typ

e

Data is entered by a variety of caregivers. Details of who entered data and when it was captured must be tracked. Data may also be captured from monitoring devices or other applications.

Identify and Maintain a Patient Record

DC.1.1.2 F Manage Patient Demographics

DC.1.1.2.1 F EDIS Registration

DC.1.1.2.3 F ED Merge Registration

DC.1.1.3 F Data and Documentation

DC.1.1.3.1 F Capture Data and Documentation from External Clinical Sources

DC.1.1.3.1.1 F Capture EMS data

DC. 1.1.3.2 F

DC.1.1.3.3 F

Capture Patient Originated Data

Capture Patient Originated Data

Capture Patient Health Data Derived from Administrative and Financial Data and Documentation

DC.1.2 F Manage Patient History

DC.1.2.1 F Manage Pre-Arrival Data

DC.1.2.2 F Manage Arrival Data

DC.1.2.3 F Manage Triage

DC.1.2.4 F Manage History of Present Illness

DC.1.3.1 F

DC.1.3.2 F

DC.1.3.3 F

Manage Patient and Family Preferences

Manage Patient Advanced Directives

Manage Consents and Authorizations

DC.1.4.1 F Manage Allergy, Intolerance and Adverse Reaction List

DC.1.4.2 F Manage Mediation List

DC.1.4.3 F Manage Problem List

DC.1.4.4 F

DC.1.5 F Manage Assessments

Manage Immunization List

DC.1.5.1 F

DC.1.5.2 F Manage Progress Notes

DC.1.6.1 F

DC.1.7 H

DC.1.7.1 F Manage Medication Orders

Manage Physical Examination

Present Guidelines and Protocols for Planning Care

Orders and Referrals Management

DC.1.7.2.1 F

DC.1.7.2.2 F

Manage Non-Medication Patient Care Orders

Manage Orders for Diagnostic Tests

DC.1.7.2.3 F

DC.1.7.2.4 F Manage Referrals

DC.1.7.3 F Manage Order Sets

Manage Orders for Blood Products and Other Biologics

DC.1.8.1 F

DC.1.8.3 F Manage Results

Manage Medication Administration

DC.1.8.4 F Manage Patient Clinical Measurements

DC.1.8.5 F

DC.1.8.5.1 F

DC.1.8.5.2 F

Manage Clinical Documents and Notes

Acknowledge/Amend Other Provider Documentation

Document Patient and Family Communication and Education

DC.1.8.5.3 F

DC.1.8.6 F

DC.1.8.7 F Manage Procedures

DC.1.8.8 F

Manage Transfers of Care between ED Providers

Manage Documentation of Clinician Response to Decision Support Prompts

Manage Medical Decision-Making

DC.1.9 F

DC.1.10 F Manage ED Disposition

DC.1.10.1 F Manage ED Discharge

Generate and Record Patient-Specific Instructions

DC.1.10.1.1 F Manage Follow-up Care

DC.1.10.1.2 F Manage prescriptions

DC.1.10.1.3 F

DC.1.10.1.4 F Manage Transfers

DC.1.11 F

Manage ED to Hospital Admission

Manage Discharged Patients

DC.2.1.1 F

DC.2.1.2 F

Support for Standard Assessments

Support for Patient Context- Driven Assessments

DC.2.1.5 F

DC.2.1.6 F

DC.2.2.1.1 F

DC.2.2.1.2 F

Support Triage Categorization

Support Waiting Room Management

Support for Standard Care Plans, Guidelines, Protocols

Support for Context-Sensitive Care Plans, Guidelines, Protocols

DC.2.2.3 F

DC.2.3.1.1 F

Support for Research Protocols Relative to Individual Patient Care

Support for Drug Interaction Checking

DC.2.3.1.2 F

DC.2.3.1.3 F

Support for Patient Specific Dosing and Warnings

Support for Medication Recommendations

DC.2.3.2 F

DC.2.3.3 F

Support for Medication and Immunization Administration

Support Medication Reconciliation

DC.2.4 H

DC.2.4.1 F Create Order Set Templates

DC.2.4.2 F

Orders, Referrals, Results and Care Management

Support for Non-Medication Ordering

DC.2.4.3 F

DC.2.4.4.1 F

DC.2.4.4.2 F

Support for Result Interpretation

Support for Referral Process

Support for Referral Recommendations

DC.2.4.5.1 F

DC.2.4.5.2 F

DC.2.6.1 F

Support for Safe Blood Administration

Support for Accurate Specimen Collection

Support for Epidemiological Investigations of Clinical Health Within a Population.

DC.2.7.1 F

DC.3.1 H Clinical Workflow Tasking

DC.3.1.1 F

Access Healthcare Guidance

Clinical Task Assignment and Routing

DC.3.1.2 F Clinical Task Linking

DC.3.1.3 F Clinical Task Tracking

DC.3.2 H

DC.3.2.1 F

Support Clinical Communication

Support for Inter-Provider Communication

DC.3.2.1.1 F

DC.3.2.2 F

DC.3.2.4 F

Manage Consultation Requests and Responses

Support for Provider -Pharmacy Communication

Patient, Family and Care Giver Education

DC.3.2.5 F

SUPPORT FUNCTIONS - EDIS HL7 EHR-S FUNCTIONAL PROFILES.1.1 F Registry Notification

S.1.3 H Provider Information

S.1.3.1 F Provider Access Levels

Communication with Medical Devices

S.1.3.2 F

S.1.3.3 F Provider’s On-Call Location

S.1.3.4 F

S.1.4 H Patient Directory

S.1.4.1 F Patient Demographics

S.1.4.2 F

Provider’s Location Within Facility

Provider’s Location(s) or Office(s)

Patient’s Location Within a Facility

S.1.4.2.1 F

S.1.4.2.2 F

S.1.4.2.2 F

Patient’s Location Within the Emergency Department

Department Modeling and Room Management

Department Modeling and Room Management

S.1.4.4 F

S.1.6 F Scheduling

S.1.7 F

Patient Bed Assignment

Healthcare Resource Availability

S.1.8 F Information View

S.2.1 H

S.2.1.1 F

S.2.1.2 F

Measurement, Monitoring and Analysis

Measurement, Monitoring and Analysis

Outcome Measures and Analysis

Performance and Accountability Measures

S.2.2 H Report Generation

S.2.2.1 F Health Record Output

S.2.2.2 F Standard Report Generation

S.2.2.2.1 F ED Benchmarking Reports

S.2.2.3 F Ad-Hoc Query and Report Generation

S.3.1 H

S.3.1.3 F

S.3.1.5 F

Encounter/Episode of Care Management

Automatic Generation of Administrative and Financial Data from Clinical Record

Other Encounter and Episode of Care Support

S.3.2 H

S.3.2.1 F

S.3.2.2 F

S.3.2.3 F

Information Access for Supplemental Use

Rules-Driven Clinical Coding Assistance

Rules-Driven Financial and Administrative Coding Assistance

Integrate Cost/Financial Information

S.3.3 H

S.3.3.2 F

S.3.3.4 F

S.3.3.5 F

Administrative Transaction Processing

Eligibility Verification and Determination of Coverage

Support of Service Requests and Claims

Claims and Encounter Reports for Reimbursement

S.3.3.6 F

S.3.6 F Acuity and Severity

F Acuity and Severity

S.3.7 F

S.3.7.1 F

Health Service Reports at the Conclusion of an Episode of Care.

Supportive Function Maintenance

Clinical Decision Support System Guidelines Update

S.3.7.2 F

S.3.7.4 F

INFRASTRUCTURE FUNCTIONSIN.1 H Security

IN.1.1 F Entity Authentication

Patient Education Material Updates

Public Health Related Updates

IN.1.2 F Entity Authorization

IN.1.3 F Entity Access Control

IN.1.4 F

IN.1.5 F Non-repudiation

Patient Access Management

IN.1.6 F Secure Data Exchange

IN.1.7 F Secure Data Routing

IN.1.8 F Information Attestation

IN.1.9 F Patient Privacy and Confidentialty

IN.1.9.1 F

IN.1.9.2 F

IN.2 H

IN.2.1 F

Redact patient identifying information.

Protect individual patient identity.

Health Record Information and Management

Data Retention Availability and Destruction

IN.2.2 F Auditable Records

IN.2.3 F Synchronization

IN.2.4 F Extraction of Health Record Information

IN.2.5 H

IN.2.5.1 F

Store and Manage Health Record Information

Store and Manage Unstructured Health Record Information

IN.2.5.2 F

IN.3 H

Store and Manage Structured Health Record Information

Registry and Directory Services

IN.4 H Standard Terminologies and Terminology Services

IN.4.1 F

IN.4.2 F

Standard Terminologies and Terminology Models

Maintenance and Versioning of Standard Terminologies

IN.4.3 F Terminology Mapping

IN.5 H

IN.5.1 F Interchange Standards

Standards-based Interoperability

IN.5.1.1 F Structured Documents

IN.5.2 F Interchange Standards Versioning and Maintenance

IN.5.3 F

IN.5.4 F Interchange Agreements

IN.5.5 H EDIS Interoperability

Standards-based Application Integration

IN.5.5.1 F Bed Board Interface

IN.5.5.2 F

IN.5.5.3 F Billing Interface

IN.6 F

Electronic Prescribing Interface

Business Rules Management

IN.7 F Workflow Management

IN.8 F Application Optimization

Statement and Description Priority

E

E

E

Statement: None

Description: Care Management functions are those used directly by providers as they create a record and deliver patient care in the ED.

DC.1.1 functions address the mechanics of creating a single logical health record, beginning a new encounter, managing patient demographics, and managing externally generated (including patient originated) health data.

DC.1.2 - DC.1.11 follow a fairly typical flow of patient care through an ED encounter beginning with pre-arrival and moving thorough discharge. Specific items include, but are not limited to: consents, assessments, care plans, orders, results etc.

Integral to care management activities is an underlying system foundation that maintains the privacy, security, and integrity of the captured health information – the information infrastructure of the EDIS covered in the IN section.

Also essential to care management are the supporting knowledge bases, tables, and system configuration settings developed for a particular system implementation – the system support functions addressed in S section.

In the ED, there are frequently times when actions/activities related to "patients" are also applicable to the patient representative. Therefore, throughout the profile, the term “patient” can refer to the patient and/or the patient’s personal representative, guardian or surrogate.

Statement: None

Description: For those functions related to data capture, data may be captured using standardized code sets or nomenclature, depending on the nature of the data, or captured as unstructured data.

Statement: Identify and maintain a single patient record for each patient.

Description: A single patient record is needed for legal purposes, as well as to organize information unambiguously for the provider. All health information is captured and linked to the patient record. Static data elements as well as data elements that will change over time are maintained. The patient is uniquely identified, after which the record is tied to that patient.

EDIS are frequently thought of as being encounter based. However, it is advantageous to tie specific information directly to a patient so that if a patient returns, legacy data may be incorporated and updated when beginning a new encounter.

E

Combining information on the same patient, or separating information where it was inadvertently captured for the wrong patient, helps maintain health information for a single patient.

Statement: Capture and maintain demographic information. Where appropriate, the data should be clinically relevant and reportable.

Description: Contact information including addresses and phone numbers, as well as key demographic information such as date of birth, gender, and other information is stored and maintained for patient identification, reporting purposes and for the provision of care.

Patient demographics are captured and maintained as discrete fields (e.g., patient names and addresses) and may be enumerated, numeric or codified. Key patient identifiers are shown on all patient information output (such as name and ID# on each screen of a patient’s record). The system will track who updates demographic information, and when the demographic information is updated.

E

E

Statement: Identify the patient in the EDIS and initiate a new encounter.

Description: ED workflow is unique in that care must be supported and documented immediately upon arrival. The system must be able to immediately generate a new patient encounter without the need to identify the patient or previous records.

To maximize usability, when time permits, identification of a previous patient record in the EDIS should be possible to facilitate the triage process by recovering prior medications, allergies, problems. Data entry is minimized and time can be spent verifying, updating, and correcting data.

Statement: Receive an account number from the hospital ADT system without complete supporting demographics, in order to facilitate patient care before registration is complete.

Description: The registration process, including the verification of full demographics data, insurance, contact information, etc. is frequently time consuming. To facilitate patient care in emergency situations, the system must be interoperable with other hospital systems in a time critical manner.

In order to support interoperability with other hospital systems, for such tasks as medication or other order entry the system should be able to, in a time critical manner, receive an account number from the hospital ADT system, or alternatively, generate an account number in concert with the hospital system.

Statement: Merge the record begun in the EDIS with the formal registration in an ADT system.

E

E

Description: In the EDIS environment, the EDIS is rarely used to capture full demographic or financial data. Instead, a hospital or other ADT system is used to capture this data which is then transferred or linked to the EDIS along with the account number generated for the visit. A method needs to exist to perform this transaction. An automated ADT merge is preferable, minimizing the administrative burden.

Description: External sources are those outside the EHR system, including clinical, administrative, and financial information systems, other EHR systems, PHR systems, and data received through health information exchange networks.

Statement: Incorporate clinical data and documentation from external sources

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

In the ED, consultants, EMS, social workers, respiratory therapists, and a number of other providers may not use the EDIS to document care. Therefore, a method should be available to capture or link these documents to the ED visit.

Data managed outside of the EDIS by other providers and systems should be available to providers in the ED. This data includes referral summaries, transfer summaries, DNR orders and medication lists. This data must be linked to the patient’s medical record and viewable to providers in the ED.

EF09

O

O

Statement: Capture EMS data electronically, including telemetry, vital sign measurements, procedures performed and both structured and non-structured clinical observations.

Description: In the future, interoperability between EMS systems and ED Information Systems will assist in the care provided in the ED. Electronic transmission of data may not only occur at the time of EMS arrival to the ED, but upon selection of, and en-route to, a receiving facility.

Statement: Capture and explicitly label patient originated data, link the data source with the data, and support provider authentication for inclusion in patient health record.

Description: Patients may provide data for entry into the health record or be given a mechanism for entering this data directly. It is critically important to be able to distinguish patient-originated data that is either provided or entered by a patient from clinically authenticated data.

Patient-originated data intended for use by providers should be available for their use. Data about the patient may be provided by: (1) patient, (2) surrogate (parent, spouse, guardian), or (3) informant (teacher, lawyer, case worker).

Patient-originated data may also be captured by interactions with devices or electronic PHR services and transmitted for inclusion into the electronic health record. Data entered by any of these must be stored with source information. A provider must authenticate patient originated data included in the patient’s legal health record.

Statement: Capture and explicitly label patient health data derived from administrative or financial data; and link the data source with that data.

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

E

E

Patient health data that is derived from administrative or financial data may be provided by: (1) the patient, (2) a provider, (3) a payer; or (4) entities that transmit or process administrative or financial data. Since this data is non-clinical, it may not be authenticated for inclusion in the patient’s legal health record.

Statement: Capture and maintain medical, procedural/surgical, social and family history including the capture of pertinent positive and negative histories, patient-reported or externally available patient clinical history.

Description: The history of the current illness and patient historical data related to previous medical diagnoses, surgeries

and other procedures performed on the patient, and relevant health conditions of family members is captured through such methods as patient reporting (for example interview, medical alert band) or electronic or non-electronic historical data. This data may take the form of a pertinent positive such as: "The

patient/family member has had..." or a pertinent negative such as "The patient/family member has not had..."

ED patients commonly receive care prior to registration, and care must be documented before registration is completed, or infrequently, before the patient is able to be identified.

The delivery of care and clinical documentation frequently occur in a non-linear temporal sequence. However, clinical summaries created by the EDIS should re-create a traditional or standard type of record flow.

Statement: Create and update information about incoming referrals from physicians’ offices, clinics, EMS, transfers from other hospitals or emergency departments, nursing homes, etc. and link this data to the patient’s record.

Description: The management of information on patients who are inbound to the ED is an important component of information management in the ED. This documentation most often begins with a telephone call made from referring provider to receiving ED.

Often, this information gets haphazardly recorded. Data must be easily accessible, central, retrievable, updatable, transportable and reusable.

E

E

E

Clinical data from provider to provider is essential to quality coordinated care for patients referred to the ED. Knowledge of patients who are expected to arrive helps both ED and administrative staff plan resource use in real time.

Advance notification is also common for patients arriving via EMS. This data is most often taken during a radio call, when patient demographic data is omitted for privacy concerns. As such, some systems may elect to capture this data without demographic information to be linked to the medical record when the patient arrives. EMS arrivals frequently require in-room registration. Notifying registration of incoming ambulances can direct staff to be available as soon as the patient arrives.

Statement: Capture Arrival Data at the time of patient arrival to the ED.

Description: Capture data pertinent to the ED visit including, but not limited to: Mode of arrival, Referral source (if any), Arrival time. This data need not be captured by clinical personnel, but is important for patient management as well as administrative management of the ED. ,

Statement: Capture Triage Assessment

Description: Fundamental to emergency care is the concept of triage, whereby patients with differing problems and presentations are stratified and prioritized for care.

Patients who are critically ill are generally brought directly back to the treatment area and seen immediately by emergency care providers. Other patients may need to wait to be seen by a provider. Depending on local practice, severity of illness, or other factors, patients may undergo triage in multiple ways and by multiple providers. An EDIS must be extensible enough to accommodate these differing workflows.

Statement: Provide a means to capture and maintain the history of present illness and patient review of systems (ROS).

O

E

E

Description: The history of present illness and associated review of systems are unique to each encounter. HPI and ROS may be captured as discrete data (i.e. template) or as narrative (i.e. voice recognition, typing, etc). However, there must be a method for capturing this data that allows the provider to capture the essence of the encounter as he or she feels it should be recorded.

Statement: Capture and maintain patient and family preferences.

Description: Patient and family preferences regarding issues such as language, religion, spiritual practices and culture – may be important to the delivery of care. It is important to capture these so that they will be available to the provider at the point of care.

Statement: Capture and maintain patient advance directives.

Description: Patient advance directives and provider DNR orders are captured as well as the date and circumstances under which the directives were received, and the location of any paper records or legal documentation (e.g. the original) of advance directives as appropriate.

Statement: Create, maintain, and verify patient decisions such as informed consent for treatment and authorization/consent for disclosure when required.

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

E

There may be several documents active at any one time that may govern a patient’s care. Both clinical and administrative consents and authorizations are considered part of this function. A consent or authorization includes patient authorization for re-disclosure of sensitive information to third parties. Consents/Authorizations for printing should include appropriate standardized forms for patients, guardians, foster parents. The system must appropriately present forms for adolescents according to privacy rules. Some states may mandate assent. Assent is agreement by the patient to participate in services when they are legally unable to consent (e.g., an adolescent, an adult with early dementia).

Statement: Create and maintain patient specific allergy, intolerance and adverse reaction lists

Description: Allergens, including immunizations, and substances are identified and coded (whenever possible) and the list is captured and maintained over time. All pertinent dates, including patient-reported events, are stored and the description of the patient allergy and adverse reaction is modifiable over time.

The entire allergy history, including reaction, for any allergen is viewable. The list(s) includes all reactions including those that are classifiable as a true allergy, intolerance, side effect or other adverse reaction to drug, dietary or environmental triggers. Notations indicating whether item is patient reported and/or provider verified are maintained.

E

E

Statement: Create and maintain patient specific medication lists.

Description: Medication lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. All pertinent dates, including medication start, modification, and end dates are stored. The entire medication history for any medication, including alternative supplements and herbal medications, is viewable.

Medication lists are not limited to medication orders recorded by providers, but may include, for example, pharmacy dispense/supply records, patient-reported medications and additional information such as age specific dosage.

Statement: Create and maintain patient specific problem lists.

Description: A problem list may include, but is not limited to: chronic conditions, diagnoses, or symptoms, functional limitations, visit or stay-specific conditions, diagnoses, or symptoms.

E

E

Problem lists are managed over time, whether over the course of a visit or stay or the life of a patient, allowing documentation of historical information and tracking the changing character of problem(s) and their priority. The source (e.g. the provider, the system id, or the patient) of the updates should be documented.

In addition all pertinent dates are stored, including date noted or diagnosed, dates of any changes in problem specification or prioritization, and date of resolution. This might include time stamps, where useful and appropriate. The entire problem history for any problem in the list is viewable.

Statement: Create and maintain patient specific immunization lists.

Description: Immunization lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. Details of immunizations administered are captured as discrete data elements including date, type, manufacturer and lot number. The entire immunization history is viewable.

Statement: Create and Maintain Assessments

Description: During an encounter with a patient, providers conduct assessments that are germane to the age, gender, and medical condition of the patient.

Wherever possible, this assessment should follow standard protocols although, for example, an assessment for an infant will have different content than one for an elderly patient.

When a specific standard assessment does not exist, a unique assessment can be created, using the format and data elements of similar standard assessments whenever possible.

E

E

O

E

E

Statement: Provide a means to create and update physical examination findings.

Description: The physical examination is unique to each encounter and problem. The PE may be captured as discrete data (i.e. template) or as narrative (i.e. voice recognition, typing, etc). However, there must be a method for capturing this data that allows the provider to capture the examination as the provider feels it should be recorded.

Statement: Provide a means to capture and maintain progress notes or ongoing evaluations.

Description: Important, and perhaps unique, to the documentation of ED care is the concept of progress notes to document improvement or decline in a patient’s clinical condition over time, based upon response to therapy. Progress notes are a unique form of assessment that may be standardized for a particular problem (i.e. asthma) or observation (i.e. pain).

Statement: Present organizational guidelines for patient care as appropriate to support planning of care, including order entry and clinical documentation

Description: Guidelines, and protocols presented for planning care may be site specific, community or industry-wide standards.

Description: Each ED and institution is different. When an EDIS is employed for orders or referrals management, the EDIS serves as the gateway or interface to that institution. The EDIS must support specific ordering and associated workflows identified with ED care. Dependencies should be minimized and user interactions streamlined.

Statement: Create prescriptions or other medication orders with detail adequate for correct filling and administration. Provide information regarding compliance of medication orders with formularies

Description: Different medication orders, including discontinue, refill, and renew, require different levels and kinds of detail, as do medication orders placed in different situations. The correct details are recorded for each situation. Administration or patient instructions are available for selection by the ordering clinicians, or the ordering clinician is facilitated in creating such instructions.

The system may allow for the creation of common content for prescription details. Appropriate time stamps for all medication related activity are generated. This includes series of orders that are part of a therapeutic regimen, e.g. Renal Dialysis, Oncology. When a clinician places an order for a medication, that order may or may not comply with a formulary specific to the patient’s location or insurance coverage, if applicable. Whether the order complies with the formulary should be communicated to the ordering clinician at an appropriate point to allow the ordering clinician to decide whether to continue with the order. Formulary-compliant alternatives to the medication being ordered may also be presented.

E

E

Statement: Capture and track patient care orders. Enable the origination, documentation, and tracking of non-medication patient care orders.

Description: Non-medication orders that request actions or items can be captured and tracked. Examples include orders to admit a patient, ambulate a patient, for medical supplies, durable medical equipment, home IV, and diet or therapy orders.

Each item ordered includes the appropriate detail, such as order identification and instructions. Orders should be communicated to the correct service provider for completion

Statement: Enable the origination, documentation, and tracking of orders for diagnostic tests.

Description: Orders for diagnostic tests (e.g. diagnostic radiology, blood test) are captured and tracked. Each order includes appropriate detail, such as order identification, instructions and clinical information necessary to perform the test. Orders and supporting detailed documentation shall be communicated to the service provider for completion of the diagnostic test(s). Some systems may contain instructions, but in some settings, instructions may be provided from external sources (e.g., handouts).

O

EF

E

Provide a means for providers to order diagnostic tests including, but not limited to, laboratory, radiology, and special procedures.

Statement: Communicate with appropriate sources or registries to manage orders for blood products or other biologics.

Description: Interact with a blood bank system or other source to support orders for blood products or other biologics. Use of such products in the provision of care is captured. Blood bank or other functionality that may come under jurisdictional law or other regulation (e.g. by the FDA in the United States) is not required; functional communication with such a system is required.

Statement: Enable the origination, documentation and tracking of referrals between care providers or healthcare organizations, including clinical and administrative details of the referral, and consents and authorizations for disclosures as required.

Description: Documentation and tracking of a referral from one care provider to another is supported, whether the referred to or referring providers are internal or external to the healthcare internal or external to the healthcare organization. Guidelines for whether a particular referral for a particular patient is appropriate in a clinical context and with regard to administrative factors such as insurance may be provided to the care provider at the time the referral is created.

Statement: Provide order sets based on provider input or system prompt.

Description: Order sets, which may include medication and non-medication orders, allow a care provider to choose common orders for a particular circumstance or disease state according to standards or other criteria. Recommended order sets may be presented based on patient data or other contexts.

E

E

Statement: Present providers with the list of medications that are to be administered to a patient, necessary administration information, and capture administration details.

Description: In a setting in which medication orders are to be administered by a provider rather than the patient, the necessary information is presented including: the list of medication orders that are to be administered; administration instructions, times or other conditions of administration; dose and route, etc. The system shall securely relate medications to be administered to the unique identity of the patient (see DC.1.1.1). Additionally, the provider can record what actually was or was not administered, whether or not these facts conform to the order. Appropriate time stamps for all medication related activity are generated.

For some settings that administer complete sets of medications from a variety of providers’ orders, it may be useful to provide an additional check for possible drug-drug or other interactions.

Statement: Present, annotate, and route current and historical test results to appropriate providers or patients for review. Provide the ability to filter and compare results.

E

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

Statement: Capture and manage patient clinical measures, such as vital signs, as discrete patient data

Description: Patient measures such as vital signs are captured and managed as discrete data to facilitate reporting and provision of care. Other clinical measures (such as expiratory flow rate, size of lesion, etc.) are captured and managed, and may be discrete data

E

E

E

Statement: Create, addend, correct, authenticate and close, as needed, transcribed or directly-entered clinical documentation and notes.

Description: Clinical documents and notes may be unstructured and created in a narrative form, which may be based on a template, graphical, audio, etc. The documents may also be structured documents that result in the capture of coded data. Each of these forms of clinical documentation is important and appropriate for different users and situations.

Statement: Review other care giver notes and indicate or amend as permitted by legal or regulatory restrictions.

Description: Scan/review notes, annotate for disparities, import when desired. Scan/review nurses notes, annotate for disparities, import when desired. Review nurses notes, assistants (Physician, Nursing) notes, ancillary care (Technicians, etc), other care givers (RT, PT, etc).

This is a key function of documentation in an EDIS. Making this happen easily and smoothly is a matter of implementation.

Statement: Provide a mechanism for documentation of patient and family communications, counseling, and education.

E

E

E

Description: The system should A Function allowing for entry/retrieval of a description of the counseling given to the Patient/Family regarding the condition (for which the patient was seen in the ED)

The EHR should show not only the thinking about a patient's condition, but also what was communicated to patient/family, so that subsequent physicians to whom the patient is referred have a grasp of conversations that have already taken place.

Statement: provide a means to document transfers of care between ED providers.

Description: Patient care in the ED often spans the shifts of ED providers, necessitating support for the care transfer process. This support may include the need to document that care has been transferred to another ED provider,

Statement: Capture the decision support prompts and manage decisions to accept or override decision support prompts

Description: Clinician actions in response to decision support prompts are captured and can be managed at the patient level or aggregated for organizational trending

Statement: Provide a means to document procedures performed by ED providers.

Description: Procedures are an integral part of the care provided to ED patients. The system should support the clinical documentation of procedures performed by all providers. This documentation should also be available to support reimbursement without additional data entry by the provider.

Statement: Provide a means to capture and maintain the assessment and plan of the ED physician, including interpretations of laboratory, radiology, and other diagnostic tests, as well as the means to create and maintain a record of the medical decision making process.

E

Description: The results of diagnostic tests may or may not be interpreted by both the ED physician (i.e. ECG, plain radiography) and other physicians (i.e. radiologists or cardiologists). Nevertheless, all ED provider interpretations must be recorded.

E

E

E

Similarly, the development of a differential diagnosis and process used to exclude life-threatening diagnoses must be recorded. Support for documentation also includes medico-legal and billing aspects.

Statement: Generate and record patient specific instructions related to pre- and post-procedural and post- discharge requirements.

Description: When a patient is scheduled for a test, procedure, or discharge, specific instructions about diet, clothing, transportation assistance, convalescence, follow-up with physician, etc., may be generated and recorded, including the timing relative to the scheduled event.

Statement: Manage the admission, discharge, or transfer process for each patient.

Description: Provide a means to create a disposition for the patient.

Statement: Manage the discharge process for patients discharged from the emergency department.

Description: Provide means to create a complete and tailored discharge package for patients discharged from the ED. Includes instructions, prescriptions, and follow up information.

E

E

E

E

E

Statement: Provide scheduled vs. unscheduled follow up for patients discharged from the ED.

Statement: Provide a means to create prescriptions for patients discharged from the ED.

Statement: Provide a means to manage patient admission from the ED to

the inpatient facility. . Description: To facilitate the admission process for patients being admitted to the hospital from the emergency department, the system should permit the clinician to enter a bed request that includes all the information necessary to expedite the admission, including but not limited to admitting physician, specialty or service, type of bed, and special bed needs such as isolation, private room, 1:1 sitter.

Communication with the hospital admitting personnel or system can take many forms. The EDIS itself may provide a list of patients and details in a view designed for hospital admitting. Alternatively, an electronic interface with a hospital bed board or scheduling system may be employed.

Statement: Provide a means to manage patient transfers from ED to another facility.

Statement: Provide a means to manage outstanding patient issues after the ED visit is completed.

Description: After the completion of an encounter, a number of tasks may remain. There may be outstanding laboratory tests (i.e. blood cultures) radiology interpretations, or other tasks such as arrangement of home health aids (VNA), or calls to the patient’s primary care provider during office hours to establish follow-up. There must be a way to track and document these tasks after the patient is discharged and even after clinical documentation has been finalized and signed.

E

O

Statement: Offer prompts to support the adherence to care plans, guidelines, and protocols at the point of information capture.

Description: When a clinician fills out an assessment, data entered triggers the system to prompt the assessor to consider issues that would help assure a complete/accurate assessment. A simple demographic value or presenting problem (or combination) should provide a template for data gathering that represents best practice in this situation, (e.g. prompt for auscultation for murmur and check BP in both arms in a patient with chest pain).

Statement: Offer prompts based on patient-specific data at the point of information capture for assessment purposes.

Description: When a clinician fills out an assessment, data entered is matched against data already in the system to identify potential linkages. For example, the system could scan the medication list and the knowledge base to see if any of the symptoms are side effects of medication already prescribed.

Important diagnoses could be brought to the doctor’s attention, for instance ectopic pregnancy in a woman of child bearing age who has abdominal pain.

E

E

E

O

Statement: Provide support for triage categorization and the triage process.

Description: The categorization of patients by triage priority is highly evidence-based. There are a number of triage classification systems available, and while most are not particularly complex, an EDIS should provide support to the assignment of these triage categories.

Statement: Provide support for prioritizing patients based upon acuity, waiting time, and practitioner load.

Description: Triage is the most fundamental process in emergency department care. Not the collection of data on arriving patients, but the categorization and prioritization of patients who are unable to be seen immediately. Unless an ED has unlimited resources, some patients will invariable need to wait. An EDIS should support the management of these patients by displaying them and supporting decisions by the providers who are caring for them.

Statement: Support the use of appropriate standard care plans, guidelines and/or protocols for the management of specific conditions.

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

Statement: Identify and present the appropriate care plans, guidelines and/or protocols for the management of patient specific conditions that are identified in a patient clinical encounter.

O

Protocols.

E

E

Description: At the time of the clinical encounter (problem identification), recommendations for tests, treatments, medications, immunizations, referrals and evaluations are presented based on evaluation of patient specific data such as age, gender, developmental stage, their health profile, and any site-specific considerations. These may be modified on the basis of new clinical data at subsequent encounters.

Statement: Provide support for the management of patients enrolled in research

Description: The clinician is presented with appropriate protocols for patients participating in research studies, and is supported in the management and tracking of study participants.

Statement: Identify drug interaction warnings at the time of medication ordering.

Description: The clinician is alerted to drug-drug, drug-allergy, and drug-food interactions at levels appropriate to the health care setting and with respect to the patient condition. These alerts may be customized to suit the user or group. If the patient’s condition is one where, in

order to view the necessary components of the health record, patient authorization or consent is required, then the system should show the medication but mask the condition for which the medication is prescribed until the required consent or authorization is available. In an

E

O

emergent situation, where all health information is required to provide the most effective treatment, and it is not possible to obtain an authorization or consent, the system should provide an override function to allow access to the diagnosis or problem for which a medication was ordered. This may vary based on jurisdictional law.

Statement: Identify and present appropriate dose recommendations based on known patient- conditions and characteristics at the time of medication ordering

Description: The clinician is alerted to drug-condition interactions and patient specific contraindications and warnings e.g. pregnancy, breast-feeding or occupational risks, hepatic or renal insufficiency. The preferences of the patient may also be presented e.g. reluctance to use an antibiotic. Additional patient parameters, such as age, gestation, Ht, Wt, BSA, shall also be incorporated

Statement: The system should provide recommendations and options in medication and monitoring on the basis of diagnosis, cost, local formularies or therapeutic guidelines and protocols

E

EF08

Description: Offer alternative medications on the basis of practice standards (e.g. cost or adherence to guidelines), a generic brand, a different dosage, a different drug, or no drug (watchful waiting). Suggest lab order monitoring as indicated by the medication or the medical condition to be affected by the medication. Support expedited entry of series of medications that are part of a treatment regimen, (i.e. rapid sequence intubation, conscious sedation).

Statement: Alert providers to potential administration errors (such as wrong patient, wrong drug, wrong dose, wrong route and wrong time) in support of safe and accurate medication administration and support medication administration workflow.

Description: To reduce medication errors at the time of administration of a medication, the patient is positively identified; checks on the drug, the dose, the route and the time are facilitated. Documentation is a by-product of this checking; administration details and additional patient information, such as injection site, vital signs, and pain assessments, are captured. Access to drug monograph information may be provided to allow providers to check details about a drug and enhance patient education. Workflow for medication administration is supported through prompts and reminders regarding the “window” for timely administration of medications.

Statement:  Medication Reconciliation refers in the US Realm to JCAHO Patient Safety Goal 8, which requires "Accurately and completely reconcile medications across the continuum of care."  The ED has specific needs with respect to medication reconciliation.

E

E

E

Description: Medication reconciliation is the process of identifying the most accurate list of all medications a patient is taking, including drug name, dosage, schedule and route of administration. This data is then used to ensure deliberate and safe continuation, discontinuation, substitution, or new administration of medications throughout the healthcare continuum.

The needs regarding medication reconciliation/administration have been addressed by the principle organizations of Emergency Medicine (ACEP, ENA, AAEM) in communication with JCAHO, which has modified its approach to ED medication reconciliation to avoid to ED delays to timely ED care.

Statement: Capture, maintain and display order sets templates based on patient data or preferred standards or other criteria.

Description: Order sets templates,, which may include medication orders, allow a care provider to choose common orders for a particular circumstance or disease state according to standards or other criteria. Recommended order sets may be presented based on patient data or other contexts.

Statement: Display and request provider validation of information necessary for non-medication orders that make the order pertinent, relevant and resource conservative at the time of provider order entry

O

O

O

Description: Possible order entry support includes, but is not limited to: notification of missing results required for the order, suggested corollary orders, notification of duplicate orders, institution specific order guidelines, guideline-based orders/order sets, order sets, order reference text, patient diagnosis specific recommendations pertaining to the order. Also, warnings for orders that may be inappropriate or contraindicated for specific patients (e.g. X-rays for pregnant women) are presented.

Statement: Evaluate results and notify provider of results within the context of the patient’s healthcare data.

Description: Possible result interpretations include, but are not limited to: abnormal result evaluation/notification, trending of results (such as discrete lab values), evaluation of pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam), evaluation of incoming results against active medication orders.

In most EDIS implementations, the laboratory system generally handles critical alerts. However. It is recognized that in some implementations this may be an EDIS function. Other ways of notification of significantly abnormal results may be developed in the future, including paging, phone, and PDA.

Statement: Evaluate referrals within the context of a patient’s healthcare data.

Description: When a healthcare referral is made, health information, including pertinent clinical and behavioral health results, demographic and insurance data elements (or lack thereof) are presented to the provider. Standardized or evidence based protocols for appropriate workup prior to referral may be presented.

Statement: Evaluate patient data and recommend that a patient be referred based on the specific patient’s healthcare data.

Description: Entry of specific patient conditions may lead to recommendations for referral. For example, a patient with mild hypertension noted during a visit for an unrelated complaint could be recommended for follow up with a primary care physician. A patient who reports tobacco use could automatically be referred for cessation counseling

O

O

E

Statement: Provide checking in real-time for potential blood administration errors.

Description:

To reduce errors at the time of blood product administration, the patient is positively identified. Additionally, checks on blood product identification, amount to be delivered, route and time of administration are captured, and alerts are provided as appropriate.

Statement: Provide checking in real-time to ensure accurate specimen collection is supported.

Description: To ensure the accuracy of specimen collection, the patient and specimen are positively identified. The provider is notified in real-time of potential collection errors such as wrong patient, wrong specimen type, wrong means of collection, wrong site, and wrong date and time.

Statement: Support internal and external epidemiological investigations of clinical health of aggregate patient data for use in identifying health risks from the environment and/or population in accordance with jurisdictional law

Description: Standardized surveillance performance measures that are based on known patterns of disease presentation can be identified by aggregating data from multiple input mechanisms. For example, elements include, but are not limited to patient demographics, resource utilization, presenting symptoms, acute treatment regimens, laboratory and imaging study orders and results and genomic and proteomic data elements. Identification of known patterns of existing diseases involves aggregation and analysis of these data elements by existing relationships. However, the identification of new patterns of disease requires more sophisticated pattern recognition analysis. Early recognition of new patterns requires data points available early in the disease presentation. Demographics, ordering patterns and resource use (e.g., ventilator or intensive care utilization pattern changes) are often available earlier in the presentation of non-predictable diseases. Consumer-generated information is also valuable with respect to surveillance efforts.

E

E

E

Statement: Provide pertinent information from available evidence-based knowledge, at the point of care, for use in healthcare decisions and care planning.

Description: The information available regarding disease, disease processes, diagnostic testing, pharmaceuticals, treatment patterns and all aspects of healthcare is constantly changing. The practitioner should be able to access a wide variety of sources that provide relevant, accurate information about any given subject. Examples of resources include, but are not limited to: evidence on treatment of specific medical conditions, maintenance specific medical conditions, maintenance of wellness, drug or device trials, context specific information available through online journals, printed resources such as books and specialty organizations resources. For example, when a condition is diagnosed the provider might be directed to relevant resources that give updated clinical research, useful pharmaceutical combinations, surgical techniques, products or other information useful in the management of the specific condition under consideration.

Statement: Schedule and manage tasks with appropriate timeliness.

Description: Since the electronic health record will replace the paper chart, tasks that were based on the paper artifact must be effectively managed in the electronic environment. Functions must exist in the EHR-S that support electronically any workflow that previously depended on the existence of a physical artifact (such as the paper chart, a phone message slip) in a paper based system. Tasks differ from other more generic communication among participants in the care process because they are a call to action and target completion of a specific workflow in the context of a patient's health record (including a specific component of the record). Tasks also require disposition (final resolution). The initiator may optionally require a response. For example, in a paper based system, physically placing charts in piles for review creates a physical queue of tasks related to those charts. This queue of tasks (for example, a set of patient phone calls to be returned) must be supported electronically so that the list (of patients to be called) is visible to the appropriate user or role for disposition. Tasks are time-limited (or finite). The state transition (e.g. created, performed and resolved) may be managed by the user explicitly or automatically based on rules. For example, if a user has a task to signoff on a test result, that task should automatically be marked complete by the EHR when the test result linked to the task is signed in the system. Patients will become more involved in the care process by receiving tasks related to their care. Examples of patient related tasks include acknowledgement of receipt of a test result forwarded from the

Statement: Assignment, delegation and/or transmission of tasks to the appropriate parties

E

E

Description: Tasks are at all times assigned to at least one user or role for disposition. Whether the task is assignable and to whom the task can be assigned will be determined by the specific needs of care setting. Task-assignment lists help users prioritize and complete assigned tasks. For example, after receiving orders on multiple patients, the RN should be provided with a list of tasks that have been assigned to him or her. These tasks, (i.e. blood draw) can then be routed to other providers in the ED (i.e. technologist). To facilitate workflow, display of tasks by provider is helpful, so that tasks may be routed to providers who are free and available.

Task creation and assignment may be automated, where appropriate. An example of a system-triggered task is when lab results are received electronically; a task to review the result is automatically generated and assigned to the licensed practitioner. Proper task assignment ensures that all tasks are disposed of by the appropriate person or role and allows efficient interaction of entities in the care process.

Statement: Linkage of tasks to patients and/or a relevant part of the electronic health record.

Description: Clinical tasks must include information or provide an electronic link to information that is required to complete the task. For example, upon ordering an ECG, two separate tasks are automatically created 1) to obtain and ECG on a particular patient, and 2) for the physician to record an interpretation.

Statement: Track tasks to facilitate monitoring for timely and appropriate completion of each task.

Description: In order to reduce the risk of errors during the care process due to missed tasks, the provider is able to view and track un-disposed tasks, current work lists, the status of each task, unassigned tasks or other tasks where a risk of omission exists. The timeliness of certain tasks can be tracked, and backlogs identified.

For example, a the provider responsible for obtaining ECGs is presented with a list of patients requiring an ECG. Ideally this list should be available to all providers working in the ED so that other provider are able to assist when backlogs occur.

E

E

Statement: Manage and Support Communication between Providers.

Description: ED care requires secure communications among various providers: doctors, nurses, pharmacy and laboratory personnel, consultants, etc. An effective EDIS should support communication by all participants (outside of the scope of order or task fulfillment) to provide automatic tracking and reporting of this communication.

The list of communication participants is determined by the care setting and may change over time. Because of concerns about scalability of the specification over time, communication participants are not enumerated here because it would limit the possibilities available to each care setting and implementation. However, communication between providers and between patients and providers will be supported in all appropriate care settings and across care settings. Implementation of an EDIS enables new and more effective channels of communication, significantly improving efficiency and patient care. The communication functions of the EDIS will eventually change the way participants collaborate and distribute the work of patient care.

Statement: Support exchange of information between providers as part of the patient care process, and the appropriate documentation of such exchanges. Support secure communication to protect the privacy of information as required by federal or jurisdictional law.

Description: Communication among providers involved in the care process can range from real time communication (for example, fulfillment of an injection while the patient is in the exam room), to asynchronous communication (for example, consult reports between physicians).

The system should provide for both verbal and written communication. These exchanges would include but not limited to discussions with primary care physicians, other care providers, or the communication from one ED provider to another that a task has been completed.

E

EF

E

Statement: Provide a means to capture and maintain requests for consultation and responses.

Description: The EDIS should have an easy means to document and note calls made to consultants, as well as their responses. This includes the time of the initial and any subsequent pages or calls, the time and method whereby the consultant responded, as well as the final disposition of the consultation.

Statement: Provide features to enable secure bidirectional communication of information electronically between practitioners and pharmacies or between practitioner and intended recipient of pharmacy orders.

Description: When a medication is prescribed, the order is routed to the pharmacy or other intended recipient of pharmacy orders. This information is used to avoid transcription errors and facilitate detection of potential adverse reactions. If there is a question from the pharmacy, that communication can be presented to the provider with their other tasks. The transmission of prescription data between systems should conform to realm acceptable messaging standards. As an example, specific standards in the United States include the most recent versions of criteria from Health Level 7 (HL7), X12N, and/or the National Council for Prescription Drug Programs (NCPDP); and those of the National Electronic Claims Standard (NeCST) in Canada. It is anticipated that other realms may list other acceptable messaging standards.

Statement: Facilitate access to educational or support resources pertinent to and usable by the patient or patient representative.

Description: The provider or patient is presented with a library of educational materials. Material may be made available in the language or dialect understood by the patient or representative. Material should be at the level of the patient or representative’s level of understanding and sensory capability. Special needs are documented. Material may be disseminated via a mode available to and acceptable by the patient e.g., printed, electronically or otherwise. The review of material between a provider and the patient, and the patient’s understanding of the review, is documented.

O

SUPPORT FUNCTIONS - EDIS HL7 EHR-S FUNCTIONAL PROFILEEF

10

10

E

Statement: Support communication and presentation of data captured from medical devices.

Description: Communication with medical devices is supported. Examples include: vital signs, pulse-oximetry, telemetry, ventilators, point of care testing devices, and bar code facilitated artifacts (patient IDs, medications, demographics, billing codes, history, and identification, etc).

Statement: Enable the automated transfer of formatted demographic and clinical information to and from local disease specific registries (and other notifiable registries) for patient monitoring and subsequent epidemiological analysis.

Description: The user can export personal health information to disease specific registries, other notifiable registries such as immunization registries, through standard data transfer protocols or messages. The user can update and configure communication for new registries.

Statement: Maintain, or provide access to, current provider information.

Description: An EDIS must provide the ability to manage multiple registries of personnel, including ED staff, other users of the system, and providers both internal and external to the ED and healthcare organization for the purposes facilitating communication, referral, and follow up on patients. Examples include on-call lists, primary care or specialty referral lists, as well as other healthcare facilities that may send or receive patients from the host ED.

Statement: Provide a current registry or directory of practitioners that contains data needed to determine levels of access required by the system.

Description: Provider information may include any credentials, certifications, or any other information that may be used to verify that a practitioner is permitted to use or access authorized data.

O

O

E

E

E

E

Statement: Provide provider location or contact information on a facility's premises.

Description: The identification of provider’s location within a facility may facilitate the handling of critical care situations. This may include the location of on site practitioners by name or immediate required specialty. A real-time tracking system may provide automatic update of such information.

Statement: Provide provider location or contact information when on call.

Description: The provider immediate contact information. This may include on call practitioners on a facility’s premises as well as on call contact information after scheduled working hours.

Statement: Provide locations or contact information for the provider in order to direct patients or queries.

Description: Providers may have multiple locations or offices where they practice. The system should maintain information on the primary location, any secondary locations, as well as the scheduled hours at each location. Information maintained may include web sites, maps, office locations, etc.

Statement: Provide a current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions.

Description: The patient directory may capture information including but not limited to, full name, address or physical location, alternate contact person, primary phone number, and relevant health status information. The view of this information may vary based on purpose. Several specific directory views are described in the following functions.

Statement: Support interactions with other systems, applications, and modules to enable the maintenance of updated demographic information in accordance with realm-specific recordkeeping requirements.

Description: The minimum demographic data set must include the data required by realm-specific laws governing health care transactions and reporting. For example, this may include data input of death status information, or may include support to identify multiple names, such as updating from Baby Girl Doe, to neonate's given name.

Statement: Provide the patient’s location information within a facility’s premises.

E

E

E

Description: This function is intended to support maintaining and/or providing access to information on the patient’s location during an episode of care. This function can be a as simple as displaying the assigned bed for a patient (i.e. “Room 3” or “Hallway 4” ). It can also be a function that supports real-time information on the patient location as they receive ancillary services in other parts of a facility (i.e. “Radiology”).

Patients who have not consented to share information still need to be tracked and treated, and provisions should be available to manage these patients within the system.

Statement: Manually or automatically (i.e. passively) track patient physical location throughout the ED visit.

Description: It is imperative to identify the current location of patient and to record the history of the patient’s movement through the ED visit. Milestones or benchmarks of ED throughput (i.e. triage time, registration time, in-room time, disposition time, and departure time) should be automatically captured based on business logic behind location and room types whenever possible, and not require additional input from the user. Patient physical location and progress through the encounter are not necessarily related. For instance, a patient may be placed in a hallway chair instead of a room, however this placement would be recorded as the time the patient entered the treatment area (aka “In Room Time”).

Statement: Provide means to describe the ED physically and organizationally including, but not limited to multiple departments (adult, pediatric), multiple treatment areas (acute, non-acute, fast track), treatment room names, holding areas, and areas outside the ED (radiology, special procedures, dialysis unit) and to and manage locations, descriptions, and rules.

Description: In order to manage the process of describing the patient’s physical location in the ED, and to track and report patient flow, it is necessary to manage the description and business logic behind ED layout, configuration, and description. Unique views of the department, waiting room, and other areas for which status is of importance is required to facilitate relevant communication and to administratively report and manage patient flow and maximize ED throughput.

EF

10

10

EF

11

11

11

EF

10

10

Larger EDs may have multiple departments, locations, areas and waiting rooms. The system must be able to accurately represent each department in which it is deployed.

ED Flow is dependent on readying new rooms, changing linen, and making the room availability known. Providers should have a means to flag rooms as reserved, clean, dirty, or unavailable for other reasons.

In cases of mass casualty or significant surge, he system should allow for the management of patients in hallways, as well as the creation, dissolution of beds or other areas in hallways and other “temporary” locations.

Statement: Support interactions with other systems, applications, and modules to ensure that the patient's bed assignments within the facility optimize care and minimize risks e.g. of exposure to contagious patients.

Description: Access to a list of available beds is important to safely manage the care of patients whose bed requirements may change based on change in condition or risk factors. For example, a patient may need a room with special equipment or to be close to the nursing station or to be in a private room.

Statement: Support interactions with other systems, applications, and modules to provide the necessary data to a scheduling system for optimal efficiency in the scheduling of patient care, for either the patient or a resource/device.

Description: The system may support user access to scheduling systems as required. Relevant clinical or demographic information required in the scheduling process could be linked to the task.

Statement: Support the collection and distribution of local healthcare resource information, through interactions with other systems, applications, and modules, to enable planning and response to extraordinary events such as local or national emergencies.

Description: In times of identified local or national emergencies and upon request from authorized bodies, provide current status of healthcare resources including, but not limited to, available beds, providers, support personnel, ancillary care areas and devices, operating theaters, medical supplies, vaccines, and pharmaceuticals. The intent is to enable the authorized body to distribute or re-distribute either resources or patient load to maximize efficient healthcare delivery. In addition, these functions may also be used for internal assessment and planning purposes by facility administrators.

10

O

E

E

E

Statement: Support user-defined information views.

Description: Views of the information can be tailored for or by the user (or department or "job classification”) for their presentation preferences, within local or facility established rules. For example, a nursing supervisor may elect or prefer to see summary data on all patients as the default view. However, it is unproven whether customized views are advantageous to overall ED operations. For example, a view of the ED that does not include the waiting room may not alert providers that a backlog exists.

Statement: Support measurement and monitoring of care for relevant purposes.

Description:

Statement: Support the capture and subsequently export or retrieval of data necessary for the reporting on patient outcome of care by population, facility, provider or community.

Description: Many regions require regular reporting on the healthcare provided to individuals and populations. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software. The system should also provide the functionality to prompt for the collection of necessary information at the appropriate time in a patient encounter if such collection need can be properly defined in a supportive workflow. For instance, the collection of data such as pain scores as required by regulatory agencies.

Statement: Support the capture and subsequent export or retrieval of data necessary to provide quality, performance, and accountability measurements which providers, facilities, delivery systems, and communities are held accountable.

E

E

E

Description: Many regions require regular reporting on the healthcare provided to individuals and populations. These reports may include measures related to process, outcomes, costs of care, may be used in 'pay for performance' monitoring and adherence to best practice guidelines. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software.

Statement: Support the export of data or access to data necessary for report generation and ad hoc analysis.

Description: Providers and administrators need access to data in the EDIS for the generation of both standard and ad hoc reports. These reports may be needed for clinical, administrative, and financial decision-making, as well as for patient use. Reports may be based on structured data and/or unstructured text from the patient's health record.

Statement: Support the definition of the formal health record, a partial record for referral purposes, or sets of records for other necessary disclosure purposes.

Description: Provide hardcopy and electronic output that fully chronicles the healthcare process, supports selection of specific sections of the health record, and allows healthcare organizations to define the report and/or documents that will comprise the formal health record for disclosure purposes. A mechanism should be provided for both chronological and specified record element output. This may include defined reporting groups (i.e. print sets). For example: Print Set A = Patient Demographics, History & Physical, Consultation Reports, and Discharge Summaries. Print Set B = all information created by one caregiver. Print Set C = all information from a specified encounter.

Statement: Provide report generation features using tools internal or external to the system, for the generation of standard reports.

Description: Providers and administrators need access to data in the EDIS for clinical, administrative, financial decision-making, audit trail and metadata reporting, as well as to create reports for patients.

E

E

Systems may use internal or external reporting tools to accomplish this (i.e. Crystal Reports). Reports may be based on structured data and/or unstructured text from the patient's health record. Users need to be able to sort and/or filter reports. For example, the user may wish to view only male patients over 35 with a complaint of chest pain.

Statement: Create reports of ED throughput and efficiency based upon key milestones (points of time) captured of during the ED visit.

Description: Key point of time include arrival time; treatment area entrance time, MD contact time; decision to admit, discharge or transfer time; and departure (left ED) time. Important intervals include, but are not limited to the “door to doctor time”, “doctor to diction time”, “admission to bed availability or departure” as well as overall length of stay. Other measures of ED performance include the numbers of patients who leave without being seen or before treatment is completed.

These reports are central to ED function and need to be available in a focused fashion.

Statement: Provide support for ad hoc query and report generation using tools internal or external to the system.

Description: Providers and administrators need to respond quickly to new requirements for data measurement and analysis. This may be as a result of new regulatory requirements or internal requirements. This requires that users be able to define their own query parameters and retain them. The data may be found in both structured and unstructured data. Providers and administrators also need to query for the absence of specific clinical or administrative data. For example, the Quality Control department may be reviewing whether or not the protocol for antibiotic administration within four hours of arrival in patients with community acquired pneumonia has been followed. To be accurate, the report would need to identify all patients with an admission diagnosis of pneumonia, whether or not they received an antibiotic in the ED, and the time to antibiotic administration—if any.

E

(1) The health record,

(2) Public health, financial and administrative reporting, and

(3) The healthcare delivery process.

E

E

Statement: Support the definition of “Manage” and document the health care needed and delivered during an encounter/episode of care.

Description: Using data standards and technologies that support interoperability, encounter management promotes patient centered care and enables real time, immediate point of service, point of care by facilitating efficient work flow and operations performance to ensure the integrity of:

This support is necessary for direct care functionality that relies on providing user interaction and workflows, which are configured according to clinical protocols and business rules based on encounter specific values such as care setting, encounter type (inpatient, outpatient, home health, etcetera), provider type, patient's EHR, health status, demographics, and the initial purpose of the encounter.

Statement: Provide patients clinical data to support administrative and financial reporting.

Description: A user can generate a bill based on health record data. Maximizing the extent to which administrative and financial data can be derived or developed from clinical data will lessen provider reporting burdens and the time it takes to complete administrative and financial processes such as claim reimbursement. This may be implemented by mapping of clinical terminologies in use to administrative and financial terminologies.

Statement: Where not covered above, provide the means to manage and organize the documentation of the health care needed and delivered during an encounter/episode of care.

Description: The creation of a record of care in the ED is a time-critical and essential component of an EDIS. EDs and EDIS vary widely in their methods for documenting the content of an encounter. Changes in technology may make this documentation easier, and in certain EDs, the labor of documentation may be passed to scribes or other assistants. Regardless of how captured, each piece of record content is the responsibility of a particular provider, and the record must reflect this fact.

E

E

O

EF

11

11

11

Statement: Support extraction, transformation and linkage of information from structured data and unstructured text in the patient's health record for care management, financial, administrative, and public health purposes.

Description: Using data standards and technologies that support interoperability, information access functionalities serve a number of roles whereby information gathered from the encounter is used to support additional uses. These uses may include physician and facility financial coding and billing.

Statement: Make available all pertinent patient information needed to support coding of diagnoses, procedures and outcomes.

Description: The user is assisted in coding information for clinical reporting reasons. For example, a professional coder may have to code the principal diagnosis in the current, applicable ICD as a basis for hospital funding. All diagnoses and procedures during the episode may be presented to the coder, as well as the applicable ICD hierarchy containing these codes.

Statement: Provide financial and administrative coding assistance based on the structured data and unstructured text available in the encounter documentation.

Description: The user is assisted in coding information for billing or administrative reasons. For example, the HIPAA 837 Professional claim requires the date of the last menstrual cycle for claims involving pregnancy. To support the generation of this transaction, the provider would need to be prompted to enter this date when the patient is first determined to be pregnant, then making this information available for the billing process.

Statement: Support interactions with other systems, applications, and modules to enable the use of cost management information required to guide users and workflows.

Description: The provider is alerted or presented with the most cost-effective services, referrals, devices and etcetera, to recommend to the patient. This may be tailored to the patient's health insurance/plan coverage rules. Medications may be presented in order of cost, or the cost of specific interventions may be presented at the time of ordering.

EF

O

EF

9

9

9

9

EF

Statement: Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care.

Description: The EDIS should capture the patient health-related information needed for administrative and financial purposes including reimbursement. This information should be captured to pass to administrative or financial processes as by-product of interactions such as order entry, result entry, documentation entry, medication administration charting. As a byproduct of care delivery and documentation: capture and present all patient information needed to support coding. Ideally performs coding based on documentation. Clinical information needed for billing is available on the date of service, reducing revenue cycle time. However, physicians or other providers should not perform additional data entry / tasks exclusively to support administrative or financial processes. For instance, an RN should not be required to manually code procedures that have otherwise been documented.

Statement: Support interactions with other systems, applications, and modules to enable eligibility verification for health insurance and special programs, including verification of benefits and pre-determination of coverage.

Description: Real-time eligibility checking has become more common in the ambulatory care environment. In the ED, this eligibility checking more restricted. However, two places where eligibility checking at the point of care would be helpful to ED providers is in prescribing and in the establishment of follow-up care. In the future, other areas of eligibility checking may become important or relevant to ED care. Since real time eligibility checking is currently employed in some EHR-S, this function should be considered optional. However, the committee believes this function should be considered essential some time in the future.

Statement: Support interactions with other systems, applications, and modules to support the creation of health care attachments for submitting additional clinical information in support of service requests and claims.

Description: Retrieves structured and unstructured data, including but not limited to lab data, imaging data, device monitoring data, and text based data, based on rules or requests for additional clinical information, in support of service requests or claims, at the appropriate juncture in the encounter workflow.

Statement: Support interactions with other systems, applications, and modules to enable the creation of claims and encounter reports for reimbursement.

10

10

E

E

E

E

Description: Retrieves information needed to support claims and encounter reporting. This reporting occurs at the appropriate juncture in the encounter workflow in a manual or automated fashion. For example this could occur at an initial, interim or final billing. The system may also present the information that is provided for audit and review by local authorities.

Statement: Support the creation of health service reports at the conclusion of an episode of care. Support the creation of health service reports to authorized health entities, for example public health, such as notifiable condition reports, immunization, cancer registry and discharge data that a provider may be required to generate at the conclusion of an episode of care.

Description: Effective use of this function means that providers do not perform additional data entry to support health management programs and reporting.

Statement: Provide the data necessary to support and manage patient acuity/severity for illness/risk-based adjustment of resources.

Description: Research has been done on staffing and patient outcomes which indicates that staffing has a definite and measurable impact on patient outcomes, medical errors, length of stay, nurse turnover, and patient mortality.

Acuity data helps determine what is, indeed, appropriate staffing. Also, acuity and severity data is routinely the evidential basis most frequently cited by staff when recommending clinical staffing changes.

Statement: Update EHR supportive content using a manual or automated process.

Description: EDIS content such as discharge instructions, clinical guidelines, formularies, and other knowledge bases should be maintainable and updatable independent of a particular encounter. For large databases, automated updates should be possible. For example, addition, deletion or update of discharge instructions could be a manual process. However, replacement of an entire discharge instruction set should be automatic. Addition of a particular therapy to a clinical guideline or order set could be a manual process, but removal of a recalled medication from all order sets should be an automated process.

Statement: Facilitate and/or perform updates of clinical decision support system guidelines and associated reference material.

O

O

INFRASTRUCTURE FUNCTIONSE

E

Description: Clinical decision support rules may be applied to the system using a manual process. As standards are developed to represent these rules, an automated update will be recommended. Any process to update decision support rules should include the verification of the appropriateness of the rules to the system. This may include but not be limited to authenticity of the source, the currency of the version, and any necessary approvals before updates can take place.

Statement: Receive and validate formatted inbound communications to facilitate and/or perform updating of patient education material.

Description: Materials may include information about a diagnosis, recommended diets, associated patient health organizations, or web links to similar educational information. These materials may be provided electronically and may require validation prior to inclusion in the system.

Statement: Receive and validate formatted inbound communications to facilitate updating of public health reporting guidelines.

Description: Information and reporting requirements from outside groups, such as public health organizations, may be made available to patient care providers. Examples may include requirements to report on new disease types, or changes to reporting guidelines. The information in these public health updates may be applied to the system so that appropriate data can be collected and reported to comply with requirements.

Statement: Secure the access to an EHR-S and EHR information. Manage the sets of access control permissions granted within an EHR-S. Prevent unauthorized use of data, data loss, tampering and destruction.

Description: To enforce security, all EHR-S applications must adhere to the rules established to control access and protect the privacy of EHR information. Security measures assist in preventing unauthorized use of data and protect against loss, tampering and destruction. An EHR-S must be capable of including or interfacing with standards-conformant security services to ensure that any Principal (user, organization, device , application, component, or object) accessing the system or its data is appropriately authenticated, authorized and audited in conformance with local and/or jurisdictional policies. An EHR-S should support Chains of Trust in respect of authentication, authorization, and privilege management, either intrinsically or by interfacing with relevant external services.

Statement: Authenticate EHR-S users and/or entities before allowing access to an EHR-S.

E

Description: Both users and applications are subject to authentication. The EHR-S must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement may need to be in place. Examples of entity authentication include: Username/ password; Digital certificate; Secure token; Biometrics.

Statement: Manage the sets of access control permissions granted to entities that use an EHR-S (EHR-S Users). Enable EHR-S security administrators to grant authorizations to users, for roles, and within contexts. A combination of these authorization categories may be applied to control access to EHR-S functions or data within an EHR-S, including at the application or the operating system level.

Description: EHR-S Users are authorized to use the components of an EHR-S according to their identity, role, work-assignment, location and/or the patient’s present condition and the EHR-S User’s scope of practice within a legal jurisdiction.

·   User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is a patient defined denial of access to all or part of a record to a particular party for privacy related reasons. Another user based authorization is for a tele-monitor device or robotic access to an EHR-S for prescribed directions and other input.

·   Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device (tele-monitor or robotic); or a nurse, dietician, administrator, legal guardian, and auditor.

·   Context-based Authorization is defined by ISO 10181-3 Technical Framework for Access Control Standard as security relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For example, an EHR-S might only allow supervising providers’ context authorization to attest to entries proposed by residents under their supervision. In addition to the ISO standard, context authorization for an EHR-S is extended to satisfy special circumstances such as, work assignment, patient consents and authorizations, or other healthcare-related factors. A context-based example is a patient-granted authorization to a specific third party for a limited period to view specific EHR records. Another example is a right granted for a limited period to view those, and only those, EHR records connected to a specific topic of investigation.

E

E

E

Statement: Verify and enforce access control to all EHR-S components, EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource.

Description: Entity Access Control is a fundamental function of an EHR-S. To ensure that access is controlled, an EHR-S must perform authentication and authorization of users or applications for any operation that requires it and enforce the system and information access rules that have been defined.

Statement: Enable a healthcare delivery organization to allow and manage a patient’s access to the patient’s personal health information.

Description: A healthcare delivery organization will be able to manage a patient’s ability to view his or her EHR based on scope of practice, organization policy or jurisdictional law. Typically, a patient has the right to view his or her EHR and the right to place restrictions on who can view parts or the whole of that EHR. For example, in some jurisdictions, minors have the right to restrict access to their data by parents/guardians.

One example of managing a patient’s access to his or her data is by extending user access controls to patients.

Statement: Limit an EHR-S user’s ability to deny (repudiate) the origination, receipt, or authorization of a data exchange by that user.

Description: An EHR-S allows data entry and data access to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non repudiation guarantees that the source of the data record can not later deny that it is the source; that the sender or receiver of a message cannot later deny having sent or received the message. An EHR-S allows data entry and data access to a patient’s electronic health record, and it can be a sender of healthcare information, and a receiver of healthcare information. Non-repudiation is a way to guarantee that the source of data/record can not later deny that fact, that the sender of a message cannot later deny having sent the message, and that the recipient cannot deny having received the message. For example, non-repudiation may be achieved through the use of a:

·   Digital signature, which serves as a unique identifier for an individual (much like a written signature on a paper document).

E

E

·   Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent and/or received) and

·   Timestamp, which proves that a document existed at a certain date and time.

Statement: Secure all modes of EHR data exchange.

Description: Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation as well as both destination and source authentication when necessary. For example, it may be necessary to encrypt data sent to remote or external destinations. A secure data exchange requires that there is an overall coordination regarding the information coordination regarding the information that is exchanged between EHR-S entities and how that exchange is expected to occur.

The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within an EHR-S or external to an EHR-S.

Statement: Route electronically exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

Description: An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange.

Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP addresses or recordings of DNS names. For dynamic determination of known sources and destinations systems can use authentication mechanisms as described in IN.1.1.

For example, the sending of a lab order from the EHR-S to a lab system within the same organization usually uses a simple static setup for routing. In contrast sending a lab order to a reference lab outside of the organization will involve some kind of authentication process. In general, when the underlying network infrastructure is secure (e.g. secure LAN or VPN) the simple static setup is used.

E

E

Statement: Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with incoming or outgoing information.

Description: The purpose of attestation is to show authorship and assign responsibility for an act, event, condition, opinion, or diagnosis. Every entry in the health record must be identified with the author and should not be made or signed by someone other than the author. (Note: A transcriptionist may transcribe an author's notes and a senior clinician may attest to the accuracy of another's statement of events.) Attestation is required for (paper or electronic) entries such as narrative or progress notes, assessments, flow sheets, and orders. Digital signatures may be used to implement document attestation. For an incoming document, the record of attestation is retained if included. Attestation functionality must meet applicable legal, regulatory and other applicable standards or requirements.

Statement: Enable the enforcement of the applicable jurisdictional and organizational patient privacy rules as they apply to various parts of an EHR-S through the implementation of security mechanisms.

Description: Patients’ privacy and the confidentiality of EHRs are violated if access to EHRs occurs without authorization. Violations or potential violations can impose tangible economic or social losses on affected patients and providers, as well as less tangible feelings of vulnerability and pain. Fear of potential violations discourages patients from revealing sensitive personal information that may be relevant to diagnostic and treatment services. Rules for the protection of privacy and confidentiality may vary depending upon the vulnerability of patients and the sensitivity of records. Strongest protections should apply to the records of minors and the records of patients with stigmatized conditions. Authorization to access the most sensitive parts of an EHR is most definitive if made by the explicit and specific consent of the patient.

E

E

E

E

Statement: Keep patient identities and conditions invisible to the public and other providers who do not have “need to know” on public tracking screens.

Description: A number of systems implementation large tracking screens, common displays or dashboards to support workflows. In these applications, there is a need to create de-identified views for broadcast in common areas.

Statement: Flag patient identity as confidential to others.

Description: Create a flag to indicate to all providers caring for the patient, as well as administrative staff who may receive phone calls from family members or others, the need to protect the identity of patients at risk of harm, or requesting similar anonymity. Despite best efforts of confidentiality, display should identify patients at particular risk of harm during stay (e.g. domestic violence).

Statement: Manage EHR information across EHR-S applications by ensuring that clinical information entered by providers is a valid representation of clinical notes; and is accurate and complete according to clinical rules and tracking amendments to clinical documents. Ensure that information entered by or on behalf of the patient is accurately represented.

Description: Since EHR information will typically be available on a variety of EHRS applications, an EHR-S must provide the ability to access, manage and verify accuracy and completeness of EHR information, maintain the integrity and reliability of the data, and provide the ability to audit the use of and access to EHR information.

Statement: Retain, ensure availability, and destroy health record information according to scope of practice, organizational policy, or jurisdictional law. This includes: -Retaining all EHR-S data and clinical documents for the time period designated by policy or legal requirement; -Retaining inbound documents as originally received (unaltered); -Ensuring availability of information for the legally prescribed period of time to users and patients; and -Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally prescribed retention period.

Description: Discrete and structured EHR-S data, records and reports must be: -Made available to users in a timely fashion; -Stored and retrieved in a semantically intelligent and useful manner (for example, chronologically, retrospectively per a given disease or event, or in accordance with business requirements, local policies, or legal requirements); -Retained for a legally prescribed period of time; and -Destroyed in a systematic manner in relation to the applicable retention period. An EHR-S must also allow an organization to identify data/records to be destroyed, and to review and approve destruction before it occurs. In such a case it should pass along record destruction date info along with the data when providing records to another entity

EStatement: Provide audit capabilities for system access and usage indicating the author, the modification (where pertinent), and the date and time at which a record was created, modified, viewed, extracted, or deleted. Auditable records extend to information exchange, to audit of consent status management (to support DC.1.3.3) and to entity authentication attempts. Audit functionality includes the ability to generate audit reports and to interactively generate audit reports and to interactively view change history for individual health records or for an EHR-S

Description: Audit functionality extends to security audits, data audits, audits of data exchange, and the ability to generate audit reports. Audit capability settings should be configurable to meet the needs of local policies. Examples of audited areas include:

·   Security audit, which logs access attempts and resource usage including user login, file access, other various activities, and whether any actual or attempted security violations occurred;

·   Data audit, which records who, when, and by which system an EHR record was created, updated, translated, viewed, extracted, or (if local policy permits) deleted. Audit-data may refer to system setup data or to clinical and patient management data;

·   Information exchange audit, which records data exchanges between EHR-S applications (for example, sending application; the nature, history, and content of the information exchanged); and information about data transformations (for example, vocabulary translations, reception event details, etc.).

There is a requirement for system audit trails for the following events:

Audit reports should be flexible and address various users' needs. For example, a legal authority may want to know how many patients a given healthcare provider treated while the provider's license was suspended. Similarly, in some cases a report detailing all those who modified or viewed a certain patient record

Security audit trails and data audit trails are used to verify enforcement of business, data integrity, security, and access-control rules.

·   Loading new versions of, or changes to, the clinical system; Loading new versions of codes and knowledge bases; >Taking and restoring of backup;

·   Changing the date and time where the clinical system allows this to be done; >Archiving any data;

·   Re-activating of an archived patient record;

·   Entry to and exiting from the clinical system;

·   Remote access connections including those for system support and maintenance activities

E

-Interaction with entity directories;

-Linkage of received data with existing entity records;

-Location of each health record component; and

-Communication of changes between key systems.

E

Statement: Maintain synchronization involving:

Description: An EHR-S may consist of a set of components or applications; each application manages a subset of the health information. Therefore it is important that, through various interoperability mechanisms, an EHR-S maintains all the relevant information regarding the health record in synchrony. For example, if a physician orders an MRI, a set of diagnostic images and a radiology report will be created. The patient demographics, the order for MRI, the diagnostic images associated with the order, and the report associated with the study must all be synchronized in order for the clinicians to view the complete record.

Statement: Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions may be used to exchange data and provide reports for primary and ancillary purposes.

Description: An EHR-S enables an authorized user, such as a clinician, to access and aggregate the distributed information, which corresponds to the health record or records that are needed for viewing, reporting, disclosure, etc.

An EHR-S must support data extraction operations across the complete data set that constitutes the health record of an individual and provide an output that fully chronicles the healthcare process. Data extractions are used as input to patient care coordination between facilities, organizations and settings. In addition, data extractions can be used for administrative, financial, research, quality analysis, and public health purposes.

E

General examples of unstructured health record information include:

- text

- word processing document

- image

- multimedia

Specific examples include:

- text message to physician

- patient photo

- letter from family

- scanned image of insurance card

- dictated report (voice recording)

Examples of structured health information include:

- patient address (non-codified, but discrete field)

- diastolic blood pressure (numeric)

- coded result observation

- coded diagnosis

- patient risk assessment questionnaire with multiple-choice answers

E

Statement: Store and manage health record information as structured and unstructured data

Description: Unstructured health record information is information that is not divided into discrete fields AND not represented as numeric, enumerated or codified data.

Structured health record information is divided into discrete fields, and may be enumerated, numeric or codified.

Context may determine whether or not data are unstructured, e.g., a progress note might be standardized and structured in some EHR-S (e.g., Subjective/Objective/Assessment/Plan) but unstructured in others.

Managing healthcare data includes capture, retrieval, deletion, correction, amendment, and augmentation.

Augmentation refers to providing additional information regarding the healthcare data, which is not part of the data itself, e.g. linking patient consents or authorizations to the healthcare data of the patient.

Statement: Create, capture, and maintain unstructured health record information

Description: A number of documents are created that are unstructured such as signed consent or DNR forms. These forms must be managed with the patient’s record including identifying updates, or when a document is superseded by another.

E

E

Statement: Create, capture, and maintain structured health record information

Description: Clinical information has value beyond the immediate presentation in the ED as many problems are acute on chronic events or involve multiple care-givers in disparate settings. Additionally, analysis of performance is better made when using structured documentation.

Statement: Enable the use of registry services and directories to uniquely identify, locate and supply links for retrieval of information related to: retrieval of information related to: - patients and providers for healthcare purposes; - payers, health plans, sponsors, and employers for administrative and financial purposes; - public health agencies for healthcare purposes, and - healthcare resources and devices for resource management purposes.

E

Description: Registry and directory service functions are critical to successfully managing the security, interoperability, and the consistency of the health record data across an EHR-S. These services enable the linking of relevant information across multiple information sources within, or external to, an EHR-S for use within an application. Directories and registries support communication between EHR Systems and may be organized hierarchically or in a federated fashion. For example, a patient being treated by a primary care physician for a chronic condition may become ill while out of town. The new provider’s EHR-S interrogates a local, regional, or national registry to find the patient’s previous records. From the primary care record, a remote EHR-S retrieves relevant information in conformance with applicable patient privacy and confidentiality rules. An example of local registry usage is an EHR-S application sending a query message to the Hospital Information System to retrieve a patient’s demographic data.

Statement: Support semantic interoperability through the use of standard terminologies, standard terminology models and standard terminology services.

Description: The purpose of supporting terminology standards and services is to enable semantic interoperability. Interoperability is demonstrated by the consistency of human and machine interpretation of shared data and reports. It includes the capture and support of consistent data for templates and decision support logic. Terminology standards pertain to concepts, representations, synonyms, relationships and computable (machine-readable) definitions. Terminology services provide a common way for managing and retrieving these items.

E

E

Statement: Employ standard terminologies to ensure data correctness and to enable semantic interoperability (both within an enterprise and externally). Support a formal standard terminology model.

Description: Semantic interoperability requires standard terminologies combined with a formal standard information model. An example of an information model is the HL7 Reference Information model. Examples of terminologies that an EHR-S may support include: LOINC, SNOMED, ICD-9, ICD-10, and CPT-4. A terminology provides semantic and computable identity to its concepts. Terminologies are use-case dependent and may or may not be realm dependent. For example, terminologies for public health interoperability may differ from those for healthcare quality, administrative reporting, research, etc. Formal standard terminology models enable common semantic representations by describing relationships that exist between concepts within a terminology or in different terminologies, such as exemplified in the model descriptions contained in the HL7 Common Terminology Services specification. The clinical use of standard terminologies is greatly enhanced with the ability to perform hierarchical inference searches across coded concepts. Hierarchical Inference enables searches to be conducted across sets of coded concepts stored in an EHR-S. Relationships between concepts in the terminology are between concepts in the terminology are used in the search to recognize child concepts of a common parent. For example, there may be a parent concept, "penicillin containing preparations" which has numerous child concepts, each of which represents a preparation containing a specific form of penicillin (Penicillin V, Penicillin G, etc). Therefore, a search may be conducted to find all patients taking any form of penicillin preparation. Clinical and other terminologies may

Statement: Enable version control according to customized policies to ensure maintenance of utilized standards. This includes the ability to accommodate changes to terminology sets as the source terminology undergoes its natural update process (new codes, retired codes, redirected codes). Such changes need to be cascaded to clinical content embedded in templates, custom formularies, etc., as determined by local policy

Description: Version control allows for multiple sets or versions of the same terminology to exist and be distinctly recognized over time. Terminology standards are usually periodically updated, and concurrent use of different versions may be required. Since the meaning of a concept can change over time, it is important that retrospective analysis and research maintains the ability to relate changing conceptual meanings. If the terminology encoding for a concept changes over time, it is also important that retrospective analysis and research can correlate the different encodings to ensure the (permanence of the concept. It should be possible to retire deprecated versions when applicable business cycles are completed while maintaining obsolescent code sets. An example use of this is for possible claims adjustment throughout the claim's lifecycle.

E

E

E

Statement: Map or translate one terminology to another as needed by local, regional, national, or international interoperability requirements

Description: The ability to map or translate one terminology to another is fundamental to an organization in an environment where several terminologies are in play with overlapping concepts. It is a common occurrence that data is captured using one terminology, but is shared using another terminology. For example, within a healthcare organization there may be a need to map overlapping terminology concepts (e.g. between an EHR-S and an external laboratory system, ore between an EHR-S and a billing system). Realm specific (including local, regional, national or international) interoperability requirements can also determine the need for terminology mapping, and in many cases terminology mapping services can be used to satisfy these requirements.

Statement: Provide automated health care delivery processes and seamless exchange of clinical, administrative, and financial information through standards- based solutions

Description: Interoperability standards enable an EDIS to operate as a set of applications. This results in a unified view of the system where the reality is that several disparate systems may be coming together. Interoperability standards also enable the sharing of information between EHR systems, including the participation in regional, national, or international information exchanges. Timely and efficient access to information and capture of information is promoted with minimal impact to the user.

Statement: Support the ability to operate seamlessly with other systems, either internal or external, that adhere to recognized interchange standards. “Other systems” include other EHR Systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

A variety of interaction modes are typically supported such as:

EF

09

Description: An organization typically uses a number of interchange standards to meet its external and internal interoperability requirements. It is fundamental that there be a common understanding of rules regarding connectivity, information structures, formats and semantics. These are known as “interoperability or interchange standards”. Data exchange which may be between internal systems or modules, or external to the organization, is to occur in a manner which is seamless to the user. For example, if data interchange involves double entry, or manual cut-and paste steps by the user, it is not considered seamless.

Representation of EHR content is transmitted in a variety of interchange formats such as: HL7 Messages, Clinical Document Architecture (CDA) and other HL7 Structured Documents, X12N healthcare transactions, and Digital Imaging and Communication in Medicine (DICOM) format.

Support for multiple interaction modes is needed to respond to differing levels of immediacy and types of exchange. For example, messaging is effective for many near-real time, asynchronous data exchange scenarios but may not be appropriate if the end-user is requesting an immediate response from a remote application.

·   Unsolicited Notifications, e.g. a patient has arrived for a clinic appointment -Query/Response e.g., Is Adam Everyman known to the system? Yes, MRN is 12345678.

·   Service Request and Response, e.g., Laboratory Order for “Fasting Blood Sugar” and a response containing the results of the test. -Information Interchange between organizations (e.g. in a RHIO, or in a organizations (e.g. in a RHIO, or in a 171 146 National Health System)

·   Structured/discrete clinical documents, e.g., Clinical Note -Unstructured clinical document, e.g., dictated surgical note

Standard terminology is a fundamental part of interoperability and is described in section IN.4. Using a formal explicit information model further optimizes interoperability. An example of an information model is the HL7 Reference Information Model (RIM). Organizations typically need to deal with more than one information model and may need to develop a mapping or a meta-model.

Statement: Support the management of structured documents in support of emergency department operations.

Description: Structured documents represent an important method to facilitate the transfer of information to support care. Structured documents are also used to facilitate care transfers across domains, and to support patient care in RHIO environments. Structured documents have been purposed for the purposes of ED referral, transfer of care between EMS and ED systems, and transfers of care from ED to inpatient providers as well as back to ambulatory providers. Structured medical documents (including medical summaries) may reside in information systems external to the hospital enterprise. These documents are often sent from primary care physicians or clinics.

09

EStatement: Enable version control according to local policies to ensure maintenance of utilized interchange standards. Version control of an interchange standard implementation includes the ability to accommodate changes as the source interchange standard undergoes its natural update process

Description: The life cycle of any given standard results in changes to its requirements. It is critical that an organization know the version of any given standard it uses and what its requirements and capabilities are. For example, if the organization migrates to an HL7 v2.5 messaging standard, it may choose to take advantage of new capabilities such as specimen or blood bank information. The organization may find that certain fields have been retained have been retained for backwards compatibility only or withdrawn altogether. The EHR-S needs to be able to handle all of these possibilities.

Standards typically evolve in such a way as to protect backwards compatibility. On the other hand, sometimes there is little, or no, backwards compatibility when an organization may need to replace an entire standard with a new methodology. An example of this is migrating from HL7 v2 to HL7 v3.

Interchange standards that are backward compatible support exchange among senders and receivers who are using different versions. Version control ensures that those sending information in a later version of a standard consider the difference in information content that can be interchanged effectively with receivers, be interchanged effectively with receivers, who are capable of processing only earlier versions. That is, senders need to be aware of the information that receivers are unable to capture and adjust their business processes accordingly. Version control enables multiple versions of the same interchange standard to exist and be distinctly recognized over time. Since interchange standards are usually periodically updated, concurrent use of different versions may be required. Large (and/or federated) organizations typically need to use different versions of an interchange standard to meet internal organizational interoperability requirements.

For example, the enterprise-wide standard might use HL7 v2.5 for Lab messages, but some regions of the enterprise might be at a lower level. It should be possible to retire deprecated interchange standards versions when interchange standards versions when applicable business cycles are completed while maintaining obsolete versions. An example use of this is for possible claims adjustment throughout the claim’s life cycle.

When interchange standards change over time, it is important that retrospective analysis and research correlate and note gaps between the different versions’ information structures to support the permanence of concepts over time. An example use of this is the calculation of outcome or performance measures from persisted data stores where one version of a relevant interchange standard, e.g., CDA Release 1 captures the relevant data, e.g., discharge.

E

E

E

Statement: Enable standards-based application integration with other systems

Description: When an organization wishes to integrate its applications, they must use standardized methods. Standards-based application integration may be achieved in a variety of ways. For example:

·   Desktop visual integration may be achieved via HL7 Clinical Context Object Workgroup (CCOW) standards

·   Workflow functions may be integrated via The Workflow Management Coalition (WfMC) standards

·   EHR-S may be integrated in an Enterprise Information System Architecture via Service Oriented Architecture (SOA) standards Architecture (SOA) standards.

It is recognized that these examples are very disparate and used for very different purposes. The method used depends on the organization’s approach to application integration. An organization could conceivably use multiple integration approaches.

Statement: Support interactions with entity directories to determine the address, profile and data exchange requirements of known and/or potential partners.

Use the rules of interaction specified in the partner’s interchange agreement when exchanging information.

Description: Systems that wish to communicate with each other, must agree on the parameters associated with that information exchange. Interchange Agreements allow an EHR-S to describe those parameters/criteria. An EHR-S can use the entity registries to determine the security, addressing, and reliability requirements between partners. An EHR-S can use this information to define how data will be exchanged between the sender and the receiver. Discovery of interchange services and capabilities can be automatic. For example:

- A new application can automatically determine a patient demographics source using a Universal Description and Discovery Integration (UDDI) for source discovery, and retrieve the Web Services Description Language (WSDL) specification for binding details.

- Good Health Hospital is a member of AnyCounty LabNet, for sharing laboratory results with other partners. Good Health Hospital periodically queries LabNet's directory (UDDI) to determine if additional information providers have joined LabNet. When new information providers are discovered, the Good Health IT establishes the appropriate service connections based upon the Service Description (WSDL).

Statement: Support EDIS integration, using available and developing interoperability solutions, for the importation and exportation of information to support care delivery and ED operations.

EF

10

EF

10

10

O

E

Description: ED care requires access to and sharing of substantial amounts of information. When deploying an EDIS, certain types of integration need to be supported, based upon the unique needs of the institution. For example, one hospital may elect to integrate the EDIS with the hospital order entry system for all outbound lab, radiology, and pharmacy orders. Others may need to interface to these systems directly. Regardless of how this integration is carried out, certain heuristics of these different order types need to be considered.

Data may be imported into the system to plan care and may be exported to other providers. Documents may be structured or unstructured.

Statement: Interface with bed management information system.

Description: Hospital bed management systems are becoming more prevalent. The system should communicate with bed request system to support the hospital admission process. Bed allocation for admitted patients involves identifying the bed type needed (such as ICU, telemetry, isolation, private or patient’s gender). The announcement of bed type needed mobilizes a series of hospital processes.

Statement: Interface with external pharmacy systems.

Description: The system should support the electronic transfer of prescriptions to outpatient pharmacies. This workflow includes initial transmission of the prescription, verification of receipt and prescription filling. Bas

Statement: Interface with billing information systems

Description: Provide means to send messages to billing systems to support the generation bills for facility, medication, supply and physician services. Frequently, external contractors provide billing services for physician and hospital organizations. Provide a means to send messages to external billing systems to support the generation bills for facility, medication, supply and physician services.

Statement: Manage the ability to create, update, delete, view, and version business rules including institutional preferences. Apply business rules from necessary points within an EHR-S to control system behavior. An EHR-S audits changes made to business rules, as well as compliance to and overrides of applied business rules.

Description: EHR-S business rule implementation functions include: decision support, diagnostic support, workflow control, and access privileges, as well as system and user defaults and preferences. An EHR-S supports the ability of providers and institutions to customize decision support components such as triggers, rules, or algorithms, as well as the wording of alerts and advice to meet realm specific requirements and preferences. Examples of applied business rules include: - Suggesting diagnosis based on the combination of symptoms (flu-like symptoms combined with widened mediastinum suggesting anthrax); - Classifying a pregnant patient as high risk due to factors such as age, health status, and prior pregnancy outcomes; - Sending an update to an immunization registry when a vaccination is administered; - Limiting access to mental health information to authorized providers; - Establishing system level defaults such as for vocabulary data sets to be implemented.; and - Establishing user level preferences such as allowing the use of health information for research purposes.

E

E

Statement: Support workflow management functions including both the management and set up of work queues, personnel lists, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Description: Workflow management functions that an EHR-S supports include:

-Distribution of information to and from internal and external parties; -Support for task-management as well as parallel and serial task distribution;

-Support for notification and task routing based on system triggers; and -Support for task assignments, escalations and redirection in accordance with business rules. Workflow definitions and management may be implemented by a designated application or distributed across an EHRS.

Work and information flow in the ED is naturally asynchronous and done in both parallel and serial modes. Priority of tasks can change over time and as new information is available. Additionally information used to change workflow tasking comes from multiple sources.

Statement: Performance characteristics essential to support or maintain workflow in the ED.

Description: Speed of system response is both an implementation element and a necessity for EHR adoption. It is essential that system response speed fast enough that there are no added delays in workflows in the ED when using the system. This also includes other performance and issues including logins, application timeouts.

Conformance Criteria ID#DC.1

DC.1.1

DC.1.1.1 1. The system SHALL create a single logical record for each patient.

2. The system SHALL provide the ability to create a record for a patient when the identity of the patient is unknown.

3. The system SHALL provide the ability to store more than one identifier for each patient record.

DC.1.1.2

4. The system SHALL associate key identifier information (e.g., system ID, medical record number) with each patient record.

5. The system SHALL provide the ability to uniquely identify a patient and tie the record to a single patient.

6. The system SHALL provide the ability, through a controlled method, to merge or link dispersed information for an individual patient upon recognizing the identity of the patient.

7. When health information has been mistakenly associated with a patient, the system SHALL provide the ability to mark the information as erroneous in the record of the patient in which it was mistakenly associated and represent that information as erroneous in all outputs containing that information.

8. When health information has been mistakenly associated with a patient, the system SHALL provide the ability to associate it with the correct patient.

9. The system SHALL provide the ability to retrieve parts of a patient record using a primary identifier, secondary identifiers, or other information which are not identifiers, but could be used to help identify the patient.

10. The system SHOULD provide the ability to obsolete, inactivate, nullify, destroy and archive a patient's record in accordance with local policies and procedures, as well as applicable laws and regulations.

11. The system SHALL provide a means to enter patients into the system that have been missed or who were seen during system downtime.

1. The system SHALL capture demographic information as part of the patient record.

2. The system SHALL store and retrieve demographic information as discrete data.

3. The system SHALL provide the ability to retrieve demographic data as part of the patient record.

4. The system SHALL provide the ability to update demographic data.

5. The system SHOULD provide the ability to report demographic data.

6. The system SHOULD store historical values of demographic data over time.

7. The system SHALL present a set of patient identifying information at each interaction with the patient record.

8. The system SHALL store, at a minimum, the following information with the patient record:

·   Name

·   Date of birth

·   Administrative gender

·   Internal Patient ID

·   Account number

9. The system SHOULD store:

·   Patient Address(es)

·   Telephone number(s)

DC.1.1.2.1

DC.1.1.2.2

DC.1.1.2.3

·   Emergency Contact Name

·   Emergency Contact Address

·   Emergency Contact Telephone Number

·   Emergency Contact Relationship

·   Primary Practitioner Name

·   Primary Practitioner ID

·   Primary Practitioner Type

·   Primary Practitioner Address

·   Primary Practitioner Telephone Number

·   Primary Practitioner Organization

1.   The system SHALL be able to immediately generate a new encounter at the time of patient arrival.

2.   The system SHALL permit the users to identify a patient’s pre-existing record in the system at the time of arrival.

3.   The system SHOULD permit the user to search by core demographic data including name, DOB, administrative gender, patient ID number and account number.

4.   The system SHOULD provide the ability to retrieve legacy data once the patient is identified.

5.   The system SHALL provide the ability to assign an identity to a patient at the time of arrival.

6.   The system SHALL provide the ability to assign either a previously established identity for the patient or to create a new identity.

7.   The system SHALL provide the ability to create a temporary identity (i.e. John Doe) for the patient.

8.   The system SHALL provide the ability to reconcile temporary identity assignments after care has been initiated, and further information becomes available.

1. The system SHALL provide the ability to receive an account number from the hospital or other ADT system, before additional identifying data is known.

2. The system MAY generate a temporary account number for emergent orders and other

interoperability need, in the absence of an account number from the hospital or other ADT system.

1.   The system shall provide a means to capture data from the hospital ADT system.

DC.1.1.3

DC.1.1.3.1

2.   The system shOULD merge registrations automatically based upon certain rules.

3.   The system shall provide a means to manually merge registrations if automated merge fails or is not employed..

1. The system SHALL provide the ability to capture external data and documentation.

2. IF lab results are received through an electronic interface, THEN the system SHALL receive and store the data elements into the patient record.

3. IF lab results are received through an electronic interface, THEN the system SHALL display them upon request.

4. The system SHOULD provide the ability to receive, store and display scanned documents as images.

5. The system MAY provide the ability to store imaged documents or reference the imaged documents via links to imaging systems.

6. The system SHALL provide the ability to receive, store and present text-based externally-sourced documents and reports.

7. The system MAY provide the ability to receive, store and display clinical result images (such as radiological images) received from an external source.

8. The system MAY provide the ability to receive, store and display other forms of clinical results (such as wave files of EKG tracings) received through from an interface with an external source.

9. The system SHOULD provide the ability to receive, store and display present medication details from an external source.

10. The system SHOULD provide the ability to receive, store and display present structured text-based reports received from an external source.

11. The system SHOULD provide the ability to receive, store and present standards-based (i.e. CDA) structured, codified data received from an external source.

12. The system SHOULD provide a means to link externally stored EMS data to the patient record.

13 The system MAY provide a means to import the EMS run sheet.

14. If electronic capture is not available for EMS data, the system may allow EMS personnel to input EMS data into the system.

15. The system MAY provide a means to electronically capture and audio file of a verbal EMS report.

DC.1.1.3.1.1

DC. 1.1.3.2

clinical data provided on behalf of the patient

verify the accuracy of patient-originated data for inclusion

in the patient record

comment, but not alter, patient-originated data

DC.1.1.3.3

1. The system shall provide a mechanism for the electronic capture of EMS data.

2. The system SHOULD provide the ability to electronically capture patient data including medications, vital signs, and other data as structured data.

3. The system SHOULD provide the ability to electronically capture digitally recorded or transmitted EMS data (i.e. EKG, telemetry, and defibrillator data, display alarms, etc.).

1. The system SHALL capture and explicitly label patient originated data.

2. IF the system provides the ability for direct entry by the patient, THEN the system SHALL explicitly label the data as patient entered

3. The system SHALL capture and label the source of

4. The system SHALL present patient-originated data for use by care providers

5. The system SHALL provide the ability for a provider to

6. The system SHOULD provide the ability to view or

7. The system shall provide the ability to capture patient originated data including, but not limited to, demographics, past medical history, medications, and allergies.

1. The system SHALL provide the ability to capture and label patient health data derived from administrative or financial data.

2. The system SHALL provide the ability to capture and link data about the source of patient health data derived from administrative and financial data with that patient data.

DC.1.2

DC.1.2.1

3. The system SHALL provide the ability to present labeled patient health information derived from administrative or financial data and the source of that data for use by authorized users.

4. The system SHOULD provide the ability to view or comment on patient health information derived from administrative or financial data.

5. The system MAY provide the ability to request correction of the administrative or financial data.

1. The system SHALL provide the ability to capture, update, and present current patient history including pertinent positive and negative elements.

2. The system SHALL display past patient histories.

3. The system MAY provide the ability to capture and present previous external histories.

4. The system MAY provide the ability to capture the relationship between patient and others.

5. The system SHALL capture the complaint, presenting problem or other reason(s) for the visit or encounter.

6. The system SHOULD capture the reason for visit/encounter from the patient's perspective.

7. The system shall provide a means to capture family history and social history.

8. The system shOULD provide a means of clinical documentation for all ED providers.

9. The system shall provide the ability to capture and update new clinical documentation before the patient is registered.

10. The system shall provide a means to distinguish between time of observation and time of data entry.

11. The system shall reconcile documentation made in a non-linear temporal sequence.

12. The system should provide multiple levels of data display (log view versus readable view) vs. not display at all.

1. The system shall provide a means to document data on patients who have been referred to the ED.

2. The system shall capture and display the Source of Referral and the Reason for Referral.

3. The system shALL provide a means to track patients who are en-route to the ED via the EMS system.

DC.1.2.2

DC.1.2.3

DC.1.2.4

4. The system shall display the patient who has been referred to the ED as a referral throughout the ED stay.

5. The system SHOULD allow users to reserve an ED bed and assign human resources, including registration and RN staff to incoming patients.

6. The system shall provide a means to view all pre-arrival data upon arrival.

1. The system shall provide a means to document ED arrival data.

2. The system shall capture and display Time of Arrival and Mode of Arrival. .

3. The system shall link any data captured prior to patient arrival with the record created at the time of arrival.

4.   The system should provide a mechanism to vary the information taken during the arrival process, depending on local practice or patient acuity.

5.   The system SHALL capture the EMS Agency that Transported the Patient if the patient arrived by EMS.

6.   The system SHOULD capture the EMS unit that transported the patient, if the patient arrived via EMS.

1. The system shall provide a means to capture a focused triage assessment.

2. The system shall provide a means to capture a comprehensive triage assessment.

3. The system shall provide a means to capture the initial Chief Complaint.

4. The system SHALL provide a means to capture an initial Presenting Problem.

5. The system SHOULD provide a means to document triage as a narrative.

6. The system SHOULD provide a means to document different data for different complaints.

7. The system SHALL provide a means to capture a Triage Acuity Rating for the patient.

1. The system shall provide a means to capture the history of present illness and review of systems.

DC.1.3.1

DC.1.3.2

Resuscitate” orders.

DC.1.3.3

2. The system shALL provide a means a provider to capture the HPI as narrative text and/or story.

3. The system may provide a means to capture the HPI as discrete data.

4. The system SHOULD provide a means to capture the review of system as discrete data.

1. The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions patient preferences such as language, religion, spiritual practices and culture.

2. The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions family preferences such as language, religion, spiritual practices and culture.

1. The system SHALL provide the ability to indicate that advance directives exist for the patient.

2. The system SHALL provide the ability to indicate the type of advanced directives completed for the patient such as living will, durable power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order”.

3. The system SHOULD provide the ability to capture, present, maintain and make available for clinical decisions patient advance directives documents and “Do Not

4. The system SHOULD conform to function DC.1.1.3.1

(Capture data and documentation from external clinical sources) and capture scanned patient advance directive documents and “Do Not Resuscitate” orders.

6. The system SHOULD provide the ability to indicate the name and relationship of the party completing the advance directive for the patient.

7. The system SHALL time and date stamp advance directives.

8. The system SHOULD provide the ability to document the location and or source of any legal documentation regarding advance directives.

1. The system SHALL provide the ability to indicate that a patient has completed applicable consents and authorizations.

2. The system SHALL provide the ability to indicate that a patient has withdrawn applicable consents and authorizations.

DC.1.4.1

2. The system SHOULD conform to function DC.1.1.3.1 (Capture data and documentation from external clinical sources) and capture scanned paper consent and authorization documents.

3. The system MAY provide the ability to view and complete consent and authorizations forms on-line.

4. The system SHOULD provide the ability to generate printable consent and authorization forms.

5. The system SHOULD display the authorizations associated with a specific clinical activity (procedure, release of information) along with that event in the patient's electronic chart.

6. The system SHOULD provide the ability to document an assent for patients legally unable to consent.

7. The system SHALL provide the ability to document the source of each consent, such as the patient or the patient’s personal representative (guardian/surrogate), if the patient is legally unable to provide it.

8. The system SHOULD provide the ability to document the patient’s personal representative’s level of authority to make decisions on behalf of the patient.

1. The system SHALL provide the ability to capture true allergy, intolerance, and adverse reaction to drug, dietary or environmental triggers as unique, discrete entries.

2. The system SHOULD provide the ability to capture the reason for entry of the allergy, intolerance or adverse reaction.

3. The system SHALL provide the ability to capture the reaction type.

4. The system SHOULD provide the ability to capture the severity of a reaction.

5. The system SHALL provide the ability to capture a report of No Known Allergies (NKA) for the patient.

6. The system SHOULD provide the ability to capture a report of No Known Drug Allergies (NKDA) for the patient

7. The system SHOULD provide the ability to capture the source of allergy, intolerance, and adverse reaction information.

8. The system SHALL provide the ability to deactivate an item on the list.

9. The system SHALL provide the ability to capture the reason for deactivation of an item on the list

DC.1.4.2

DC.1.4.3

10. The system MAY present allergies, intolerances and adverse reactions that have been deactivated.

11. The system MAY provide the ability to display user defined sort order of list.

12. The system SHOULD provide the ability to indicate that the list of medications and other agents has been reviewed.

13. They system SHALL provide the ability to capture and display the date on which allergy information was entered.

14. The system SHOULD provide the ability to capture and display the approximate date of the allergy occurrence.

1. The system SHALL provide the ability to capture patient specific medication lists.

2. The system SHALL display and report patient-specific medication lists.

3. The system SHALL provide the ability to capture the details of the medication such as ordering date, dose, route, and SIG (description of the prescription, such as the quantity) when known.

4. The system SHOULD provide the ability to capture other dates associated with medications such as start and end dates.

5. The system SHALL provide the ability to capture medications not reported on existing medication lists or medication histories.

6. The system SHALL provide the ability to capture nonprescription medications including over the counter and complementary medications such as vitamins, herbs and supplements.

7. The system SHALL present the current medication lists associated with a patient.

8. The system SHALL present the medication, prescriber, and medication ordering dates when known.

9. The system SHALL provide the ability to mark a medication as erroneously captured and excluded from the presentation of current medications.

10. The system SHALL provide the ability to print a current medication list for patient use.

11. The system MAY provide the ability to capture information regarding the filling of prescriptions (dispensation of medications by pharmacies or other providers).

12. The system SHALL provide a means to document that a medication history is unavailable.

13. The system SHALL provide a means to document a description of a medication when the medication name is unknown.

14. The system SHOULD prove a means to identify one time medications taken in the recent past.

15. The system SHOULD support the process of medication reconciliation as required by organizational policy, scope of practice, and jurisdictional law.

1. The system SHALL capture, display and report all active problems associated with a patient.

2. The system SHALL capture, display and report a history of all problems associated with a patient.

DC.1.4.4

DC.1.5

3. The system SHALL provide the ability to capture onset date of problem.

4. The system SHOULD provide the ability to capture the chronicity (chronic, acute/self-limiting, etc.) of a problem.

5. The system SHALL provide the ability to capture the source, date and time of all updates to the problem list.

6. The system SHALL provide the ability to deactivate a problem.

7. The system MAY provide the ability to re-activate a previously deactivated problem.

8. The system SHOULD provide the ability to display inactive and/or resolved problems.

9. The system SHOULD provide the ability to manually order/sort the problem list.

10. The system MAY provide the ability to associate encounters, orders, medications, notes with one or more problems.

11. The system SHALL manage pregnancy status, including the date of last menstrual period, patient reported pregnancy status, and results of bedside or laboratory testing.

1. The system SHALL capture, display and report all immunizations associated with a patient.

2. The system SHALL record as discrete data elements data associated with any immunization given including date, type, lot number and manufacturer.

3. The system MAY prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.

1. The system SHALL provide the ability to create assessments.

2. The system SHOULD provide the ability to use standardized assessments where they exist.

3. The system SHOULD provide the ability to document using standard assessments germane to the age, gender, health condition as appropriate to the EHR user’s scope of practice.

4. The system SHOULD provide the ability to capture data relevant to standard assessment.

5. The system SHOULD provide the ability to capture additional data to augment the standard assessments relative to variances in medical conditions.

6. The system SHOULD provide the ability to link data from a standard assessment to a problem list.

7. The system SHOULD provide the ability to link data from a standard assessment to an individual care plan.

8. The system MAY provide the ability to link data from external sources, laboratory results, and radiographic results to the standard assessment.

9.   The system SHOULD provide the ability to compare documented data against standardized curves and display trends.

10. The system SHALL capture Glasgow Coma Score.

DC.1.5.1

DC.1.5.2

DC.1.6.1

4. IF decision support prompts are used to support

DC.1.7

DC.1.7.1

11. The system SHALL capture pain score.

1. The system shall capture the physical examination. .

2. The system should provide a means to vary the physical examination documented based upon patient problem.

1. The system shall provide a means to record progress notes by providers.

2. The system SHOULD prompt the provider for progress notes based upon various rules, including but not limited to, chief complaint, length of stay, abnormal vital signs, response to medication.

3. The system SHOULD support capture and storage of progress notes as discrete data where appropriate.

4. The system SHALL support free-text or narrative progress notes.

1. The system SHALL provide the ability to present current guidelines and protocols to clinicians who are creating plans for treatment and care

2. The system SHOULD provide the ability to search for a guideline or protocol based on appropriate criteria (such as problem)

3. The system SHOULD provide the ability to present previously used guidelines and protocols for historical or legal purposes

a specific clinical guideline or protocol THEN the system SHALL conform to function DC.1.8.6

5. The system SHALL conform to function DC.2.2.1.2 (Support for context-sensitive care plans, guidelines and protocols)

1. The system shall maintain a list of orders available to providers in the ED. .

2. The system should provide a means to name orders according to a local taxonomy.

3. The system shall display orders that have not been fulfilled.

4. The system shall permit order entry prior to formal registration.

5. The system should provide a means for the creation of both role-based and location-based orders.

6. The system may provide a means for sub-classification of order types based upon local interoperability needs.

7. The system SHOULD provide a means to manage standing orders or orders that may be submitted by protocol by providers other than licensed providers.

1. The system SHALL provide the ability to create prescription or other medication orders with the details adequate for correct filling and administration captured as discrete data.

prescriptions in order sets.

2. The system SHALL capture user and date stamp for all prescription related events.

3. The system SHALL conform to function DC.1.4.2 (Manage Medication List) and update the appropriate medication list with the prescribed medications (in case of multiple medication lists).

4. The system SHALL provide a list of medications to search, including both generic and brand name.

5. The system SHALL provide the ability to maintain a discrete list of orderable medications.

6. The system SHALL conform to function DC.1.7.2.1 (Manage patient care orders) and provide the ability to order supplies associated with medication orders according to the users’ scope of practice in accordance with organizational policy or jurisdictional law.

7. The system MAY make common content available for prescription details to be selected by the ordering clinician

8. The system MAY provide the ability for the ordering clinician to create prescription details as needed

9. The system MAY make available common patient medication instruction content to be selected by the ordering clinician.

10. The system MAY provide the ability to include

11. The system MAY provide a list of frequently-ordered medications by diagnosis by provider which could include the full details of the medication, including SIG, quantity, refills, dispense as written, etc.

12. The system MAY provide the ability to select drugs by therapeutic class and/or indication.

13. The system MAY conform to function S.3.3.2 (Eligibility verification and determination of coverage) and display the results of electronic prescription eligibility and health plan/payer formulary checking.

14. The system MAY provide the ability to re-prescribe medication by allowing a prior prescription to be reordered without re-entering previous data (e.g. administration schedule, quantity).

15. The system SHOULD provide the ability to re-prescribe a medication from a prior prescription using the same dosage but updating body weight.

16. The system SHALL conform to function DC.2.3.1.1 (Support for drug interaction checking) and check and report allergies, drug-drug interactions, and other potential adverse reactions, when new medications are ordered.

17. The system SHOULD conform to function DC.2.3.1.2 (Support for patient specific dosing and warnings) and check and report other potential adverse reactions, when new medications are ordered.

DC.1.7.2.1

DC.1.7.2.2

18. The system SHALL provide the ability to create prescriptions in which the weight-specific dose employs a starting range with incremental changes toward a target scope.

19. The system SHOULD conform to function DC.2.3.1.3 (Support for Medication Recommendations)

20. The system shALL support institution specific formularies.

21. The system shall provide a means to institute co-signatures for therapeutic orders based upon roles (i.e. medical student, consulting physician).

22. The system shall permit medication order entry prior to formal registration.

23. The system shall provide a means to order medications via continuous infusion.

24. The system shall provide a means to order combination drugs or compounds (i.e. magic mouthwash).

1. The system SHALL provide the ability to capture non-medication patient care orders for an action or item.

2. The system SHALL provide the ability to capture adequate order detail for correct order fulfillment.

3. The system SHALL track the status of the ordered action or item

4. The system SHOULD provide the ability to capture patient instructions necessary for correct order fulfillment

5. The system SHOULD provide the ability to present patient instructions necessary for correct order fulfillment

6. The system SHOULD provide the ability to communicate the order to the correct recipient(s) for order fulfillment

7. The system SHALL conform to DC.2.4.2 (Support for non-medication ordering).

8. The system shall provide a means to order intravenous catheter placement and fluid therapy.

9. The system shall provide a means to order dressings and wound care.

10. The system shall provide a means to order a diet for the patient, including NPO status.

11. The system shall provide a means to order an ECG and cardiopulmonary monitoring.

13. The system shall provide a means to order ventilator therapy.

14. The system shall provide a means to order specific patient education tasks.

1. The system SHALL provide the ability to capture orders for diagnostic tests.

2. The system SHALL provide the ability to capture adequate order detail for correct diagnostic test fulfillment.

DC.1.7.2.3

DC.1.7.2.4

DC.1.7.3

3. The system SHALL provide the ability to track the status of diagnostic test(s).

4. The system SHOULD provide the ability to capture and present patient instructions relevant to the diagnostic test ordered.

5. The system SHALL communicate orders to the service provider of the diagnostic test.

6. The system SHOULD communicate supporting detailed documentation to the correct service provider of the diagnostic test.

7. The system SHALL conform to DC.2.4.2 (Support for non-medication ordering).

1. The system SHALL provide the ability to interface with systems of blood banks or other sources to manage orders for blood products or other biologics.

2. The system SHALL provide the ability to capture use of such products in the provision of care.

1. The system SHALL provide the ability to capture and communicate referral(s) to other care provider (s), whether internal or external to the organization.

2. The system SHALL provide the ability to capture clinical details as necessary for the referral.

3. The system SHALL provide the ability to capture administrative details (such as insurance information, consents and authorizations for disclosure) as necessary for the referral.

4. The system SHALL present captured referral information.

5. The system MAY provide the ability to capture completion of a referral appointment.

6. The system SHOULD provide diagnosis-based clinical guidelines for making a referral.

7. The system MAY provide order sets for referral preparation.

8. The system SHALL provide the ability to document transfer of care according to organizational policy, scope of practice, and jurisdictional law.

9. The system should maintain a list of providers for referrals.

1. The system SHALL provide the ability to present order set(s).

2. The system SHALL provide the ability to order at the patient level from presented order sets

DC.1.8.1

DC.1.8.3

numerical and non-numerical current and historical test results to the appropriate provider

3. The system SHALL provide the ability to record each component of an order set that is ordered.

4. The system SHALL conform to function DC.2.4.1 (Support for order sets)

5. The system MAY provide the ability for a provider to choose from among the order sets pertinent to a certain disease or other criteria.

6. The system should capture the order sets used by the provider during an encounter for analysis of order set use.

1. The system SHALL present the list of medications to be administered.

2. The system SHALL display the timing, route of administration, and dose of all medications on the list.

3. The system SHOULD display instructions for administration of all medications on the list.

4. The system MAY notify the provider when specific doses are due.

5. The system SHOULD conform to function DC.2.3.1.1 (Support for drug interaction checking) and check and report allergies, drug-drug interactions, and other potential adverse reactions, when new medications are about to be given.

6. The system MAY conform to function DC.2.3.1.2 (Support for patient specific dosing and warnings) and check and report other potential adverse reactions, when new medications are about to be given.

7. The system SHALL provide the ability to capture medication administration details – including timestamps, observations, complications, and reason if medication was not given – in accordance with organizational policy, scope of practice, and jurisdictional law.

8. The system SHALL securely relate interventions to be administered to the unique identity of the patient.

9. The system SHOULD support the use of integrated point of care devices for patient and medication identification, such as barcode recognition verification of patients and medications.

9. The system shall display medication orders that have not been fulfilled.

1. The system SHALL provide the ability to present

DC.1.8.4

2. The system SHALL provide the ability to filter results for a unique patient.

3. The system SHALL provide the ability to filter results by factors that supports results management, such as type of test and date range.

4. The system SHOULD indicate normal and abnormal results depending on the data source.

5. The system SHOULD provide the ability to filter lab results by range, e.g. critical, abnormal or normal.

6. The system SHOULD display numerical results in flow sheets, graphical form, and allow comparison of results.

7. The system SHALL provide the ability to group tests done on the same day.

8. The system SHOULD notify relevant providers (ordering, copy to) that new results have been received.

9. The system SHOULD provide the ability for the user, to whom a result is presented, to acknowledge the result.

10. The system MAY provide the ability to route results to other appropriate care providers, such as nursing home, consulting physicians, etc.

12. The system SHOULD provide the ability for providers to pass on the responsibility to perform follow up actions to other providers.

13. The system MAY provide the ability for an authorized user to group results into clinically logical sections.

14. The system MAY trigger decision support algorithms from the results.

15. IF the system contains the electronic order, THEN the results SHALL be linked to a specific order.

16. The system MAY provide the ability for providers to annotate a result.

17. The system MAY display a link to an image associated with results.

18. The system may integrate with RIS or PACS system for viewing images obtained during ED visit.

19. The system shall display reports of diagnostic studies ordered during the ED visit.

20. The system SHOULD provide a means to view results of diagnostic studies ordered during prior ED visits.

21. The system MAY provide a means to view prior diagnostic studies ordered within the same facility.

22. The system should provide a means to view laboratory results in trend view.

23. The system shall flag results that have been received but have not been reviewed.

1. The system SHALL capture patient vital signs including blood pressure, temperature, heart rate, respiratory rate, and severity of pain as discrete elements of structured or unstructured data.

2. The system SHOULD capture other clinical measures as discrete elements such as peak expiratory flow rate, size of lesions, oxygen saturation, height, weight, and body mass index and severity of pain as discrete elements of structured or unstructured data.

DC.1.8.5

DC.1.8.5.1

DC.1.8.5.2

3. The SHOULD compute and display percentile values when data with normative distributions are entered.

4. The system MAY compute normal ranges for data based on age and other parameters such as height, weight, ethnic background, gestational age.

5. The system SHALL document both the time the vital sign was recorded as well as the time the vital sign was entered into the system.

6. The system SHOULD display trends of vital signs.

7. The system SHOULD provide a means for automated capture and recording of vital signs via external devices.

1. The system SHALL provide the ability to capture clinical documentation (henceforth "documentation") including original, update by amendment in order to correct, and addenda.

2. The system SHALL provide the ability to capture free text documentation.

3. The system MAY present documentation templates (structured or free text) to facilitate creating documentation.

4. The system SHALL provide the ability to view other documentation within the patient's logical record while creating documentation.

5. The system SHOULD provide the ability to associate documentation for a specific patient with a given event, such as an office visit, phone communication, e-mail consult, lab result, etc.

6. The system SHOULD provide the ability to associate documentation with problems and/or diagnoses.

7. The system SHALL provide the ability to update documentation prior to finalizing it.

8. The system SHALL provide the ability to finalize a document or note.

9. The system SHALL provide the ability to attribute record and display the identity of all users contributing to or finalizing a document or note, including the date and time of entry (see appropriate criteria in IN.2.2).

10. The system SHALL present captured documentation.

11. The system MAY provide the ability to filter, search or sort notes.

12. The system SHOULD provide documentation templates for data exchange.

13. The system shall permit clinical documentation prior to registration.

1. The system shall provide a means to mark the documentation by another provider as read.

2. The system shall provide a means to mark documentation by another provider as agreed or disagreed with.

3. The system shall provide a means for a supervising attending ED physician to attest to his or her advising and direct care.

1. The system SHALL provide a means to document patient education, counseling, and communication with the patient’s family by the emergency physician.

DC.1.8.5.3

DC.1.8.6

DC.1.8.7

DC.1.8.8

2. The system SHALL provide a means to document patient education provided to the patient or family.

1. The system shall provide a means to document the transfer of care between ED providers.

2. Upon the transfer of care, the system shall record that the patient was cared for by multiple providers.

3. The system SHOULD provide the ability to attribute a particular visit to a particular provider (i.e. attending physician) based upon pre-defined rules, when a patient was seen by multiple providers, but the visit must be tied to a single provider.

1. The system SHALL provide the ability to capture clinical decision support prompts and user decisions to accept or override those prompts

2. The system SHALL provide the ability to record the reason for variation from the decision support prompt.

3. The system SHOULD provide the ability to display recorded variances upon request by authorized users of the EHR.

1. The system SHALL provide a means to record procedures performed on the patient.

2. The system SHOULD capture the procedure performed as coded data.

3. The system SHOULD provide a means to record sufficient data to support billing.

4. The system SHOULD capture indication for the procedure, applications, results and outcomes.

5. The system SHALL conform to DC.1.3.3 Manage Consents and Authorizations to document procedure consents where required by local practice.

1. The system shall provide a means for physicians to document medical decision making including development of differential diagnosis and process used to exclude life-threatening diagnoses.

2. The system should provide a mechanism to incorporate narrative interpretation of the physician’s decision making process

DC.1.9

Procedures.

DC.1.10

DC.1.10.1

3. The system shall provide a means to record ECG interpretations by the emergency physician.

4. The system shall provide a means to record laboratory test interpretations by the emergency physician.

5. The system shall provide a means to record radiographic interpretations by the emergency physician.

6. The system shall provide a means to record initial (“wet”) and final radiograph interpretations by the radiology department.

1. The system SHALL provide the ability to generate instructions pertinent to the patient for standardized

2. The system SHALL provide the ability to generate instructions pertinent to the patient based on clinical judgment.

3. The system SHALL provide the ability to include details on further care such as follow up, return visits and appropriate timing of further care.

4. The system SHALL provide the ability to record that instructions were given to the patient.

5. The system SHALL provide the ability to record the actual instructions given to the patient or reference the document(s) containing those instructions.

1. The system SHALL capture the time of ED disposition.

2. The system SHALL capture the time of ED departure.

3. The system SHALL capture ED disposition.

4. The system SHALL capture one or more ED Diagnoses.

5. The system SHOULD capture ED diagnoses as coded data.

1.   The system shall create a record of the materials provided to the patient at discharge.

2.   The system shall provide a means to manage discharge instructions.

3.   The system may provide the ability for individual providers to manage their discharge instructions.

4.   The system shall provide a means to edit discharge instructions for a particular patient.

5.   The system should provide a means to manage patient discharge instructions in multiple languages.

6.   The system may provide a list of appropriate discharge instructions based on age.

7.   The system may provide a list of appropriate discharge instructions based on sex.

8.   The system may provide a list of appropriate discharge instructions based on diagnosis.

9.   The system may provide a list of appropriate discharge instructions based on reading level.

10. The system shall provide a means to document that instructions were given.

DC.1.10.1.1

DC.1.10.1.2

DC.1.10.1.3

DC.1.10.1.4

DC.1.11

11. The system SHOULD provide a means to capture via digitized signature that instructions were given.

12. The system shall provide a means to manage work, school, or other custom forms.

13. The system SHOULD capture the Mode of Transport for patient’s discharged from the ED.

1. The system shall provide a means to provide scheduled or unscheduled but intended follow up for patients discharged from the ED.

2. The system shall provide the ability to manage a list of follow up physicians, offices, or clinics.

3. The system SHALL capture identity of the follow-up provider, the provider type, and intended date and time of follow-up if known.

1. The system shall provide a means to create outpatient prescriptions with detail adequate for correct filling and administration.

2. The system may provide a means to create and securely transmit electronic prescriptions in compliance with current regulations.

3. The system should provide the ability to tailor formularies by institution, insurance or other local rules.

4. The system shall provide a means to create outpatient prescriptions for durable items and equipment that require prescriptions.

1. The system SHALL provide a means to notify admitting office personnel that an ED patient requires hospital admission.

2. The system SHOULD display the time between disposition initiation and disposition achieved.

3. The system SHOULD provide a means to specify sufficient detail to request a particular bed.

4. The system SHOULD capture the times when the hospital bed is assigned and available.

5. The system SHOULD capture when a patient is ready for transport to inpatient bed.

6. The system SHALL capture the inpatient practitioner and inpatient practitioner type.

1. The system shall provide a means to create legal transfer documentation.

2. The system shall capture the name of the accepting physician.

3. The system shall capture the name of the accepting facility.

1. The system SHALL provide a means to flag patients requiring follow-up after disposition from the ED.

2. The system shall provide a mechanism for the laboratory follow-up for discharged patients.

DC.2.1.1

2.1.2 (Support for Patient Context-driven Assessments).

DC.2.1.2

3. The system shall provide a mechanism for the management of radiological follow-up for discharged patients.

4. The system shall provide a mechanism for the management of administrative follow up for discharged patients.

5. The system shall provide a mechanism for the management of clinical follow-up for discharged patients.

6. The system should provide a means to flag, document and reconcile discrepancies between ED physician interpretation, radiology wet reads, and final interpretations of radiographic studies.

7. The system should provide a means to flag discrepancies between ED physician interpretation and cardiologist interpretations of ECGs, when cardiologist over read is instituted.

8. The system should provide means to capture and flag errors or other issues for department analysis, administrative review, and systemic error reduction.

9. The system should integrate with RIS or PACS system for ED, wet reads and final radiologist interpretations.

1. The system SHALL provide the ability to access the standard assessment in the patient record.

2. The system SHALL provide the ability to access to health standards and practices appropriate to the EHR user’s scope of practice.

3. The system SHOULD provide the ability to compare elements of assessments captured by the clinician and those available as best practices and/or evidence based resources.

4. The system MAY provide the ability to derive supplemental assessment data from evidence based standard assessments, practice standards, or other generally accepted, verifiable, and regularly updated standard clinical sources.

5. The system SHOULD provide prompts based on practice standards to recommend additional assessment functions.

6. The system MAY conform to function DC.1.4.3 (Manage Problem List) and provide the ability to update the problem list by activating new problems and de-activating old problems as identified by conduct of standard assessments.

7. The system SHOULD provide the ability to create standard assessments that correspond to the problem list.

8. The system SHOULD conform to function DC

1. The system SHALL provide the ability to access health assessment data in the patient record

DC.2.1.5

DC.2.1.6

DC.2.2.1.1

DC.2.2.1.2

1. The system shall conform to function DC.1.2.3 Manage Triage and provide a means to create and maintain a triage acuity rating for a patient.

2. The system shall permit the triage acuity rating to be derived from standardized ED triage scales.

3. The system MAY permit the triage acuity rating to be customized according to locally derived rules.

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

5. The system MAY automatically assign a triage category in response to specific prompts for patient associated data or data already captured in the record (i.e. arrival by ambulance, age, vital signs, etc.).

1. The system shall display a list of patients who are waiting to be seen.

2. The system should provide a means to sort and display patients who are waiting to be seen by waiting time.

3. The system should provide a means to sort and display patients who are waiting to be seen by triage acuity rating.

4. The system MAY provide an alert when the number of patients waiting, or the patient waiting time exceeds selected thresholds.

1. The system SHALL conform to function DC.1.6.1 (Present guidelines and protocols for planning care) and provide the ability to access to standard care plans, protocols and guidelines when requested within the context of a clinical encounter.

2. The system MAY provide the ability to create and use site specific care plans, protocols, and guidelines.

3. The system MAY provide the ability to make site-specific modifications to standard care plans, protocols, and guidelines obtained from outside sources.

4. The system SHOULD identify, track and provide alerts, notifications and reports about variances from standard care plans, guidelines and protocols.

1. The system SHALL provide the ability to access care and treatment plans that are sensitive to the context of patient data and assessments.

DC.2.2.3

(Interactions with other systems), to enable participation in research studies.

Services).

DC.2.3.1.1

2. The system MAY provide the ability to capture care processes across the continuum of care.

3. The system MAY present care processes from across the continuum of care.

4. The system MAY provide the ability to document the choice of action in response to care plan suggestions.

5. The system SHOULD identify, track and provide alerts, notifications and reports about variances from standard care plans, guidelines and protocols.

6. The system SHALL conform to function DC2.2.1.1 (Support for Standard Care Plans, Guidelines, Protocols).

7. The system SHALL conform to function DC.2.1.1 (Support for Standard Assessments).

8. The system SHALL conform to function DC.2.1.2 (Support for Patient Context-Driven Assessments).

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

2. The system SHALL provide the ability to maintain research study protocols.

3. The system SHOULD conform to function S.3.3.1

4. The system SHOULD provide the ability to identify and track patients participating in research studies.

5. The system MAY provide the ability to capture details of patient condition and response to treatment as required for patients enrolled in research studies.

6. If research protocols require standardized transmission of data to/from a registry or directory, THEN the system SHALL conform to function IN.3 (Registry and Directory

1. The system SHALL check for and alert providers to interactions between prescribed drugs and medications on the current medication list.

2. The system SHALL relate medication allergies to medications to facilitate allergy checking decision support for medication orders.

medications against a list of drugs noted to be ineffective for the patient in the past

DC.2.3.1.2

DC.2.3.1.3

(Support for Patient-Specific Dosing and Warnings)

3. The system SHOULD provide the ability to document that a provider was presented with and acknowledged a drug interaction warning.

4. The system SHALL provide the ability to prescribe a medication despite alerts for interactions and/or allergies being present.

5. The system MAY provide the ability to set the severity level at which warnings should be displayed.

6. The system SHOULD provide the ability to check for duplicate therapies.

7. The system SHOULD conform to DC.1.8.6 (Manage documentation of clinician response to decision support prompts) and provide the ability to document why a drug interaction warning was overridden.

8. The system SHOULD check for interactions between prescribed drugs and food detailing changes in a drug's effects potentially caused by food (including beverages) consumed during the same time period.

9. The system SHOULD check for drug-lab interactions, to indicate to the prescriber that certain lab test results may be impacted by a patient’s drugs.

10. The system SHOULD provide the ability to check

11. The system SHOULD identify contraindications between a drugs and patient conditions at the time of medication ordering.

1. The system SHALL provide the ability to identify an appropriate drug dosage range, specific for each known patient condition and parameter at the time of medication ordering.

2. The system SHALL provide the ability to automatically alert the provider if contraindications to the ordered dosage range are identified.

3. The system SHALL provide the ability for the provider to override a drug dosage warning.

4. The system SHOULD provide the ability to document reasons for overriding a drug alert or warning at the time of ordering.

5. The system MAY transmit documented reasons for overriding a drug alert to the pharmacy to enable communication between the clinician and the pharmacist.

6. IF the maximum daily doses are known THEN the system SHALL apply the maximum dose per day in dosing decision support.

7. The system SHOULD compute drug doses, based on appropriate dosage ranges, using the patient’s body weight.

8. The system SHOULD allow the user to specify an alternative “dosing weight” for the purposes of dose calculation.

9. The system’s drug dosage functions SHOULD work using any component of a combination drug (e.g., acetaminophen-hydrocodone).

10. The system SHOULD allow the recording of the dosage used to calculate the dose for a given medication.

1. The system SHOULD conform to function DC.2.3.1.2

DC.2.3.2

DC.2.3.3

2. The system SHOULD present recommendations for medication regimens based on findings related to the patient diagnosis.

3. The system SHALL present alternative treatments in medications on the basis of practice standards, cost, formularies, and or protocols.

4. The system MAY present suggested lab monitoring as appropriate to a particular medication.

1. The system SHALL present information necessary to correctly identify the patient and accurately administer medications and immunizations such as patient name, medication name, strength, dose, route and frequency.

2. The system SHALL 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 immunizations administration.

3. The system SHOULD alert providers to potential medication administration errors at the point of medication administration.

4. The system SHALL provide the ability to capture all pertinent details of the medication administration including medication name, strength, dose, route, time of administration, exceptions to administration, and administrator of the medication.

5. The system SHALL capture the administrator of the immunization and the immunization information identified in DC.1.8.2, Conformance Criteria #3.

6. The system SHOULD generate documentation of medication or immunization administration as a by-product of verification of patient, medication, dose, route and time

7. The system SHOULD prompt or remind providers regarding the date/time range for timely administration of medications.

8. The system MAY suggest alternative administration techniques based on age, developmental stage, weight, physiological status, mental status, educational level, and past physical history of the patient.

9. The system MAY conform to function DC.2.7.1 (Access healthcare guidance) and provide to the ability for a provider to access drug monograph information.

1. The system SHALL support ED specific medication reconciliation according to local, national, and jurisdictional requirements (see DC 1.4.2, CC 12).

DC.2.4

DC.2.4.1

DC.2.4.2

2. The system SHALL display incomplete medication information captured during initial assessment.

3. The system SHALL display all pre-existing medications, medications administered in the ED, as well as all new prescriptions in patient discharge instructions and chart abstracts used in transfers of care.

4. The system SHOULD support real-time display or communications with hospital pharmacy personnel for mediation reconciliation.

5. The system MAY support interoperability with the hospital pharmacy system to enable pharmacist medication reconciliation.

6. The system MAY support notification of reconciliation discrepancies in the event a review by the pharmacy or non-ED personnel occurs after ED discharge.

1. The system SHALL provide the ability to create order sets templates.

2. The system SHALL provide the ability to maintain order sets templates, including version control.

3. The system SHOULD provide the ability to create order sets templates from provider input.

4. The system MAY provide the ability to create order sets templates for known conditions for a particular disease.

5. The system SHALL present the order sets templates to the provider.

6. The system MAY record the basis of the practice standards or criteria for the creation of the order sets templates.

7. The system MAY provide the ability to relate order sets templates to aid decision support for certain diseases.

8. The system should permit the inclusion of all order types relevant to a particular problem (i.e. laboratory, radiology, medications, nursing tasks, and materials management) in an order set.

9. The system should allow for the customization and/or presentation of order sets by patient age, sex, or other patient factors.

10. The system should allow for the customization of order sets by provider type.

11. The system may allow for the customization of order sets by physician.

12. The system SHOULD allow for the creation of standing order sets for use in triage or for specific conditions.

1. The system SHALL identify required order entry components for non-medication orders.

DC.2.4.3

DC.2.4.4.1

DC.2.4.4.2

2. The system SHALL alert the provider, at the time of order entry, if a non-medication order is missing required information.

3. The system SHOULD alert providers via warnings of orders that may be inappropriate or contraindicated for specific patients at the time of provider order entry.

4. The system SHOULD automatically answer or pre-populate the answers to questions required for diagnostic test ordering from data within the medical record or captured during the encounter.

5. The system should provide a flag of certain diagnostic studies that are being repeated within a proscribed period of time.

1. The system SHALL present alerts for a result that is outside of a normal value range.

2. The system shall display critical results that have not been acknowledged.

3. The system shall provide a mechanism to flag results that have not returned before completion of the ED visit.

4. The system MAY provide the ability to evaluate pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam).

1. The system SHALL provide the ability to include clinical and administrative data (e.g. insurance information) as part of the referral process.

2. The system SHALL provide the ability to include test and procedure results with a referral.

3. The system MAY provide the ability to include standardized or evidence based protocols with the referral.

4. The system SHOULD allow clinical, administrative data, and test and procedure results to be transmitted to the referral clinician.

1. The system SHALL present recommendations for potential referrals based on diagnos(es).

2. The system SHALL present recommendations for potential referrals based on patient condition (e.g. for smoking cessation counseling if the patient is prescribed a medication to support cessation).

DC.2.4.5.1

DC.2.4.5.2

DC.2.6.1

1. The system SHALL present information necessary to correctly identify the patient and accurately administer blood products including patient name, blood product number, amount, route, and time of administration.

2. The system SHALL capture validation of the correct matching of the patient to the blood product.

3. The system SHALL capture the blood product number, amount, route and time of administration.

4. The system SHALL conform to function DC.1.8.4 (Manage Patient Clinical Measurements) and capture the blood pressure, temperature, pulse, respirations of the patient receiving the product.

1. The system SHALL provide the ability to present

information necessary to correctly identify the patient and accurately identify the specimen to be collected including, but not limited to, patient name, specimen type, specimen source, means of collection, date and time.

2. The system SHALL report variation between the type of specimen order placed and actual specimen received.

3. The system SHALL capture the details of specimen collection.

1. The system SHALL provide the ability to aggregate patient information based on user-identified criteria.

2. The system SHALL apply local privacy and confidentially rules when assembling aggregate data to prevent identification of individuals by unauthorized parties.

3. The system SHOULD provide the ability to use any demographic or clinical information as criteria for aggregation

4. The system SHOULD present aggregate data in the form of reports for external use

5. The system SHOULD provide the ability to save report definitions for later use.

DC.2.7.1

DC.3.1

DC.3.1.1

6. The system MAY present aggregate data in an electronic format for use by other analytical programs.

7. The system MAY provide the ability to derive statistical information from aggregate data.

1. The system SHALL provide the ability to access evidence based healthcare recommendations, with documentation of sources.

2. The system SHOULD provide the ability to access evidenced-based documentation appropriate for the care provider to render a timely judgment.

3. The system MAY provide the ability to access external evidence-based documentation.

4. The system should support interoperability with knowledge bases or guidelines deployed in an enterprise.

1. The system SHALL maintain a list of tasks.

2. The system SHALL permit the creation of new tasks.

3. The system SHOULD permit the prioritization of tasks according to the nature of the task itself.

1. The system SHALL provide the ability for users to create manual clinical tasks.

DC.3.1.2

Task.

DC.3.1.3

2. The system SHALL provide the ability to automate clinical task creation.

3. The system SHALL provide the ability to manually modify and update task status (e.g. created, performed, canceled, pended, denied, and resolved).

4. The system MAY provide the ability to automatically modify or update the status of tasks based on workflow rules.

5. The system SHOULD provide the ability to assign, and change the assignment of, tasks to individuals or to clinical roles.

6. The system MAY provide the ability to manage workflow task routing to multiple individuals or roles in succession and/or in parallel.

7. The system SHOULD provide the ability to prioritize tasks based on urgency assigned to the task.

8. The system MAY provide the ability to restrict task assignment based on appropriate role as defined by the entity.

9. The system MAY provide the ability to escalate clinical tasks as appropriate to ensure timely completion.

10. The system SHALL permit the delegation of tasks to one or multiple providers.

11. The system SHOULD permit the provider to re-prioritize tasks according to the patient severity, length of stay, task duration, or other criteria.

1. The system SHALL provide the ability to link a clinical task to the component of the EHR required to complete the

2. The system SHALL link each clinical task to a patient, an object in the department (i.e. bed to be cleaned), or a place on the patient’s ED chart.

1. The system SHALL provide the ability to track the status of tasks.

2. The system SHALL provide the ability to notify providers of the status of tasks.

3. The system SHOULD provide the ability to sort clinical tasks by status.

DC.3.2

DC.3.2.1

4. The system SHOULD provide the ability to present current clinical tasks as work lists.

5. The system SHOULD provide the ability to define the presentation of clinical task lists.

6. The system shall track creation, acknowledgment, and completion of tasks.

7. The system shOULD display, by provider or role, an up to date list of tasks to be done.

8. The system shall display, by patient, an up to date list of tasks to be done.

9. The system MAY notify the tasking or requesting provider when clinical tasks are complete.

10. The system shOULD support time limits on particular tasks and display tasks which are overdue.

11. The system shall flag tasks that have not been completed at the time of disposition.

12. The system should flag tasks that are not yet complete, but that are not expected to be complete prior to the end of the ED visit, as requiring follow up.

1. The system SHALL provide the ability to document in the patient record verbal/telephone communication between providers.

2. The system SHALL provide the ability to incorporate scanned documents from external providers into the patient record.

3. The system MAY provide the ability to communicate using real-time messaging.

4. The system MAY provide the ability to communicate clinical information (e.g. referrals) via email or other electronic means.

5. The system MAY provide the ability to transmit electronic multi-media data types representing pictures, sound clips, or video as part of the patient record.

DC.3.2.1.1

DC.3.2.2

DC.3.2.4

1. The system shall provide a means to record consultations by providers other than the emergency physician.

2. The system shall provide a means to document time paged, time responded, and time arrived, as well as final disposition and recommendation.

3. The system SHOULD capture the details of consultation request and responses as discrete data, including timestamps, sufficient for reporting.

4. The system MAY provide a means to page and initiate calls from within the application.

5. The system shOULD display consultations which are pending.

6. The system MAY notify the consulting provider of the completion of consultations.

7. The system may display estimated time of arrival of consultants.

1. The system SHALL electronically communicate orders between the prescriber, provider and pharmacy, as necessary, to initiate, change, or renew a medication order.

2. The system SHALL receive any acknowledgements, prior authorizations, renewals, inquiries and fill notifications provided by the pharmacy or other participants in the electronic prescription and make it available for entry in the patient record.

1. The system SHALL provide the ability to access to a library of educational material for health concerns, conditions, and/or diagnosis.

2. The system SHALL provide the ability to communicate applicable educational materials to the patients and/or patient representative.

3. The system SHOULD provide the ability to deliver multilingual educational material.

4. The system MAY provide the ability to deliver patient educational materials using alternative modes to accommodate patient sensory capabilities.

5. The system SHOULD provide the ability to use rules-based support to identify the most pertinent educational material, based on the patient health status, condition and/or diagnosis.

11. The system SHALL conform to function IN.1.4 (Patient

Access Management).

DC.3.2.5

S.1.1

S.1.3

S.1.3.1

7. The system SHOULD provide the ability to document who received the educational material provided, the patient, or the patient representative.

8. The system SHALL provide the ability to document that the educational material was reviewed with the patient and/or patient representative and their comprehension of the material.

10. The system MAY provide the ability to identify age appropriate and/or reading-ability appropriate educational materials for the patient and/or patient representative.

12. IF the system is used to enter, modify, or exchange data, THEN the system SHALL conform to IN.1.5 (Nonrepudiation) to guarantee that the sources and receivers of data cannot deny that they entered/sent/received the data.

1. The system SHALL provide the ability to collect accurate electronic data from medical devices according to realm specific applicable regulations and/or requirements.

2. The system SHOULD provide the ability to present information collected from medical devices as part of the medical record.

3. The system SHOULD present data captured from medical devices for verification by a provider.

4. The system SHOULD display data from medical devices as coming from the device and verified by the verifying provider.

1. The system SHALL automatically transfer formatted demographic and clinical information to local disease specific registries (and other notifiable registries).

2. The system MAY provide the ability to automate the retrieval of formatted demographic and clinical information from local disease specific registries (and other notifiable registries).

3. The system SHOULD provide the ability to add, change, or remove access to registries.

1. The system SHALL provide a registry or directory of all personnel who currently use or access the system.

2. For licensed practitioners the directory SHOULD contain realm-specific legal identifiers required for care delivery such as the practitioners' license number.

S.1.3.2

S.1.3.3

S.1.3.4

S.1.4

S.1.4.1

S.1.4.2

3. The system SHOULD provide the ability to add, update, and inactivate entries in the directory so that it is current.

4. The directory SHOULD contain the information necessary to determine levels of access required by the system security functionality.

5. The system SHALL provide a directory of clinical personnel that are not users of the system to facilitate documentation, communication, and information exchange.6. The system SHALL provide a means for designated providers to create new users at the point of care, and assign appropriate access permissions, in cases of emergency.

1. The system SHALL provide the ability to input or create information on provider location or contact information on a facility's premises.

2. The system SHOULD provide the ability to add, update, or inactivate information on provider's location or contact information on a facility's premises, so that it is current.

1. The system SHALL provide the ability to input or create information on provider location or contact information when on call.

2. The system SHOULD provide the ability to add, update, or obsolete information on a provider's on call location or contact information, so that it is current.

1. The system SHALL contain information necessary to identify primary and secondary practice locations or office of providers to support communication and access.

2. The system SHOULD provide the ability to add, update and obsolete information on the provider's primary and secondary practice locations or offices.

1. The system SHALL add and update patient demographic information through interaction with other systems, applications and modules.

2. The system MAY accept and retrieve patient demographic information as required by realm specific laws governing health care transactions and reporting.

1. IF the patient has an assigned location, THEN system SHALL provide the ability to identify and display/view the patient’s assigned location.

S.1.4.2.1

S.1.4.2.2

2. The system SHOULD support consents as they apply to the release of patient location information according to scope of practice, organization policy, or jurisdictional laws.

3. The system SHOULD display the patients who have not consented to release of information in a de-identified manner without any supporting information.

4. The system SHALL provide the ability to identify the patient’s current, real-time location, unambiguously, within a facility.

1. The system SHALL provide a means to identify the current physical location of a patient in the ED.

2. The system SHALL provide a means to update the current location of a patient.

3. The system SHALL record the movement of patients through the ED.

4. The system SHALL capture the time when the patient first enters the treatment area.

5. The system SHOULD provide a means to display the prior locations of a patient while still in the ED.

6. The system should provide means to hold patients in EDIS for unique reasons, including out of department, other departments, etc.

7. The system shall allow multiple patients to be in a single room.

8. The system shall allow for the management of hallway patients.

9. The system SHOULD provide a means to indicate patients requiring special bed assignments within the ED.

1. The system shall allow for Department, Area, and Room Management.

2. The system should allow for the management of holding areas.

S.1.4.4

S.1.6

S.1.7

3. The system should provide for the management of rooms containing multiple patients.

4. The system should display room availability.

5. The system shall provide for the management of patient placement.

6. The system should provide a means to flag room status as reserved, in need of cleaning, biohazard, or other status.

7. The system should provide a means to allow or prohibit multiple patients in single room.

8. The system MAY provide a means to create holding areas as needed to accommodate surge.

1. The system SHALL support interactions as required to support patient bed assignment internal or external to the system.

2. The system SHOULD provide patient information to an external system to facilitate bed assignment that optimizes care and minimizes risk.

1. The system SHALL provide the ability to access scheduling features, either internal or external to the system, for patient care resources.

2. The system MAY provide the ability to access external scheduling systems for the establishment of patient follow-up.

3. The system MAY incorporate relevant clinical or demographic information in the scheduling process.

4. The system MAY pass relevant clinical or demographic information to support efficient scheduling with other system.

1. The system SHALL aggregate and format information on ED resource availability and publish this information in a format suitable for use by other systems and agencies.

2. The system SHOULD collect information on healthcare resource availability through interactions with other systems, applications, and modules.

3. The system SHOULD display data on inbound EMS patients if provided by the local or regional EMS system.

S.1.8

S.2.1

S.2.1.1

S.2.1.2

4. The system SHOULD provide the ability to access information on healthcare resource availability for internal assessment and planning purposes. Healthcare resources may include, but is not limited to available beds, providers, support personnel, ancillary care areas and devices, operating theaters, medical supplies, vaccines, and pharmaceuticals.

1. The system SHALL provide authorized administrators the ability to tailor the presentation of information for preferences of the user, department/area or user type.

2. The system MAY provide authorized users the capability to tailor their presentation of information for their preferences Tailored views by administrators or users.

1. The system SHALL provide the ability to export or retrieve data required to evaluate patient outcomes.

2. The system SHALL provide the ability to define prompts in the clinical care setting that would request information needed to comply with regional requirements when specific triggers are met.

3. The system SHOULD provide data detailed by physician, facility, facility subsection, or other selection criteria.

4. The system SHOULD provide the ability to define outcome measures for specific patient diagnosis.

5. The system MAY provide the ability to define outcome measures to meet various regional requirements.

6. The system MAY provide for the acceptance and retrieval of unique outcome data defined to meet regional requirements.

1.   The system SHOULD provide the ability to define report formats for the export of data. This formatted data could be viewed, transmitted electronically or printed.

2.   The system MAY export data or provide a limited query access to data through a secure data service.

1. The system SHALL provide the ability to export or retrieve data required to assess health care quality, performance and accountability.

S.2.2

S.2.2.1

S.2.2.2

2. The system SHOULD provide the ability to define multiple data sets required for performance and accountability measures.

3. The system MAY provide the data export in a report format that could be displayed, transmitted electronically or printed.

4. The system MAY export data or provide a limited query access to data through a secure data service.

1. The system SHALL provide the ability to generate reports consisting of all and part of an individual patient’s record.

2. The system SHALL provide the ability to define the record or reports that is considered the formal health record for disclosure purposes.

3. The system SHALL have the ability to specify patient record reports as preliminary vs. final or signed vs. unsigned.

4. The system SHOULD provide the ability to generate reports in both chronological and specified record elements order.

5. The system SHOULD provide the ability to create hardcopy and electronic report summary information (procedures, medications, labs, immunizations, allergies, vital signs).

6. The system SHALL include patient identifying information on each page of reports generated.

7. The system SHOULD have the ability to customize reports to match mandated formats.

1. The system SHALL provide the ability to generate reports of structured clinical and administrative data using either internal or external reporting tools.

2. The system MAY provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools.

S.2.2.2.1

S.2.2.3

3. The system SHALL be capable of exporting reports generated.

4. The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.

5. The system (or an external application, using data from the system) SHOULD provide the ability to save report parameters for generating subsequent reports.

6. The system (or an external application, using data from the system) MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification.

1. The system SHALL provide the ability to access key ED benchmarking times and reports.

2. The system SHALL provide the ability to view, sort, and display key ED benchmarking times and reports according to need, and analytic purpose.

3. The system SHALL restrict particular or sensitive ED benchmarking reports to authorized entities.

4. The system SHALL be able to generate reports for the entire ED, specific areas of the ED (i.e. fast-track), particular patients (those requiring laboratory tests or radiography), and by individual provider.

5. The system SHALL be able to report ED benchmarking data over any prescribed period for which data is available.

1. The system SHALL provide the ability to generate ad hoc query and reports of structured clinical and administrative data through either internal or external reporting tools.

2. The system MAY provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools.

3. The system SHOULD be capable of exporting reports generated.

4. The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.

S.3.1

S.3.1.3

S.3.1.5

5. The system MAY provide the ability to save report parameters for generating subsequent reports.

6. The system MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification.

7. The system MAY provide the ability to produce reports, using internal or external reporting tools, based on the absence of a clinical data element (e.g., a lab test has not been performed in the last year).

1. The system SHALL export appropriate data to administrative and financial systems.

2. The system SHOULD provide the ability to define the data required for each external administrative and financial system.

1. The system SHALL provide the ability to organize patient data by encounter.

2. The system SHOULD accept and append patient encounter data from external systems, such as diagnostic tests and reports.

3. The system SHALL provide the ability to create encounter documentation by one or more of the following means: direct keyboard entry of text; structured data entry utilizing templates, forms, pick lists or macro substitution; dictation with subsequent transcription of voice to text, either manually or via voice recognition system.

S.3.2

S.3.2.1

S.3.2.2

S.3.2.3

1. The system SHALL provide the ability to access all pertinent patient information needed to support coding of diagnosis, procedures and outcomes.

2. The system SHOULD assist with the coding of diagnoses, procedures and outcomes based on provider specialty, care setting and other information that may be entered into the system during the encounter.

1. The system SHALL maintain financial and administrative codes.

2. The system SHOULD provide the ability to retrieve data from the electronic health record as required to simplify the coding of financial and administrative documentation.

3. The system SHOULD support rules driven prompts to facilitate the collection of data in the clinical workflow that is required for administrative and financial coding.

4. The system SHOULD assist with the coding of required administrative and financial documents based on provider specialty, care setting and other information that may be entered into the system during the encounter.

5. The system MAY internally generate internal administrative and financial coding such as place of service, type of facility, tax rates, etc.

1. The system SHALL provide the ability to retrieve formularies, preferred providers, and other information, from internal or external sources, that are associated with a patient’s health care plan and coverage so that the provider can offer cost effective alternatives to patients.

2. The system MAY provide the ability to retrieve or request information about exemptions on coverage limitations and guidelines.

3. The system MAY provide the ability to retrieve and provide expected patient out-of- pocket cost information for medications, diagnostic testing, and procedures, from internal or external sources, that are associated with a patients health care plan and coverage.

4. The system MAY alert the provider of care where formularies, preferred provider and other information indicate the health plan requires an alternative.

S.3.3

S.3.3.2

S.3.3.4

S.3.3.5

1. The system SHALL provide the ability to access information received through electronic prescription eligibility checking.

2. The system MAY provide the ability to access information received through provider eligibility checking.

1. The system SHALL provide the ability to view available, applicable clinical information to support service requests.

2. The system SHALL provide the ability to view available, applicable clinical information to support claims.

3. The system MAY provide available, applicable clinical information to support service requests in a computer readable format.

4. The system MAY provide available, applicable clinical information to support claims in computer readable formats.

1. The system SHALL provide the ability to view available, applicable information needed to enable the creation of claims and encounter reports for reimbursement.

S.3.3.6

S.3.6

S.3.7

S.3.7.1

2. The system SHALL provide the ability to provide available, applicable data as required by local authority for audit and review.

3. The system MAY provide available, applicable data in a computer readable form when needed to enable the creation of claims and encounter reports for reimbursement.

1. The system SHALL create service reports at the completion of an episode of care such as but not limited to; discharge summaries, public health reports, etc. using data collected during the encounter.

2. The system SHOULD prompt providers for data needed for end of care reporting during the continuum of care to reduce the need for end of care data collection.

3. The system SHALL produce a comprehensive ED encounter record including all documentation by all providers during an encounter.

4. The system SHOULD provide a means to customize summaries, excerpts or abstracts of the ED encounter record for distribution to different audiences.

5. The system SHOULD provide a means to capture if transmitted health service reports have been received.

1. The system SHALL provide the ability to collect appropriate existing data to support the patient acuity/severity processes for illness/risk-based adjustment of resources.

2. The system MAY provide the ability to export appropriate data to support the patient acuity/severity processes for illness/risk-based adjustment of resources.

3. The system MAY prompt the user to provide key data needed to support acuity/severity processes.

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

S.3.7.2

S.3.7.4

IN.1

IN.1.1

2. The system SHOULD validate that the most applicable version is utilized for the update, and capture the date of update.

3. The system MAY track and retain the version used when guidelines are provided in a patient encounter

1. The system SHALL support the capture and update of material that may be printed and provided to the patient at the point of care.

2. The system MAY provide the ability to validate the material prior to update.

1. The system SHALL support the capture and update of public health reporting guidelines.

2. The system MAY provide the ability to validate the material prior to update.

1. The system SHALL authenticate principals prior to accessing an EHR-S application or EHR-S data.

IN.1.2

2. The system SHALL prevent access to EHR-S applications or EHR-S data to all non-authenticated principals.

3. The system SHOULD provide the ability to implement a Chain of Trust agreement.

4. IF other appropriate authentication mechanisms are absent, THEN the system SHALL authenticate principals using at least one of the following authentication mechanisms: username/password, digital certificate, secure token or biometrics.

1. The system SHALL provide the ability to create and update of sets of access-control permissions granted to principals.

2. The system SHALL conform to function IN.2.2 (Auditable Records) for the purpose of recording all authorization actions.

3. The system SHALL provide EHR-S security administrators with the ability to grant authorizations to principals according to scope of practice, organizational policy, or jurisdictional law.

4. The system SHALL provide EHR-S security administrators with the ability to grant authorizations for roles according to scope of practice, organizational policy, or jurisdictional law.

5. The system SHALL provide EHR-S security administrators with the ability to grant authorizations within contexts according to scope of practice, organizational policy, or jurisdictional law.

IN.1.3

IN.1.4

IN.1.5

6. The system MAY provide the ability to define context for the purpose of principal authorization based on identity, role, work assignment, present condition, location, patient consent, or patient’s present condition.

7. The system MAY provide the ability to define context based on legal requirements or disaster conditions.

1. The system SHALL conform to function IN.1.1 (Entity Authentication).

2. The system SHALL conform to function IN.1.2 (Entity Authorization).

3. The system SHALL provide the ability to define system and data access rules.

4. The system SHALL enforce system and data access rules for all EHR-S resources (at component, application, or user level, either local or remote).

1. The system SHALL conform to function IN.1.3 (Entity Access Control) in order for a healthcare delivery organization to manage a patient’s access to his or her healthcare information.

2. The system SHALL conform to IN.1.2 & IN.1.3 in order to assure that patients are not extended user access controls or access to healthcare information in the normal ED temporal and physical scope of practice &  setting unless specifically authorized due to unusual circumstances, or as appropriate to organizational policy, or jurisdictional law .

1. The system SHALL time stamp initial entry, modification, or exchange of data, and identify the actor/principal taking the action as required by users' scope of practice, organizational policy, or jurisdictional law.

2. The system SHALL provide additional non-repudiation functionality where required by users' scope of practice, organizational policy, or jurisdictional law.

IN.1.6

IN.1.7

3. The system SHOULD conform to function IN.2.2 (Auditable Records) to prevent repudiation of data origination, receipt, or access.

4. The system SHOULD conform to function IN.1.8 (Information Attestation) to ensure the integrity of data exchange and thus prevent repudiation of data origination or receipt.

1. The system SHALL secure all modes of EHR data exchange.

2. The system SHOULD conform to function IN.1.7 (Secure Data Routing).

3. The system MAY provide the ability to obfuscate data.

4. The system SHALL encrypt and decrypt EHR data that is exchanged over a non-secure link.

5. The system SHALL support standards-based encryption mechanisms when encryption is used for secure data exchange.

1. The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations and only over secure networks.

2. The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to function IN.1.1 (Entity Authentication).

3. The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to the status of destinations and sources.

IN.1.8

IN.1.9

1. The system SHALL conform to function IN.1.1 (Entity Authentication) to provide authentication capabilities.

2. The system SHALL conform to function IN.1.2 (Entity Authorization) to provide authorization capabilities.

3. The system SHALL provide the ability to associate any attestable content added or changed to an EHR with the content's author (for example by conforming to function IN.2.2 (Auditable Records)).

4. The system SHALL provide the ability for attestation of attestable EHR content by the content's author.

5. The system SHALL indicate the status of attestable data which has not been attested.

6. The system MAY provide the ability for attestation of EHR content by properly authenticated and authorized users different from the author as required by users’ scope of practice, organizational policy, or jurisdictional law.

7. The system MAY provide the ability to use digital signatures as the means for attestation.

1. The system SHALL provide the ability to fully comply with the requirements for patient privacy and confidentiality in accordance with a user's scope of practice, organizational policy, or jurisdictional law.

2. The system SHALL conform to function IN.1.1 (Entity Authentication).

3. The system SHALL conform to function IN.1.2 (Entity Authorization).

4. The system SHALL conform to function IN.1.3 (Entity Access Control).

5. The system SHOULD conform to function IN.1.5 (Non- Repudiation).

6. The system SHALL conform to function IN.1.6 (Secure Data Exchange).

7. The system SHOULD conform to function IN.2.2 (Auditable Records)

IN.1.9.1

IN.1.9.2

IN.2

IN.2.1

8. The system SHALL provide the ability to maintain varying levels of confidentiality in accordance with users' scope of practice, organizational policy, or jurisdictional law.

1. The system SHALL provide a means to protect patient identities from other patients, patient visitors, and non participating healthcare providers.

1. The system shall provide a means to flag patients who require protection of their identity from others, including family, visitors, and non participating healthcare providers.

1. The system SHALL provide the ability to store and retrieve health record data and clinical documents for the legally prescribed time.

2. The system SHALL provide the ability to retain inbound data or documents (related to health records) as originally received (unaltered, inclusive of the method in which they were received) for the legally organizationally prescribed time in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

IN.2.2

3. The system SHALL retain the content of inbound data (related to health records) as originally received for the legally prescribed time.

4. The system SHOULD provide the ability to retrieve both the information and business context data within which that information was obtained.

5. The system SHALL provide the ability to retrieve all the elements included in the definition of a legal medical record.

6. The system MAY provide the ability to identify specific EHR data/records for destruction, review and confirm destruction before it occurs and implement function IN.2.2 (Auditable Records).

7. The system MAY provide the ability to destroy EHR data/records so that all traces are irrecoverably removed according to policy and legal retentions periods.

8. The system MAY pass along record destruction date information (if any) along with existing data when providing records to another entity.

1. The system SHALL provide audit capabilities for recording access and usage of systems, data, and organizational resources.

2. The system SHALL conform to function IN.1.1 (Entity Authentication).

3. The system SHALL provide audit capabilities indicating the time stamp for an object or data creation.

4. The system SHALL provide audit capabilities indicating the time stamp for an object or data modification in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

5. The system SHALL provide audit capabilities indicating the time stamp for an object or data extraction in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

6. The system SHALL provide audit capabilities indicating the time stamp for an object or data exchange.

7. The system SHOULD provide audit capabilities indicating the time stamp for an object or data view.

8. The system SHALL provide audit capabilities indicating the time stamp for an object or data deletion in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

9. The system SHALL provide audit capabilities indicating the author of a change in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

10. The system SHOULD provide audit capabilities indicating the viewer of a data set.

11. The system MAY provide audit capabilities indicating the data value before a change.

12. The system MAY provide audit capabilities to capture system events at the hardware and software architecture level.

13. The system SHALL conform to function IN.1.3 (Entity Access Control) to limit access to audit record information to appropriate entities in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

14. The system SHALL provide the ability to generate an audit report

15. The system SHALL provide the ability to view change history for a particular record or data set in accordance with users’ scope of practice, organizational policy, or jurisdictional law.

16. The system SHOULD provide the ability to record system maintenance events for loading new versions of, or changes to, the clinical system.

17. The system SHOULD provide the ability to record system maintenance events for loading new versions of codes and knowledge bases.

18. The system SHOULD provide the ability to record changing the date and time where the clinical system allows this to be done.

19. The system SHOULD provide the ability to record system maintenance events for creating and restoring of backup.

20. The system SHOULD provide the ability to record system maintenance events for archiving any data.

21. The system SHOULD provide the ability to record system maintenance events for re-activating of an archived patient record.

22. The system SHOULD provide the ability to record system maintenance events for entry to and exit from the EHR system.

23. The system SHOULD provide the ability to record system maintenance events for remote access connections including those for system support and maintenance activities.

24. The system SHOULD utilize standardized time keeping (for example using the IHE consistent time profile).

IN.2.3

IN.2.4

25. The system SHOULD provide the ability to record and report upon audit information using a standards-based audit record format.

1. The system SHALL conform to function IN.5.1 (Interchange Standards).

2. The system SHOULD conform to function IN.3 (Registry and Directory Services) to enable the use of registries and directories.

3. The system SHOULD provide the ability to link entities to external information.

4. The system SHOULD store the location of each known health record component in order to enable authorized access to a complete logical health record if the EHR is distributed among several applications within the EHR-S.

1. The system SHALL provide the ability to extract health record information.

2. The system SHOULD conform to function IN.1.6 (Secure Data Exchange) to provide secure data exchange capabilities.

3. The system SHOULD provide the ability to de-identify extracted information.

4. The system SHOULD conform to function IN.5.1 (Interchange Standards) to enable data extraction in standard-based formats.

5. The system SHOULD provide the ability to perform extraction operations across the complete data set that constitutes the health record of an individual within the system.

6. The system MAY provide the ability to perform extraction operations whose output fully chronicles the healthcare process.

7. The system SHOULD provide the ability to extract data for administrative purposes.

8. The system SHOULD provide the ability to extract data for financial purposes.

9. The system MAY provide the ability to extract data for research purposes.

10. The system MAY provide the ability to extract data for quality analysis purposes.

11. The system SHOULD provide the ability to extract data for public health purposes.

IN.2.5

IN.2.5.11. The system SHALL capture unstructured health record information as part of the patient EHR.

2. The system SHALL retrieve unstructured health record information as part of the patient EHR.

3. The system SHALL provide the ability to update unstructured health record information.

4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy unstructured health record information.

IN.2.5.2

IN.3

5. The system SHOULD provide the ability to report unstructured health record information.

6. The system MAY track unstructured health record information over time.

7. The system SHALL provide the ability append corrected unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied.

8. The system SHALL provide the ability to append unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied.

9. The system SHALL provide the ability append augmented unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied.

1. The system SHALL capture structured health record information as part of the patient EHR.

2. The system SHALL retrieve structured health record information as part of the patient EHR.

3. The system SHALL provide the ability to update structured health record information.

4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy structured health record information.

5. The system SHOULD provide the ability to report structured health record information.

6. The system MAY track structured health record information over time.

7. The system SHOULD provide the ability to retrieve each item of structured health record information discretely within patient context.

8. The system SHALL provide the ability to append corrected structured health record information to the original structured health record information. A specific type of implementation is not implied.

9. The system SHALL provide the ability to append structured health record information to the original structured health record information. A specific type of implementation is not implied.

10. The system SHALL provide the ability to append augmented structured health record information to the original structured health record information. A specific type of implementation is not implied.

1. The system SHALL provide the ability to use registry services and directories.

IN.4

2. The system SHALL provide the ability to securely use registry services and directories.

3. The system SHALL conform to function IN.5.1 (Interchange Standards) to provide standard data interchange capabilities IN. for using registry services and directories.

4. The system SHOULD communicate with local registry services through standardized interfaces.

5. The system SHOULD communicate with non-local registry services (that is, to registry services that are external to an EHR-S) through standardized interfaces.

6. The system SHOULD provide the ability to use registries or directories to uniquely identify patients for the provision of care.

7. The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care.

8. The system MAY provide the ability to use registries or directories to retrieve links to relevant healthcare information regarding a patient.

9. The system MAY provide the ability to use registries to supply links to relevant healthcare information regarding a patient.

10. The system MAY provide the ability to use registries or directories to identify payers, health plans, and sponsors for administrative and financial purposes.

11. The system MAY provide the ability to use registries or directories to identify employers for administrative and financial purposes.

12. The system MAY provide the ability to use registries or directories to identify public health agencies for healthcare purposes.

13. The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource management purposes.

IN.4.1

IN.4.2

1. The system SHALL provide the ability to use standard terminologies to communicate with other systems (internal or external to the EHR-S).

2. The system SHALL provide the ability to validate that clinical terms and coded clinical data exists in a current standard terminology.

3. The system SHOULD provide the ability to exchange healthcare data using formal standard information models and standard terminologies.

4. The system SHOULD provide the ability to use a formal standard terminology model.

5. The system SHOULD provide the ability to use hierarchical inference searches e.g., subsumption across coded terminology concepts, that were expressed using standard terminology models.

6. The system SHOULD provide the ability to use a terminology service (internal or external to the EHR-S).

7. Where there is no standard terminology model available, then the system MAY provide a formal explicit terminology model.

1. The system SHALL provide the ability to use different versions of terminology standards.

2. The system SHALL provide the ability to update terminology standards.

IN.4.3

IN.5

IN.5.1

3. The system MAY relate modified concepts in the different versions of a terminology standard to allow preservation of interpretations over time.

4. The system SHOULD provide the ability to interoperate with systems that use known different versions of a terminology standard.

5. The system SHOULD provide the ability to deprecate terminologies.

6. The system MAY provide the ability to deprecate individual codes within a terminology.

7. The system SHALL provide the ability to cascade terminology changes where coded terminology content is embedded in clinical models (for example, templates and custom formularies) when the cascaded terminology changes can be accomplished unambiguously.

8. Changes in terminology SHALL be applied to all new clinical content (via templates, custom formularies, etc.).

1. The system SHALL provide the ability to use a terminology map

2. The system SHOULD provide the ability to use standard terminology services for the purposes of mapping terminologies

3. The system MAY provide the ability for a user to validate a mapping

4. The system MAY provide the ability to create a terminology map.

1. The system SHALL provide the ability to use interchange standards as required by realm specific and/or local profiles.

IN.5.1.1

2. The system SHALL provide the ability to seamlessly perform interchange operations with other systems that adhere to recognized interchange standards.

3. The system SHALL conform to functions under header IN.4 (Standard Terminologies and Terminology Services) to support terminology standards in accordance with a users' scope of practice, organizational policy, or jurisdictional law.

4. If there is no standard information model available then the system MAY provide a formal explicit information model in order to support the ability to operate seamlessly with other systems.

5. The system SHOULD provide the ability to exchange data using an explicit and formal information model and standard, coded terminology.

1. The system SHALL manage structured documents.

2. The system SHALL support S.3.3.6 Health Service Reports at the Conclusion of an Episode of Care and be able to output the ED encounter record and other reports as structured documents.

IN.5.2

3. The system SHALL be able to retrieve, format and display structured documents from external sources.

1. The system SHALL provide the ability to use different versions of interchange standards.

2. The system SHALL provide the ability to change (reconfigure) the way that data is transmitted as an interchange standard evolves over time and in accordance with business needs.

3. The system SHOULD provide the ability to deprecate an interchange standard.

4. The system SHOULD provide the ability to interoperate with other systems that use known earlier versions of an interoperability standard.

IN.5.3

IN.5.4

IN.5.5

1. The system SHALL provide the ability to support standards-based application integration.

2. The system SHOULD provide the ability to support CCOW standards for purposes of application integration.

3. The system MAY provide the ability to support WfMC standards for purposes of application integration.

4. The system MAY provide the ability to support SOA standards for purposes of application integration.

1. The system SHALL use interchange agreement descriptions standards when exchanging information with partners.

2. The system SHOULD use interchange agreement description standards (when available).

3. The system MAY conform to function IN.3 (Registry and Directory Services) to interact with entity directories to determine the address, profile and data exchange requirements of known and/or potential partners.

4. The system MAY provide the ability to automatically discover interchange services and capabilities.

1. The system SHALL support integration with hospital systems sufficient to integrate patient registration, laboratory, diagnostic radiology, and pharmacy departments in the ED care process.

5. The system SHOULD support integration with PACS systems.

6. The system MAY provide a means to integrate with materials management systems.

IN.5.5.1

IN.5.5.2

IN.5.5.3

IN.6

2. The system SHALL conform to DC.2.3.2 (Support for Medication and Immunization Administration) and integrate with medical dispensing equipment including drug delivery systems and point of care devices to support the electronic medication administration process.

3. The system SHOULD support dynamic query to enterprise or federated data repositories to retrieve problem lists, medications, and allergies.

4. The system SHOULD provide a means to browse documents in a Clinical Document Repository.

1. The system SHALL interface with the bed-board system to support bed requests.

2. The system SHOULD be able to receive messages from the bed management system that a bed is available or will be available at a scheduled time.

1. The system SHALL support electronic transmission of prescriptions.

2. The system SHOULD provide a means to receive messages from external pharmacies about prescription problems, interactions, suggested substitutions and other issues that relate to prescription filing

3. The system MAY provide a mechanism to receive messages from outpatient pharmacies about potential prescription abuse or use.

1. The system SHALL support interfaces to billing systems to allow sending information needed to construct bills for facility, supply, medication and physician services

2. The system SHOULD provide a means for receiving confirmations of messages received by the enterprise billing system.

1. The system SHALL provide the ability to manage business rules.

workflow control rules.

obsolete, or destroy workflow control rules.

2. The system SHOULD provide the ability to create, import, or access decision support rules to guide system behavior.

3. The system SHOULD provide the ability to update decision support rules.

4. The system SHOULD provide the ability to customize decision support rules and their components.

5. The system SHOULD provide the ability to inactivate, obsolete, or destroy decision support rules.

6. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to decision support rules.

7. The system SHOULD provide the ability to create diagnostic support rules to guide system behavior.

8. The system SHOULD provide the ability to update diagnostic support rules.

9. The system MAY provide the ability to customize diagnostic support rules and their components.

10. The system SHOULD provide the ability to inactivate, obsolete, or destroy diagnostic support rules.

11. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to diagnostic support rules.

12. The system SHALL provide the ability to manage workflow control rules to guide system behavior.

13. The system SHOULD provide the ability to update

14. The system MAY provide the ability to customize workflow control rules and their components.

15. The system SHOULD provide the ability to inactivate,

16. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to workflow control rules.

17. The system MAY provide the ability to create access privilege rules to guide system behavior.

18. The system MAY provide the ability to update access privilege rules.

19. The system MAY provide the ability to customize access privilege rules and their components.

20. The system MAY provide the ability to inactivate, obsolete, or destroy access privilege rules.

21. The system MAY conform to function IN.2.2 (Auditable Records) to audit all changes to access privilege rules.

22. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to other business rules.

IN.7

IN.8

23. The system SHOULD support the ability to selectively export business rules.

1. The system SHALL use workflow-related business rules to direct the flow of work assignments.

2. The system SHOULD provide the ability to manage workflow (task list) queues.

3. The system MAY provide the ability to manage human resources (i.e., personnel lists) for workflow queues.

4. The system MAY use system interfaces that support the management of human resources (i.e., personnel lists)

5. The system MAY use system interfaces that support the management of workflow (task lists) queues

6. The system MAY provide the ability to distribute information to and from internal and external parties

7. The system SHOULD provide the ability to route notifications and tasks based on system triggers.

8. The system MAY dynamically escalate workflow according to business rules.

9. The system MAY dynamically redirect workflow according to business rules.

10. The system MAY dynamically reassign workflow according to business rules.

11. The system SHOULD direct and redirect information to providers to optimize workflow based on ad hoc decisions.

1. The system SHALL provide response to information requests from providers in sub-second times so as to not impair user attention, workflow, or patient flow in the ED practice setting.

2. The system SHOULD facilitate the login process by requiring only the information required to satisfy authentication.

3. The system SHOULD permit local setting of application timeout.

4. The system SHOULD log a user off a particular workstation if the user logs on to another workstation.

Row

ED 2

ED 4

ED 6

ED 8

ED 10

ED 12

ED 14

ED 15

ED 17

ED 19

ED 20

ED 22

ED 24

Funct. Profile

ED 26

ED 28

ED 30

ED 32

ED 34

ED 36

ED 38

ED 40

ED 41

ED 43

ED 45

ED 47

ED 49

ED 51

ED 53

ED 55

ED 56

ED 57

ED 58

ED 59

ED 60

ED 62

ED 63

ED 64

ED 65

ED 66

ED 67

ED 68

ED 69

ED 70

ED 71

ED 72

ED 73

ED 74

ED 75

ED 77

ED 79

ED 81

ED 83

ED 85

ED 87

ED 89

ED 90

ED 92

ED 94

ED 95

ED 97

ED 99

ED 102

ED 104

ED 106

ED 108

ED 110

ED 112

ED 114

ED 116

ED 117

ED 118

ED 120

ED 122

ED 124

ED 126

ED 128

ED 130

ED 132

ED 133

ED 135

ED 137

ED 138

ED 140

ED 141

ED 142

ED 143

ED 145

ED 147

ED 148

ED 149

ED 151

ED 152

ED 154

ED 155

ED 157

ED 159

ED 161

ED 163

ED 164

ED 166

ED 167

ED 168

ED 170

ED 172

ED 174

ED 176

ED 178

ED 180

ED 182

ED 184

ED 186

ED 187

ED 189

ED 191

ED 193

ED 195

ED 197

ED 198

ED 200

ED 202

ED 204

ED 206

ED 208

ED 209

ED 211

ED 213

ED 215

ED 217

ED 219

ED 221

ED 222

ED 224

ED 226

ED 228

ED 231

ED 233

ED 237

ED 239

ED 241

ED 242

ED 244

ED 245

ED 247

ED 249

ED 251

ED 253

ED 255

ED 256

ED 257

ED 259

ED 261

ED 263

ED 265

ED 267

ED 269

ED 272

ED 274

ED 275

ED 276

ED 277

ED 278

ED 280

ED 282

ED 286

ED 288

ED 290

ED 291

ED 292

ED 294

ED 299

ED 301

ED 303

ED 305

ED 307

ED 309

ED 311

ED 313

ED 315

ED 317

ED 319

ED 321

ED 323

ED 325

ED 327

ED 328

ED 330

ED 332

ED 334

ED 336

ED 338

ED 340

ED 342

ED 344

ED 346

ED 348

ED 349

ED 351

ED 353

ED 354

ED 356

ED 358

ED 360

ED 362

ED 364

ED 366

ED 368

ED 370

ED 372

ED 374

ED 375

ED 377

ED 379

ED 381

ED 383

ED 385

ED 388

ED 390

ED 392

ED 393

ED 394

ED 395

ED 397

ED 398

ED 400

ED 402

ED 404

ED 406

ED 408

ED 410

ED 411

ED 413

ED 415

ED 416

ED 417

ED 419

ED 421

ED 423

ED 425

ED 427

ED 429

ED 430

ED 432

ED 434

ED 436

ED 438

ED 440

ED 442

ED 444

ED 446

ED 448

ED 450

ED 452

ED 454

ED 456

ED 458

ED 461

ED 463

ED 465

ED 467

ED 469

ED 471

ED 473

ED 475

ED 477

ED 479

ED 481

ED 483

ED 485

ED 486

ED 487

ED 488

ED 490

ED 492

ED 494

ED 496

ED 498

ED 499

ED 501

ED 502

ED 503

ED 505

ED 507

ED 509

ED 511

ED 513

ED 515

ED 517

ED 519

ED 520

ED 522

ED 524

ED 526

ED 528

ED 530

ED 533

ED 534

ED 535

ED 536

ED 537

ED 539

ED 541

ED 543

ED 545

ED 547

ED 549

ED 552

ED 553

ED 554

ED 555

ED 557

ED 559

ED 561

ED 563

ED 565

ED 567

ED 569

ED 571

ED 573

ED 575

ED 577

ED 579

ED 581

ED 583

ED 585

ED 587

ED 589

ED 591

ED 593

ED 595

ED 596

ED 597

ED 598

ED 600

ED 602

ED 604

ED 606

ED 608

ED 609

ED 611

ED 613

ED 615

ED 617

ED 619

ED 621

ED 623

ED 625

ED 627

ED 629

ED 631

ED 633

ED 634

ED 636

ED 637

ED 638

ED 639

ED 641

ED 643

ED 645

ED 647

ED 649

ED 651

ED 653

ED 655

ED 656

ED 658

ED 660

ED 662

ED 664

ED 666

ED 668

ED 670

ED 672

ED 674

ED 676

ED 678

ED 679

ED 680

ED 681

ED 683

ED 685

ED 687

ED 689

ED 691

ED 693

ED 695

ED 697

ED 699

ED 701

ED 703

ED 705

ED 707

ED 709

ED 711

ED 713

ED 715

ED 717

ED 719

ED 721

ED 723

ED 725

ED 727

ED 729

ED 731

ED 733

ED 735

ED 737

ED 739

ED 741

ED 743

ED 745

ED 747

ED 749

ED 751

ED 753

ED 755

ED 757

ED 759

ED 761

ED 763

ED 765

ED 767

ED 769

ED 771

ED 773

ED 777

ED 779

ED 781

ED 783

ED 785

ED 787

ED 789

ED 791

ED 792

ED 794

ED 796

ED 797

ED 798

ED 800

ED 802

ED 804

ED 806

ED 808

ED 810

ED 811

ED 812

ED 814

ED 816

ED 818

ED 822

ED 824

ED 826

ED 828

ED 830

ED 832

ED 834

ED 836

ED 838

ED 840

ED 842

ED 844

ED 845

ED 846

ED 847

ED 848

ED 849

ED 850

ED 852

ED 854

ED 856

ED 857

ED 861

ED 863

ED 864

ED 865

ED 867

ED 869

ED 871

ED 873

ED 875

ED 877

ED 879

ED 880

ED 882

ED 884

ED 886

ED 888

ED 890

ED 892

ED 894

ED 896

ED 898

ED 900

ED 902

ED 904

ED 905

ED 906

ED 907

ED 909

ED 911

ED 912

ED 914

ED 916

ED 918

ED 920

ED 922

ED 924

ED 926

ED 928

ED 930

ED 932

ED 934

ED 936

ED 938

ED 940

ED 942

ED 943

ED 945

ED 947

ED 949

ED 951

ED 953

ED 955

ED 957

ED 959

ED 961

ED 963

ED 965

ED 967

ED 969

ED 971

ED 973

ED 975

ED 977

ED 979

ED 981

ED 983

ED 989

ED 991

ED 993

ED 995

ED 997

ED 999

ED 1002

ED 1004

ED 1005

ED 1006

ED 1008

ED 1009

ED 1010

ED 1011

ED 1012

ED 1014

ED 1017

ED 1019

ED 1021

ED 1023

ED 1025

ED 1027

ED 1029

ED 1031

ED 1033

ED 1035

ED 1037

ED 1042

ED 1044

ED 1046

ED 1047

ED 1049

ED 1051

ED 1053

ED 1055

ED 1057

ED 1059

ED 1061

ED 1063

ED 1065

ED 1067

ED 1069

ED 1070

ED 1071

ED 1072

ED 1073

ED 1075

ED 1077

ED 1079

ED 1081

ED 1083

ED 1085

ED 1087

ED 1089

ED 1091

ED 1093

ED 1095

ED 1097

ED 1099

ED 1101

ED 1103

ED 1105

ED 1107

ED 1109

ED 1111

ED 1113

ED 1115

ED 1117

ED 1119

ED 1121

ED 1123

ED 1125

ED 1127

ED 1129

ED 1131

ED 1133

ED 1135

ED 1137

ED 1139

ED 1141

ED 1143

ED 1145

ED 1147

ED 1148

ED 1150

ED 1152

ED 1154

ED 1156

ED 1158

ED 1160

ED 1163

ED 1165

ED 1167

ED 1168

ED 1170

ED 1172

ED 1174

ED 1176

ED 1178

ED 1180

ED 1182

ED 1184

ED 1186

ED 1188

ED 1190

ED 1191

ED 1192

ED 1194

ED 1196

ED 1198

ED 1200

ED 1202

ED 1204

ED 1206

ED 1208

ED 1210

ED 1212

ED 1214

ED 1216

ED 1218

ED 1220

ED 1222

ED 1224

ED 1226

ED 1228

ED 1231

ED 1233

ED 1235

ED 1237

ED 1239

ED 1241

ED 1243

ED 1245

ED 1247

ED 1249

ED 1252

ED 1253

ED 1255

ED 1257

ED 1259

ED 1261

ED 1263

ED 1265

ED 1267

ED 1269

ED 1271

ED 1274

ED 1276

ED 1277

ED 1279

ED 1281

ED 1283

ED 1285

ED 1287

ED 1289

ED 1291

ED 1293

ED 1295

ED 1297

ED 1299

ED 1300

ED 1302

ED 1304

ED 1306

ED 1308

ED 1310

ED 1312

ED 1314

ED 1316

ED 1318

ED 1320

ED 1322

ED 1324

ED 1326

ED 1328

ED 1330

ED 1332

ED 1333

ED 1334

ED 1336

ED 1338

ED 1340

ED 1342

ED 1344

ED 1346

ED 1348

ED 1350

ED 1352

ED 1356

ED 1358

ED 1359

ED 1360

ED 1361

ED 1363

ED 1365

ED 1367

ED 1370

ED 1372

ED 1374

ED 1375

ED 1377

ED 1379

ED 1381

ED 1383

ED 1385

ED 1387

ED 1389

ED 1391

ED 1393

ED 1395

ED 1397

ED 1399

ED 1401

ED 1403

ED 1404

ED 1406

ED 1408

ED 1410

ED 1412

ED 1414

ED 1415

ED 1416

ED 1418

ED 1420

ED 1422

ED 1424

ED 1426

ED 1428

ED 1430

ED 1432

ED 1434

ED 1436

ED 1438

ED 1440

ED 1442

ED 1444

ED 1446

ED 1447

ED 1449

ED 1451

ED 1453

ED 1454

ED 1456

ED 1458

ED 1460

ED 1462

ED 1464

ED 1466

ED 1468

ED 1470

ED 1472

ED 1473

ED 1474

ED 1476

ED 1478

ED 1480

ED 1481

ED 1483

ED 1485

ED 1487

ED 1490

ED 1491

ED 1492

ED 1494

ED 1495

ED 1497

ED 1498

ED 1499

ED 1500

ED 1501

ED 1502

ED 1504

ED 1506

ED 1508

ED 1510

ED 1511

ED 1513

ED 1515

ED 1517

ED 1519

ED 1521

ED 1523

ED 1525

ED 1527

ED 1529

ED 1531

ED 1533

ED 1535

ED 1537

ED 1539

ED 1541

ED 1543

ED 1545

ED 1547

ED 1550

ED 1552

ED 1554

ED 1556

ED 1558

ED 1560

ED 1562

ED 1564

ED 1566

ED 1568

ED 1570

ED 1572

ED 1574

ED 1576

ED 1577

ED 1578

ED 1580

ED 1581

ED 1582

ED 1583

ED 1584

ED 1585

ED 1586

ED 1587

ED 1588

ED 1589

ED 1590

ED 1591

ED 1592

ED 1593

ED 1594

ED 1595

ED 1596

ED 1598

ED 1600

ED 1602

ED 1604

ED 1606

ED 1608

ED 1610

ED 1612

ED 1614

ED 1616

ED 1618

ED 1620

ED 1622

ED 1624

ED 1626

ED 1628

ED 1629

ED 1630

ED 1631

ED 1632

ED 1634

ED 1636

ED 1638

ED 1640

ED 1642

ED 1644

ED 1646

ED 1648

ED 1650

ED 1652

ED 1654

ED 1656

ED 1657

ED 1658

ED 1660

ED 1662

ED 1663

ED 1664

ED 1665

ED 1666

ED 1668

ED 1669

ED 1670

ED 1671

ED 1672

ED 1673

ED 1675

ED 1677

ED 1678

ED 1679

ED 1680

ED 1681

ED 1682

ED 1684

ED 1686

ED 1688

ED 1690

ED 1692

ED 1694

ED 1696

ED 1698

ED 1700

ED 1702

ED 1704

ED 1706

ED 1707

ED 1709

ED 1711

ED 1713

ED 1715

ED 1717

ED 1719

ED 1721

ED 1723

ED 1725

ED 1728

ED 1730

ED 1732

ED 1734

ED 1736

ED 1738

ED 1740

ED 1742

ED 1744

ED 1746

ED 1748

ED 1750

ED 1752

ED 1753

ED 1754

ED 1756

ED 1758

ED 1760

ED 1762

ED 1764

ED 1766

ED 1768

ED 1770

ED 1771

ED 1773

ED 1775

ED 1777

ED 1779

ED 1781

ED 1783

ED 1785

ED 1786

ED 1787

ED 1789

ED 1791

ED 1793

ED 1794

ED 1796

ED 1798

ED 1800

ED 1802

ED 1804

ED 1805

ED 1806

ED 1807

ED 1808

ED 1809

ED 1811

ED 1813

ED 1815

ED 1817

ED 1819

ED 1821

ED 1823

ED 1825

ED 1827

ED 1829

ED 1831

ED 1833

ED 1834

ED 1835

ED 1836

ED 1837

ED 1838

ED 1840

ED 1841

ED 1842

ED 1843

ED 1844

ED 1845

ED 1846

ED 1848

ED 1850

ED 1851

ED 1852

ED 1854

ED 1856

ED 1858

ED 1860

ED 1862

ED 1863

ED 1865

ED 1867

ED 1869

ED 1871

ED 1873

ED 1875

ED 1877

ED 1879

ED 1881

ED 1883

ED 1885

ED 1887

ED 1889

ED 1891

ED 1893

ED 1895

ED 1897

ED 1898

ED 1900

ED 1902

ED 1903

ED 1905

ED 1907

ED 1909

ED 1911

ED 1913

ED 1915

ED 1917

ED 1919

ED 1921

ED 1923

ED 1924

ED 1925

ED 1927

ED 1929

ED 1931

ED 1933

ED 1935

ED 1937

ED 1939

ED 1941

ED 1943

ED 1945

ED 1947

ED 1949

Level IDCode Model1 DC.1 Both Basic EDIS2 DC.1.1 Both Basic EDIS3 DC.1.1.3 Both Basic EDIS4 DC.1.1.3.4 Both Basic EDIS3 DC.1.1.6 Both Basic EDIS

2 DC.1.10 EDIS Only EDIS3 DC.1.10.1 EDIS Only EDIS4 DC.1.10.1.1 EDIS Only EDIS4 DC.1.10.1.2 EDIS Only EDIS4 DC.1.10.1.3 EDIS Only EDIS4 DC.1.10.1.4 EDIS Only EDIS

2 DC.1.11 EDIS Only EDIS1 DC.3 Both Basic EDIS2 DC.3.2 Both Basic EDIS3 DC.3.2.6 Both Basic EDIS3 DC.3.2.7 Both Basic EDIS4 DC.3.2.7.1 Both Basic EDIS4 DC.3.2.7.2 Both Basic EDIS3 DC.3.2.8 Both Basic EDIS3 DC.3.2.9 Both Basic EDIS4 DC.3.2.10 Both Basic EDIS4 DC.3.2.11 Both Basic EDIS

1 S.1 Both Basic EDIS2 S.1.8 Both Basic EDIS3 S.1.8.1 Both Basic EDIS3 S.1.8.2 Both Basic EDIS3 S.1.8.3 Both Basic EDIS

1 S.2 Both Basic EDIS2 S.2.1 Both Basic EDIS3 S.2.1.3 Both Basic EDIS3 S.2.1.4 Both Basic EDIS2 S.2.2 Both Basic EDIS3 S.2.2.2 Both Basic EDIS4 S.2.2.2.1 EDIS Only EDIS

1 S.3 Both Basic EDIS2 S.3.2 Both Basic EDIS3 S.3.2.4 Both Basic EDIS3 S.3.2.5 Both Basic EDIS3 S.3.2.6 Both Basic EDIS

1 IN.1 Both Basic EDIS2 IN.1.9 Both Basic EDIS3 IN.1.9.1 EDIS Only EDIS3 IN.1.9.2 EDIS Only EDIS1 IN.2 Both Basic EDIS2 IN.2.5 Both Basic EDIS3 IN.2.5.3 Both Basic EDIS3 IN.2.5.4 Both Basic EDIS3 IN.2.5.5 Both Basic EDIS1 IN.5 Both Basic EDIS2 IN.5.1 Both Basic EDIS

3 IN.5.1.1 EDIS Only EDIS2 IN.5.5 EDIS Only EDIS3 IN.5.5.1 EDIS Only EDIS3 IN.5.5.2 EDIS Only EDIS3 IN.5.5.3 EDIS Only EDIS1 IN.8 Both Basic EDIS2 IN.8.1 Both Basic EDIS2 IN.8.2 Both Basic EDIS2 IN.8.3 Both Basic EDIS1 IN.9 Both Basic EDIS2 IN.9.1 Both Basic EDIS2 IN.9.2 Both Basic EDIS2 IN.9.3 Both Basic EDIS2 IN.9.4 Both Basic EDIS2 IN.9.5 Both Basic EDIS

Care Management DC.1Record Management DC.1 .1

Data and Documentation from External Sources DC.1 .1 .3

Capture Guidelines and Standards from External Souces DC.1 .1 .3 .4

Non-text Data DC.1 .1 .6

Manage ED Disposition DC.1 .10Manage ED Discharge DC.1 .10 .1Manage Follow-on Care DC.1 .10 .1 .1Manage Prescriptions DC.1 .10 .1 .2Manage ED to Hospital Admission DC.1 .10 .1 .3Manage Transfers DC.1 .10 .1 .4

Manage Discharged Patients DC.1 .11Operations Management and Communication DC.3Support Clinical Communication DC.3 .2

Communication with non-Medical Devices DC.3 .2 .6

Support for Communications Within an Enterprise/Facility DC.3 .2 .7

Tracking Boards DC.3 .2 .7 .1

Transition of Care Tools DC.3 .2 .7 .2

Support for Communications Between Enterprises/Facilities DC.3 .2 .8

Support for Facility to External Agency Communications DC.3 .2 .9

Support for Provider-Employer Communications DC.3 .2 .10

Support for Special Interest Personnel Communications DC.3 .2 .11

Clinical Support S.1Information View S.1 .8

User Interface Management 1: Views S.1 .8 .1

User Interface Management 2: Interface S.1 .8 .2

User Interface Management 3: Entry S.1 .8 .3

Measurement, Analysis, Research and Reports S.2Measurement, Monitoring, and Analysis S.2 .1

Support for Process Improvement S.2 .1 .3

Support for Care System Performance Indicators (Dashboards) S.2 .1 .4

Report Generation S.2 .2

Standard Report Generation S.2 .2 .2ED Benchmarking Reports S.2 .2 .2 .1

Administrative and Financial S.3Information Access for Supplemental Use S.3 .2

Assistance for Coding Deficiencies S.3 .2 .4

Support for Provider Training S.3 .2 .5

Support for Provider Credentialing and Privileging S.3 .2 .6

Security IN.1Patient Privacy and Confidentiality IN.1 .9Redact patient identifying information. IN.1 .9 .1Protect individual patient identity. IN.1 .9 .2

Health Record Information and Management IN.2

Store and Manage Health Record Information IN.2 .5Manage Health Information Record Quality IN.2 .5 .3Manage Macros, Templates and Pre-Defined Text IN.2 .5 .4Locate External Health Record Information IN.2 .5 .5

Standards-based Interoperability IN.5

Interchange Standards IN.5 .1

DC.3      DC.3.2        DC.3.2.5   

S.1      S.  S.

S.2      S.2.1        S.2.1.2        S.2.1.2      S.2.2        S.2.2.2   

S.3      S.3.2        S.3.2.3   

  IN.1.9   

IN.2

  IN    IN.2.5.1    IN.5      IN.5.1   

Structured Documents IN.5 .1 .1EDIS Interoperability IN.5 .5Bed Board Interface IN.5 .5 .1Electronic Prescribing Interface IN.5 .5 .2Billing Interface IN.5 .5 .3

Application Optimization IN.8EHR-S User Feedback IN.8 .1Automated System Performance Feedback IN.8 .2Ad-Hoc System Performance Queries IN.8 .3

User Interface Support IN.9Presentation Configuration IN.9 .1User Help IN.9 .2Spelling and Grammar Check IN.9 .3User Interface with Devices IN.9 .4Pre-Defined Text, Macros and Templates IN.9 .5

DC.1 Care Management.1 Record Management.3 Data and Documentation from External Sources.4 Capture Guidelines and Standards from External Souces.6 Non-text Data

.10 Manage ED Disposition

.1 Manage ED Discharge

.1 Manage Follow-on Care

.2 Manage Prescriptions

.3 Manage ED to Hospital Admission

.4 Manage Transfers

.11 Manage Discharged PatientsDC.3 Operations Management and Communication.2 Support Clinical Communication.6 Communication with non-Medical Devices.7 Support for Communications Within an Enterprise/Facility.1 Tracking Boards.2 Transition of Care Tools.8 Support for Communications Between Enterprises/Facilities.9 Support for Facility to External Agency Communications Support for Provider-Employer Communications Support for Special Interest Personnel Communications

S.1 Clinical Support.8 Information View.1 User Interface Management 1: Views.2 User Interface Management 2: Interface.3 User Interface Management 3: Entry

S.2 Measurement, Analysis, Research and Reports.1 Measurement, Monitoring, and Analysis.3 Support for Process Improvement.4 Support for Care System Performance Indicators (Dashboards).2 Report Generation.2 Standard Report Generation.1 ED Benchmarking Reports

S.3 Administrative and Financial.2 Information Access for Supplemental Use.4 Assistance for Coding Deficiencies.5 Support for Provider Training.6 Support for Provider Credentialing and Privileging

IN.1 Security.9 Patient Privacy and Confidentiality.1 Redact patient identifying information..2 Protect individual patient identity. IN.2 Health Record Information and Management.5 Store and Manage Health Record Information.3 Manage Health Information Record Quality.4 Manage Macros, Templates and Pre-Defined Text.5 Locate External Health Record InformationIN.5 Standards-based Interoperability.1 Interchange Standards

.1 Structured Documents

.5 EDIS Interoperability

.1 Bed Board Interface

.2 Electronic Prescribing Interface

.3 Billing InterfaceIN.8 Application Optimization.1 EHR-S User Feedback.2 Automated System Performance Feedback.3 Ad-Hoc System Performance QueriesIN.9 User Interface Support.1 Presentation Configuration.2 User Help.3 Spelling and Grammar Check.4 User Interface with Devices.5 Pre-Defined Text, Macros and Templates

Level IDCode Model1 DC.1 Both Basic EDIS2 DC.1.1 Both Basic EDIS3 DC.1.1.1 Both Basic EDIS3 DC.1.1.2 Both Basic EDIS4 DC.1.1.2.1 EDIS Only EDIS4 DC.1.1.2.2 EDIS Only EDIS4 DC.1.1.2.3 EDIS Only EDIS3 DC.1.1.3 Both Basic EDIS4 DC.1.1.3.1 Both Basic EDIS5 DC.1.1.3.1.1 EDIS Only EDIS4 DC.1.1.3.2 Both Basic EDIS4 DC.1.1.3.3 Both Basic EDIS4 DC.1.1.3.4 Both Basic EDIS3 DC.1.1.4 Basic Only Basic3 DC.1.1.5 Basic Only Basic3 DC.1.1.6 Both Basic EDIS2 DC.1.2 Both Basic EDIS3 DC.1.2.1 EDIS Only EDIS3 DC.1.2.2 EDIS Only EDIS3 DC.1.2.3 EDIS Only EDIS3 DC.1.2.4 EDIS Only EDIS2 DC.1.3 Both Basic EDIS3 DC.1.3.1 Both Basic EDIS3 DC.1.3.2 Both Basic EDIS3 DC.1.3.3 Both Basic EDIS2 DC.1.4 Both Basic EDIS3 DC.1.4.1 Both Basic EDIS3 DC.1.4.2 Both Basic EDIS3 DC.1.4.3 Both Basic EDIS3 DC.1.4.4 Both Basic EDIS2 DC.1.5 Both Basic EDIS3 DC.1.5.1 EDIS Only EDIS3 DC.1.5.2 EDIS Only EDIS2 DC.1.6 Both Basic EDIS3 DC.1.6.1 Both Basic EDIS3 DC.1.6.2 Basic Only Basic2 DC.1.7 Both Basic EDIS3 DC.1.7.1 Both Basic EDIS3 DC.1.7.2 Both Basic EDIS4 DC.1.7.2.1 Both Basic EDIS4 DC.1.7.2.2 Both Basic EDIS4 DC.1.7.2.3 Both Basic EDIS4 DC.1.7.2.4 Both Basic EDIS3 DC.1.7.3 Both Basic EDIS

2 DC.1.8 Both Basic EDIS3 DC.1.8.1 Both Basic EDIS3 DC.1.8.2 Basic Only Basic

3 DC.1.8.3 Basic Only Basic Basic3 DC.1.8.4 Basic Only Basic Basic3 DC.1.8.5 Basic Only Basic Basic4 DC.1.8.5.1 EDIS Only EDIS4 DC.1.8.5.2 EDIS Only EDIS4 DC.1.8.5.3 EDIS Only EDIS

3 DC.1.8.6 Basic Only Basic Basic3 DC.1.8.7 EDIS Only EDIS3 DC.1.8.8 EDIS Only EDIS

2 DC.1.9 Basic Only Basic Basic2 DC.1.10 EDIS Only EDIS3 DC.1.10.1 EDIS Only EDIS4 DC.1.10.1.1 EDIS Only EDIS4 DC.1.10.1.2 EDIS Only EDIS4 DC.1.10.1.3 EDIS Only EDIS4 DC.1.10.1.4 EDIS Only EDIS

2 DC.1.11 EDIS Only EDIS1 DC.2 Both Basic EDIS2 DC.2.1 Both Basic EDIS3 DC.2.1.1 Both Basic EDIS3 DC.2.1.2 Both Basic EDIS3 DC.2.1.3 Basic Only Basic3 DC.2.1.4 Basic Only Basic3 DC.2.1.5 EDIS Only EDIS3 DC.2.1.6 EDIS Only EDIS

2 DC.2.2 Both Basic EDIS3 DC.2.2.1 Both Basic EDIS4 DC.2.2.1.1 Both Basic EDIS4 DC.2.2.1.2 Both Basic EDIS3 DC.2.2.2 Basic Only Basic3 DC.2.2.3 Both Basic EDIS3 DC.2.2.4 Basic Only Basic2 DC.2.3 Both Basic EDIS3 DC.2.3.1 Both Basic EDIS4 DC.2.3.1.1 Both Basic EDIS4 DC.2.3.1.2 Both Basic EDIS4 DC.2.3.1.3 Both Basic EDIS3 DC.2.3.2 Both Basic EDIS2 DC.2.4 Both Basic EDIS3 DC.2.4.1 Both Basic EDIS3 DC.2.4.2 Both Basic EDIS3 DC.2.4.3 Both Basic EDIS3 DC.2.4.4 Both Basic EDIS4 DC.2.4.4.1 Both Basic EDIS4 DC.2.4.4.2 Both Basic EDIS3 DC.2.4.5 Both Basic EDIS4 DC.2.4.5.1 Both Basic EDIS4 DC.2.4.5.2 Basic Only Basic

2 DC.2.5 Basic Only Basic3 DC.2.5.1 Basic Only Basic3 DC.2.5.2 Basic Only Basic2 DC.2.6 Both Basic EDIS3 DC.2.6.1 Both Basic EDIS3 DC.2.6.2 Basic Only Basic3 DC.2.6.3 Basic Only Basic2 DC.2.7 Both Basic EDIS3 DC.2.7.1 Both Basic EDIS3 DC.2.7.2 Basic Only Basic

1 DC.3 Both Basic EDIS2 DC.3.1 Both Basic EDIS3 DC.3.1.1 Both Basic EDIS3 DC.3.1.2 Both Basic EDIS3 DC.3.1.3 Both Basic EDIS2 DC.3.2 Both Basic EDIS3 DC.3.2.1 Both Basic EDIS4 DC.3.2.1.1 EDIS Only EDIS3 DC.3.2.2 Both Basic EDIS3 DC.3.2.3 Both Basic EDIS3 DC.3.2.4 Both Basic EDIS3 DC.3.2.5 Both Basic EDIS3 DC.3.2.6 Both Basic EDIS3 DC.3.2.7 Both Basic EDIS4 DC.3.2.7.1 Both Basic EDIS4 DC.3.2.7.2 Both Basic EDIS3 DC.3.2.8 Both Basic EDIS3 DC.3.2.9 Both Basic EDIS4 DC.3.2.10 Both Basic EDIS4 DC.3.2.11 Both Basic EDIS

1 S.1 Both Basic EDIS2 S.1.1 Both Basic EDIS2 S.1.2 Basic Only Basic2 S.1.3 Both Basic EDIS3 S.1.3.1 Both Basic EDIS3 S.1.3.2 Both Basic EDIS3 S.1.3.3 Both Basic EDIS3 S.1.3.4 Both Basic EDIS3 S.1.3.5 Basic Only Basic3 S.1.3.6 Basic Only Basic3 S.1.3.7 Basic Only Basic2 S.1.4 Both Basic EDIS3 S.1.4.1 Both Basic EDIS3 S.1.4.2 Both Basic EDIS4 S.1.4.2.1 EDIS Only EDIS4 S.1.4.2.2 EDIS Only EDIS3 S.1.4.3 Basic Only Basic3 S.1.4.4 Both Basic EDIS

2 S.1.5 Basic Only Basic2 S.1.6 Both Basic EDIS2 S.1.7 Both Basic EDIS2 S.1.8 Both Basic EDIS3 S.1.8.1 Both Basic EDIS3 S.1.8.2 Both Basic EDIS3 S.1.8.3 Both Basic EDIS2 S.1.9 Both Basic EDIS

1 S.2 Both Basic EDIS2 S.2.1 Both Basic EDIS3 S.2.1.1 Both Basic EDIS3 S.2.1.2 Both Basic EDIS3 S.2.1.3 Both Basic EDIS3 S.2.1.4 Both Basic EDIS2 S.2.2 Both Basic EDIS3 S.2.2.1 Both Basic EDIS3 S.2.2.2 Both Basic EDIS4 S.2.2.2.1 EDIS Only EDIS3 S.2.2.3 Both Basic EDIS

1 S.3 Both Basic EDIS2 S.3.1 Both Basic EDIS3 S.3.1.1 Basic Only Basic3 S.3.1.2 Basic Only Basic3 S.3.1.3 Both Basic EDIS3 S.3.1.4 Basic Only Basic3 S.3.1.5 Both Basic EDIS2 S.3.2 Both Basic EDIS3 S.3.2.1 Both Basic EDIS3 S.3.2.2 Both Basic EDIS3 S.3.2.3 Both Basic EDIS3 S.3.2.4 Both Basic EDIS3 S.3.2.5 Both Basic EDIS3 S.3.2.6 Both Basic EDIS2 S.3.3 Both Basic EDIS3 S.3.3.1 Basic Only Basic3 S.3.3.2 Both Basic EDIS3 S.3.3.3 Basic Only Basic3 S.3.3.4 Both Basic EDIS3 S.3.3.5 Both Basic EDIS3 S.3.3.6 Both Basic EDIS2 S.3.4 Basic Only Basic2 S.3.5 Basic Only Basic3 S.3.5.1 Basic Only Basic3 S.3.5.2 Basic Only Basic3 S.3.5.3 Basic Only Basic3 S.3.5.4 Basic Only Basic2 S.3.6 Both Basic EDIS2 S.3.7 Both Basic EDIS

3 S.3.7.1 Both Basic EDIS3 S.3.7.2 Both Basic EDIS3 S.3.7.3 Basic Only Basic3 S.3.7.4 Both Basic EDIS

1 IN.1 Both Basic EDIS2 IN.1.1 Both Basic EDIS2 IN.1.2 Both Basic EDIS2 IN.1.3 Both Basic EDIS2 IN.1.4 Both Basic EDIS2 IN.1.5 Both Basic EDIS2 IN.1.6 Both Basic EDIS2 IN.1.7 Both Basic EDIS2 IN.1.8 Both Basic EDIS2 IN.1.9 Both Basic EDIS3 IN.1.9.1 EDIS Only EDIS3 IN.1.9.2 EDIS Only EDIS1 IN.2 Both Basic EDIS2 IN.2.1 Both Basic EDIS2 IN.2.2 Both Basic EDIS2 IN.2.3 Both Basic EDIS2 IN.2.4 Both Basic EDIS2 IN.2.5 Both Basic EDIS3 IN.2.5.3 Both Basic EDIS3 IN.2.5.4 Both Basic EDIS3 IN.2.5.5 Both Basic EDIS1 IN.3 Both Basic EDIS1 IN.4 Both Basic EDIS2 IN.4.1 Both Basic EDIS2 IN.4.2 Both Basic EDIS2 IN.4.3 Both Basic EDIS1 IN.5 Both Basic EDIS2 IN.5.1 Both Basic EDIS3 IN.5.1.1 EDIS Only EDIS2 IN.5.2 Both Basic EDIS2 IN.5.3 Both Basic EDIS2 IN.5.4 Both Basic EDIS2 IN.5.5 EDIS Only EDIS3 IN.5.5.1 EDIS Only EDIS3 IN.5.5.2 EDIS Only EDIS3 IN.5.5.3 EDIS Only EDIS1 IN.6 Both Basic EDIS1 IN.7 Both Basic EDIS1 IN.8 Both Basic EDIS2 IN.8.1 Both Basic EDIS2 IN.8.2 Both Basic EDIS2 IN.8.3 Both Basic EDIS1 IN.9 Both Basic EDIS2 IN.9.1 Both Basic EDIS

2 IN.9.2 Both Basic EDIS2 IN.9.3 Both Basic EDIS2 IN.9.4 Both Basic EDIS2 IN.9.5 Both Basic EDIS

Care ManagementRecord ManagementIdentify and Maintain a Patient RecordManage Patient DemographicsEDIS RegistrationQuick RegistrationED Merge Registration

Data and Documentation from External SourcesCapture Data and Documentation from External Clinical SourcesCapture EMS data

Capture Patient-Originated DataCapture Patient Health Data Derived from Administrative and Financial Data and DocumentationCapture Guidelines and Standards from External SoucesProduce a Summary Record of CarePresent Ad Hoc Views of the Health RecordNon-text DataManage Patient HistoryManage Pre-Arrival DataManage Arrival DataManage TriageManage History of Present Illness

Preferences, Directives, Consents and AuthorizationsManage Patient and Family PreferencesManage Patient Advance DirectivesManage Consents and AuthorizationsSummary ListsManage Allergy, Intolerance and Adverse Reaction ListManage Medication ListManage Problem ListManage Immunization ListManage AssessmentsManage Physical ExaminationManage Progress Notes

Care Plans, Treatment Plans, Guidelines, and ProtocolsPresent Guidelines and Protocols for Planning CareManage Patient-Specific Care and Treatment PlansOrders and Referrals ManagementManage Medication OrdersNon-Medication Orders and Referrals ManagementManage Non-Medication Patient Care OrdersManage Orders for Diagnostic TestsManage Orders for Blood Products and Other BiologicsManage ReferralsManage Order SetsDocumentation of Care, Measurements and ResultsManage Medication AdministrationManage Immunization Administration

Manage ResultsManage Patient Clinical MeasurementsManage Clinical Documents and NotesAcknowledge/Amend Other Provider Documentation Document Patient and Family Communication and EducationManage Transfers of Care between ED Providers

Manage Documentation of Clinician Response to Decision Support PromptsManage ProceduresManage Medical Decision-Making

Generate and Record Patient-Specific InstructionsManage Patient Disposition DocumentationManage Discharge DispositionManage Follow-on Care DocumentionManage Prescription DocumentaitonManage ED to Hospital Admission DocumentationManage Transfer Documentation

Manage Discharged PatientsClinical Decision SupportManage Health Information to Provide Decision SupportSupport for Standard AssessmentsSupport for Patient Context-Driven Assessments

Support for Patient and Family PreferencesSupport Triage Categorization Support Waiting Room Management

Care and Treatment Plans, Guidelines and ProtocolsSupport for Condition Based Care and Treatment Plans, Guidelines, ProtocolsSupport for Standard Care Plans, Guidelines, ProtocolsSupport for Context-Sensitive Care Plans, Guidelines, ProtocolsSupport Consistent Healthcare Management of Patient Groups or PopulationsSupport for Research Protocols Relative to Individual Patient CareSupport Self-CareMedication and Immunization ManagementSupport for Medication and Immunization OrderingSupport for Drug Interaction CheckingSupport for Patient Specific Dosing and WarningsSupport for Medication RecommendationsSupport for Medication and Immunization AdministrationOrders, Referrals, Results and Care ManagementCreate Order Set TemplatesSupport for Non-Medication OrderingSupport for Result InterpretationSupport for ReferralsSupport for Referral ProcessSupport for Referral RecommendationsSupport for Care DeliverySupport for Safe Blood AdministrationSupport for Accurate Specimen Collection

Support for Identification and Notification of Potential Problems and Trends

Support for Health Maintenance: Preventive Care and WellnessPresent Alerts for Preventive Services and WellnessNotifications and Reminders for Preventive Services and WellnessSupport for Population HealthSupport for Epidemiological Investigations of Clinical Health Within a Population.Support for Notification and ResponseSupport for Monitoring Response Notifications Regarding a Specific Patient's HealthSupport for Knowledge AccessAccess Healthcare GuidancePatient Knowledge AccessOperations Management and CommunicationClinical Workflow TaskingClinical Task Assignment and RoutingClinical Task LinkingClinical Task TrackingSupport Clinical CommunicationSupport for Inter-Provider CommunicationManage Consultation Requests and Responses

Support for Provider-Pharmacy CommunicationSupport for Communications Between Provider and Patient and/or the Patient RepresentativePatient, Family and Care Giver EducationCommunication with Medical DevicesCommunication with non-Medical DevicesSupport for Communications Within an Enterprise/FacilityTracking BoardsTransition of Care ToolsSupport for Communications Between Enterprises/FacilitiesSupport for Facility to External Agency CommunicationsSupport for Provider-Employer CommunicationsSupport for Special Interest Personnel CommunicationsClinical SupportRegistry NotificationDonor Management SupportProvider InformationProvider Access LevelsProvider's Location Within FacilityProvider's On Call LocationProvider's Location(s) or Office(s)Team/Group of Providers Registry or DirectoryProvider Caseload/PanelProvider Registry or DirectoryPatient DirectoryPatient DemographicsPatient's Location Within a FacilityPatient’s Location Within the Emergency DepartmentDepartment Modeling and Room Management

Patient's Residence for the Provision and Administration of ServicesPatient Bed Assignment

De-Identified Data Request ManagementSchedulingHealthcare Resource AvailabilityInformation View User Interface Management 1: Views User Interface Management 2: Interface User Interface Management 3: EntrySupport Healthcare Management for Disaster ResponseMeasurement, Analysis, Research and ReportsMeasurement, Monitoring, and AnalysisOutcome Measures and AnalysisPerformance and Accountability MeasuresSupport for Process ImprovementSupport for Care System Performance Indicators (Dashboards)Report GenerationHealth Record OutputStandard Report GenerationED Benchmarking Reports

Ad Hoc Query and Report GenerationAdministrative and FinancialEncounter/Episode of Care ManagementSpecialized ViewsEncounter Specific FunctionalityAutomatic Generation of Administrative and Financial Data from Clinical RecordSupport Remote Healthcare ServicesOther Encounter and Episode of Care SupportInformation Access for Supplemental UseRules-Driven Clinical Coding AssistanceRules-Driven Financial and Administrative Coding AssistanceIntegrate Cost/Financial InformationAssistance for Coding DeficienciesSupport for Provider TrainingSupport for Provider Credentialing and PrivilegingAdministrative Transaction ProcessingEnrollment of PatientsEligibility Verification and Determination of CoverageService AuthorizationsSupport of Service Requests and ClaimsClaims and Encounter Reports for ReimbursementHealth Service Reports at the Conclusion of an Episode of Care.Manage Practitioner/Patient RelationshipsSubject to Subject RelationshipRelated by GenealogyRelated by InsuranceRelated by Living SituationRelated by Other MeansAcuity and SeveritySupportive Function Maintenance

Clinical Decision Support System Guidelines UpdatesPatient Education Material UpdatesPatient Reminder Information UpdatesPublic Health Related UpdatesSecurityEntity AuthenticationEntity AuthorizationEntity Access ControlPatient Access ManagementNon-RepudiationSecure Data ExchangeSecure Data RoutingInformation AttestationPatient Privacy and ConfidentialityRedact patient identifying information.Protect individual patient identity.

Health Record Information and ManagementData Retention, Availability and DestructionAuditable RecordsSynchronizationExtraction of Health Record InformationStore and Manage Health Record InformationManage Health Information Record QualityManage Macros, Templates and Pre-Defined TextLocate External Health Record Information

Registry and Directory ServicesStandard Terminologies and Terminology ServicesStandard Terminologies and Terminology ModelsMaintenance and Versioning of Standard TerminologiesTerminology MappingStandards-based InteroperabilityInterchange StandardsStructured Documents

Interchange Standards Versioning and MaintenanceStandards-based Application IntegrationInterchange AgreementsEDIS InteroperabilityBed Board InterfaceElectronic Prescribing InterfaceBilling Interface

Business Rules ManagementWorkflow ManagementApplication OptimizationEHR-S User FeedbackAutomated System Performance FeedbackAd-Hoc System Performance Queries

User Interface SupportPresentation Configuration

User HelpSpelling and Grammar CheckUser Interface with DevicesPre-Defined Text, Macros and Templates

DC.1 DC.1 Care ManagementDC.1 .1 .1 Record ManagementDC.1 .1 .1 .1 Identify and Maintain a Patient RecordDC.1 .1 .2 .2 Manage Patient DemographicsDC.1 .1 .2 .1 .1 EDIS RegistrationDC.1 .1 .2 .2 .2 Quick RegistrationDC.1 .1 .2 .3 .3 ED Merge RegistrationDC.1 .1 .3 .3 Data and Documentation from External SourcesDC.1 .1 .3 .1 .1 Capture Data and Documentation from External Clinical SourcesDC.1 .1 .3 .1 .1 .1 Capture EMS dataDC.1 .1 .3 .2 .2 Capture Patient-Originated DataDC.1 .1 .3 .3 .3 Capture Patient Health Data Derived from Administrative and Financial Data and DocumentationDC.1 .1 .3 .4 .4 Capture Guidelines and Standards from External SoucesDC.1 .1 .4 .4 Produce a Summary Record of CareDC.1 .1 .5 .5 Present Ad Hoc Views of the Health RecordDC.1 .1 .6 .6 Non-text DataDC.1 .2 .2 Manage Patient HistoryDC.1 .2 .1 .1 Manage Pre-Arrival DataDC.1 .2 .2 .2 Manage Arrival DataDC.1 .2 .3 .3 Manage TriageDC.1 .2 .4 .4 Manage History of Present IllnessDC.1 .3 .3 Preferences, Directives, Consents and AuthorizationsDC.1 .3 .1 .1 Manage Patient and Family PreferencesDC.1 .3 .2 .2 Manage Patient Advance DirectivesDC.1 .3 .3 .3 Manage Consents and AuthorizationsDC.1 .4 .4 Summary ListsDC.1 .4 .1 .1 Manage Allergy, Intolerance and Adverse Reaction ListDC.1 .4 .2 .2 Manage Medication ListDC.1 .4 .3 .3 Manage Problem ListDC.1 .4 .4 .4 Manage Immunization ListDC.1 .5 .5 Manage AssessmentsDC.1 .5 .1 .1 Manage Physical ExaminationDC.1 .5 .2 .2 Manage Progress NotesDC.1 .6 .6 Care Plans, Treatment Plans, Guidelines, and ProtocolsDC.1 .6 .1 .1 Present Guidelines and Protocols for Planning CareDC.1 .6 .2 .2 Manage Patient-Specific Care and Treatment PlansDC.1 .7 .7 Orders and Referrals ManagementDC.1 .7 .1 .1 Manage Medication OrdersDC.1 .7 .2 .2 Non-Medication Orders and Referrals ManagementDC.1 .7 .2 .1 .1 Manage Non-Medication Patient Care OrdersDC.1 .7 .2 .2 .2 Manage Orders for Diagnostic TestsDC.1 .7 .2 .3 .3 Manage Orders for Blood Products and Other BiologicsDC.1 .7 .2 .4 .4 Manage ReferralsDC.1 .7 .3 .3 Manage Order Sets

DC.1 .8 .8 Documentation of Care, Measurements and ResultsDC.1 .8 .1 .1 Manage Medication AdministrationDC.1 .8 .2 .2 Manage Immunization Administration

DC.1 .8 .3 .3 Manage ResultsDC.1 .8 .4 .4 Manage Patient Clinical MeasurementsDC.1 .8 .5 .5 Manage Clinical Documents and NotesDC.1 .8 .5 .1 .1 Acknowledge/Amend Other Provider Documentation DC.1 .8 .5 .2 .2 Document Patient and Family Communication and EducationDC.1 .8 .5 .3 .3 Manage Transfers of Care between ED Providers

DC.1 .8 .6 .6 Manage Documentation of Clinician Response to Decision Support PromptsDC.1 .8 .7 .7 Manage ProceduresDC.1 .8 .8 .8 Manage Medical Decision-Making

DC.1 .9 .9 Generate and Record Patient-Specific InstructionsDC.1 .10 .10 Manage Patient Disposition DocumentationDC.1 .10 .1 .1 Manage Discharge DispositionDC.1 .10 .1 .1 .1 Manage Follow-on Care DocumentionDC.1 .10 .1 .2 .2 Manage Prescription DocumentaitonDC.1 .10 .1 .3 .3 Manage ED to Hospital Admission DocumentationDC.1 .10 .1 .4 .4 Manage Transfer Documentation

DC.1 .11 .11 Manage Discharged PatientsDC.2 DC.2 Clinical Decision SupportDC.2 .1 .1 Manage Health Information to Provide Decision SupportDC.2 .1 .1 .1 Support for Standard AssessmentsDC.2 .1 .2 .2 Support for Patient Context-Driven AssessmentsDC.2 .1 .3 .3 Support for Identification and Notification of Potential Problems and TrendsDC.2 .1 .4 .4 Support for Patient and Family PreferencesDC.2 .1 .5 .5 Support Triage Categorization DC.2 .1 .6 .6 Support Waiting Room Management

DC.2 .2 .2 Care and Treatment Plans, Guidelines and ProtocolsDC.2 .2 .1 .1 Support for Condition Based Care and Treatment Plans, Guidelines, ProtocolsDC.2 .2 .1 .1 .1 Support for Standard Care Plans, Guidelines, ProtocolsDC.2 .2 .1 .2 .2 Support for Context-Sensitive Care Plans, Guidelines, ProtocolsDC.2 .2 .2 .2 Support Consistent Healthcare Management of Patient Groups or PopulationsDC.2 .2. 3 3 Support for Research Protocols Relative to Individual Patient CareDC.2 .2. 4 4 Support Self-CareDC.2 .3 .3 Medication and Immunization ManagementDC.2 .3. 1 1 Support for Medication and Immunization OrderingDC.2 .3. 1. 1 1 Support for Drug Interaction CheckingDC.2 .3. 1. 2 2 Support for Patient Specific Dosing and WarningsDC.2 .3 .1 .3 .3 Support for Medication RecommendationsDC.2 .3 .2 .2 Support for Medication and Immunization AdministrationDC.2 .4 .4 Orders, Referrals, Results and Care ManagementDC.2 .4 .1 .1 Create Order Set TemplatesDC.2 .4 .2 .2 Support for Non-Medication OrderingDC.2 .4 .3 .3 Support for Result InterpretationDC.2 .4 .4 .4 Support for ReferralsDC.2 .4 .4 .1 .1 Support for Referral ProcessDC.2 .4 .4 .2 .2 Support for Referral RecommendationsDC.2 .4 .5 .5 Support for Care DeliveryDC.2 .4 .5 .1 .1 Support for Safe Blood AdministrationDC.2 .4 .5 .2 .2 Support for Accurate Specimen Collection

  DC.2.1        DC.2.1.1        DC.2.1.2        DC.2.1.3        DC.2.1.4   

  DC.2.2        DC.2.2.1          DC.2.2.1.1          DC.2.2.1.2        DC.2.2.2        DC.2.2.3        DC.2.2.4      DC.2.3        DC.2.3.1          DC.2.3.1.1          DC.2.3.1.2          DC.2.3.1.3        DC.2.3.2      DC.2.4        DC.2.4.1        DC.2.4.2        DC.2.4.3        DC.2.4.4          DC.2.4.4.1          DC.2.4.4.2        DC.2.4.5          DC.2.4.5.1          DC.2.4.5.2   

DC.2 .5 .5 Support for Health Maintenance: Preventive Care and WellnessDC.2 .5 .1 .1 Present Alerts for Preventive Services and WellnessDC.2 .5 .2 .2 Notifications and Reminders for Preventive Services and WellnessDC.2 .6 .6 Support for Population HealthDC.2 .6 .1 .1 Support for Epidemiological Investigations of Clinical Health Within a Population.DC.2 .6 .2 .2 Support for Notification and ResponseDC.2 .6 .3 .3 Support for Monitoring Response Notifications Regarding a Specific Patient's HealthDC.2 .7 .7 Support for Knowledge AccessDC.2 .7 .1 .1 Access Healthcare GuidanceDC.2 .7 .2 .2 Patient Knowledge Access

DC.3 DC.3 Operations Management and CommunicationDC.3 .1 .1 Clinical Workflow TaskingDC.3 .1 .1 .1 Clinical Task Assignment and RoutingDC.3 .1 .2 .2 Clinical Task LinkingDC.3 .1 .3 .3 Clinical Task TrackingDC.3 .2 .2 Support Clinical CommunicationDC.3 .2 .1 .1 Support for Inter-Provider CommunicationDC.3 .2 .1 .1 .1 Manage Consultation Requests and ResponsesDC.3 .2 .2 .2 Support for Provider-Pharmacy CommunicationDC.3 .2 .3 .3 Support for Communications Between Provider and Patient and/or the Patient RepresentativeDC.3 .2 .4 .4 Patient, Family and Care Giver EducationDC.3 .2 .5 .5 Communication with Medical DevicesDC.3 .2 .6 .6 Communication with non-Medical DevicesDC.3 .2 .7 .7 Support for Communications Within an Enterprise/FacilityDC.3 .2 .7 .1 .1 Tracking BoardsDC.3 .2 .7 .2 .2 Transition of Care ToolsDC.3 .2 .8 .8 Support for Communications Between Enterprises/FacilitiesDC.3 .2 .9 .9 Support for Facility to External Agency CommunicationsDC.3 .2 .10 Support for Provider-Employer CommunicationsDC.3 .2 .11 Support for Special Interest Personnel Communications

S.1 S.1 Clinical SupportS.1 .1 .1 Registry NotificationS.1 .2 .2 Donor Management SupportS.1 .3 .3 Provider InformationS.1 .3 .1 .1 Provider Access LevelsS.1 .3 .2 .2 Provider's Location Within FacilityS.1 .3 .3 .3 Provider's On Call LocationS.1 .3 .4 .4 Provider's Location(s) or Office(s)S.1 .3 .5 .5 Team/Group of Providers Registry or DirectoryS.1 .3 .6 .6 Provider Caseload/PanelS.1 .3 .7 .7 Provider Registry or DirectoryS.1 .4 .4 Patient DirectoryS.1 .4 .1 .1 Patient DemographicsS.1 .4 .2 .2 Patient's Location Within a FacilityS.1 .4 .2 .1 .1 Patient’s Location Within the Emergency DepartmentS.1 .4 .2 .2 .2 Department Modeling and Room ManagementS.1 .4 .3 .3 Patient's Residence for the Provision and Administration of ServicesS.1 .4 .4 .4 Patient Bed Assignment

  DC.2.5        DC.2.5.1        DC.2.5.2      DC.2.6        DC.2.6.1        DC.2.6.2        DC.2.6.3      DC.2.7        DC.2.7.1        DC.2.7.2   

DC.3      DC.3.1        DC.3.1.1        DC.3.1.2        DC.3.1.3      DC.3.2        DC.3.2.1   

    DC.3.2.2        DC.3.2.3        DC.3.2.4        DC.3.2.5        DC.3.2.5   

S.1      S.1.1      S.1.2      S.1.3        S.1.3.1        S.1.3.2        S.1.3.3        S.1.3.4        S.1.3.5        S.1.3.6        S.1.3.7      S.1.4        S.1.4.1        S.1.4.2   

    S.1.4.3        S.1.4.4   

S.1 .5 .5 De-Identified Data Request ManagementS.1 .6 .6 SchedulingS.1 .7 .7 Healthcare Resource AvailabilityS.1 .8 .8 Information ViewS.1 .8 .1 .1 User Interface Management 1: ViewsS.1 .8 .2 .2 User Interface Management 2: InterfaceS.1 .8 .3 .3 User Interface Management 3: EntryS.1 .9 .9 Support Healthcare Management for Disaster Response

S.2 S.2 Measurement, Analysis, Research and ReportsS.2 .1 .1 Measurement, Monitoring, and AnalysisS.2 .1 .1 .1 Outcome Measures and AnalysisS.2 .1 .2 .2 Performance and Accountability MeasuresS.2 .1 .3 .3 Support for Process ImprovementS.2 .1 .4 .4 Support for Care System Performance Indicators (Dashboards)S.2 .2 .2 Report GenerationS.2 .2 .1 .1 Health Record OutputS.2 .2 .2 .2 Standard Report GenerationS.2 .2 .2 .1 .1 ED Benchmarking ReportsS.2 .2 .3 .3 Ad Hoc Query and Report Generation

S.3 S.3 Administrative and FinancialS.3 .1 .1 Encounter/Episode of Care ManagementS.3 .1 .1 .1 Specialized ViewsS.3 .1 .2 .2 Encounter Specific FunctionalityS.3 .1 .3 .3 Automatic Generation of Administrative and Financial Data from Clinical RecordS.3 .1 .4 .4 Support Remote Healthcare ServicesS.3 .1 .5 .5 Other Encounter and Episode of Care SupportS.3 .2 .2 Information Access for Supplemental UseS.3 .2 .1 .1 Rules-Driven Clinical Coding AssistanceS.3 .2 .2 .2 Rules-Driven Financial and Administrative Coding AssistanceS.3 .2 .3 .3 Integrate Cost/Financial InformationS.3 .2 .4 .4 Assistance for Coding DeficienciesS.3 .2 .5 .5 Support for Provider TrainingS.3 .2 .6 .6 Support for Provider Credentialing and PrivilegingS.3 .3 .3 Administrative Transaction ProcessingS.3 .3 .1 .1 Enrollment of PatientsS.3 .3 .2 .2 Eligibility Verification and Determination of CoverageS.3 .3 .3 .3 Service AuthorizationsS.3 .3 .4 .4 Support of Service Requests and ClaimsS.3 .3 .5 .5 Claims and Encounter Reports for ReimbursementS.3 .3 .6 .6 Health Service Reports at the Conclusion of an Episode of Care.S.3 .4 .4 Manage Practitioner/Patient RelationshipsS.3 .5 .5 Subject to Subject RelationshipS.3 .5 .1 .1 Related by GenealogyS.3 .5 .2 .2 Related by InsuranceS.3 .5 .3 .3 Related by Living SituationS.3 .5 .4 .4 Related by Other MeansS.3 .6 .6 Acuity and SeverityS.3 .7 .7 Supportive Function Maintenance

  S.1.5      S.1.6      S.1.7      S.1.8   

  S.1.8   

S.2      S.2.1        S.2.1.1        S.2.1.2        S.2.1.2        S.2.1.2      S.2.2        S.2.2.1        S.2.2.2   

    S.2.2.3   

S.3      S.3.1        S.3.1.1        S.3.1.2        S.3.1.3        S.3.1.4        S.3.1.5      S.3.2        S.3.2.1        S.3.2.2        S.3.2.3        S.3.2.3   

  S.3.3        S.3.3.1        S.3.3.2        S.3.3.3        S.3.3.4        S.3.3.5        S.3.3.6      S.3.4      S.3.5        S.3.5.1        S.3.5.2        S.3.5.3        S.3.5.4      S.3.6      S.3.7   

S.3 .7 .1 .1 Clinical Decision Support System Guidelines UpdatesS.3 .7 .2 .2 Patient Education Material UpdatesS.3 .7 .3 .3 Patient Reminder Information UpdatesS.3 .7 .4 .4 Public Health Related Updates

IN.1 IN.1 SecurityIN.1 .1 .1 Entity AuthenticationIN.1 .2 .2 Entity AuthorizationIN.1 .3 .3 Entity Access ControlIN.1 .4 .4 Patient Access ManagementIN.1 .5 .5 Non-RepudiationIN.1 .6 .6 Secure Data ExchangeIN.1 .7 .7 Secure Data RoutingIN.1 .8 .8 Information AttestationIN.1 .9 .9 Patient Privacy and ConfidentialityIN.1 .9 .1 .1 Redact patient identifying information.IN.1 .9 .2 .2 Protect individual patient identity. IN.2 IN.2 Health Record Information and ManagementIN.2 .1 .1 Data Retention, Availability and DestructionIN.2 .2 .2 Auditable RecordsIN.2 .3 .3 SynchronizationIN.2 .4 .4 Extraction of Health Record InformationIN.2 .5 .5 Store and Manage Health Record InformationIN.2 .5 .3 .3 Manage Health Information Record QualityIN.2 .5 .4 .4 Manage Macros, Templates and Pre-Defined TextIN.2 .5 .5 .5 Locate External Health Record InformationIN.3 IN.3 Registry and Directory ServicesIN.4 IN.4 Standard Terminologies and Terminology ServicesIN.4 .1 .1 Standard Terminologies and Terminology ModelsIN.4 .2 .2 Maintenance and Versioning of Standard TerminologiesIN.4 .3 .3 Terminology MappingIN.5 IN.5 Standards-based InteroperabilityIN.5 .1 .1 Interchange StandardsIN.5 .1 .1 .1 Structured DocumentsIN.5 .2 .2 Interchange Standards Versioning and MaintenanceIN.5 .3 .3 Standards-based Application IntegrationIN.5 .4 .4 Interchange AgreementsIN.5 .5 .5 EDIS InteroperabilityIN.5 .5 .1 .1 Bed Board InterfaceIN.5 .5 .2 .2 Electronic Prescribing InterfaceIN.5 .5 .3 .3 Billing InterfaceIN.6 IN.6 Business Rules ManagementIN.7 IN.7 Workflow ManagementIN.8 IN.8 Application OptimizationIN.8 .1 .1 EHR-S User FeedbackIN.8 .2 .2 Automated System Performance FeedbackIN.8 .3 .3 Ad-Hoc System Performance QueriesIN.9 IN.9 User Interface SupportIN.9 .1 .1 Presentation Configuration

    S.3.7.1        S.3.7.2        S.3.7.3        S.3.7.4   

  IN.1.1      IN.1.2      IN.1.3      IN.1.4      IN.1.5      IN.1.6      IN.1.7      IN.1.8      IN.1.9   

IN.2      IN.2.1      IN.2.2      IN.2.3      IN.2.4      IN.2.5   

    IN.2.5.1    IN.3    IN.4      IN.4.1      IN.4.2      IN.4.3    IN.5      IN.5.1   

  IN.5.2      IN.5.3      IN.5.4   

IN.9 .2 .2 User HelpIN.9 .3 .3 Spelling and Grammar CheckIN.9 .4 .4 User Interface with DevicesIN.9 .5 .5 Pre-Defined Text, Macros and Templates

.3 Capture Patient Health Data Derived from Administrative and Financial Data and Documentation

.6 Manage Documentation of Clinician Response to Decision Support Prompts

.1 Support for Epidemiological Investigations of Clinical Health Within a Population.

.3 Support for Monitoring Response Notifications Regarding a Specific Patient's Health

.3 Support for Communications Between Provider and Patient and/or the Patient Representative

.3 Automatic Generation of Administrative and Financial Data from Clinical Record

LevelDC.1 1 DC.1 DC.1 Care Management

DC.1.1 2 DC.1 .1 .1 Record Management

DC.1.1.1 3 DC.1 .1 .1

DC.1.1.2 3 DC.1 .1 .2

DC.1.1.2.1 4 DC.1 .1 .2 .1

DC.1.1.2.2 4 DC.1 .1 .2 .2

DC.1.1.2.3 4 DC.1 .1 .2 .3

DC.1.1.3 3 DC.1 .1 .3

DC.1.1.3.1 4 DC.1 .1 .3 .1

DC.1.1.3.1.1 5 DC.1 .1 .3 .1 .1

DC.1.1.3.2 4 DC.1 .1 .3 .2

DC.1.1.3.3 4 DC.1 .1 .3 .3

DC.1.1.3.4 4 DC.1 .1 .3 .4

DC.1.1.4 3 DC.1 .1 .4

DC.1.1.5 3 DC.1 .1 .5

DC.1.1.6 3 DC.1 .1 .6

DC.1.2 2 DC.1 .2 .2 Manage Patient History

DC.1.2.1 3 DC.1 .2 .1

DC.1.2.2 3 DC.1 .2 .2

DC.1.2.3 3 DC.1 .2 .3

DC.1.2.4 3 DC.1 .2 .4

DC.1.3 2 DC.1 .3 .3 Preferences, Directives, Consents and

DC.1.3.1 3 DC.1 .3 .1

DC.1.3.2 3 DC.1 .3 .2

DC.1.3.3 3 DC.1 .3 .3

DC.1.4 2 DC.1 .4 .4 Summary Lists

DC.1.4.1 3 DC.1 .4 .1

DC.1.4.2 3 DC.1 .4 .2

DC.1.4.3 3 DC.1 .4 .3

DC.1.4.4 3 DC.1 .4 .4

DC.1.5 2 DC.1 .5 .5 Manage Assessments

DC.1.5.1 3 DC.1 .5 .1

DC.1.5.2 3 DC.1 .5 .2

DC.1.6 2 DC.1 .6 .6 Care Plans, Treatment Plans, Guideli

DC.1.6.1 3 DC.1 .6 .1

DC.1.6.2 3 DC.1 .6 .2

DC.1.7 2 DC.1 .7 .7 Orders and Referrals Management

DC.1.7.1 3 DC.1 .7 .1

DC.1.7.2 3 DC.1 .7 .2

DC.1.7.2.1 4 DC.1 .7 .2 .1

DC.1.7.2.2 4 DC.1 .7 .2 .2

DC.1.7.2.3 4 DC.1 .7 .2 .3

DC.1.7.2.4 4 DC.1 .7 .2 .4

DC.1.7.3 3 DC.1 .7 .3

DC.1.8 2 DC.1 .8 .8 Documentation of Care, Measurement

DC.1.8.1 3 DC.1 .8 .1

DC.1.8.2 3 DC.1 .8 .2

DC.1.8.3 3 DC.1 .8 .3

DC.1.8.4 3 DC.1 .8 .4

DC.1.8.5 3 DC.1 .8 .5

DC.1.8.5.1 4 DC.1 .8 .5 .1

DC.1.8.5.2 4 DC.1 .8 .5 .2

DC.1.8.5.3 4 DC.1 .8 .5 .3

DC.1.8.6 3 DC.1 .8 .6

DC.1.8.7 3 DC.1 .8 .7

DC.1.8.8 3 DC.1 .8 .8

DC.1.9 2 DC.1 .9 .9 Generate and Record Patient-Specific

DC.1.10 2 DC.1 .10 .10 Manage Patient Disposition Documen

DC.1.10.1 3 DC.1 .10 .1

DC.1.10.1.1 4 DC.1 .10 .1 .1

DC.1.10.1.2 4 DC.1 .10 .1 .2

DC.1.10.1.3 4 DC.1 .10 .1 .3

DC.1.10.1.4 4 DC.1 .10 .1 .4

DC.1.11 2 DC.1 .11 .11 Manage Discharged Patients

DC.2 1 DC.2 DC.2 Clinical Decision Support

DC.2.1 2 DC.2 .1 .1 Manage Health Information to Provide

DC.2.1.1 3 DC.2 .1 .1

DC.2.1.2 3 DC.2 .1 .2

DC.2.1.3 3 DC.2 .1 .3

DC.2.1.4 3 DC.2 .1 .4

DC.2.1.5 3 DC.2 .1 .5

DC.2.1.6 3 DC.2 .1 .6

DC.2.2 2 DC.2 .2 .2 Care and Treatment Plans, Guidelines

DC.2.2.1 3 DC.2 .2 .1

DC.2.2.1.1 4 DC.2 .2 .1 .1

DC.2.2.1.2 4 DC.2 .2 .1 .2

DC.2.2.2 3 DC.2 .2 .2

DC.2.2.3 3 DC.2 .2 .3

DC.2.2.4 3 DC.2 .2 .4

DC.2.3 2 DC.2 .3 .3 Medication and Immunization Manag

DC.2.3.1 3 DC.2 .3 .1

DC.2.3.1.1 4 DC.2 .3 .1 .1

DC.2.3.1.2 4 DC.2 .3 .1 .2

DC.2.3.1.3 4 DC.2 .3 .1 .3

DC.2.3.2 3 DC.2 .3 .2

DC.2.4 2 DC.2 .4 .4 Orders, Referrals, Results and Care

DC.2.4.1 3 DC.2 .4 .1

DC.2.4.2 3 DC.2 .4 .2

DC.2.4.3 3 DC.2 .4 .3

DC.2.4.4 3 DC.2 .4 .4

DC.2.4.4.1 4 DC.2 .4 .4 .1

DC.2.4.4.2 4 DC.2 .4 .4 .2

DC.2.4.5 3 DC.2 .4 .5

DC.2.4.5.1 4 DC.2 .4 .5 .1

DC.2.4.5.2 4 DC.2 .4 .5 .2

DC.2.5 2 DC.2 .5 .5 Support for Health Maintenance: Prev

DC.2.5.1 3 DC.2 .5 .1

DC.2.5.2 3 DC.2 .5 .2

DC.2.6 2 DC.2 .6 .6 Support for Population Health

DC.2.6.1 3 DC.2 .6 .1

DC.2.6.2 3 DC.2 .6 .2

DC.2.6.3 3 DC.2 .6 .3

DC.2.7 2 DC.2 .7 .7 Support for Knowledge Access

DC.2.7.1 3 DC.2 .7 .1

DC.2.7.2 3 DC.2 .7 .2

DC.3 1 DC.3 DC.3 Operations Management

DC.3.1 2 DC.3 .1 .1 Clinical Workflow Tasking

DC.3.1.1 3 DC.3 .1 .1

DC.3.1.2 3 DC.3 .1 .2

DC.3.1.3 3 DC.3 .1 .3

DC.3.2 2 DC.3 .2 .2 Support Clinical Communication

DC.3.2.1 3 DC.3 .2 .1

DC.3.2.1.1 4 DC.3 .2 .1 .1

DC.3.2.2 3 DC.3 .2 .2

DC.3.2.3 3 DC.3 .2 .3

DC.3.2.4 3 DC.3 .2 .4

DC.3.2.5 3 DC.3 .2 .5

DC.3.2.6 3 DC.3 .2 .6

DC.3.2.7 3 DC.3 .2 .7

DC.3.2.7.1 4 DC.3 .2 .7 .1

DC.3.2.7.2 4 DC.3 .2 .7 .2

DC.3.2.8 3 DC.3 .2 .8

DC.3.2.9 3 DC.3 .2 .9

DC.3.2.10 3 DC.3 .2 .10

DC.3.2.11 3 DC.3 .2 .11

S.1 1 S.1 S.1 Clinical Support

S.1.1 2 S.1 .1 .1 Registry Notification

S.1.2 2 S.1 .2 .2 Donor Management Support

S.1.3 2 S.1 .3 .3 Provider Information

S.1.3.1 3 S.1 .3 .1

S.1.3.2 3 S.1 .3 .2

S.1.3.3 3 S.1 .3 .3

S.1.3.4 3 S.1 .3 .4

S.1.3.5 3 S.1 .3 .5

S.1.3.6 3 S.1 .3 .6

S.1.3.7 3 S.1 .3 .7

S.1.4 2 S.1 .4 .4 Patient Directory

S.1.4.1 3 S.1 .4 .1

S.1.4.2 3 S.1 .4 .2

S.1.4.2.1 4 S.1 .4 .2 .1

S.1.4.2.2 4 S.1 .4 .2 .2

S.1.4.3 3 S.1 .4 .3

S.1.4.4 3 S.1 .4 .4

S.1.5 2 S.1 .5 .5 De-Identified Data Request Managem

S.1.6 2 S.1 .6 .6 Scheduling

S.1.7 2 S.1 .7 .7 Healthcare Resource Availability

S.1.8 2 S.1 .8 .8 Information View

S.1.8.1 3 S.1 .8 .1

S.1.8.2 3 S.1 .8 .2

S.1.8.3 3 S.1 .8 .3

S.1.9 2 S.1 .9 .9 Support Healthcare Management for

S.2 1 S.2 S.2 Measurement, Analysis, R

S.2.1 2 S.2 .1 .1 Measurement, Monitoring, and Analys

S.2.1.1 3 S.2 .1 .1

S.2.1.2 3 S.2 .1 .2

S.2.1.3 3 S.2 .1 .3

S.2.1.4 3 S.2 .1 .4

S.2.2 2 S.2 .2 .2 Report Generation

S.2.2.1 3 S.2 .2 .1

S.2.2.2 3 S.2 .2 .2

S.2.2.2.1 4 S.2 .2 .2 .1

S.2.2.3 3 S.2 .2 .3

S.3 1 S.3 S.3 Administrative and Financi

S.3.1 2 S.3 .1 .1 Encounter/Episode of Care Managem

S.3.1.1 3 S.3 .1 .1

S.3.1.2 3 S.3 .1 .2

S.3.1.3 3 S.3 .1 .3

S.3.1.4 3 S.3 .1 .4

S.3.1.5 3 S.3 .1 .5

S.3.2 2 S.3 .2 .2 Information Access for Supplemental

S.3.2.1 3 S.3 .2 .1

S.3.2.2 3 S.3 .2 .2

S.3.2.3 3 S.3 .2 .3

S.3.2.4 3 S.3 .2 .4

S.3.2.5 3 S.3 .2 .5

S.3.2.6 3 S.3 .2 .6

S.3.3 2 S.3 .3 .3 Administrative Transaction Processin

S.3.3 2 S.3 .3 .3 Administrative Transaction Processin

S.3.3.1 3 S.3 .3 .1

S.3.3.2 3 S.3 .3 .2

S.3.3.3 3 S.3 .3 .3

S.3.3.4 3 S.3 .3 .4

S.3.3.5 3 S.3 .3 .5

S.3.3.6 3 S.3 .3 .6

S.3.4 2 S.3 .4 .4 Manage Practitioner/Patient Relations

S.3.5 2 S.3 .5 .5 Subject to Subject Relationship

S.3.5.1 3 S.3 .5 .1

S.3.5.2 3 S.3 .5 .2

S.3.5.3 3 S.3 .5 .3

S.3.5.4 3 S.3 .5 .4

S.3.6 2 S.3 .6 .6 Acuity and Severity

S.3.7 2 S.3 .7 .7 Supportive Function Maintenance

S.3.7.1 3 S.3 .7 .1

S.3.7.2 3 S.3 .7 .2

S.3.7.3 3 S.3 .7 .3

S.3.7.4 3 S.3 .7 .4

IN.1 1 IN.1 IN.1 Security

IN.1.1 2 IN.1 .1 .1 Entity Authentication

IN.1.2 2 IN.1 .2 .2 Entity Authorization

IN.1.3 2 IN.1 .3 .3 Entity Access Control

IN.1.4 2 IN.1 .4 .4 Patient Access Management

IN.1.5 2 IN.1 .5 .5 Non-Repudiation

IN.1.6 2 IN.1 .6 .6 Secure Data Exchange

IN.1.7 2 IN.1 .7 .7 Secure Data Routing

IN.1.8 2 IN.1 .8 .8 Information Attestation

IN.1.9 2 IN.1 .9 .9 Patient Privacy and Confidentiality

IN.1.9.1 3 IN.1 .9 .1

IN.1.9.2 3 IN.1 .9 .2

IN.2 1 IN.2 IN.2 Health Record Informati

IN.2.1 2 IN.2 .1 .1 Data Retention, Availability and Destr

IN.2.2 2 IN.2 .2 .2 Auditable Records

IN.2.3 2 IN.2 .3 .3 Synchronization

IN.2.4 2 IN.2 .4 .4 Extraction of Health Record Informati

IN.2.5 2 IN.2 .5 .5 Store and Manage Health Record Info

IN.2.5.3 3 IN.2 .5 .3

IN.2.5.4 3 IN.2 .5 .4

IN.2.5.5 3 IN.2 .5 .5

IN.3 1 IN.3 IN.3 Registry and Directory Se

IN.3 1 IN.3 IN.3 Registry and Directory Se

IN.4 1 IN.4 IN.4 Standard Terminologies a

IN.4.1 2 IN.4 .1 .1 Standard Terminologies and Termino

IN.4.2 2 IN.4 .2 .2 Maintenance and Versioning of Stand

IN.4.3 2 IN.4 .3 .3 Terminology Mapping

IN.5 1 IN.5 IN.5 Standards-based Interoper

IN.5.1 2 IN.5 .1 .1 Interchange Standards

IN.5.1.1 3 IN.5 .1 .1

IN.5.2 2 IN.5 .2 .2 Interchange Standards Versioning an

IN.5.3 2 IN.5 .3 .3 Standards-based Application Integrati

IN.5.4 2 IN.5 .4 .4 Interchange Agreements

IN.5.5 2 IN.5 .5 .5 EDIS Interoperability

IN.5.5.1 3 IN.5 .5 .1

IN.5.5.2 3 IN.5 .5 .2

IN.5.5.3 3 IN.5 .5 .3

IN.6 1 IN.6 IN.6 Business Rules Managem

IN.7 1 IN.7 IN.7 Workflow Management

IN.8 1 IN.8 IN.8 Application Optimization

IN.8.1 2 IN.8 .1 .1 EHR-S User Feedback

IN.8.2 2 IN.8 .2 .2 Automated System Performance Fee

IN.8.3 2 IN.8 .3 .3 Ad-Hoc System Performance Queries

IN.9 1 IN.9 IN.9 User Interface Support

IN.9.1 2 IN.9 .1 .1 Presentation Configuration

IN.9.2 2 IN.9 .2 .2 User Help

IN.9.3 2 IN.9 .3 .3 Spelling and Grammar Check

IN.9.4 2 IN.9 .4 .4 User Interface with Devices

IN.9.5 2 IN.9 .5 .5 Pre-Defined Text, Macros and Templa

.1 Identify and Maintain a Patient Record

.2 Manage Patient Demographics

.1 EDIS Registration

.2 Quick Registration

.3 ED Merge Registration

.3 Data and Documentation from External Sources

.1 Capture Data and Documenta

.2 Capture Patient-Originated

.3 Capture Patient Health Dat

.4 Capture Guidelines and Sta

.4 Produce a Summary Record of Care

.5 Present Ad Hoc Views of the Health Record

.6 Non-text Data

.1 Manage Pre-Arrival Data

.2 Manage Arrival Data

.3 Manage Triage

.4 Manage History of Present Illness

.1 Manage Patient and Family Preferences

.2 Manage Patient Advance Directives

.3 Manage Consents and Authorizations

.1 Manage Allergy, Intolerance and Adverse Reaction List

.2 Manage Medication List

.3 Manage Problem List

.4 Manage Immunization List

.1 Manage Physical Examination

.2 Manage Progress Notes

.1 Present Guidelines and Protocols for Planning Care

.2 Manage Patient-Specific Care and Treatment Plans

.1 Manage Medication Orders

.2 Non-Medication Orders and Referrals Management

.1 Manage Non-Medication Pat

.2 Manage Orders for Diagnost

.3 Manage Orders for Blood Pr

.4 Manage Referrals

.3 Manage Order Sets

.1 Manage Medication Administration

.2 Manage Immunization Administration

.3 Manage Results

.4 Manage Patient Clinical Measurements

.5 Manage Clinical Documents and Notes

.1 Acknowledge/Amend Other P

.2 Document Patient and Fami

.3 Manage Transfers of Care

.6 Manage Documentation of Clinician Response to Decision Support Prompts

.7 Manage Procedures

.8 Manage Medical Decision-Making

.1 Manage Discharge Disposition

.1 Manage Follow-on Care Do

.2 Manage Prescription Docum

.3 Manage ED to Hospital Adm

.4 Manage Transfer Documenta

.1 Support for Standard Assessments

.2 Support for Patient Context-Driven Assessments

.3 Support for Identification and Notification of Potential Problems and Trends

.4 Support for Patient and Family Preferences

.5 Support Triage Categorization

.6 Support Waiting Room Management

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.1 Support for Standard Care P

.2 Support for Context-Sensiti

.2 Support Consistent Healthcare Management of Patient Groups or Populations

.3 Support for Research Protocols Relative to Individual Patient Care

.4 Support Self-Care

.1 Support for Medication and Immunization Ordering

.1 Support for Drug Interactio

.2 Support for Patient Specifi

.3 Support for Medication Re

.2 Support for Medication and Immunization Administration

.1 Create Order Set Templates

.2 Support for Non-Medication Ordering

.3 Support for Result Interpretation

.4 Support for Referrals

.1 Support for Referral Process

.2 Support for Referral Recom

.5 Support for Care Delivery

.1 Support for Safe Blood Admi

.2 Support for Accurate Specim

.1 Present Alerts for Preventive Services and Wellness

.2 Notifications and Reminders for Preventive Services and Wellness

.1 Support for Epidemiological Investigations of Clinical Health Within a Population.

.2 Support for Notification and Response

.3 Support for Monitoring Response Notifications Regarding a Specific Patient's Health

.1 Access Healthcare Guidance

.2 Patient Knowledge Access

.1 Clinical Task Assignment and Routing

.2 Clinical Task Linking

.3 Clinical Task Tracking

.1 Support for Inter-Provider Communication

.1 Manage Consultation Requ

.2 Support for Provider-Pharmacy Communication

.3 Support for Communications Between Provider and Patient and/or the Patient Representative

.4 Patient, Family and Care Giver Education

.5 Communication with Medical Devices

.6 Communication with non-Medical Devices

.7 Support for Communications Within an Enterprise/Facility

.1 Tracking Boards

.2 Transition of Care Tools

.8 Support for Communications Between Enterprises/Facilities

.9 Support for Facility to External Agency Communications

.10 Support for Provider-Employer Communications

.11 Support for Special Interest Personnel Communications

.1 Provider Access Levels

.2 Provider's Location Within Facility

.3 Provider's On Call Location

.4 Provider's Location(s) or Office(s)

.5 Team/Group of Providers Registry or Directory

.6 Provider Caseload/Panel

.7 Provider Registry or Directory

.1 Patient Demographics

.2 Patient's Location Within a Facility

.1 Patient’s Location Within

.2 Department Modeling and

.3 Patient's Residence for the Provision and Administration of Services

.4 Patient Bed Assignment

.1 User Interface Management 1: Views

.2 User Interface Management 2: Interface

.3 User Interface Management 3: Entry

.1 Outcome Measures and Analysis

.2 Performance and Accountability Measures

.3 Support for Process Improvement

.4 Support for Care System Performance Indicators (Dashboards)

.1 Health Record Output

.2 Standard Report Generation

.1 ED Benchmarking Reports

.3 Ad Hoc Query and Report Generation

.1 Specialized Views

.2 Encounter Specific Functionality

.3 Automatic Generation of Administrative and Financial Data from Clinical Record

.4 Support Remote Healthcare Services

.5 Other Encounter and Episode of Care Support

.1 Rules-Driven Clinical Coding Assistance

.2 Rules-Driven Financial and Administrative Coding Assistance

.3 Integrate Cost/Financial Information

.4 Assistance for Coding Deficiencies

.5 Support for Provider Training

.6 Support for Provider Credentialing and Privileging

.1 Enrollment of Patients

.2 Eligibility Verification and Determination of Coverage

.3 Service Authorizations

.4 Support of Service Requests and Claims

.5 Claims and Encounter Reports for Reimbursement

.6 Health Service Reports at the Conclusion of an Episode of Care.

.1 Related by Genealogy

.2 Related by Insurance

.3 Related by Living Situation

.4 Related by Other Means

.1 Clinical Decision Support System Guidelines Updates

.2 Patient Education Material Updates

.3 Patient Reminder Information Updates

.4 Public Health Related Updates

.1 Redact patient identifying information.

.2 Protect individual patient identity.

.3 Manage Health Information Record Quality

.4 Manage Macros, Templates and Pre-Defined Text

.5 Locate External Health Record Information

.1 Structured Documents

.1 Bed Board Interface

.2 Electronic Prescribing Interface

.3 Billing Interface

.1 Capture EMS data

Level1 Level2

DC.1 Care Management .1 Clinical Workflow Tasking

DC.2 Clinical Decision Support .1 Data Retention, Availability and Destruction

DC.3 Operations Management and Communicat.1 EHR-S User Feedback

S.1 Clinical Support .1 Encounter/Episode of Care Management

S.2 Measurement, Analysis, Research and Rep .1 Entity Authentication

S.3 Administrative and Financial .1 Interchange Standards

IN.1 Security .1 Manage Health Information to Provide Decis

IN.2 Health Record Information and Manageme .1 Measurement, Monitoring, and Analysis

IN.3 Registry and Directory Services .1 Presentation Configuration

IN.4 Standard Terminologies and Terminology .1 Record Management

IN.5 Standards-based Interoperability .1 Registry Notification

IN.6 Business Rules Management .1 Standard Terminologies and Terminology Mo

IN.7 Workflow Management .2 Auditable Records

IN.8 Application Optimization .2 Automated System Performance Feedback

IN.9 User Interface Support .2 Care and Treatment Plans, Guidelines and P

.2 Donor Management Support

.2 Entity Authorization

.2 Information Access for Supplemental Use

.2 Interchange Standards Versioning and Main

.2 Maintenance and Versioning of Standard Ter

.2 Manage Patient History

.2 Report Generation

.2 Support Clinical Communication

.2 User Help

.3 Ad-Hoc System Performance Queries

.3 Administrative Transaction Processing

.3 Entity Access Control

.3 Medication and Immunization Management

.3 Preferences, Directives, Consents and Autho

.3 Provider Information

.3 Spelling and Grammar Check

.3 Standards-based Application Integration

.3 Synchronization

.3 Terminology Mapping

.4 Extraction of Health Record Information

.4 Interchange Agreements

.4 Manage Practitioner/Patient Relationships

.4 Orders, Referrals, Results and Care Manag

.4 Patient Access Management

.4 Patient Directory

.4 Summary Lists

.4 User Interface with Devices

.5 De-Identified Data Request Management

.5 EDIS Interoperability

.5 Manage Assessments

.5 Non-Repudiation

.5 Pre-Defined Text, Macros and Templates

.5 Store and Manage Health Record Informatio

.5 Subject to Subject Relationship

.5 Support for Health Maintenance: Preventive

.6 Acuity and Severity

.6 Care Plans, Treatment Plans, Guidelines, an

.6 Manage Unstructured Health Record Informa

.6 Scheduling

.6 Secure Data Exchange

.6 Support for Population Health

.7 Healthcare Resource Availability

.7 Manage Structured Health Record Informatio

.7 Orders and Referrals Management

.7 Secure Data Routing

.7 Support for Knowledge Access

.7 Supportive Function Maintenance

.8 Documentation of Care, Measurements and

.8 Information Attestation

.8 Information View

.8 Provider Training, Credentialing and Privileg

.9 Generate and Record Patient-Specific Instruc

.9 Patient Privacy and Confidentiality

.10 Manage Patient Disposition Documentation

.11 Manage Discharged Patients

.9 Support Healthcare Management for Disaste

.10 Manage ED Disposition

.11 Manage Discharged Patients

Level3

.1 Access Healthcare Guidance

.1 Bed Board Interface

.1 Clinical Decision Support System Guidelines Updates

.1 Clinical Task Assignment and Routing

.1 Create Order Set Templates

.1 Enrollment of Patients

.1 Health Record Output

.1 Identify and Maintain a Patient Record

.1 Manage Allergy, Intolerance and Adverse Reaction List

.1 Manage Discharge Disposition

.1 Manage Medication Administration

.1 Manage Medication Orders

.1 Manage Patient and Family Preferences

.1 Manage Physical Examination

.1 Manage Pre-Arrival Data

.1 Outcome Measures and Analysis

.1 Patient Demographics

.1 Present Alerts for Preventive Services and Wellness

.1 Present Guidelines and Protocols for Planning Care

.1 Provider Access Levels

.1 Redact patient identifying information.

.1 Related by Genealogy

.1 Rules-Driven Clinical Coding Assistance

.1 Specialized Views

.1 Store and Manage Unstructured Health Record Information

.1 Structured Documents

.1 Support for Condition Based Care and Treatment Plans, Guidelines, Protocols

.1 Support for Epidemiological Investigations of Clinical Health Within a Population.

.1 Support for Inter-Provider Communication

.1 Support for Medication and Immunization Ordering

.1 Support for Provider Training

.1 Support for Standard Assessments

.1 User Interface Management 1: Views

.2 Clinical Task Linking

.2 Electronic Prescribing Interface

.2 Eligibility Verification and Determination of Coverage

.2 Encounter Specific Functionality

.2 Manage Arrival Data

.2 Manage Immunization Administration

.2 Manage Medication List

.2 Manage Patient Advance Directives

.2 Manage Patient Demographics

.2 Manage Patient-Specific Care and Treatment Plans

.2 Manage Progress Notes

.2 Non-Medication Orders and Referrals Management

.2 Notifications and Reminders for Preventive Services and Wellness

.2 Patient Education Material Updates

.2 Patient Knowledge Access

.2 Patient's Location Within a Facility

.2 Performance and Accountability Measures

.2 Protect individual patient identity.

.2 Provider's Location Within Facility

.2 Related by Insurance

.2 Rules-Driven Financial and Administrative Coding Assistance

.2 Standard Report Generation

.2 Store and Manage Structured Health Record Information

.2 Support Consistent Healthcare Management of Patient Groups or Populations

.2 Support for Medication and Immunization Administration

.2 Support for Non-Medication Ordering

.2 Support for Notification and Response

.2 Support for Patient Context- Driven Assessments

.2 Support for Provider Credentialing & Privileging

.2 Support for Provider-Pharmacy Communication

.2 User Interface Management 2: Interface

.3 Ad Hoc Query and Report Generation

.3 Automatic Generation of Administrative and Financial Data from Clinical Record

.3 Billing Interface

.3 Clinical Task Tracking

.3 Data and Documentation from External Sources

.3 Integrate Cost/Financial Information

.3 Manage Consents and Authorizations

.3 Manage Health Information Record Quality

.3 Manage Order Sets

.3 Manage Problem List

.3 Manage Results

.3 Manage Triage

.3 Patient Reminder Information Updates

.3 Patient's Residence for the Provision and Administration of Services

.3 Provider's On Call Location

.3 Related by Living Situation

.3 Service Authorizations

.3 Support for Communications Between Provider and Patient and/or the Patient Representative

.3 Support for Monitoring Response Notifications Regarding a Specific Patient's Health

.3 Support for Process Improvement

.3 Support for Research Protocols Relative to Individual Patient Care

.3 Support for Result Interpretation

.3 User Interface Management 3: Entry

.4 Assistance for Coding Deficiencies

.3 Support for Identification and Notification of Potential Problems and Trends

.4 Manage History of Present Illness

.4 Manage Immunization List

.4 Manage Macros, Templates and Pre-Defined Text

.4 Manage Patient Clinical Measurements

.4 Patient Bed Assignment

.4 Patient, Family and Care Giver Education

.4 Produce a Summary Record of Care

.4 Provider's Location(s) or Office(s)

.4 Public Health Related Updates

.4 Support for Care System Performance Indicators (Dashboards)

.4 Related by Other Means

.4 Support for Patient and Family Preferences

.4 Support for Referrals

.4 Support of Service Requests and Claims

.4 Support Remote Healthcare Services

.4 Support Self-Care

.5 Claims and Encounter Reports for Reimbursement

.5 Communication with Medical Devices

.5 Locate External Health Record Information

.5 Manage Clinical Documents and Notes

.5 Other Encounter and Episode of Care Support

.5 Provider Training, Credentialing and Privileging

.5 Present Ad Hoc Views of the Health Record

.5 Support for Care Delivery

.5 Support Triage Categorization

.5 Team/Group of Providers Registry or Directory

.5 Support for Provider Training

.6 Support for Provider Credentialing and Privileging

.6 Communication with non-Medical Devices

.6 Health Service Reports at the Conclusion of an Episode of Care.

.6 Manage Documentation of Clinician Response to Decision Support Prompts

.6 Non-text Data

.6 Provider Caseload/Panel

.6 Support Waiting Room Management

.7 Manage Procedures

.7 Provider Registry or Directory

.7 Support for Communications Within an Enterprise/Facility

.8 Manage Medical Decision-Making

.8 Support for Communications Between Enterprises/Facilities

.9 Support for Facility to External Agency Communications

.10 Support for Provider-Employer Communications

.11 Support for Special Interest Personnel Communications

Level4 Level5

.1 Acknowledge/Amend Other Provider Documentation .1 Capture EMS data

.1 Capture Data and Documentation from External Clinical Sources

.1 ED Benchmarking Reports

.1 EDIS Registration

.1 Manage Consultation Requests and Responses

.1 Manage Follow-On Care

.1 Manage Non-Medication Patient Care Orders

.1 Patient’s Location Within the Emergency Department

.1 Support for Drug Interaction Checking

.1 Support for Referral Process

.1 Support for Safe Blood Administration

.1 Support for Standard Care Plans, Guidelines, Protocols

.1 Tracking Boards

.1 Support for Provider Training

.2 Support for Provider Credentialing and Privileging

.2 Capture Patient-Originated Data

.2 Department Modeling and Room Management

.2 Document Patient and Family Communication and Education

.2 Manage Orders for Diagnostic Tests

.2 Manage prescriptions

.2 Quick Registration

.2 Support for Accurate Specimen Collection

.2 Support for Context-Sensitive Care Plans, Guidelines, Protocols

.2 Support for Patient Specific Dosing and Warnings

.2 Support for Referral Recommendations

.2 Transition of Care Tools

.3 Capture Patient Health Data Derived from Administrative and Financial Data and Documentation

.3 ED Merge Registration

.3 Manage ED to Hospital Admission

.3 Manage Orders for Blood Products and Other Biologics

.3 Manage Transfers of Care between ED Providers

.3 Support for Medication Recommendations

.4 Capture Guidelines and Standards from External Souces

.4 Manage Referrals

.4 Manage Transfers

.3 Support for Communications Between Provider and Patient and/or the Patient Representative

.3 Support for Monitoring Response Notifications Regarding a Specific Patient's Health