Transcript Document

EHR System Function and Information Model
(EHR-S FIM) Release 2.1 Prototype
Executive Summary for
Immunization Capability
and its EHR-S FIM
[email protected] , EHR WG facilitator
[email protected] , DoD Point-of-Contact
February 9, 2012 – Original
February 24, 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/20/2015
DRAFT WORKING DOCUMENT
1
Executive Summary
• For EHR-S FIM Release 2.1, this project has the purpose to
1) add core information models for each EHR-S FM 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 plan 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/activities,
dependencies, business rules, information & data
• 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/20/2015
DRAFT WORKING DOCUMENT
2
EHR-FIM
Legend
class Legend
Perspective
Activ ity associated w ith EHR-S Function
control flow
control flow
Task w ithin Activ ity
End Activity
Start Activity
depends on
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]()
system component 4
has-a
aggregation
is-a (type)
generalization
association
System Component 2
EHR-S Function
«trace»
FEAT URE:
EHR-S Function
depends on
FEAT URE 2
realization
"implements"
REQUIREMENT :
Conformance
Criteria
7/20/2015
DRAFT WORKING DOCUMENT
3
Description of Diagrams
The “Activities Mapped to System-Components” show
• Row 1: operational activities performed by the clinician, indicating
dependencies on
• Row 2: The EHR System components, which support the clinician’s
activities.
The “CIM Mapped to EHR-S Functions” show
• System Components for the EHR-S Function being analyzed, mapped
to the requisite System Components.
The Conceptual Data Model shows
• Attributes & operations for each System Component.
CDM Requirements-Traceability Shows
• Derivation of attributes and operations for each Component
7/20/2015
DRAFT WORKING DOCUMENT
4
Methodology
Sparx Enterprise Architect views were used to create a separate slide set for an
Immunization Management Capability based on the “See Also” Dependencies
of CP.6.2 Manage Immunization Administration (defined on “Prototype Scope”
Slide) following these steps:
1.
Create Component Traceability View for each EHR-S Function
•
•
•
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
–
–
2.
3.
Indicate SHALL attributes or operations as “public”
Indicate SHOULD or MAY attributes or operations as “private”
Create Conceptual Information Model view from step 1.
Create Conceptual Data Model view from step 1.
•
4.
Map EHR-S Components to supporting EHR-S Functions (“See Also” Dependencies)
Create Activity Model for the function.
•
Map Activities to EHR-S Components
This Executive Summary was created from the resultant model.
7/20/2015
DRAFT WORKING DOCUMENT
5
Immunization Management Capability
Prototype Scope
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
See separate slide deck
for each EHR-S Function
11. Trust Infrastructure
7/20/2015
DRAFT WORKING DOCUMENT
6
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 components and their relationships? … recommend informative
– Conceptual Data Models (many-to-many mappings from functions-to-components)
• Set of components and their data elements per EHR-S Function … 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 with other Functions conformance criteria
– Dependency relationship with derived EHR-S Function’s entities
3. How will we represent the Information Model for Ballot.
–
Tool generated Graphic representation (e.g., same as Immunization Prototype)
•
–
Textural listing of components and data elements similar to
•
•
7/20/2015
Will ISO accept this?
HITSP/C83 CDA Content Modules and
HITSP/C154 Data Dictionary
DRAFT WORKING DOCUMENT
7
Conclusions
• EHR-S FIM can be the conceptual foundation for Interoperability
Specifications, refined into:
– Logical Perspective
– Implementable Perspective
• Messages, Documents, Services
• EHR-S FIM can be composed into higher level capabilities by functional
analysts and system engineers
– Encourage reuse
– Avoid duplication and “stovepipe applications”
• EHR-S FIM can populate portions of SAIF for HL7 WGs
– Information and Computational Dimensions
– Conceptual Perspective
• An Enterprise Architecture tool is essential to maintain consistency
7/20/2015
DRAFT WORKING DOCUMENT
8
Immunization Management Capability
Models
•
•
•
•
•
•
•
•
CIM for Immunization Management Capability
CDM for Advanced Directive
CDM for Allergy, Intolerance and Adverse Reaction Event
CDM for Clinical Decision Support
CDM for Clinical Document or Note
CDM for Event for Lists
CDM for Immunization Event
CDM for Medication Event
CIM is Conceptual Information Model
CDM is Conceptual Data Model
7/20/2015
DRAFT WORKING DOCUMENT
9
Immunization Capability
Conceptual Information Model (CIM)
The Immunization Capability was modeled as a set of linkable events &
clinical information, documents-or-notes and lists linked into encounters.
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/20/2015
ia-a
is-a
Trust Infrastructure
DRAFT WORKING DOCUMENT
10
Advanced Directive
Conceptual Data Model (CDM)
class CDM Adv anced Directiv e
Document or Note
+
+
+
+
+
+
+
authenti cator
author
date
faci l i ty
pati ent
type
status
+
+
+
+
render()
capture()
update()
tag()
i s-a
has-a
Adv anced
Directiv e Rev iew
-
ci rcumstances
date
revi ewer
Adv anced
Directiv e Author
-
date si gned
name
rel ati onshi p
ti me si gned
Adv anced Directiv e Type Enumeration
-
Do Not Recusi tate (DNR) Order
Durabl e Power of Attorney
Li vi ng Wi l l
other
Preferred Interventi ons for Known Condi ti ons
7/20/2015
Clinical Document or
Note
Ev ent
-
di sposi ti on
si gnature
structured :bool ean
+
+
manage()
render()
tag()
0..*
0..*
Adv anced Directiv e Ev ent
+
+
+
+
+
+
+
+
+
+
+
+
advanced di recti ve captured :bool ean
person compl eti ng AD
rel ati onshi p to pati ent
ci rcumstances (of recei pt)
ci rcumstances (of revi ew)
date (recei ved)
date (reci nded)
date (revi ew)
date (si gned/compl eted)
date (updated)
Revi ew
type
DRAFT WORKING DOCUMENT
i s-a
Adv anced
Directiv e
document or note
11
Advanced Directive
Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
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/20/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
document or note
CPS.1.7.2#05
CPS.1.7.2#04
12
Allergy, Intolerance and Adverse Reaction Event
Conceptual Data Model (CDM)
class Allergy, Intolerance and Adv erse Reaction ...
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
+
+
+
deactivate()
justify()
manage()
is-a
Clinical
Information
-
7/20/2015
type
Allergy, Intolerance
and Adv erse
Reaction Ev ent
-
data of review
reaction type
severity
type
+
manage()
DRAFT WORKING DOCUMENT
13
Clinical Decision Support
Conceptual Data Model (CDM)
class CDM Clinical Decision Support (CDS)
T here are many CDS
conformance criteria,
within non-CDS
functions; but, there is
NO CDS function!
CDS-Clinical Decision
Support
-
maintain()
Ev ent
is-a
CDS Update
-
date (update)
version
-
manage()
CDS Content
7/20/2015
DRAFT WORKING DOCUMENT
CDS Rules
14
Clinical Document or Note
Conceptual Data Model (CDM)
class CDM Clinical Document or Note
Document or Note
Document or Note Type Enumeration
-
addenda
original
updated by amendment in order to correct
Clinical Document or
Note Disposition
Enumeration
-
future follow-up
recall patient
reviewed and files
Clinical Document or
Note Type Enumeration
«enum»
+ original
+ addenda
+ update
+
+
+
+
+
+
+
authenticator
author
date
facility
patient
type
status
+
+
+
+
render()
capture()
update()
tag()
Document or Note
Status Enumeration
-
final
preliminary
signed
is-a
Clinical Document or
Note
-
disposition
signature
structured :boolean
+
+
manage()
render()
tag()
Template
-
type
is-a
Adv anced
Directiv e
document or note
7/20/2015
DRAFT WORKING DOCUMENT
Unstructured
Document
15
Event
Conceptual Data Model (CDM)
class CDM Ev ent
Person-Role
-
person identifier
role
Clinical Document or
Note
-
disposition
signature
structured :boolean
- manage()
+ render()
+ tag()
Ev ent-Status
Enumeration
-
active
completed
deactive
erroneously captured
pending
7/20/2015
Clinical
Information
Ev ent
1..*
1..*
+
+
-
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
type
Demographic
Information
-
date & Time
identifier
location
Demographic
Information
(structured)
Trigger
Enumeration
-
drug
environment
food
other
DRAFT WORKING DOCUMENT
-
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
16
Lists
Conceptual Data Model (CDM)
class CDM Lists
Ev ent
+
+
+
+
+
7/20/2015
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()
List
has-a
0..* -
define sort restrictions()
define sort criteria()
filter()
link to problem-treatment()
manage()
manage reason for change ()
sort()
ia-a
Immunization
is-a
List
+
+
is-a
Medication
List
Patients Requiring
Follow up List
analyze()
manage()
Problem List
Allergy, Intolerance
and Adv erse
Reaction List
DRAFT WORKING DOCUMENT
17
Immunization Event
Conceptual Data Model (CDM)
class CDM Immunization Ev ent
Immunization Ev ent
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
+
+
+
deactivate()
justify()
manage()
is-a
+
+
+
Immunization
date (recommended booster)
Schedule
dose
educational information received :boolean
+ manage()
encounter
future booster
healthcare organization
immunization order
0..*
Immunization Future
immunization provider
Booster
immunization type
justification-immunization refusal
0..*
immunization type
lot
recommended date
manufacturer
ordered immunization due date
receipt of immunization preference
receiving entity (educational information)
health care
refusal of vaccine type
organisation
route of administration
time (administration)
type
series (immunization)
is-a
Immunization Witheld Ev ent
+
+
7/20/2015
exception reason
withholding provider
DRAFT WORKING DOCUMENT
18
Medication Event
Conceptual Data Model (CDM)
class CDM Medication 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
+
+
+
deactivate()
justify()
manage()
is-a
-
date of discontinuation
date of end
date of review
date of start
dispensing information
dose
formulation
instructions
interaction checking done :boolean
interactions indicated
justification
medication administration information
name
order date
pharmacist change information
potential interaction
prescriber
route
SIG
source
type
dispensing
information
Attributes
- medication order
- non-prescription
- prescribed
- previously unreported
association
«enumeration»
Medication Source
Enumeration
Medication
Administration
Information
-
administrator
date
dose
exceptions
medication name
route
time
Attributes
- erroneously captured
- patient
- patient history
Pharmacist's
Change
Information
Medication
Potential
Interaction
-
7/20/2015
«enumeration»
Medication Type
Enumeration
Medication Ev ent
Ev ent
date
time
DRAFT WORKING DOCUMENT
19
Reference Information
• EHR-S FIM Verb Hierarchy
• Observations by reviewers
7/20/2015
DRAFT WORKING DOCUMENT
20
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/20/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
21
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/20/2015
DRAFT WORKING DOCUMENT
22
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/20/2015
DRAFT WORKING DOCUMENT
23
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/20/2015
DRAFT WORKING DOCUMENT
24
CP.6.2 Immunization Management
“See Also” Dependencies
DRAFT WORKING DOCUMENT
7/20/2015
RED: delete, Blue: insert
25
EHR-S FIM Immunization Management Prototype Status
L
A
S
t
C
C
Notional
Scenario
CP.6.2 Manage Immunization Administration
2/11
X
X
X
X
X
X
X
CP.1.6 Manage Immunization List
2/11
X
X
X
X
X
√
X
CP.1.2 Manage Allergy, Intolerance and Adverse
Reaction List
2/11
√
√
√
√
√
√
√
CP.1.3 Manage Medication List
2/11
X
X
X
X
X
X
X
CP.3.3 Manage Clinical Documents and Notes
2/11
√
√
√
√
√
√
√
CPS.1.7.2 Manage Patient Advance Directives
2/11
X
X
X
X
X
X
X
CP.3.3 Manage Clinical Documents and Notes
2/11
√
√
√
√
√
√
√
CPS.3.9 Clinical Decision Support System
Guidelines Updates
2/11
√
√
√
√
√
√
√
CPS.9.4 Standard Report Generation
2/11
√
√
√
√
√
√
√
AS.4.1 Manage Registry Communication
2/11
√
√
√
√
√
√
√
EHR-S Function
Act CIM CDM RT
See
Also
√ = first draft done, X = Peer reviewed by WG
CC=Conformance Criteria, Act=Activity Diagram, CIM=Conceptual Information Model, CDM=Conceptual
7/20/2015 Data Model, RT-A=Requirements Trace to Activities, RT-D=Requirements trace to Data
26