Transcript Document

EHR System Function and Information Model
(EHR-S FIM) Release 2.1
HL7 Project ID# 688
Executive Summary for
EHR-S FIM Immunization Capability Prototype
[email protected] , EHR WG Modeling Facilitator
[email protected] , DoD-MHS Proponent
February 9, 2012 – Original
March 2, 2012 – Last Update
Call for Participation
This work is being done by the HL7 EHR Interoperability Work-group,
meeting every Tuesday at 4PM ET, dial-in: 1-770-657-9270, Passcode: 510269#
The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
7/21/2015
DRAFT WORKING DOCUMENT
1
EHR System Function and Information Model
EHR-S FIM Vision
Starting with the EHR-S FIM, analysts, engineers and
testers can efficiently-specify system functions,
information models and interoperability;
• for EHR system capabilities, components and their
messages, documents and services;
• which are tailored to specific environments and needs.
7/21/2015
DRAFT WORKING DOCUMENT
2
Executive Summary
For EHR-S FIM Release 2.1, this prototype has the purpose to
1) add conceptual information and data models for each EHR-S function
•
make the EHR-S FM easier to use for analysts and engineers
•
verify and validate EHR-S FM Release 2.0
2) Service Aware Interoperability Framework (SAIF) DSTU demonstration
3) Support specific profiles (e.g., WG project DAMs, DIMs, DCMs).
The Sparx Enterprise Architect modeling tool is being used 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/activities, dependencies, business rules, information & data models.
The DoD-VA Joint Immunization Capability (JIC), HL7 EHR Diabetes project,
ISO 13940 Continuity-of-Care harmonization are proposed as a set of
demonstration prototypes of increasing complexity.
7/21/2015
DRAFT WORKING DOCUMENT
3
EHR-S FM Release 2.0
Sections
• Overarching (O) – 2 major subsections
• Care Provision (CP) - 9 major subsections
• Care Provision Support (CPS) – 9 major subsections
• Population Health Support (POP) – 10 major subsections
• Administrative Support (AS) – 9 major subsections
• Record Infrastructure (RI) – 3 major subsections
• Trust Infrastructure (TI) – 9 major subsections
EHR-S FM R2 ballot package can be downloaded at:
http://wiki.hl7.org/index.php?title=December_2011_Ballot_Package
7/21/2015
DRAFT WORKING DOCUMENT
4
CP.6.2 Manage Immunization Administration
Statement: Capture and maintain discrete data concerning immunizations given to a patient including date
administered, type, manufacturer, lot number, and any allergic or adverse reactions. Facilitate the
interaction with an immunization registry to allow maintenance of a patient’s immunization history.
Description: During an encounter, recommendations based on accepted immunization schedules are
presented to the provider. Allergen and adverse reaction histories are checked prior to giving the
immunization. If an immunization is administered, discrete data elements associated with the immunization
including date, type, manufacturer and lot number are recorded. Any new adverse or allergic reactions are
noted. If required, a report is made to the public health immunization registry or other organization (e.g.
military unit commander, refugee program leadership).
Example: (Notional Scenario) During an encounter, recommendations based on accepted immunization
schedules and previous adverse or allergic reactions are presented to the clinician. If an immunization is
administered, discrete data elements associated with the immunization are recorded and any new adverse
or allergic reactions are noted. Patient demographic information is harmonized with and reports are made
to the appropriate public health immunization registries and organizations (e.g., PHRs, schools), according
to scope of practice, organizational policy and/or jurisdictional law.
7/21/2015
DRAFT WORKING
DOCUMENT
RED: Recommend deletion,
Blue:
Recommended Insertion
5
EHR-FIM
Model Legend
Clinician Perspective
class Legend
EHR-S Function Activity
control
flow
control flow
Task within Activity
Start Activity
End Activity
depends on
EHR-S Function
EHR-S Component
depends on
Syatem Component 3
System Component
+
-
attribute 2 [SHALL CC]
attribute 1 [SHOULD or MAY CC]
+
-
operation [SHALL CC]()
operation 2 [SHOULD or MAY CC]()
association
system component 4
has-a (part)
aggregation
is-a (type)
generalization
System Component 2
«trace»
FEATURE:
EHR-S Function
depends on
FEATURE 2
realization
"implements"
REQUIREMENT:
Conformance Criteria (CC)
7/21/2015
DRAFT WORKING DOCUMENT
6
EHR-FIM
Description of Model Diagrams
“Clinician-Activities Mapped to System-Components” shows
• Row 1: operational activities performed by the clinician, indicating dependencies on
• Row 2: The EHR System components, which support the clinician’s activities.
“CIM Mapped to EHR-S Functions” shows
• System Components mapped to the EHR-S Functions they support
“Conceptual Data Model (CDM)” shows
• Attributes & operations for System Components.
“Information Exchanges Mapped-to Conformance Criteria” shows
• Conformance Criteria requiring specific information exchanges
“CDM Requirements-Traceability” shows
• Conformance Criteria requiring specific attributes and operations within a Component
CIM is Conceptual Information Model
CDM is Conceptual Data Model
7/21/2015
DRAFT WORKING DOCUMENT
7
Immunization Management Capability
Models
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CP.6.2 Clinician-Activities Mapped-to System-Components
CP.6.2 Conceptual Information Model (CIM) Mapped to EHR-S Functions
CIM for Immunization Management Capability
Immunization Management CCs Requiring Information Exchanges
CDM for Advanced Directive
CDM for Allergy, Intolerance and Adverse Reaction Event
CDM for Clinical Decision Support (CDS)
CDM for Clinical Document or Note
CDM for Event
CDM for Lists
CDM for Immunization Event
CC is Conformance Criteria
CIM is Conceptual Information Model
CDM is Conceptual Data Model
7/21/2015
DRAFT WORKING DOCUMENT
8
CP.6.2 Manage Immunization Administration
Clinician-Activities Mapped-to EHR-S Components
Clinician
act CP.6.2 ACT Manage Immunization Administration
EHR-S Components
Manage Trusts
Manage Business
Rules
depends on
depends on
depends on
CP.6.2 Manage Immunization Administration
Start
Encounter
Manage Records
Manage
Ev ents
Manage
Immunization
Schedules
Manage
Lists
Manage
Documents &
Notes
Ev ent
Immunization
Schedule
List
Document
or Note
Manage
Terminology
Manage
Regestries
Terminology
Registry
Manage
Reports
End
Report
is-a
is-a
Allergy,
Intolerance and
Adv erse
Reaction Ev ent
ia-a
is-a
Immunization
Ev ent
Immunization List
Clinical Document or Note
Registry Immunization
(Public Health)
is-a
Adv anced Directiv e Ev ent
7/21/2015
is-a
Adv anced Directiv e
RED: Recommend deletion,
Blue:
Recommended Insertion
DRAFT WORKING
DOCUMENT
9
CP.6.2 Manage Immunization Administration
EHR-S Components Mapped to Supporting Functions
class CP.6.2 CI M Manage I mmunization Administration
CP, CPS & AS
Registry
List
Clinical Document or Note
Document or
Note
Registry I mmunization
(Public Health)
I mmunization List
AS.4.1 Manage Registry
Communication
Encounter
Event
Report
Terminology
Advanced Directive
I mmunization
History
CPS.9.4 Standard
Report Generation
I mmunization
Event
CPS.1.7.2 Manage Patient
Advance Directives
Allergy, I ntolerance and
Adverse Reaction Event
CP.3.2 Manage Patient
Clinical Measurements
CP.6.2 Manage Immunization Administration
CP.1.6 Manage Immunization List
CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List
Trust I nfrastructure
7/21/2015
Record I nfrastructure
RED:
delete,
Blue:
insert
DRAFT
WORKING
DOCUMENT
10
Immunization Management Capability
Conceptual Information Model (CIM)
class CIM Immunization Management Capability
Clinical and Clinical Support System Components
Registry Immunization
(Public Health)
is-a
Registry
EHR System
Medical Dev ice
CDS-Clinical
Decision Support
Encounter
Clinical
Information
has-a
0..*
1..*
has-a
Document or Note
is-a
Report
Template
List
Ev ent
Clinical Document
or Note
Adv anced
Directiv e
document or note
0..*
is-a
is-a
Immunization
Ev ent
Medication
Ev ent
is-a
Reminder
or Alert
0..*
has-a
is-a
is-a
Allergy, Intolerance
and Adv erse
Reaction Ev ent
Immunization
List
is-a
Adv anced
Directiv e Ev ent
Immunization
Schedule
Immunization
Witheld Ev ent
is-a
Medication
List
is-a
CDS
Update
Terminology
Allergy, Intolerance
and Adv erse
Reaction List
Immunization
History
Patients Requiring
Follow up List
Problem List
Record Infrastructure
7/21/2015
ia-a
is-a
Trust Infrastructure
DRAFT WORKING DOCUMENT
11
Immunization Management Capability
Conformance Criteria (CC) Requiring Information Exchanges
class IE-RT Immunization Management Capability
standardUsage
Enumeration
- SHALL
- SHOULD
- MAY
StandardType
Enumeration
-
content
transport
information assurance
other
7/21/2015
EHR-System Information-Exchange
Metadata
-
sourceSystem
recipientSystem
releventStandard
standardOrganization
standardVersion
standardType
standardUsage
standardRealm
rational
effectiveDate
possibleRisk
harmonizationIssue
implementationGuide
implementationGuideVersion
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
AS.4.1#04
CP.3.3#07
Medical Device
EHR System
other EHR
or related
systems
- reminders or alerts
- Information Exchange Metadata
Demographic
Information
(structured)
+ manage()
+ Manage 'Do Not Recusitste"()
Registry
-
clinical information
demographic information
organization (source)
patient
provider (source)
type
- manage()
is-a
AS.4.1#02
AS.4.1#05
AS.4.1#03
AS.4.1#01
RED: Recommend deletion,
Blue:
Recommended Insertion
DRAFT WORKING
DOCUMENT
Registry Immunization
(Public Health)
12
Immunization Management Information Exchange
Conformance Criteria (CC) Requiring Specific Information Exchanges
CP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment, prosthetic/orthotic devices, medications, and notes to one or
more problems (Ref: CP.1.4 [Manage Problem List] cc#9).
AS.4.1#01 The system SHOULD provide the ability to exchange structured demographic and clinical information with registries (e.g., local, disease-specific,
notifiable, patient, provider, organization, or health services registries).
AS.4.1#02 The system MAY provide the ability to render and tag registry information as reviewed and the information's related assessment of validity or
applicability for clinical, financial or administrative activities.
AS.4.1#03 The system SHOULD provide the ability to maintain information received from registries (e.g., local, disease-specific, notifiable, patient, provider,
organization, or health services registries).
AS.4.1#04 The system MAY provide the ability to receive structured demographic and clinical information from registries.
AS.4.1#05 The system SHOULD provide the ability to harmonize system information with registry information.
7/21/2015
DRAFT WORKING DOCUMENT
13
Advanced Directive
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
class RT Adv anced Directiv e
Ev ent
+
+
-
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
CPS.1.7.2#03
CP.3.3#09
CP.3.3#11
Document or Note
has-a
CPS.1.7.2#01
+
+
+
+
+
+
+
authenticator
author
date
facility
patient
type
status
+
+
+
+
render()
capture()
update()
tag()
CP.3.3#10
CP.3.3#02
CP.3.3#03
CP.6.2#02
CP.6.2#06
CP.3.3#08
CP.3.3#05
is-a
CP.3.3#07
+ deactivate()
+ justify()
+ manage()
Adv anced Directiv e Ev ent
CPS.1.7.2#02
CPS.1.7.2#08
CPS.1.7.2#07
CPS.1.7.2#06
7/21/2015
+
+
+
+
+
+
+
+
+
+
+
+
advanced directive captured :boolean
person completing AD
relationship to patient
circumstances (of receipt)
circumstances (of review)
date (received)
date (recinded)
date (review)
0..*
date (signed/completed)
date (updated)
Review
type
Adv anced Directiv e Type Enumeration
-
CP.3.3#14
Do Not Recusitate (DNR) Order
Durable Power of Attorney
Living Will
other
Preferred Interventions for Known Conditions
-
circumstances
date
reviewer
CP.3.3#15
-
CP.3.3#17
disposition
signature
structured :boolean
- manage()
+ render()
+ tag()
Adv anced
Directiv e Rev iew
0..*
Clinical Document or
Note
CP.3.3#04
CP.3.3#12
CP.3.3#01
Adv anced
Directiv e Author
-
DRAFT WORKING DOCUMENT
date signed
name
relationship
time signed
is-a
CP.3.3#16
Adv anced
Directiv e
CPS.1.7.2#05
CPS.1.7.2#04
14
Advanced Directive
Conformance Criteria (CC) Applicable to This Component
CP.3.3#01 The system SHALL provide the ability to capture and render clinical documentation (henceforth "documentation") including original, update by amendment in order to correct,
and addenda.
CPS.1.7.2#08 The system SHALL provide the ability to manage the date and/or time an advance directives paper document was signed/completed.
CP.3.3#02 The system SHALL provide the ability to capture free text documentation.
CP.3.3#03 The system MAY present documentation templates (structured or free text) to facilitate creating documentation.
CP.3.3#04 The system SHALL provide the ability to present other existing documentation within the patient's EHR while new creating documentation.
CP.3.3#05 The system SHOULD provide the ability to link documentation for a specific patient with a given event (e.g., office visit, phone communication, e-mail consult, lab result).
CP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment, prosthetic/orthotic devices, medications, and notes to one or more problems (Ref:
CP.1.4 [Manage Problem List] cc#9).
CP.3.3#08 The system SHALL provide the ability to update documentation prior to finalizing it.
CP.3.3#09 The system SHALL provide the ability to tag a document or note as final.
CP.3.3#10 The system SHALL provide the ability to render the author(s) and authenticator(s) of documentation when the documentation is rendered.
CP.3.3#11 The system SHALL provide the ability to render documents based on document metadata (e.g., note type, date range, facility, author, authenticator and patient).
CP.3.3#12 The system MAY provide the ability for providers to capture clinical documentation using standard choices for disposition (e.g., reviewed and filed, recall patient, or future
follow-up).
CP.3.3#14 The system SHOULD provide the ability to render clinical documentation using an integrated charting or documentation tool (e.g., notes, flow-sheets, radiology views, or
laboratory views).
CP.3.3#15 The system MAY provide the ability to capture clinical documentation using specialized charting tools for patient-specific requirements (e.g., age - neonates, pediatrics,
geriatrics; condition - impaired renal function; medication).
CP.3.3#16 The system SHOULD provide the ability to capture, maintain and render transition-of-care related information.
CP.3.3#17 The system SHOULD provide the ability to tag the status of clinical documentation (e.g., preliminary, final, signed).
CP.6.2#02 The system MAY auto-populate the immunization administration record as a by-product of verification of administering provider, patient, medication, dose, route and time
according to scope of practice, organizational policy and/or jurisdictiona
CP.6.2#06 The system SHOULD provide the ability to link standard codes (e.g. NDC, LOINC, SNOMED or CPT) with discrete data elements associated with an immunization.
CPS.1.7.2#01 The system SHALL provide the ability to manage advance directive information including the type of directive, relevant dates (e.g., received, reviewed, rescinded, updated),
circumstances under which the directives were received, and the ...
CPS.1.7.2#02 The system SHALL render an indication that advance directive(s) have been captured.
CPS.1.7.2#03 The system SHALL provide the ability to render the type of advance directives captured for the patient (e.g., living will, durable power of attorney, preferred interventions for
known conditions, or the existence of a "Do Not Resuscitate" ...
CPS.1.7.2#04 The system SHALL provide the ability to manage “Do Not Resuscitate” orders.
CPS.1.7.2#05 The system SHOULD conform to function CPS.2.4 (Support Externally Sourced Clinical Images) in order to capture scanned patient advance directive documents and/or
“Do Not Resuscitate” orders.
CPS.1.7.2#06 The system SHALL provide the ability to manage the date and circumstances of the most recent review of the advanced directives.
CPS.1.7.2#07 The system SHALL provide the ability to manage the name and relationship of the principal completing the advance directive for the patient.
7/21/2015
DRAFT WORKING DOCUMENT
15
Advanced Directive Allergy, Intolerance and Adverse Reaction Event
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
class RT Allergy, Intolerance and Adv erse Reaction Ev ent
Ev ent
Clinical
Information
-
type
CP.6.2#09
CP.1.2#04
CP.1.2#16
CP.1.2#17
+
+
-
date (occurence)
ti me (occurence)
change j usti fi cati on
ci rcumstances
cl i ni cal i nformati on
date (entry)
date (revi ew)
descri pti on
durati on
i nformati on revi ewed
i nformati on source
i nformati on val i dator
l ocati on
mechani sm
metadata
person-rol e
status
tri gger
type
+
+
+
deacti vate()
j usti fy()
manage()
CP.1.2#24
CP.1.2#26
CP.1.2#25
CP.1.2#07
CP.1.2#19
CP.1.2#22
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
i s-a
Allergy, Intolerance
and Adv erse
Reaction Ev ent
CP.1.2#02
CP.1.2#01
CP.1.2#03
-
data of revi ew
reacti on type
severi ty
type
CP.1.2#18
+
manage()
CP.1.2#21
CP.1.2#13
CP.6.2#04
7/21/2015
DRAFT WORKING DOCUMENT
16
Advanced Directive Allergy, Intolerance and Adverse Reaction Event
Conformance Criteria (CC) Applicable to This Component
CP.1.2#01 The system SHALL provide the ability to manage true allergy, intolerance, and adverse reaction to drug, food or environmental triggers as unique,
discrete entries.
CP.1.2#02 The system SHOULD provide the ability to manage the reason for entry or maintenance (including update or remove) of the allergy, intolerance or
adverse reaction.
CP.1.2#03 The system SHALL provide the ability to manage the reaction type as discrete data.
CP.1.2#04 The system SHALL provide the ability to manage the severity of an allergic or adverse reaction as discrete data.
CP.1.2#07 The system SHOULD provide the ability to manage the source of allergy, intolerance, and adverse reaction information.
CP.1.2#13 The system SHALL provide the ability to tag that the list of medications and other agents has been reviewed.
CP.1.2#16 The system SHOULD provide the ability to manage allergy information as coded data.
CP.1.2#17 The system SHOULD provide the ability to capture and maintain the required documentation of allergies prior to completion of the medication order.
CP.1.2#18 The system SHOULD provide the ability to capture and render that the allergies are “Unknown” or “Unable to Assess Allergies".
CP.1.2#19 The system SHOULD provide the ability to capture the reason for “Unknown” or “Unable to Assess Allergies” documentation.
CP.1.2#21 The system SHOULD provide the ability to capture free text allergies and render them in a manner that distinguishes them from coded allergy entries.
CP.1.2#22 The system SHOULD tag and render an indicator that interaction checking will not occur against free text allergies.
CP.1.2#24 The system SHOULD provide the ability to link allergic reactions to specific treatment or diagnostic protocols.
CP.1.2#25 The system SHOULD conform to function CPS.4.2.1 (Support for Medication Interaction and Allergy Checking) to render any potential interactions
when capturing or maintaining allergies, intolerances or adverse reactions.
CP.1.2#26 The system SHOULD capture information that a provider was presented with and acknowledged a drug interaction notification.
CP.6.2#04 The system SHOULD provide the ability to capture, in a discrete field, an allergy/adverse reaction to a specific unization.
CP.6.2#09 The system SHALL conform to function CP.1.2 (Manage Allergy, Intolerance and Adverse Reaction List).
7/21/2015
DRAFT WORKING DOCUMENT
17
Clinical Decision Support
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
class RT Clinical Decision S upport (CDS )
Event
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
CPS.3.9# 04
CDS -Clinical
Decision S upport
CPS.3.9# 01
-
maintain()
is-a
CDS Update
-
date (update)
version
-
manage()
+
+
-
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information v alidator
location
mechanism
metadata
person-role
status
trigger
type
+
+
+
deactivate()
justify()
manage()
CPS.3.9# 03
CPS.3.9# 02
CDS Content
7/21/2015
CDS Rules
DRAFT WORKING DOCUMENT
18
Clinical Decision Support
Conformance Criteria (CC) Applicable to This Component
CPS.3.9#01 The system SHALL provide the ability to maintain the clinical content or rules utilized to generate clinical decision support reminders and alerts.
CPS.3.9#02 The system SHOULD provide the ability to render information that will allow validation that the most applicable version (of the decision support rules)
is utilized for the update.
CPS.3.9#03 The system SHOULD capture the date of update of the decision support rules.
CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are provided in a patient encounter.
7/21/2015
DRAFT WORKING DOCUMENT
19
Clinical Document or Note
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
class RT Clinical Document or Note
CPS.1.7.2#03
Document or Note
Document or Note Type Enumeration
-
addenda
ori gi nal
updated by am endm ent i n order to correct
Document or Note
Status Enumeration
-
fi nal
prel i m i nary
si gned
+
+
+
+
+
+
+
authenti cator
author
date
faci l i ty
pati ent
type
status
CPS.1.7.2#01
+
+
+
+
render()
capture()
update()
tag()
CP.3.3#08
CP.3.3#11
CP.3.3#10
CP.3.3#02
CP.3.3#09
CP.3.3#03
i s-a
Template
Clinical Document or
Note Disposition
Enumeration
-
future fol l ow-up
recal l pati ent
revi ewed and fi l es
Clinical Document or
Note Type Enumeration
«enum »
+
ori gi nal
+
addenda
+
update
-
CP.3.3#04
type
CP.3.3#16
CP.3.3#14
Clinical Document or
Note
CP.3.3#15
-
di sposi ti on
si gnature
structured :bool ean
+
+
m anage()
render()
tag()
CP.6.2#06
CP.6.2#02
CP.3.3#07
CP.3.3#12
i s-a
CP.3.3#05
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide
deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Int
eroperability_WG
Adv anced
Directiv e
CP.3.3#01
CPS.1.7.2#04
7/21/2015
CP.3.3#17
Unstructured
Document
CPS.1.7.2#05
DRAFT WORKING DOCUMENT
20
Clinical Document or Note
Conformance Criteria (CC) Applicable to This Component
CP.3.3#01 The system SHALL provide the ability to capture and render clinical documentation (henceforth "documentation") including original, update by
amendment in order to correct, and addenda.
CP.3.3#02 The system SHALL provide the ability to capture free text documentation.
CP.3.3#03 The system MAY present documentation templates (structured or free text) to facilitate creating documentation.
CP.3.3#04 The system SHALL provide the ability to present other existing documentation within the patient's EHR while new creating documentation.
CP.3.3#05 The system SHOULD provide the ability to link documentation for a specific patient with a given event (e.g., office visit, phone communication, e-mail
consult, lab result).
CP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment, prosthetic/orthotic devices, medications, and notes to one or
more problems (Ref: CP.1.4 [Manage Problem List] cc#9).
CP.3.3#08 The system SHALL provide the ability to update documentation prior to finalizing it.
CP.3.3#09 The system SHALL provide the ability to tag a document or note as final.
CP.3.3#10 The system SHALL provide the ability to render the author(s) and authenticator(s) of documentation when the documentation is rendered.
CP.3.3#11 The system SHALL provide the ability to render documents based on document metadata (e.g., note type, date range, facility, author, authenticator
and patient).
CP.3.3#12 The system MAY provide the ability for providers to capture clinical documentation using standard choices for disposition (e.g., reviewed and filed,
recall patient, or future follow-up).
CP.3.3#14 The system SHOULD provide the ability to render clinical documentation using an integrated charting or documentation tool (e.g., notes, flow-sheets,
radiology views, or laboratory views).
CP.3.3#15 The system MAY provide the ability to capture clinical documentation using specialized charting tools for patient-specific requirements (e.g., age neonates, pediatrics, geriatrics; condition - impaired renal function; medication).
CP.3.3#16 The system SHOULD provide the ability to capture, maintain and render transition-of-care related information.
CP.6.2#02 The system MAY auto-populate the immunization administration record as a by-product of verification of administering provider, patient, medication,
dose, route and time according to scope of practice, organizational policy and/or jurisdictiona
CP.6.2#06 The system SHOULD provide the ability to link standard codes (e.g. NDC, LOINC, SNOMED or CPT) with discrete data elements associated with an
immunization.
CPS.1.7.2#01 The system SHALL provide the ability to manage advance directive information including the type of directive, relevant dates (e.g., received,
reviewed, rescinded, updated), circumstances under which the directives were received, and the ...
CPS.1.7.2#03 The system SHALL provide the ability to render the type of advance directives captured for the patient (e.g., living will, durable power of attorney,
preferred interventions for known conditions, or the existence of a "Do Not Resuscitate" ...
CPS.1.7.2#04 The system SHALL provide the ability to manage “Do Not Resuscitate” orders.
CPS.1.7.2#05 The system SHOULD conform to function CPS.2.4 (Support Externally Sourced Clinical Images) in order to capture scanned patient advance
directive documents and/or “Do Not Resuscitate” orders.
7/21/2015
DRAFT WORKING DOCUMENT
21
Event
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
class RT Ev ent
Terminology
Trigger
Enumeration
-
-
-
date & Time
identifier
location
Demographic
Information
(structured)
7/21/2015
-
code set
-
type
+ manage()
drug
environment
food
other
Person-Role
Demographic
Information
Clinical
Information
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
person identifier 1..* 1..*
+
role
+
Clinical Document or
Note
- disposition
- signature
- structured :boolean
- manage()
+ render()
+ tag()
Ev ent-Status
Enumeration
- active
- completed
- deactive
+
- erroneously captured
+
- pending
+
CP.1.3#08
CP.1.3#13
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
deactivate()
justify()
manage()
Ev ent Type Enumeration
CP.1.2#15
Ev ent
CP.1.2#25
CPS.3.9#04
CP.1.2#14
CP.1.3#10
CP.1.3#05
AS.4.1#02
-
advanced directive
adverse reaction
allergy
CDS Alerts
CDS reminders
CDS update
clinical document or note
discharge
encounter
intolerance
medication (pharmacist change)
medication (prescription dispensing)
medication (prescription filling)
medication history received (external source)
order
other
procedure
registry
reminders & alerts
report
surgical
transfer
CP.1.6#02
DRAFT WORKING DOCUMENT
22
Event
Conformance Criteria (CC) Applicable to This Component
CP.1.6#02 The system SHALL provide the ability to manage, as discrete data elements, data associated with any immunization given including date and time of
administration, immunization type and series, lot number and manufacturer, dose and administration
CP.1.3#05 The system SHALL provide the ability to capture medications not reported on existing medication lists or medication histories.
CP.1.3#08 The system SHALL provide the ability to tag a medication as erroneously captured and excluded from the presentation of current medications.
CP.1.3#10 The system SHOULD provide the ability to capture and render information regarding the filling of prescriptions.
CP.1.3#13 The system SHALL provide the ability to capture that a medication history is unavailable or incomplete.
CP.1.2#14 They system SHALL provide the ability to capture and render the date on which allergy information was entered.
CP.1.2#15 The system SHOULD provide the ability to capture and render the approximate date of the allergy occurrence.
CP.1.2#25 The system SHOULD conform to function CPS.4.2.1 (Support for Medication Interaction and Allergy Checking) to render any potential interactions
when capturing or maintaining allergies, intolerances or adverse reactions.
CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are provided in a patient encounter.
AS.4.1#02 The system MAY provide the ability to render and tag registry information as reviewed and the information's related assessment of validity or
applicability for clinical, financial or administrative activities.
7/21/2015
DRAFT WORKING DOCUMENT
23
Lists
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
class RT List
CP.1.2#12
List
CP.1.4#08
-
CP.3.3#06
is-a
define sort restrictions()
define sort criteria()
filter()
link to problem-treatment()
manage()
manage reason for change ()
sort()
ia-a
Allergy, Intolerance
and Adv erse
Reaction List
7/21/2015
CP.1.2#11
SHALL CCs have
bolded borders.
See individual EHR-S
Function’s slide deck
for CC details at:
http://wiki.hl7.org/index.
php?title=EHR_Interop
erability_WG
is-a
Immunization List
+ analyze()
+ manage()
Medication
List
Patients Requiring
Followup List
DRAFT WORKING DOCUMENT
CP.3.3#18
24
Lists
Conformance Criteria (CC) Applicable to This Component
CP.1.2#11 The system MAY provide the ability to render the list of allergies, intolerances and adverse reactions in a user defined sort order.
CP.1.2#12 The system MAY restrict the ability to render the list in a user defined sort order.
CP.1.4#08 The system SHOULD provide the ability to render the list in a user defined sort order.
CP.3.3#18 The system SHOULD provide the ability to tag and render lists of patients requiring follow up contact (e.g., laboratory callbacks, radiology callbacks,
left without being seen).
CP.3.3#06 The system SHOULD provide the ability to render the list in a user defined sort order (Ref: CP.1.4 [Manage Problem List] cc#8).
7/21/2015
DRAFT WORKING DOCUMENT
25
Immunization Event
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
class RT Immunization Ev ent
CP.1.2#13
CP.3.3#12
CP.6.2#03
CP.3.3#19
Encounter
-
differential diagnosis
disposition
follow up activities
follow up needed :boolean
follow up results
type
+ manage()
has-a
CP.3.3#13
CP.3.3#18
CPS.3.9#04
CP.1.2#20
Immunization Future
Booster
-
CP.1.6#02
Ev ent
+
+
1..* -
0..*
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
+ deactivate()
+ justify()
+ manage()
immunization type
recommended date
health care
organisation
Immunization Witheld
Ev ent
+ exception reason
+ withholding provider
7/21/2015
is-a
CP.1.6#03
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
CP.6.2#17
CP.6.2#16
CP.6.2#21
CP.6.2#22
CP.6.2#06
CP.6.2#02
is-a
Immunization Ev ent
+
+
+
0..* -
date (recommended booster)
immunization type
series (immunization)
dose
educational information received :boolean
encounter
future booster
healthcare organization
immunization order
immunization provider
justification-immunization refusal
lot
manufacturer
ordered immunization due date
receipt of immunization preference
receiving entity (educational information)
refusal of vaccine type
route of administration
time (administration)
type
DRAFT WORKING DOCUMENT
CP.6.2#23
CP.6.2#18
CP.6.2#10
CP.6.2#20
CP.6.2#05
CP.6.2#19
CP.6.2#01
CP.1.6#05
26
Immunization Event
Conformance Criteria (CC) Applicable to This Component
CP.1.2#13 The system SHALL provide the ability to tag that the list of medications and other agents has been reviewed.
CP.1.2#20 The system SHOULD provide the ability to tag records and render to providers that the allergies are “Unknown” or “Unable to Assess Allergies” and need to be updated.
CP.1.6#02 The system SHALL provide the ability to manage, as discrete data elements, data associated with any immunization given including date and time of administration,
immunization type and series, lot number and manufacturer, dose and administration
CP.1.6#03 The system SHALL provide the ability to manage, as discrete elements, data associated with any immunization withheld (including date and time, immunization type, series,
exception reason and immunization-withholding provider).
CP.1.6#05 The system SHALL provide the ability to capture the currently recommended date for an immunization booster dose with each immunization, if needed.
CP.3.3#12 The system MAY provide the ability for providers to capture clinical documentation using standard choices for disposition (e.g., reviewed and filed, recall patient, or future
follow-up).
CP.3.3#13 The system MAY provide the ability to capture, maintain and render the clinician’s differential diagnosis and the list of diagnoses that the clinician has considered in the
evaluation of the patient.
CP.3.3#18 The system SHOULD provide the ability to tag and render lists of patients requiring follow up contact (e.g., laboratory callbacks, radiology callbacks, left without being seen).
CP.3.3#19 The system SHOULD provide the ability to capture patient follow-up contact activities (e.g., laboratory callbacks, radiology callbacks, left without being seen).
CP.6.2#01 The system SHALL provide the ability to capture, maintain and render immunization administration details as discrete data, including:(1) the immunization name/type, strength
and dose;(2) date and time of administration;(3) manufacturer, lot numb
CP.6.2#02 The system MAY auto-populate the immunization administration record as a by-product of verification of administering provider, patient, medication, dose, route and time
according to scope of practice, organizational policy and/or jurisdictiona
CP.6.2#03 The system SHALL provide the ability to determine and render required immunizations, and when they are due, based on widely accepted immunization schedules, when
rendering encounter information.
CP.6.2#05 The system SHALL conform to function CP.3.2 (Manage Patient Clinical Measurements) to capture other clinical data pertinent to the immunization administration (e.g., vital
signs).
CP.6.2#06 The system SHOULD provide the ability to link standard codes (e.g. NDC, LOINC, SNOMED or CPT) with discrete data elements associated with an immunization.
CP.6.2#10 The system SHOULD transmit required immunization administration information to a public health immunization registry according to scope of practice, organizational policy
and/or jurisdictional law.
CP.6.2#16 The system SHALL provide the ability to render the immunization order as written (i.e., exact clinician order language) when rendering administration information.
CP.6.2#17 The system SHALL provide the ability to determine due and overdue ordered immunizations and render a notification.
CP.6.2#18 The system SHALL provide the ability to render a patient educational information regarding the administration (e.g., Vaccine Information Statement (VIS)).
CP.6.2#19 The system SHALL provide the ability to capture that patient educational information (e.g., VIS) was provided at the time of immunization administration.
CP.6.2#20 The system SHALL provide the ability to capture documentation that patient educational information (e.g., VIS) was provided at the time of immunization administration.
CP.6.2#21 The system SHALL provide the ability to capture the receiving entity (e.g., patient, representative, organization) when patient education information is provided at the time of
immunization administration.
CP.6.2#22 The system SHOULD provide the ability to capture and maintain immunization refusal reasons as discrete data.
CP.6.2#23 The system SHOULD provide the ability to capture patient preferences regarding receipt of immunization (e.g. refusal of certain vaccine types) at time of immunization
administration.
CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are provided in a patient encounter.
7/21/2015
DRAFT WORKING DOCUMENT
27
Methodology
Sparx Enterprise Architect views were used to create a separate slide set for an
Immunization Management Capability based on CP.6.2 Manage Immunization
Administration and its “See Also” Dependencies :
1.
Create Activity Model for the function.
•
2.
Map Activities to EHR-S Components
Create Conceptual Data Model (CDM) view from step 1.
•
•
•
Start with applicable reusable components and their data elements
Based on Conformance Criteria, add additional function-specific components
Based on Conformance Criteria, add additional attributes or operations
–
–
3.
Create Conceptual Information Model (CIM) view from step 2.
•
•
4.
Indicate SHALL attributes or operations as “public” with a proceeding “+”
Indicate SHOULD or MAY attributes or operations as “private” with a proceeding “-”
Show supporting EHR-S Functions dependencies.
Map EHR-S Components to supporting EHR-S Functions (“See Also” Dependencies)
Show Conformance Criteria (CC) Requiring Specific Information Exchanges
This Executive Summary was created from the resultant model.
7/21/2015
DRAFT WORKING DOCUMENT
28
Issues
1. What is normative within the EHR-S Information Model.
– Activity Diagrams map operational-activities to system components-and-functions.
• Recommend informative
– Conceptual Information Models
• set of applicable components and their relationships … recommend informative
– Conceptual Data Models ( attributes and operations within components)
•
Recommend normative
• Distinguish between elements derived from SHALLs vs. those from SHOULDs and MAYs
2. Criteria to determine the “See Also” Dependencies.
– EHR-S Function dependency on other Functions’ conformance criteria
– Shared activities & tasks within multiple EHR-S Functions
3. How will we represent the Information Model for Ballot.
–
Tool generated report showing models (e.g., similar to Immunization Prototype)
•
–
Textural listing of components and data elements similar to
•
•
7/21/2015
Will ISO accept this?
HITSP/C83 CDA Content Modules and
HITSP/C154 Data Dictionary
DRAFT WORKING DOCUMENT
29
Recommendations
• EHR-S FIM needs the following additional functions and components:
1.
2.
3.
Manage Business Rules
Clinical Decision Support (CDS)
EHR-System Metadata for realm-specific Information-Exchange Standards
• Make EHR-S Conceptual Data Model (CDM) Normative
1.
Remove data elements from Conformance Criteria.
• EHR-S FM CP-section should be hierarchically organized.
1.
2.
3.
4.
an EHR-S manages Encounters; where,
each Encounter is a set of Events, Documents and Lists.
Events, Documents and Lists are decomposed into types (immunization, medication).
Benefits:
•
•
7/21/2015
Reduced Conformance Criteria duplication
Increased Conformance Criteria consistency
DRAFT WORKING DOCUMENT
30
Conclusions
• EHR-S FIM can be the conceptual foundation for Interoperability
Specifications, refined into:
– HL7 Domain analysis Models (DAMs) and Detailed Clinical Models (DCL)
– Logical Perspectives
– Implementable Perspectives (Physical or Serialiazable Models)
• Messages, Documents, Services
• EHR-S FIM can be composed into higher level capabilities by functional
analysts and system engineers
– Encourage reuse of EHR-S FIM components
– Avoid duplication and “stovepipe applications”
• EHR-S FIM can populate portions of the HL7 SAIF for WGs
– Information and Computational Dimensions
– Conceptual Perspective
• An Enterprise Architecture tool is essential to maintain consistency
7/21/2015
DRAFT WORKING DOCUMENT
31
Next Steps / To Do / Help Needed
• SMEs verify and validate Conceptual Data Models (CDMs)
• Model the remaining EHR-S Functions
– Overarching (O) – 2 major subsections
– Care Provision (CP) - 9 major subsections
– Care Provision Support (CPS) – 9 major subsections
– Population Health Support (POP) – 10 major subsections
– Administrative Support (AS) – 9 major subsections
– Record Infrastructure (RI) – 3 major subsections
– Trust Infrastructure (TI) – 9 major subsections
7/21/2015
DRAFT WORKING DOCUMENT
32
Reference Information
•
•
•
•
•
7/21/2015
Glossary of Key Terms
EHR-S FIM Verb Hierarchy
HL7 SAIF Enterprise Compliance and Conformance Framework (ECCF)
Observations by reviewers
Backup Slides
DRAFT WORKING DOCUMENT
33
Glossary of Terms
•
•
A conceptual information model identifies the highest-level concepts in a domain and the relationships between each
concept; however, no attributes are specified and no primary key is specified. Conceptual models are typically human
readable though there are ways to build conceptual models that systems can process, such as, the Web Ontology
Language (OWL). http://www.w3.org/TR/owl-features/
A logical information model fully describes the data, without regard to how the data will be physically
implemented in the database. Features of a logical information model typically include the following:
–
–
–
–
–
–
7/21/2015
All concepts and relationships between them are defined.
All attributes for each concept are specified.
Business terms for concepts and attributes are agreed upon and used. (These terms should be part of the agreed upon common
terminology.)
The primary key for each concept is specified.
Foreign keys (keys identifying the relationship between different entities) are specified.
Normalization occurs at this level.
DRAFT WORKING DOCUMENT
34
EHR-S FIM
Action Verb Hierarches
Manage (Data)
Capture
Maintain
AutoStore
Populate
Enter
Archive
Import
Backup
Receive
Decrypt
Encrypt
Recover
Restore
Save
Update
Remove
Annotate
Attest
Edit
Harmonize
Integrate
Link
Tag
Delete
Purge
7/21/2015
Render
Extract
Present
Exchange
Transmit
DRAFT WORKING DOCUMENT
Export
Import
Receive
Transmit
Determine
Analyze
Decide
ManageDataVisibility
De-Identify
Hide
Mask
Re-Identify
Unhide
Unmask
35
Notional Set of HL7 Artifacts within a SAIF
Enterprise Compliance and Conformance Framework (ECCF)
ECCF
Conceptual
Perspective
Logical
Perspective
Implementable
Perspective
Enterprise
Dimension
“Why” - Policy
Information
Dimension
Computational
Dimension
Engineering
Dimension
Technical
Dimension
“What” - Content
“Who/How” - Behavior
“Where” - Implementation
“Where” - Deployments
 Inventory of Reusable
• Entities
• Associations
• Information
 Information Models
 Data Models
 Inventory of Reusable
• Scenarios
• Business Activities
• System Functions
 Requirements
• Accountability, Roles
• Conformance Criteria
• Profiles, Behaviors
• Interactions and
• Info. Exchanges
 Inventory of
• SW Platforms, Layers
• SW Environments
• SW Components
• SW Services
• Technical
Requirements
• Enterprise Service Bus
 Key Performance
Parameters
 Inventory of
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Technical Requirements
 Business Policies
 Governance
 Implementation Guides
 Design Constraints
 Organization Contracts
 Information Models
• Domain IM
• Detailed Clinical
 Terminologies
 Value Sets
 Content Specifications
• CCD
• RMIM
 Specifications
• Scenario Events
• Use Cases
• Workflow Use Cases
• Components
Interfaces
 Collaboration Actors
• Collaboration Types
• Collaboration Roles
 Function Types
 Interface Types
 Service Contracts
 Models, Capabilities,
Features and Versions for
• SW Environments
• SW Capabilities
• SW Libraries
• SW Services
• SW Transports
 Models, Capabilities,
Features and Versions for
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Business Nodes
 Business Rules
 Business Procedures
 Business Workflows
 Technology Specific
Standards
 Schemas for
• Databases
• Messages
• Documents
• Services
• Transformations
 Automation Units
 Technical Interfaces
 Technical Operations
 Orchestration Scripts
 SW Specifications for
• Applications
• GUIs
• Components
 SW Deployment
Topologies
 HW Deployment
Specifications
 HW Execution Context
 HW Application Bindings
 HW Deployment Topology
 HW Platform Bindings
 Business
• Mission,
• Vision,
• Scope ,
 Inventory of
• Contracts - PSSs
• Capabilities - RIM
• Policies
• Procedures
Responsibility: HL7 Organization | EHR-S FIM | HL7 WG Projects | Development Organization
See notes page for ECCF description
36
Observation [David Baas]
•
•
From where I’m sitting, deriving conceptual information models based on the conformance criteria
could be useful for consuming a functional profile. I would assume it could be used as reference
for developing a domain analysis model for a project, to fill in blanks of conceptual information not
expressed by clinical SMEs, and to shorten the learning curve for projects required to adopt the
conformance criteria. Regardless of how modeling evolved on the project, the CDM would still be
a bridge to validate addressing information needs at a high level. I would not foresee using the
CDM or other artifacts verbatim in modeling for a specific project because some the
relationships/associations expressed appear to be more subjective than explicit representation of
the conformance criteria. I suggest annotating whether the relationships in the CDM represent
explicit conformance criteria or not. For those that are not explicit (SHALL), it should be clear
implementers have no obligation to portray those relationships the way they are expressed
in the model.
In reviewing the other artifacts (activity diagrams, and conceptual information model) I was a little
concerned that the content suggested a more prescriptive view of EHR functionality, which I’m not
sure is a good thing. In the case of the activity diagrams being prototyped, I can see they are not
attempting to sequence how tasks within an activity are executed, but using activity diagrams
suggests that is the intended direction. I think that path would be too restrictive for implementers. I
think the CIM raises more questions than it answers. This is another one where I think it best left
to specific implementation projects. Perhaps other folks will provide a different perspective, but I
think the CDM content is the most useful for understanding the conformance criteria for greater
adoption.
7/21/2015
DRAFT WORKING DOCUMENT
37
Observation [Kevin Coonan, HL7 Patient Care WG Co-chair]
•
•
•
•
•
•
We have been having a lot of discussions in patient care, clinical statement, CIMI and MnM regarding representation of clinical
content. One of the most important is the recognition and separation of dynamic uses / extracts of information one would see in an
EHR-S GUI or CDA v. an information model suited for information exchange, persistence, transformation, analytics, decision
support. A good example of this is the common notions of a “problem list”, “allergy list” or “list of immunizations”. These are artifacts
we are used to seeing in paper charts, since there was no other effective means to address longitudinal data which otherwise would
be scattered in the linear ordering progress notes. In fact, HL7 defines these working lists as ‘..collects a dynamic list of individual
instances of Act via ActRelationship which reflects the need of an individual worker, team of workers, or an organization to manage
lists of acts for many different clinical and administrative reasons. Examples of working lists include problem lists, goal lists, allergy
lists, and to-do lists.’
There are also design patterns well suited for static semantics from the (being revised for May ballot) Patient Care domain, all of
which are different entry points into a common model. These include a pattern for a Care Record, which corresponds best to the
conventional notion of the documentation of an encounter. The Care Record, however, has entries which follow the Health Concern
pattern and the Care Plan pattern.
Health Concerns are anything which affects one’s health which need to be managed/tracked over time. These includes risks,
diseases, problems, allergies/intolerances to medications, social circumstances, and complications.
The Care Plan documents interventions, treatments and orders. Care Plans can have embedded logic, e.g. stating a specific action
should (not) be taken if a specific criterion is met. So things like immunization schedules, insulin sliding scales/sick day rules, or
complex oncology protocols have a common design basis. While we are used to thinking of Concerns and Plans as future looking,
the same pattern is used to document things which have happened (e.g. procedure which has been completed), so the Care Plan
includes not just what is currently being done, what is planned, but also what has been done in the past.
An instance of an encounter’s documentation therefore would have elements from the Care Record (e.g. the signs/symptoms
discovered at the time of the encounter), Health Concerns (in a linear narrative like a CDA these typically are organized into the
familiar ‘lists’, e.g. allergy list, problem list, PMH), and Care Plan (again in ‘lists’—e.g. medication list). An encounter would also
expect to generate new Care Plans and new Health Concerns as part of the clinical decision making. (The A&P in Weed’s POMR).
By separating the model of use (various lists) from model of meaning (the Patient Care Domain Model plus the derived detailed
clinical models which bind terminology, etc.) we can most effectively devise those specifications needed for given use cases.
7/21/2015
DRAFT WORKING DOCUMENT
38
Observation [Kevin Coonan, HL7 Patient Care WG Co-chair]
•
•
•
•
I am coordinating with Richard Savage (now working for CDC) on immunizations with Patient Care. I
don’t know who the modeling facilitator is for the new immunization project, but if it is a void I might fill
in. I am going to start tacking the immunization (JIC) (analysis/conceptual) models and see if I can get
them into something which is a better approximation of a real information model of the clinical content
static semantics.
Do you think this is a good point to start to put together the background and socialization needed to
come to some decision regarding the representation of static semantics for iEHR? I see two related
decisions: #1 what modeling language is going to be used for design, and #2 what is the modeling
language used for the wire format. Obviously, with HL7 v3 there is close traceability between the
graphic format in the Visio based RMIM Designer and the resultant MIF2 representation. I believe that
the UML based SMD also does this. MIF2 è XSD, so there is a close tie between MIF and something
which can be implemented.
Of course, we could also use HL7 templates (whatever those are) on top of a base model, rather than
having all the explicit details in the MIF2. We could even use ADL for this, if we were so inclined. That
still leaves us the question about ‘wire format’. I.e. what one server says to another.
Eventually, I would expect a ‘cleaner’ modeling language to be used for design, with transformation to
arbitrary implementable paradigms. Hopefully CIMI will fill this niche. Not in time to do the modeling for
JIC, Pharmacy, etc. but hopefully just in time to model the core content of an ambulatory documentation
system.
7/21/2015
DRAFT WORKING DOCUMENT
39
Immunization Management Capability
Scope, (Including Dependent EHR-S Functions)
We started with CP6.2 and included its dependencies:
1. CP.6.2 Manage Immunization Administration
2. CP.1.6 Manage Immunization List
3. CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List
4. CP.1.3 Manage Medication List
5. CP.3.3 Manage Clinical Documents and Notes
6. CPS.1.7.2 Manage Patient Advance Directives
7. CPS.3.9 Clinical Decision Support System Guidelines Updates
8. CPS.9.4 Standard Report Generation
9. AS.4.1 Manage Registry Communication
10. Record Infrastructure
For details, see separate slide deck for each EHR-S Function.
11. Trust Infrastructure
All referenced EHR-S Functions are available at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
7/21/2015
DRAFT WORKING DOCUMENT
40
CP.6.2 Manage Immunization Administration
Components mapped to Requirements
req CP.6.2 RT Manage Immunization Administration
Encounter
NOTE: SHALL
conformance criteria
have bolded borders
-
differential diagnosis
disposition
follow up activities
follow up needed :boolean
follow up results
type
+
manage()
CP.6.2#03 The system
SHALL provide the ability to
determine and render
required immunizations, and
when they are due, based
on widely accepted
immunization schedules,
when rendering encounter
information.
0..*
List
CP.6.2#12 The system
SHOULD harmonize
Immunization histories with
a public health
immunization registry
according to scope of
practice, organizational
policy and/or jurisdictional
law.
-
define sort restrictions()
define sort criteria()
filter()
link to problem-treatment()
manage()
manage reason for change ()
sort()
+
manage()
depends on
CP.6.2#11 The system
SHOULD exchange
immunization histories with
public health immunization
registries according to scope
of practice, organizational
policy and/or jurisdictional
law.
7/21/2015
CP.1.2 Manage Allergy, Intolerance and
Adverse Reaction List
ia-a
depends
Immunization List
on
Registry Immunization
(Public Health)
+
+
depends on
CP.6.2#14 The system
SHALL conform to function
CP.1.6 (Manage
Immunization List).
analyze()
manage()
is-a
CP.6.2#13 The system
SHOULD capture and render
immunization histories from
a public health
immunization registry.
CP.6.2#07 The system
SHALL provide the ability to
maintain the immunization
schedule.
Immunization
Schedule
Immunization
History
+
-
CP.6.2#15 The system
SHOULD provide the ability
to update immunization
histories at the time of
capturing an immunization
administration.
render()
harmonize()
capture()
exchange()
update()
Allergy, Intolerance and
Adv erse Reaction Ev ent
depends on
CP.1.6 Manage
Immunization List
CP.6.2#08 The system
SHALL provide the ability to
render a patient‘s
immunization history upon
request for appropriate
authorities such as schools or
day-care centers.
CP.6.2#17 The system
SHALL provide the ability to
determine due and overdue
ordered immunizations and
render a notification.
DRAFT WORKING DOCUMENT
-
data of review
reaction type
severity
type
+
manage()
CP.6.2#04 The system
SHOULD provide the ability
to capture, in a discrete field,
an allergy/adverse reaction to
a specific unization.
CP.6.2#09 The system
SHALL conform to function
CP.1.2 (Manage Allergy,
Intolerance and Adverse
Reaction List).
41
CP.6.2 Manage Immunization Administration
Components mapped to Requirements
req CP.6.2 RT Manage Immunization Administration
CP.6.2#02 T he system MAY
auto-popul ate the
i mmuni zati on admi ni strati on
record as a by-product of
veri fi cati on of admi ni steri ng
provi der, pati ent,
medi cati on, dose, route and
ti me accordi ng to scope of
practi ce, organi zati onal
pol i cy and/or j uri sdi cti ona
Ev ent
+
+
-
date (occurence)
ti me (occurence)
change j usti fi cati on
ci rcumstances
cl i ni cal i nformati on
date (entry)
date (revi ew)
descri pti on
durati on
i nformati on revi ewed
i nformati on source
i nformati on val i dator
l ocati on
mechani sm
metadata
person-rol e
status
tri gger
type
+
+
+
deacti vate()
j usti fy()
manage()
CP.6.2#21 T he system
SHALL provi de the abi l i ty to
capture the recei vi ng enti ty
(e.g., pati ent, representati ve,
organi zati on) when pati ent
educati on i nformati on i s
provi ded at the ti me of
i mmuni zati on
admi ni strati on.
CP.6.2#06 T he system
SHOULD provi de the abi l i ty
to l i nk standard codes (e.g.
NDC, LOINC, SNOMED or
CPT ) wi th di screte data
el ements associ ated wi th an
i mmuni zati on.
Medi cati on
Admi ni strati on?
Terminology
-
code set
+
manage()
Immunization Ev ent
i s-a
CP.6.2#05 T he system
SHALL conform to functi on
CP.3.2 (Manage Pati ent
Cl i ni cal Measurements) 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).
7/21/2015
+
+
+
date (recommended booster)
dose
educati onal i nformati on recei ved :bool ean
encounter
future booster
heal thcare organi zati on
i mmuni zati on order
i mmuni zati on provi der
i mmuni zati on type
j usti fi cati on-i mmuni zati on refusal
l ot
manufacturer
ordered i mmuni zati on due date
recei pt of i mmuni zati on preference
recei vi ng enti ty (educati onal i nformati on)
refusal of vacci ne type
route of admi ni strati on
ti me (admi ni strati on)
type
seri es (i mmuni zati on)
CP.3.2 Manage Pati ent
Cl i ni cal Measurements
NOTE: SHALL conformance
criteria have bolded
borders
DRAFT WORKING
DOCUMENT
CP.6.2#18 T he system
SHALL provi de the abi l i ty to
render a pati ent educati onal
i nformati on regardi ng the
admi ni strati on (e.g., Vacci ne
Informati on Statement
(VIS)).
CP.6.2#19 T he system
SHALL provi de the abi l i ty to
capture that pati ent
educati onal i nformati on
(e.g., VIS) was provi ded at
the ti me of i mmuni zati on
admi ni strati on.
CP.6.2#01 T he system
SHALL provi de the abi l i ty to
capture, mai ntai n and
render i mmuni zati on
admi ni strati on detai l s as
di screte data, i ncl udi ng:(1)
the i mmuni zati on
name/type, strength and
dose;(2) date and ti me of
admi ni strati on;(3)
manufacturer, l ot numb
CP.6.2#23 T he system
SHOULD provi de the abi l i ty
to capture pati ent
preferences regardi ng
recei pt of i mmuni zati on
(e.g. refusal of certai n
vacci ne types) at ti me of
i mmuni zati on
admi ni strati on.
CP.6.2#22 T he system
SHOULD provi de the abi l i ty
to capture and mai ntai n
i mmuni zati on refusal
reasons as di screte data.
CP.6.2#20 T he system
SHALL provi de the abi l i ty to
capture documentati on that
pati ent educati onal
i nformati on (e.g., VIS) was
provi ded at the ti me of
i mmuni zati on
admi ni strati on.
CP.6.2#16 T he system
SHALL provi de the abi l i ty to
render the i mmuni zati on
order as wri tten (i .e., exact
cl i ni ci an order l anguage)
when renderi ng
admi ni strati on i nformati on.
CP.6.2#10 T he system
SHOULD transmi t requi red
i mmuni zati on admi ni strati on
i nformati on to a publ i c
heal th i mmuni zati on regi stry
accordi ng to scope of
practi ce, organi zati onal
pol i cy and/or j uri sdi cti onal
l aw.
42
Immunization Management Capability
CP.6.2 Manage Immunization Administration Dependencies
7/21/2015
DRAFT WORKING DOCUMENT
43
CP.6.2 Immunization Management
“See Also” Dependencies
DRAFT WORKING DOCUMENT
7/21/2015
RED: delete, Blue: insert
44