Top Banner
EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688 EHR-S FIM Immunization Capability Executive Summary [email protected] , EHR WG facilitator [email protected] , DoD PointofContact February 9, 2012 – Original March 1, 2012 – Last Update 3/1/2012 DRAFT WORKING DOCUMENT 1 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
43

EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Jul 12, 2015

Download

Health & Medicine

Ed Dodds
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype

HL7 Project ID# 688

EHR-S FIM Immunization CapabilityExecutive Summary

[email protected] , EHR WG [email protected] , DoD Point‐of‐Contact

February 9, 2012 – Original  March 1, 2012 – Last Update

3/1/2012 DRAFT WORKING DOCUMENT 1

Call for ParticipationThis 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

Page 2: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Executive Summary For EHR-S FIM Release 2.1, this prototype had 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 demonstration3) Support specific profiles (e.g., WG project DAMs, DIMs, DCMs).

The plan is to use the Sparx Enterprise Architect 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 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. 3/1/2012 DRAFT WORKING DOCUMENT 2

Page 3: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

EHR‐S FM Release 2.0 Sections

• Overarching (O) – reference to Record and Trust Infrastructure• 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

3/1/2012 DRAFT WORKING DOCUMENT 3

Page 4: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

CP.6.2 Manage Immunization Administration

3/1/2012 DRAFT WORKING DOCUMENT 4

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 provider. 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.

RED: Recommend deletion, Blue:  Recommended Insertion

Page 5: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Immunization Management Capability Models

1. CP.6.2 Clinician-Activities Mapped-to System-Components2. CP.6.2 Conceptual Information Model (CIM) Mapped to EHR-S Functions3. CIM for Immunization Management Capability4. Immunization Management Information Exchanges Mapped-to Conformance Criteria (CC) 5. CDM for Advanced Directive6. CDM for Allergy, Intolerance and Adverse Reaction Event7. CDM for Clinical Decision Support (CDS)8. CDM for Clinical Document or Note9. CDM for Event 10. CDM for Lists11. CDM for Immunization Event

3/1/2012 DRAFT WORKING DOCUMENT 5

CIM is Conceptual Information ModelCDM is Conceptual Data Model

Page 6: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

EHR‐FIMModel Legend

3/1/2012 DRAFT WORKING DOCUMENT 6

class Legend

Clin

icia

n Pe

rspe

ctiv

e Activ ity associated with EHR-S Function

Task within Activ ity

EHR

-S C

ompo

nent

EHR-

S

Func

tion

System Component

+ attribute 2 [SHALL CC]- attribute 1 [SHOULD or MAY CC]

+ operation [SHALL CC]()- operation 2 [SHOULD or MAY CC]()

FEATURE: EHR-S Function

REQUIREMENT: Conformance Criteria

FEATURE 2

Start Activity End Activity

System Component 2

Syatem Component 3 system component 4

is-a (type)generalization

has-aaggregation

association

control flowcontrol flow

depends on

depends on

realization"implements"

«trace»

depends on

Page 7: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Description of Model Diagrams

The “Clinician-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 mapped to the defining EHR-S Functions

The Conceptual Data Model shows• Attributes & operations for each System Component.

The “Information Exchanges Mapped-to Conformance Criteria” show• Basis for information exchanges

CDM Requirements-Traceability Shows• Derivation of attributes and operations for each Component

3/1/2012 DRAFT WORKING DOCUMENT 7

Page 8: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

CP.6.2 Manage Immunization AdministrationClinician‐Activities  Mapped‐to  EHR‐S Components

3/1/2012 DRAFT WORKING DOCUMENT 8RED: delete, Blue: insert

act CP.6.2 ACT Manage Immunization Administration

CP.6.2 Manage Immunization Administration

Manage Ev ents

Manage Documents &

Notes

Manage Records Manage Trusts

Start End

Manage Immunization

Schedules

Manage Reports

Manage Business Rules

Manage Terminology

Ev ent Immunization Schedule

Allergy, Intolerance and

Adv erse Reaction Ev ent

Document or Note

Terminology Report

Immunization ListRegistry -

Immunization (Public Health)

EH

R-S

Com

pone

nts

Clin

icia

nE

ncou

nter

Manage Lists

List

Manage Regestries

Registry

Adv anced Directiv e

Clinical Document or NoteImmunization Ev ent

Adv anced Directiv e Ev ent

is-a

is-a is-a

is-a

depends on depends on depends on

ia-ais-a

Page 9: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

3/1/2012 DRAFT WORKING DOCUMENT 9

CP.6.2 Manage Immunization AdministrationEHR-S Components Mapped to Supporting Functions

class CP.6.2 CIM Manage Immunization Administration

Ev ent

Immunization Ev entImmunization

History

Immunization List

Allergy, Intolerance and Adv erse Reaction Ev ent

Terminology

Immunization Registry (Public

Health)

Record InfrastructureTrust Infrastructure

CP.6.2 Manage Immunization Administration

CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

CP.1.6 Manage Immunization List

CP, CPS & AS

CPS.1.7.2 Manage Patient Advance Directives

CP.3.2 Manage Patient Clinical Measurements

CPS.9.4 Standard Report Generation

AS.4.1 Manage Registry Communication

Report

Adv anced Directiv e document or note

Encounter

Registry

List

Document or Note

Clinical Document or Note

RED: delete, Blue: insert

Page 10: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Immunization Management CapabilityConceptual Information Model (CIM) 

3/1/2012 DRAFT WORKING DOCUMENT 10

class CIM Immunization Management Capability

Ev ent

Immunization Ev ent

Immunization History

Immunization List

Allergy, Intolerance and Adv erse

Reaction Ev ent

Immunization Schedule

List

Clinical Information

Allergy, Intolerance and Adv erse Reaction List

Medication List

Patients Requiring Followup List

Encounter

Medication Ev ent

Registry

Report Clinical Document or Note

Document or Note

Adv anced Directiv e

document or note

Adv anced Directiv e Ev ent

Reminder or Alert

CDS Update

Immunization Witheld Ev ent

EHR SystemRegistry - Immunization (Public Health)

Medical Dev ice

TerminologyTemplateProblem List

CDS-Clinical Decision Support

Clinical and Clinical Support System Components

Record Infrastructure Trust Infrastructure

is-ais-a is-a

0..*

is-a

0..*has-a

0..*

1..*

has-a

is-a

has-a

is-a

ia-ais-a is-ais-a

is-a

is-a

Page 11: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

3/1/2012 DRAFT WORKING DOCUMENT 11

Immunization Management Capability Information Exchanges Mapped-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_Interop

erability_WG

class CP.6.2 IE Manage Immunization Administration

EHR System

- reminders or alerts

+ manage()+ Manage 'Do Not Recusitste"()

Medical Dev ice

Registry - Immunization (Public Health)

Registry

- clinical information- demographic information- organization (source)- patient- provider (source)- type

- manage()

AS.4.1#01AS.4.1#02 AS.4.1#03

AS.4.1#04

AS.4.1#05

Demographic Information (structured)

CP.3.3#07

is-a

other EHRSystems

Page 12: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

3/1/2012 DRAFT WORKING DOCUMENT 12

Immunization Management Information ExchangeConformance Criteria (CC) Applicable to Information Exchange

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.

Page 13: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

class RT Adv anced Directiv e

Adv anced Directiv e Ev ent

+ advanced directive captured :boolean+ person completing AD+ relationship to patient+ circumstances (of receipt)+ circumstances (of review)+ date (received)+ date (recinded)+ date (review)+ date (signed/completed)+ date (updated)+ Review+ type

CPS.1.7.2#01

CPS.1.7.2#02

CPS.1.7.2#03

CPS.1.7.2#06

CPS.1.7.2#07

CPS.1.7.2#08

Advanced Directiv e Type Enumeration

- Do Not Recusitate (DNR) Order- Durable Power of Attorney- Living Will- other- Preferred Interventions for Known Conditions

Advanced Directiv e Rev iew

- circumstances- date- reviewer

Adv anced Directiv e Author

- date signed- name- relationship- time signed

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()

Document or Note

+ authenticator+ author+ date+ facil ity+ patient+ type+ status

+ render()+ capture()+ update()+ tag()

CP.3.3#02

CP.3.3#03

CP.3.3#08

CP.3.3#09

CP.3.3#10

CP.3.3#11

Clinical Document or Note

- disposition- signature- structured :boolean

- manage()+ render()+ tag()

Adv anced Directiv e

CPS.1.7.2#04

CPS.1.7.2#05

CP.3.3#01

CP.3.3#04

CP.3.3#05

CP.3.3#07

CP.3.3#12

CP.3.3#14

CP.3.3#15

CP.3.3#16

CP.3.3#17

CP.6.2#02

CP.6.2#06

has-a

0..*

0..*

is-a

is-a

Advanced DirectiveConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 13

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

Page 14: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Advanced DirectiveConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 14

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 jurisdictionaCP.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.

Page 15: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Advanced Directive Allergy, Intolerance and Adverse Reaction EventConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 15

class RT Allergy, Intolerance and Adv erse Reaction Ev ent

Allergy, Intolerance and Adv erse

Reaction Ev ent

- data of review- reaction type- severity- type

+ manage()

Ev ent

+ date (occurence)+ time (occurence)- change justification- circumstances- cl inical information- date (entry)- date (review)- description- duration- information reviewed- information source- information validator- location- mechanism- metadata- person-role- status- trigger- type

+ deactivate()+ justify()+ manage()

Clinical Information

- type

CP.1.2#25

CP.1.2#01

CP.1.2#02

CP.1.2#03

CP.1.2#04

CP.1.2#07

CP.1.2#13

CP.1.2#16

CP.1.2#17

CP.1.2#18

CP.1.2#19

CP.1.2#21

CP.1.2#22

CP.1.2#24

CP.1.2#26

CP.6.2#04

CP.6.2#09

is-a

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

Page 16: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Advanced Directive Allergy, Intolerance and Adverse Reaction EventConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 16

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).

Page 17: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

class RT Clinical Decision Support (CDS)

CDS-Clinical Decision Support

- maintain()

CDS RulesCDS Content

CDS Update

- date (update)- version

- manage()

CPS.3.9#01

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()

CPS.3.9#02

CPS.3.9#03

CPS.3.9#04

is-a

Clinical Decision SupportConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 17

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

Page 18: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Clinical Decision SupportConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 18

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.

Page 19: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

class RT Clinical Document or Note

Clinical Document or Note

- disposition- signature- structured :boolean

- manage()+ render()+ tag()

Document or Note

+ authenticator+ author+ date+ facili ty+ patient+ type+ status

+ render()+ capture()+ update()+ tag()

Unstructured Document

Template

- type

Document or Note Status Enumeration

- final- preliminary- signed

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

CP.3.3#03

CP.3.3#07

CP.3.3#10

CP.3.3#11

CP.3.3#12

CP.3.3#16

CP.3.3#17

CP.6.2#02

CP.6.2#06

CPS.1.7.2#05

Clinical Document or Note Type Enumeration

«enum»+ original+ addenda+ update

Adv anced Directiv e

CP.3.3#01

CP.3.3#02

CP.3.3#04

CP.3.3#05

CP.3.3#08

CP.3.3#09

CP.3.3#14

CP.3.3#15

CPS.1.7.2#04

CPS.1.7.2#01

CPS.1.7.2#03

is-a

is-a

Clinical Document or NoteConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 19

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

Page 20: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Clinical Document or NoteConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 20

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 jurisdictionaCP.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.

Page 21: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

EventConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 21

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

class RT Event

Ev ent

+ date (occurence)+ time (occurence)- change justification- circumstances- cl inical information- date (entry)- date (review)- description- duration- information reviewed- information source- information validator- location- mechanism- metadata- person-role- status- trigger- type

+ deactivate()+ justify()+ manage()

Clinical Document or Note

- disposition- signature- structured :boolean

- manage()+ render()+ tag()

Clinical Information

- type

Person-Role

- person identifier- role

Ev ent Type Enumeration

- advanced directive- adverse reaction- al lergy- CDS Alerts- CDS reminders- CDS update- clinical document or note- discharge- encounter- intolerance- medication (pharmacist change)- medication (prescription dispensing)- medication (prescription fi l l ing)- medication history received (external source)- order- other- procedure- registry- reminders & alerts- report- surgical- transfer

Trigger Enumeration

- drug- environment- food- other

AS.4.1#02

CP.1.2#25

CP.1.2#14

CP.1.2#15

CP.1.3#05

CP.1.3#08

CP.1.3#10

CP.1.3#13

CPS.3.9#04

Ev ent-Status Enumeration

- active- completed- deactive- erroneously captured- pending

Demographic Information (structured)

Terminology

- code set

+ manage()

Demographic Information

- date & Time- identifier- location

CP.1.6#02

1..*1..*

Page 22: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

EventConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 22

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 administrationCP.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.

Page 23: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

class RT List

List

- define sort restrictions()- define sort criteria()- fi l ter()- l ink to problem-treatment()- manage()- manage reason for change ()- sort()

Immunization List

+ analyze()+ manage()

Allergy, Intolerance and Adv erse Reaction List

CP.1.2#11

CP.1.2#12

CP.1.4#08

CP.3.3#06

CP.3.3#18Medication List

Patients Requiring Followup List

ia-a

is-a

is-a

ListsConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 23

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

Page 24: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

ListsConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 24

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).

Page 25: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Immunization EventConceptual Data Model (CDM) Traceable to Conformance Criteria (CC)

3/1/2012 DRAFT WORKING DOCUMENT 25

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

class RT Immunization Ev ent

Immunization Ev ent

+ 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

health care organisation

Immunization Witheld Ev ent

+ exception reason+ withholding provider

Encounter

- differential diagnosis- disposition- follow up activities- follow up needed :boolean- follow up results- type

+ manage()

Immunization Future Booster

- immunization type- recommended date

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()

CP.1.6#02

CP.1.6#03 CP.1.6#05

CP.6.2#01

CP.6.2#02

CP.6.2#05

CP.6.2#06

CP.6.2#10

CP.6.2#16

CP.6.2#17

CP.6.2#18

CP.6.2#19

CP.6.2#20

CP.6.2#21

CP.6.2#22

CP.6.2#23

CP.1.2#13

CP.1.2#20

CP.3.3#12

CP.3.3#13

CP.3.3#18

CP.3.3#19

CP.6.2#03

CPS.3.9#04

0..*

0..*

1..*

has-a

is-a

is-a

Page 26: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Immunization EventConformance Criteria (CC) Applicable to This Component

3/1/2012 DRAFT WORKING DOCUMENT 26

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 administrationCP.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 numbCP.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 jurisdictionaCP.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.

Page 27: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

MethodologySparx Enterprise Architect views were used to create a separate slide set for an Immunization Management Capability based on of CP.6.2 Manage Immunization Administration and its “See Also” Dependencies (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

– Indicate SHALL attributes or operations as “public” with a preceeding “+”– Indicate SHOULD or MAY attributes or operations as “private” with a preceeding “‐”

2. Create Conceptual Information Model (CIM) view from step 1.3. Create Conceptual Data Model (CDM) view from step 1.

• Map EHR‐S Components to supporting EHR‐S Functions (“See Also” Dependencies)

4. Create Activity Model for the function.• Map Activities to EHR‐S Components

5. Create Information Exchanges Mapped‐to Conformance CriteriaThis Executive Summary was created from the resultant model. 

3/1/2012 DRAFT WORKING DOCUMENT 27

Page 28: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Issues1. 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)

• Will ISO accept this?

– Textural listing of components and data elements similar to • HITSP/C83 CDA Content Modules and • HITSP/C154 Data Dictionary

3/1/2012 DRAFT WORKING DOCUMENT 28

Page 29: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Recommendations

• EHR-S FIM needs the following additional functions and components:1. Manage Business Rules 2. Clinical Decision Support (CDS)

• Make EHR-S Conceptual Data Model (CDM) Normative1. Remove data elements (e.g., component attributes) from conformance criteria.

• EHR-S FM CP-section should be hierarchically organized. 1. an EHR-S managing encounters; where, 2. each encounters are sets of events, documents and lists. 3. Finally, events, documents and lists are decomposed into types.4. Benefits:

• Reduced conformance criteria duplication• Increased conformance criteria consistency

3/1/2012 DRAFT WORKING DOCUMENT 29

Page 30: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

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

3/1/2012 DRAFT WORKING DOCUMENT 30

Page 31: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Next Steps / To Do / Help Needed

• SMEs verify and validate Conceptual Data Models (CDMs)• Do the remaining EHR-S Functions

– Overarching (O) – reference to Record and Trust Infrastructure– Care Provision (CP) - 9 header areas– Care Provision Support (CPS) – 9 header areas– Population Health Support (POP) – 10 header areas– Administrative Support (AS) – 9 header areas– Record Infrastructure (RI) – 3 header areas– Trust Infrastructure (TI) – 9 header areas

3/1/2012 DRAFT WORKING DOCUMENT 31

Page 32: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Reference Information

• Glossary of Key Terms• HL7 SAIF Enterprise Compliance and Conformance Framework (ECCF)• EHR-S FIM Verb Hierarchy• Observations by reviewers• Backup Slides

EHR-S FM R2 ballot package can be downloaded at:http://wiki.hl7.org/index.php?title=December_2011_Ballot_Package

3/1/2012 DRAFT WORKING DOCUMENT 32

Page 33: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

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:

– 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.

3/1/2012 DRAFT WORKING DOCUMENT 33

Page 34: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

EHR‐S FIMAction Verb Hierarches

3/1/2012 DRAFT WORKING DOCUMENT 34

Manage (Data)Capture Maintain Render Exchange Determine

Manage-Data-

VisibilityAuto‐PopulateEnterImportReceive

Store Update Remove Extract Present Transmit ExportImportReceiveTransmit

Analyze Decide De-IdentifyHideMaskRe-IdentifyUnhideUnmask

ArchiveBackupDecryptEncryptRecoverRestoreSave

AnnotateAttestEditHarmonizeIntegrateLinkTag

DeletePurge

Page 35: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Notional Set of HL7 Artifacts within a SAIF Enterprise Compliance and Conformance Framework (ECCF)

35

Business • Mission, • Vision, • Scope ,

Inventory of• Contracts - PSSs• Capabilities - RIM• Policies• Procedures

Enterprise Dimension“Why” - Policy

Business Policies Governance Implementation Guides Design Constraints Organization Contracts

Business Nodes Business Rules Business Procedures Business Workflows Technology Specific

Standards

Inventory of Reusable• Entities • Associations• Information

Information Models Data Models

Information Dimension“What” - Content

Information Models• Domain IM• Detailed Clinical

Terminologies Value Sets Content Specifications

• CCD• RMIM

Schemas for• Databases • Messages • Documents• Services • Transformations

Inventory of Reusable• Scenarios• Business Activities• System Functions

Requirements• Accountability, Roles• Conformance Criteria• Profiles, Behaviors• Interactions and• Info. Exchanges

Computational Dimension

“Who/How” - Behavior

Specifications• Scenario Events• Use Cases• Workflow Use Cases• Components

Interfaces Collaboration Actors

• Collaboration Types• Collaboration Roles

Function Types Interface Types Service Contracts

Automation Units Technical Interfaces Technical OperationsOrchestration Scripts

Inventory of• SW Platforms, Layers• SW Environments• SW Components• SW Services• Technical

Requirements• Enterprise Service Bus

Key Performance Parameters

Engineering Dimension

“Where” - Implementation

Models, Capabilities, Features and Versions for• SW Environments• SW Capabilities• SW Libraries• SW Services• SW Transports

SW Specifications for• Applications• GUIs• Components

SW Deployment Topologies

Inventory of• HW Platforms• HW Environments• Network Devices• Communication

Devices Technical Requirements

Technical Dimension

“Where” - Deployments

Models, Capabilities, Features and Versions for• HW Platforms• HW Environments• Network Devices• Communication

Devices

HW Deployment Specifications

HW Execution ContextHW Application BindingsHW Deployment TopologyHW Platform Bindings

Conceptual Perspective

ECCF

Logical Perspective

Implementable Perspective

Responsibility: HL7 Organization | EHR-S FIM | HL7 WG Projects | Development OrganizationSee notes page for ECCF description

Page 36: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

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.

3/1/2012 DRAFT WORKING DOCUMENT 36

Page 37: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

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 Concernpattern 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.

3/1/2012 DRAFT WORKING DOCUMENT 37

Page 38: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

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.

3/1/2012 DRAFT WORKING DOCUMENT 38

Page 39: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Immunization Management CapabilityScope, (Including Dependent EHR‐S Functions)

We started with CP6.2 and included its dependencies:1. CP.6.2 Manage Immunization Administration2. CP.1.6 Manage Immunization List3. CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List 4. CP.1.3 Manage Medication List5. CP.3.3 Manage Clinical Documents and Notes6. CPS.1.7.2 Manage Patient Advance Directives7. CPS.3.9 Clinical Decision Support System Guidelines Updates8. CPS.9.4 Standard Report Generation9. AS.4.1 Manage Registry Communication10. Record Infrastructure11. Trust Infrastructure

3/1/2012 DRAFT WORKING DOCUMENT 39

For details, see separate slide deck for each EHR‐S Function.All referenced EHR‐S Functions are available at: 

http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG

Page 40: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

3/1/2012 DRAFT WORKING DOCUMENT 40

CP.6.2 Manage Immunization AdministrationComponents mapped to Requirements

req CP.6.2 RT Manage Immunization Administration

Immunization History

+ render()- harmonize()- capture()- exchange()- update()

Immunization List

+ analyze()+ manage()

Allergy, Intolerance and Adv erse Reaction Ev ent

- data of review- reaction type- severity- type

+ manage()

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.

CP.6.2#03 The system SHALL provide the abil ity to determine and render required immunizations, and when they are due, based on widely accepted immunization schedules, when rendering encounter information.

CP.6.2#04 The system SHOULD provide the abil ity to capture, in a discrete field, an allergy/adverse reaction to a specific unization.

CP.6.2#07 The system SHALL provide the abil ity to maintain the immunization schedule.

CP.6.2#08 The system SHALL provide the abil ity to render a patient‘s immunization history upon request for appropriate authorities such as schools or day-care centers.

CP.6.2#09 The system SHALL conform to function CP.1.2 (Manage Allergy, Intolerance and Adverse Reaction List).

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.

CP.6.2#13 The system SHOULD capture and render immunization histories from a public health immunization registry.

CP.6.2#14 The system SHALL conform to function CP.1.6 (Manage Immunization List).

CP.6.2#15 The system SHOULD provide the abil ity to update immunization histories at the time of capturing an immunization administration.

CP.6.2#17 The system SHALL provide the abil ity to determine due and overdue ordered immunizations and render a notification.

Immunization Schedule

+ manage()

List

- define sort restrictions()- define sort criteria()- fi l ter()- l ink to problem-treatment()- manage()- manage reason for change ()- sort()

CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

CP.1.6 Manage Immunization List

Registry - Immunization (Public Health)

Encounter

- differential diagnosis- disposition- follow up activities- follow up needed :boolean- follow up results- type

+ manage()

depends on

depends on

0..*

depends on

is-a

ia-a

dependson

NOTE: SHALL conformance criteria have bolded borders

Page 41: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

req CP.6.2 RT Manage Immunization Administration

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()

Immunization Ev ent

+ date (recommended booster)- dose- educational information received :boolean- encounter- future booster- healthcare organization- immunization order- immunization provider+ immunization type- 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+ series (immunization)

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#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 abil ity to l ink 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 abil ity to render the immunization order as written (i.e., exact clinician order language) when rendering administration information.

CP.6.2#18 The system SHALL provide the abil ity to render a patient educational information regarding the administration (e.g., Vaccine Information Statement (VIS)).

CP.6.2#19 The system SHALL provide the abil ity 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 abil ity 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 abil ity 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 abil ity to capture and maintain immunization refusal reasons as discrete data.

CP.6.2#23 The system SHOULD provide the abil ity to capture patient preferences regarding receipt of immunization (e.g. refusal of certain vaccine types) at time of immunization administration.

CP.3.2 Manage Patient Clinical Measurements

Terminology

- code set

+ manage()

Medication Administration?

is-a

3/1/2012 DRAFT WORKING DOCUMENT 41

CP.6.2 Manage Immunization AdministrationComponents mapped to Requirements

NOTE: SHALL conformance criteria have bolded borders

Page 42: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

Immunization Management CapabilityCP.6.2 Manage Immunization Administration Dependencies

3/1/2012 DRAFT WORKING DOCUMENT 42

class CP.6.2 DEP Manage Immunization Administration

CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

CP.1.6 Manage Immunization List

CP.6.2 Manage Immunization Administration CPS.1.7.2 Manage Patient

Advance Directives

CPS.9.4 Standard Report Generation

AS.4.1 Manage Registry Communication

Record Infrastructure

+ RI.1 Record Lifecycle and Lifespan+ RI.2 Record Synchronization+ RI.3 Record Archive and Restore

Trust Infrastructure

+ TI.1 Security+ TI.2 Audit+ TI.3 Registry and Directory Services+ TI.4 Standard Terminology and Terminology Services+ TI.5 Standards-Based Interoperabil ity+ TI.6 Business Rules Management+ TI.7 Workflow Management+ TI.8 Database Backup and Recovery+ TI.9 System Management Operations and Performance

CP, CPS & AS

CP.3.2 Manage Patient Clinical Measurements

depends on

depends ondepend on

depends on

Page 43: EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688

CP.6.2 Immunization Management“See Also” Dependencies

3/1/2012DRAFT WORKING DOCUMENT

43RED: delete, Blue: insert

class CP.6.2 DEP-2 Manage Immunization Administration

CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

CP.1.3 Manage Medication List

CP.1.6 Manage Immunization List

CP.1.8 Manage Patient and Family Preferences

CP.6.2 Manage Immunization Administration

CPS.1.7.2 Manage Patient Advance Directives

CPS.3.9 Clinical Decision Support System Guidelines Updates

CPS.9.4 Standard Report Generation AS.4.1 Manage Registry

Communication

CPS.4.2 Support for Medication and Immunization Ordering

CPS.9.5 Ad Hoc Query and Rendering

CPS.9.3 Health Record Output

CP.3.3 Manage Clinical Documents and Notes

CPS.1.7.3 Manage Consents and Authorizations

CPS.1.6.1 Related by Genealogy

CPS.1.6.3 Related by Living Situation

CPS.1.6.4 Related by Other Means

Record Infrastructure

+ RI.1 Record Lifecycle and Lifespan+ RI.2 Record Synchronization+ RI.3 Record Archive and Restore

Trust Infrastructure

+ TI.1 Security+ TI.2 Audit+ TI.3 Registry and Directory Services+ TI.4 Standard Terminology and Terminology Services+ TI.5 Standards-Based Interoperability+ TI.6 Business Rules Management+ TI.7 Workflow Management+ TI.8 Database Backup and Recovery+ TI.9 System Management Operations and Performance

CP, CPS & AS

CP.3.2 Manage Patient Clinical Measurements

depend on