Transcript Document

EHR System Function
and Information Model
(EHR-S FIM):
DC 1.8.2 Immunization Management
Demonstration Prototype
[email protected] , editor
October 8, 2011 DRAFT-D
REQUESTED ACTION: Please help improve the EHR System Functional Model (EHR-FM) by
providing suggested improvements to the editor, so they can be considered for
incorporation into future versions of the EHR-S FM.
7/21/2015
DRAFT WORKING DOCUMENT
1
Executive Summary
For EHR-S FIM Release 2.1, this project has the dual purpose to 1) add core
information models for each EHR-S FM function in support of the design of
business objects, which are suitable to be composed into reusable business
components and their associated standards-based information-exchange
messages, documents and services and 2) make the EHR-S FM easier to
analyze and to specify & to test an interoperable EHR (iEHR).
The approach is to use an architecture modeling tool to represent the EHR-S
FIM and then generate appropriate views, reports, XML and HTML
renderings of each EHR-S function’s scenarios, requirements, actors,
actions, dependencies, business rules, information & data, which can be
adapted or refined to support specific profiles (e.g., project needs).
The DoD-VA Joint Immunization Capability (JIC) project is proposed as a
demonstration prototype.
7/21/2015
DRAFT WORKING DOCUMENT
2
This Document’s Purpose
• Prototype Information Model approach for EHR System Functional Model
(EHR-S FM), Release 2.1.
• For each EHR-S FM Function:
Scenario: Business Process Model based on function statement, description & criteria
Requirements (conformance criteria)
Business Rules
Conceptual Information Model based on function statement, description & criteria
Logical Data Model
• ISSUE: As this becomes a standard, what should be the basis to define the data elements for
each logical data module/class or should we NOT define the data elements?
– HL7 RIM, DAMS, DIMS, DCLs, etc.
– US Federal Heath Information Model (FHIM)
– Other information models (Canada, New Zealand, GB, Singapore)
– Dependencies among functions (“see also”)
– Assertions and Common Actors, Actions, Data Element Set, data dictionary (UC Simplification)
– Service, Message or Document Profiles: content & transport interoperable standards-specifications
–
–
–
–
–
• REQUESTED ACTION: Provide suggestions to increase the fidelity, to
Improve the quality and to increase the usability of the EHR-S FM.
7/21/2015
DRAFT WORKING DOCUMENT
3
1.8.2 Immunization Scenario
based on EHR-S FM 1.8.2 Statement and Description
act DC.1.8.2 SCENARIO Manage Immunization Administration
IT
NOTE: Similarities with more generic 1.8.1 Manage Medication Administration scenario.
EHR
IIS
allergen & adverse reaction histories
Clinician
Business Rule
Encounter
accepted immunization schedule
«flow»
Start
Rev iew
Immunization
Schedule
Immunization
Needed?
NOTE
separation of
OV-6a business
rules!
YES
«flow»
Rev iew Allergy &
Adv erse Reaction
Histories
Give
Immunization?
Immunization Event
Adverse Reaction
«flow»
Immunization Event
«flow»
YES
Document
Immunization
YES
Adverse
Event?
Document
Adv erse
Reactions
Reporting
Required?
NO
NO
NO
End
«flow»
End
YES
Report to
Immunization
Registry
Note: EHR-S FIM OV-7
concept & OV-5 activity
models will help
standardize verbs & nouns
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.
7/21/2015
DRAFT WORKING DOCUMENT
4
req DC.1.8.2 REQUIREMENTS Manage Immunization Administration
DC.1.8.2#01 T he system
SHALL provi de the abi l i ty to
recommend requi red
i mmuni zati ons, and when
they are due, duri ng an
encounter based on wi del y
accepted i mmuni zati on
schedul es.
DC.1.8.2#05 T he system
SHOULD provi de the abi l i ty
to capture other cl i ni cal data
perti nent to the
i mmuni zati on admi ni strati on
(e.g. vi tal si gns).
DC.1.8.2#09 T he system
SHOULD provi de the abi l i ty
to prepare a report of a
pati ent's i mmuni zati on
hi story upon request for
appropri ate authori ti es such
as school s or day-care
centers.
DC.1.8.2#04 T he system
SHALL provi de the abi l i ty to
capture i mmuni zati on
admi ni strati on detai l s,
i ncl udi ng date, type, l ot
number and manufacturer.
7/21/2015
DC.1.8.2#02 T he system
SHOULD provi de the abi l i ty
to recommend requi red
i mmuni zati ons based on
pati ent ri sk factors.
DC.1.8.2#03 T he system
SHALL perform checki ng for
potenti al adverse or al l ergi c
reacti ons for al l
i mmuni zati ons when they
are about to be gi ven.
DC.1.8.2#06 T he system
SHALL record as di screte
data el ements data
associ ated wi th any
i mmuni zati on.
DC.1.8.2#07 T he system
SHOULD provi de the abi l i ty
to associ ate standard codes
wi th di screte data el ements
associ ated wi th an
i mmuni zati on.
DC.1.8.2#10 T he system
SHALL conform to functi on
DC.1.4.1 (Manage Al l ergy,
Intol erance and Adverse
Reacti on Li sts).
DC.1.8.2#11 T he system
SHOULD transmi t requi red
i mmuni zati on i nformati on to
a publ i c heal th
i mmuni zati on regi stry.
DC.1.8.2#08 T he system
SHALL provi de the abi l i ty to
update the i mmuni zati on
schedul e.
DRAFT WORKING DOCUMENT
DC.1.8.2#12 T he system
SHOULD recei ve
i mmuni zati on hi stori es from
a publ i c heal th
i mmuni zati on regi stry.
5
class DC.1.8.2 CONCEPTUAL IM Manage Immunization Administration
QUESTION: Is an allergen
reaction a type of adverse
reaction/event?
Note: EHR-S FIM OV-7
concept & OV-5 activity
models will help
standardize verbs & nouns
Immunization Schedule
tags
schedule source = ACIP (Dec 2011)
Recommendations
«flow»
presented
Clinician
note
immunize
{new}
check
{prior to immunization}
Encounter
record Immunization Ev ent
note
{new}
Adv erse Reaction
check history
{prior to immunization}
Allergen Reaction
create
{if required}
Public Health Report
{if administered}
immunize
{new}
{previous}
{previous}
{new}
Patient
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.
7/21/2015
DRAFT WORKING DOCUMENT
6
dm DC.1.8.2 DATA MODEL Manage Immunization Administration
Patient
-
Allergen Reaction
address
birth date
identifier
name
responsible adult
-
adverse event
adverse event date
adverse event type
Adv erse Reaction
-
Vaccine Forcast
adverse event
adverse event date
adverse event type
Immunization Schedule
tags
schedule source = ACIP (Dec 2011)
Encounter
-
clinician
date
location
patient
time
Prov ider
Clinician
-
Immunization
Public Health Record
Report
identifier
location
name
Immunization Ev ent
-
administering provider
administration route
administration site
allergic or adverse reactions
dose amount
dose amount unit
NDC code
prescribing provider
target disease
vaccine expiration date
vaccine lot number
vaccine type
vacination date
NOTE: synonyms
TODO:

Attributes SHOULD be specified before balloting model.

Model Person-patient, provider organization, schedule
ISSUES:

Source of attributes (HL7 RIM, DAMS, DIMS, DCLs) other information models)?

Should Data Model classes be derived from the RIM or just be traceable to the RIM?

Can we define attributes from Federal Health Information Model (FHIM) for US domain?

Adverse Reaction = Adverse Event? Allergen Reaction = Adverse Reaction?
7/21/2015
DRAFT WORKING DOCUMENT
7
Should EHR-S FM R2 include these Operational Views (OVs)?
DoD Architectural Framework views used for discussion convenience
•
OV-1 High Level Operational Concept Graphic - High level graphical and textual description of
operational concept (high level organizations, missions, geographic configuration, connectivity, etc.).
– Recommendation = OPTIONAL, may be a nice concept view.
•
OV-2 Operational Node Connectivity Description - Operational nodes, activities performed at each
node, and connectivities and information flow between nodes.
– Recommendation = OPTIONAL , may be a useful view.
•
OV-3 Operational Information Exchange Matrix - Information exchanged between nodes and the
relevant attributes of that exchange such as media, quality, quantity, and the level of interoperability
required.
– Recommendation = YES
•
OV-4 Organizational Relationships Chart - Command, control, coordination, and other relationships
among organizations.
– Recommendation = NO
7/21/2015
DRAFT WORKING DOCUMENT
8
Should EHR-S FM R2 include these Operational Views (OVs)?
•
OV-5 Operational Activity Model - Activities, relationships among activities, inputs and outputs. In
addition, overlays can show cost, performing nodes, or other pertinent information.
– Recommendation = YES, (Level 1: access to care, provision of care, population health, manage
the business)
•
OV-6a Operational Rules Model - One of the three products used to describe operational activity
sequence and timing that identifies the business rules that constrain the operation.
– Recommendation = YES, shown as a part of slide 4
•
OV-6b Operational State Transition Description - One of the three products used to describe
operational activity sequence and timing that identifies responses of a business process to events.
– Recommendation = YES, if we want to show triggers.
•
OV-6c Operational Event-Trace Description - One of the three products used to describe operational
activity sequence and timing that traces the actions in a scenario or critical sequence of events.
– Recommendation = YES, can be shown as slide 4 or as a sequence diagram.
•
OV-7 Logical Data Model - Documentation of the data requirements and structural business process
rules of the Operational View.
•
Recommendation = YES, this is slide 7
7/21/2015
DRAFT WORKING DOCUMENT
9
Should EHR-S FM R2 include these Views?
•
•
•
•
•
•
AV-1 Overview and Summary Information - Scope, purpose, intended users, environment depicted,
analytical findings (if applicable)
• Recommendation = YES
AV-2 Integrated Dictionary - Definitions of all terms used in all products.
• Recommendation = YES, this is a traditional data dictionary
TV-1 Technical Standards Profile - Extraction of standards that apply to the given architecture. (e.g.,
information exchanges)
– Recommendation = YES, this can be a part of the Information Exchange matrix.
TV-2 Technical Standards Forecast - Description of emerging standards that are expected to apply
to the given architecture (e.g., information exchanges), within an appropriate set of timeframes.
– Recommendation = NO
SV-4a/SV-4b Systems/Services Functionality Description - The SV-4a documents system
functional hierarchies and system functions, and the system data flows between them.
– Recommendation = YES, this is the EHR-S FM
SV-5a Operational Activity to Systems Function Matrix SV-5a is a specification of the relationships
between the set of operational activities applicable to the set of SV-4 system functions applicable to
that architecture.
• Recommendation = YES
7/21/2015
DRAFT WORKING DOCUMENT
10
Level 1 Dependencies
class DC.1.8.2 DEPENDENCIES Manage Immunization Administration
DC.1.3.2 Manage Patient Advance Directives
DC.1.4.1 Manage Allergy, Intolerance and Adverse Reaction List
DC.1.4.4 Manage Immunization List
DC.1.8 Documentation of Care, Measurements and Results
DC.1.8.2 Manage Immunization Administration
DC.2.3.2 Support for Medication and Immunization Administration
IN.1.6 Secure Data Exchange
IN.1.7 Secure Data Routing
IN.2.4 Extraction of Health Record Information
IN.2.5.1 Manage Unstructured Health Record Information
IN.2.5.2 Manage Structured Health Record Information
IN.4.1 Standard Terminologies and Terminology Models
IN.4.2 Maintenance and Versioning of Standard Terminologies
IN.4.3 Terminology Mapping
IN.5.1 Interchange Standards
IN.5.2 Interchange Standards Versioning and Maintenance
IN.6 Business Rules Management
S.1.1 Registry Notification
S.2.2.2 Standard Report Generation
S.3.7.1 Clinical Decision Support System Guidelines Updates
TODO: Model each of these functional dependencies and possible their dependencies to show a more complete immunization management picture.
7/21/2015
DRAFT WORKING DOCUMENT
11
BACKUP: Requirements for Level 1 Dependent Functions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
DC.1.3.2
DC.1.4.1
DC.1.4.4
DC.1.8
DC.1.8.2
DC.2.2.1
DC.2.3.2
DC.2.7.1
S.1.1
S.2.2
S.2.2.2
S.3.7.1
IN.1.1
IN.1.2
IN.1.3
IN.1.6
IN.1.7
IN.2.4
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.6
7/21/2015
Manage Patient Advance Directives
Manage Allergy, Intolerance and Adverse Reaction List
Manage Immunization List
Documentation of Care, Measurements and Results
Manage Immunization Administration
Support for Condition Based Care and Treatment Plans, Guidelines, Protocols
Support for Medication and Immunization Administration
Access Healthcare Guidance
Registry Notification
Report Generation
Standard Report Generation
Clinical Decision Support System Guidelines Updates
Entity Authentication
Entity Authorization.
Entity Access Control
Secure Data Exchange
Secure Data Routing
Extraction of Health Record Information
Manage Unstructured Health Record Information
Manage Structured Health Record Information
Standard Terminologies and Terminology Models
Maintenance and Versioning of Standard Terminologies
Terminology Mapping
Interchange Standards
Interchange Standards Versioning and Maintenance
Business Rules Management
DRAFT WORKING DOCUMENT
12
req DC.1.3.2 REQUIREMENTS Manage Patient Adv ance Directiv es
DC.1.3.2#1 The system
SHALL provide the ability to
indicate that advance
directives exist for the
patient.
DC.1.3.2#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 or
DC.1.3.2#5 The system
SHOULD provide the ability
to indicate when advanced
directives were last
reviewed.
DC.1.3.2#6 The system
SHOULD provide the ability
to indicate the name and
relationship of the party
completing the advance
directive for the patient.
DC.1.3.2#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.
DC.1.3.2#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.
DC.1.3.2#7 The system
SHALL time and date stamp
advance directives.
DC.1.3.2#8 The system
SHOULD provide the ability
to document the location
and or source of any legal
documentation regarding
advance directives.
DC.1.3.2#9 The system
SHOULD conform to
function DC.2.1.4 (Support
for Patient and Family
Preferences).
7/21/2015
DRAFT WORKING DOCUMENT
13
req DC.1.1.3.1 Capture Data and Documentation from External Clinical Sources
DC.1.1.3.1#01 The system
SHALL provide the ability to
capture external data and
documentation.
DC.1.1.3.1#02 IF lab results
are received through an
electronic interface, THEN
the system SHALL receive
and store the data elements
into the patient record.
DC.1.1.3.1#03 IF lab results
are received through an
electronic interface, THEN
the system SHALL display
them upon request.
DC.1.1.3.1#05 The system
MAY provide the ability to
store imaged documents or
reference the imaged
documents via links to
imaging systems.
DC.1.1.3.1#06 The system
SHOULD provide the ability
to receive, store and present
text-based
externally-sourced
documents and reports.
DC.1.1.3.1#07 The system
SHOULD provide the ability
to receive, store and display
clinical result images (such
as radiologic images)
received from an external
source.
DC.1.1.3.1#08 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.
DC.1.1.3.1#09 The system
SHOULD provide the ability
to receive, store and present
medication details from an
external source.
DC.1.1.3.1#10 The system
SHOULD provide the ability
to receive, store and present
structured text-based reports
received from an external
source.
DC.1.1.3.1#11 The system
SHOULD provide the ability
to receive, store and present
standards-based structured,
codified data received from
an external source.
DC.1.1.3.1#4 The system
SHOULD provide the ability
to receive, store and display
scanned documents as
images.
7/21/2015
DRAFT WORKING DOCUMENT
14
req DC.1.4.1 Manage Allergy, Intolerance and Adv erse Reaction List
DC.1.4.1#01 The system
SHALL provide the ability to
capture true allergy,
intolerance, and adverse
reaction to drug, dietary or
environmental triggers as
unique, discrete entries.
DC.1.4.1#02 The system
SHOULD provide the ability
to capture the reason for
entry of the allergy,
intolerance or adverse
reaction.
DC.1.4.1#03 The system
SHALL provide the ability to
capture the reaction type.
DC.1.4.1#04 The system
SHOULD provide the ability
to capture the severity of a
reaction.
DC.1.4.1#05 The system
SHALL provide the ability to
capture a report of No
Known Allergies (NKA) for
the patient.
DC.1.4.1#06 The system
SHOULD provide the ability
to capture a report of No
Known Drug Allergies
(NKDA) for the patient.
DC.1.4.1#07 The system
SHOULD provide the ability
to capture the source of
allergy, intolerance, and
adverse reaction
information.
DC.1.4.1#08 The system
SHALL provide the ability to
deactivate an item on the
list.
DC.1.4.1#09 The system
SHALL provide the ability to
capture the reason for
deactivation of an item on
the list.
DC.1.4.1#10 The system
MAY present allergies,
intolerances and adverse
reactions that have been
deactivated.
DC.1.4.1#11 The system
MAY provide the ability to
display user defined sort
order of list.
DC.1.4.1#12 The system
SHOULD provide the ability
to indicate that the list of
medications and other
agents has been reviewed.
DC.1.4.1#13 They system
SHALL provide the ability to
capture and display the date
on which allergy information
was entered.
DC.1.4.1#14 The system
SHOULD provide the ability
to capture and display the
approximate date of the
allergy occurrence.
7/21/2015
DRAFT WORKING DOCUMENT
15
req DC.1.4.4 Manage Immunization List
DC.1.4.4#1 The system
SHALL capture, display and
report all immunizations
associated with a patient
DC.1.4.4#2 The system
SHALL record as discrete
data elements data
associated with any
immunization given
including date, type, lot
number and manufacturer
DC.1.4.4#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
req DC.1.8 REQUIREMENTS Docu...
DC.1.8#1 The system
SHALL conform to function
IN.2.2 (Auditable Records)
7/21/2015
DRAFT WORKING DOCUMENT
16
req IN.2.2 REQUIREMENTS Auditable Records
IN.2.2#01 The system
SHALL provide audit
capabilities for recording
access and usage of systems,
data, and organizational
resources.
IN.2.2#06 The system
SHALL provide audit
capabilities indicating the
time stamp for an object or
data exchange.
IN.2.2#03 The system
SHALL provide audit
capabilities indicating the
time stamp for an object or
data creation.
IN.2.2#07 The system
SHOULD provide audit
capabilities indicating the
time stamp for an object or
data view.
IN.2.2#10 The system
SHOULD provide audit
capabilities indicating the
viewer of a data set.
IN.2.2#11 The system MAY
provide audit capabilities
indicating the data value
before a change.
IN.2.2#14 The system
SHALL provide the ability to
generate an audit report.
IN.2.2#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.
7/21/2015
IN.2.2#04 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.
IN.2.2#08 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.
IN.2.2#12 The system MAY
provide audit capabilities to
capture system events at the
hardware and software
architecture level.
IN.2.2#16 The system
SHOULD provide the ability
to record system
maintenance events for
loading new versions of, or
changes to, the clinical
system.
DRAFT WORKING DOCUMENT
IN.2.2#05 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.
IN.2.2#09 The system
SHALL provide audit
capabilities indicating the
author of a change in
accordance with users' scope
of practice, organizational
policy, or jurisdictional law.
IN.2.2#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.
IN.2.2#17 The system
SHOULD provide the ability
to record system
maintenance events for
loading new versions of
codes and knowledge bases.
17
req IN.1.1 Entity Authentication
IN.1.1#1 The system SHALL
authenticate principals prior
to accessing an EHR-S
application or EHR-S data.
IN.1.1#2 The system SHALL
prevent access to EHR-S
applications or EHR-S data
to all non-authenticated
principals.
IN.1.1#3 The system
SHOULD provide the ability
to implement a Chain of
Trust agreement.
IN.1.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.
req IN.1.2 Entity Authorization.
IN.1.2#1 The system SHALL
provide the ability to create
and update sets of
access-control permissions
granted to principals.
IN.1.2#2 The system SHALL
conform to function IN.2.2
(Auditable Records) for the
purpose of recording all
authorization actions.
IN.1.2#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.
IN.1.2#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.2#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.
IN.1.2#7 The system MAY
provide the ability to define
context based on legal
requirements or disaster
conditions.
7/21/2015
DRAFT WORKING DOCUMENT
IN.1.2#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.
18
req IN.1.3 Entity Access Control
IN.1.3#1 The system SHALL
conform to function IN.1.1
(Entity Authentication).
7/21/2015
IN.1.3#2 The system SHALL
conform to function IN.1.2
(Entity Authorization).
IN.1.3#3 The system SHALL
provide the ability to define
system and data access
rules.
DRAFT WORKING DOCUMENT
IN.1.3#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).
19
req IN.2.2 REQUIREMENTS Auditable Records
IN.2.2#18 The system
SHOULD provide the ability
to record changing the date
and time where the clinical
system allows this to be
done.
IN.2.2#21 The system
SHOULD provide the ability
to record system
maintenance events for
re-activating of an archived
patient record.
IN.2.2#19 The system
SHOULD provide the ability
to record system
maintenance events for
creating and restoring of
backup.
IN.2.2#22 The system
SHOULD provide the ability
to record system
maintenance events for
entry to and exit from the
EHR system.
IN.2.2#2 The system SHALL
conform to function IN.1.1
(Entity Authentication).
IN.2.2#23 The system
SHOULD provide the ability
to record system
maintenance events for
remote access connections
including those for system
support and maintenance
activities.
IN.2.2#20 The system
SHOULD provide the ability
to record system
maintenance events for
archiving any data.
IN.2.2#24 The system
SHOULD utilize
standardized time keeping
(for example using the IHE
consistent time profile).
IN.2.2#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).
req DC.2.2.1 Support for Condition Based Care and Treatment Plans, Guid...
DC.2.2.1#1 The system
SHOULD conform to
function IN.1.4 (Patient
Access Management).
7/21/2015
DC.2.2.1#2 The system
SHOULD conform to
function IN.3 (Registry and
Directory Services).
DRAFT WORKING DOCUMENT
20
req DC.2.3.2 Support for Medication and Immunization Administration
DC.2.3.2#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.
DC.2.3.2#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.
DC.2.3.2#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 syst
DC.2.3.2#6 The system MAY
generate documentation of
medication or immunization
administration as a
by-product of verification of
patient, medication, dose,
route and time.
DC.2.3.2#3 The system
SHOULD alert providers to
potential medication
administration errors at the
point of medication
administration.
DC.2.3.2#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.
DC.2.3.2#7 The system
SHOULD prompt or remind
providers regarding the
date/time range for timely
administration of
medications.
DC.2.3.2#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.
DC.2.3.2#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.
7/21/2015
DRAFT WORKING DOCUMENT
21
req DC.2.7.1 Access Healthcare Guidance
DC.2.7.1#1 The system
SHALL provide the ability to
access evidence-based
healthcare
recommendations, with
documentation of sources
DC.2.7.1#2 The system
SHOULD provide the ability
to access evidenced-based
documentation appropriate
for the care provider to
render a timely judgment.
DC.2.7.1#3 The system MAY
provide the ability to access
external evidence-based
documentation.
DC.2.7.1#4 The system
SHALL conform to function
DC.2.2.1.1 (Support for
Standard Care Plans,
Guidelines, Protocols).
DC.2.7.1#5 The system
SHOULD conform to
function IN.1.4 (Patient
Access Management).
7/21/2015
DRAFT WORKING DOCUMENT
22
req IN.1.6 Secure Data Exchange
IN.1.6#1 The system SHALL
secure all modes of EHR
data exchange.
IN.1.6#2 The system
SHOULD conform to
function IN.1.7 (Secure Data
Routing).
IN.1.6#3 The system MAY
provide the ability to
obfuscate data.
IN.1.6#4 The system SHALL
encrypt and decrypt EHR
data that is exchanged over
a non-secure link.
IN.1.6#5 The system SHALL
support standards-based
encryption mechanisms
when encryption is used for
secure data exchange.
req IN.1.7 Secure Data Routing
IN.1.7#1 The system SHALL
automatically route
electronically exchanged
EHR data only from and to
known sources and
destinations and only over
secure networks.
7/21/2015
IN.1.7#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)).
DRAFT WORKING DOCUMENT
IN.1.7#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.
23
req IN.2.4 Extraction of Health Record Information
IN.2.4#02 The system
SHOULD conform to
function IN.1.6 (Secure Data
Exchange) to provide secure
data exchange capabilities.
IN.2.4#03 The system
SHOULD provide the ability
to de-identify extracted
information.
IN.2.4#04 The system
SHOULD conform to
function IN.5.1 (Interchange
Standards) to enable data
extraction in standard-based
formats.
IN.2.4#05 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.
IN.2.4#06 The system MAY
provide the ability to
perform extraction
operations whose output
fully chronicles the
healthcare process.
IN.2.4#10 The system
SHOULD provide the ability
to extract data for quality
analysis purposes.
IN.2.4#11 The system
SHOULD provide the ability
to extract data for public
health purposes.
IN.2.4#7 The system
SHOULD provide the ability
to extract data for
administrative purposes.
IN.2.4#8 The system
SHOULD provide the ability
to extract data for financial
purposes.
IN.2.4#9 The system
SHOULD provide the ability
to extract data for research
purposes.
IN.2.4#01 The system
SHALL provide the ability to
extract health record
information.
7/21/2015
DRAFT WORKING DOCUMENT
24
req IN.2.5.1 Manage Unstructured Health Record Information
IN.2.5.1#1 The system
SHALL capture unstructured
health record information as
part of the patient EHR.
IN.2.5.1#5 The system
SHOULD provide the ability
to report unstructured health
record information.
IN.2.5.1#2 The system
SHALL retrieve unstructured
health record information as
part of the patient EHR.
IN.2.5.1#3 The system
SHALL provide the ability to
update unstructured health
record information.
IN.2.5.1#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.1#6 The system MAY
track unstructured health
record information over
time.
IN.2.5.1#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.
IN.2.5.1#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.
IN.2.5.1#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.
7/21/2015
DRAFT WORKING DOCUMENT
25
req IN.2.5.2 Manage Structured Health Record Information
IN.2.5.2#1 The system
SHALL capture structured
health record information as
part of the patient EHR.
IN.2.5.2#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.
IN.2.5.2#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.
IN.2.5.2#5 The system
SHOULD provide the ability
to report structured health
record information.
IN.2.5.2#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.
IN.2.5.2#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.
7/21/2015
IN.2.5.2#2 The system
SHALL retrieve structured
health record information as
part of the patient EHR.
IN.2.5.2#3 The system
SHALL provide the ability to
update structured health
record information.
IN.2.5.2#6 The system MAY
track structured health record
information over time.
IN.2.5.2#7 The system
SHOULD provide the ability
to retrieve each item of
structured health record
information discretely within
patient context.
DRAFT WORKING DOCUMENT
26
req IN.4.1 Standard Terminologies and Terminology Models
IN.4.1#1 The system SHALL
provide the ability to use
standard terminologies to
communicate with other
systems(internal or external
to the EHR-S).
IN.4.1#2 The system SHALL
provide the ability to
validate that clinical terms
and coded clinical data
exists in a current standard
terminology.
IN.4.1#3 The system
SHOULD provide the ability
to exchange healthcare data
using formal standard
information models and
standard terminologies.
IN.4.1#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.
IN.4.1#6 The system
SHOULD provide the ability
to manage terminology
assets and supporting tools
(internal or external to the
EHR-S).
IN.4.1#7 IF there is no
standard terminology model
available, THEN the system
MAY provide a formal
explicit terminology model.
7/21/2015
DRAFT WORKING DOCUMENT
IN.4.1#4 The system
SHOULD provide the ability
to use a formal standard
terminology model.
27
req IN.4.2 Maintenance and Versioning of Standard Terminologies
IN.4.2#1 The system SHALL
provide the ability to use
different versions of
terminology standards.
IN.4.2#5 The system
SHOULD provide the ability
to deprecate terminologies.
IN.4.2#2 The system SHALL
provide the ability to update
terminology standards.
IN.4.2#3 The system MAY
relate modified concepts in
the different versions of a
terminology standard to
allow preservation of
interpretations over time.
IN.4.2#4 The system
SHOULD provide the ability
to interoperate with systems
that use known different
versions of a terminology
standard.
IN.4.2#6 The system MAY
provide the ability to
deprecate individual codes
within a terminology.
IN.4.2#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 unambiguo
IN.4.2#8 Changes in
terminology SHALL be
applied to all new clinical
content (via templates,
custom formularies, etc.).
IN.4.3#2 The system
SHOULD provide the ability
to use standard terminology
services for the purposes of
mapping terminologies.
IN.4.3#3 The system MAY
provide the ability for a user
to validate a mapping.
IN.4.3#4 The system MAY
provide the ability to create
a terminology map.
req IN.4.3 Terminology Mapping
IN.4.3#1 The system SHALL
provide the ability to use a
terminology map.
7/21/2015
DRAFT WORKING DOCUMENT
28
req IN.5.1 Interchange Standards
IN.5.1#1 The system SHALL
provide the ability to use
interchange standards as
required by realm specific
and/or local profiles.
IN.5.1#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.
IN.5.1#2 The system SHALL
provide the ability to
seamlessly perform
interchange operations with
other systems that adhere to
recognized interchange
standards.
IN.5.1#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.
IN.5.1#5 The system
SHOULD provide the ability
to exchange data using an
explicit and formal
information model and
standard, coded
terminology.
req IN.5.2 Interchange Standards Versioning and Maintenance
IN.5.2#1 The system SHALL
provide the ability to use
different versions of
interchange standards.
7/21/2015
IN.5.2#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.
IN.5.2#3 The system
SHOULD provide the ability
to deprecate an interchange
standard.
DRAFT WORKING DOCUMENT
IN.5.2#4 The system
SHOULD provide the ability
to interoperate with other
systems that use known
earlier versions of an
interoperability standard.
29
req IN.6 Business Rules Management
IN.6#01 The system SHALL
provide the ability to
manage business rules.
IN.6#05 The system
SHOULD provide the ability
to inactivate, obsolete, or
destroy decision support
rules.
IN.6#09 The system MAY
provide the ability to
customize diagnostic support
rules and their components.
7/21/2015
IN.6#02 The system
SHOULD provide the ability
to create, import, or access
decision support rules to
guide system behavior.
IN.6#03 The system
SHOULD provide the ability
to update decision support
rules.
IN.6#04 The system
SHOULD provide the ability
to customize decision
support rules and their
components.
IN.6#06 The system
SHOULD conform to
function IN.2.2 (Auditable
Records) to audit all
changes to decision support
rules.
IN.6#07 The system
SHOULD provide the ability
to create diagnostic support
rules to guide system
behavior.
IN.6#08 The system
SHOULD provide the ability
to update diagnostic support
rules.
IN.6#10 The system
SHOULD provide the ability
to inactivate, obsolete, or
destroy diagnostic support
rules.
IN.6#11 The system
SHOULD conform to
function IN.2.2 (Auditable
Records) to audit all
changes to diagnostic
support rules.
IN.6#12 The system
SHOULD provide the ability
to create workflow control
rules to guide system
behavior.
DRAFT WORKING DOCUMENT
30
req IN.6 Business Rules Management
IN.6#13 The system
SHOULD provide the ability
to update workflow control
rules.
IN.6#14 The system MAY
provide the ability to
customize workflow control
rules and their components.
IN.6#15 The system
SHOULD provide the ability
to inactivate, obsolete, or
destroy workflow control
rules.
IN.6#16 The system
SHOULD conform to
function IN.2.2 (Auditable
Records) to audit all
changes to workflow control
rules.
IN.6#17 The system MAY
provide the ability to create
access privilege rules to
guide system behavior.
IN.6#18 The system MAY
provide the ability to update
access privilege rules.
IN.6#19 The system MAY
provide the ability to
customize access privilege
rules and their components.
IN.6#20 The system MAY
provide the ability to
inactivate, obsolete, or
destroy access privilege
rules.
IN.6#21 The system MAY
conform to function IN.2.2
(Auditable Records) to audit
all changes to access
privilege rules.
IN.6#22 The system
SHOULD conform to
function IN.2.2 (Auditable
Records) to audit all
changes to other business
rules.
IN.6#23 The system
SHOULD support the ability
to selectively export business
rules.
7/21/2015
DRAFT WORKING DOCUMENT
31
Level 2 Dependencies
class DC.1.8.2 LEVEL 2 DEPENDENCIES Manage Immunization Administration
DC.1.1.2
DC.1.1.3.1
DC.1.1.3.2
DC.1.1.4
DC.1.1.5
DC.1.2
DC.1.3.1
DC.1.3.2
DC.1.3.3
DC.1.4
DC.1.4.1
DC.1.4.2
DC.1.4.3
DC.1.4.4
DC.1.5
DC.1.6.1
DC.1.6.2
DC.1.7.1
DC.1.7.2.1
DC.1.7.2.2
DC.1.7.2.3
DC.1.7.2.4
DC.1.7.3
DC.1.8.1
DC.1.8.2
DC.1.8.3
DC.1.8.4
DC.1.8.5
DC.1.8.6
DC.1.9
DC.2.1.1
DC.2.1.2
DC.2.1.3
DC.2.1.4
DC.2.2
DC.2.2.2
DC.2.2.3
DC.2.2.4
DC.2.3.1.1
DC.2.3.1.2
DC.2.3.1.3
DC.2.3.2
DC.2.4.1
DC.2.4.2
DC.2.4.3
DC.2.4.4.1
DC.2.4.4.2
DC.2.4.5.1
DC.2.4.5.2
DC.2.5.1
DC.2.5.2
DC.2.6.1
DC.2.6.2
DC.2.6.3
DC.2.7.1
DC.2.7.2
DC.3.1.1
DC.3.1.3
DC.3.2.1
DC.3.2.2
DC.3.2.3
DC.3.2.4
DC.3.2.5
IN.1.1
IN.1.2
IN.1.5
IN.1.6
IN.1.7
IN.1.8
IN.1.9
IN.2.1
IN.2.2
IN.2.4
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.2
IN.4.3
IN.5.1
IN.5.2
IN.5.3
IN.5.4
IN.6
S.1.1
S.1.2
S.1.3.6
S.1.4.4
S.1.5
S.1.6
S.1.7
S.1.8
S.2.1.1
S.2.2
S.2.2.1
S.2.2.2
S.2.2.3
S.3
S.3.1
S.3.1.2
S.3.1.3
S.3.1.4
S.3.2.1
S.3.2.2
S.3.2.3
S.3.3.1
S.3.3.2
S.3.3.4
S.3.3.5
S.3.4
S.3.5.1
S.3.5.3
S.3.5.4
S.3.7
S.3.7.1
S.3.7.3
S.3.7.4
7/21/2015
DRAFT WORKING DOCUMENT
32