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

2,106 views

Published on

Stephen.Hufnage.ctrl@tma.osd.mil , EHR WG facilitator
Nancy.Orvis@tma.osd.mil , DoD Point-of-Contact
February 9, 2012 – Original
March 1, 2012 – Last Update
3/1/2012 DRAFT WORKING DOCUMENT 1
Call for Participation, Executive Summary

Published in: Health & Medicine, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,106
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
46
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype HL7 Project ID# 688 EHR-S FIM Immunization Capability Executive Summary Stephen.Hufnage.ctrl@tma.osd.mil , EHR WG facilitator Nancy.Orvis@tma.osd.mil , DoD Point‐of‐Contact February 9, 2012 – Original   March 1, 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_WG3/1/2012 DRAFT WORKING DOCUMENT 1
  2. 2. Executive SummaryFor 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 demonstration 3) Support specific profiles (e.g., WG project DAMs, DIMs, DCMs).The plan is to use the Sparx Enterprise Architect modeling tool to represent theEHR-S FIM and then generate appropriate views, reports, XML and HTMLrenderings 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 ofdemonstration prototypes of increasing complexity.3/1/2012 DRAFT WORKING DOCUMENT 2
  3. 3. 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 subsections3/1/2012 DRAFT WORKING DOCUMENT 3
  4. 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 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.3/1/2012 RED: Recommend deletion, Blue:  Recommended Insertion DRAFT WORKING DOCUMENT 4
  5. 5. Immunization Management Capability  Models1. 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 Event10. CDM for Lists11. CDM for Immunization Event CIM is Conceptual Information Model CDM is Conceptual Data Model3/1/2012 DRAFT WORKING DOCUMENT 5
  6. 6. EHR‐FIM Model Legendclass Legend linician Perspective Activ ity associated w ith EHR-S Function control flow Task w ithin Activ ity control fl ow Start Acti vi ty End Activi ty C depends on depends on EH -S C ponent Syatem Component 3 system component 4 System Component om + attri bute 2 [SHALL CC] - attri bute 1 [SHOULD or MAY CC] has-a i s-a (type) aggregati on generali zati on R + operati on [SHALL CC]() associ ati on - operati on 2 [SHOULD or MAY CC]() System Component 2 «trace» EH -S Function FEAT URE: depends on FEAT URE 2 EHR-S Functi on R real izati on "impl ements" REQUIREMENT : Conformance Cri teri a3/1/2012 DRAFT WORKING DOCUMENT 6
  7. 7. Description of Model DiagramsThe “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 FunctionsThe Conceptual Data Model shows• Attributes & operations for each System Component.The “Information Exchanges Mapped-to Conformance Criteria” show• Basis for information exchangesCDM Requirements-Traceability Shows• Derivation of attributes and operations for each Component3/1/2012 DRAFT WORKING DOCUMENT 7
  8. 8. CP.6.2 Manage Immunization Administration Clinician‐Activities  Mapped‐to  EHR‐S Componentsact CP.6.2 ACT Manage Immunization Administration Manage Records Manage Trusts Manage Business Rules depends on depends on depends on C lin ic ia n CP.6.2 Manage Immunization Administration Manage Manage Manage Manage Manage Manage Manage Ev ents Immunization Lists Documents & Start Terminology Regestries Reports End E n c o u n te r Schedules Notes Ev ent Immunization List Document Terminology Registry Report Schedule or Note E H R -S C o m p o n e n ts is-a is-a ia-a is-a is-a Registry - Allergy, Immunization Immunization List Clinical Document or Note Immunization Intolerance and Ev ent (Public Health) Adv erse is-a Reaction Ev ent Adv anced Directiv e Ev ent Adv anced Directiv e 3/1/2012 RED: delete, Blue: insert DRAFT WORKING DOCUMENT 8
  9. 9. CP.6.2 Manage Immunization Administration EHR-S Components Mapped to Supporting Functionsclass CP.6.2 CIM Manage Immunization Administration CP, CPS & AS Registry List Clinical Document or Note Document or Note Immunization Registry (Public AS.4.1 Manage Registry Health) Communication Encounter Immunization List Report Ev ent Terminology Adv anced Directiv e document or note CPS.9.4 Standard Immunization Allergy, Intolerance and Immunization Report Generation Ev ent Adv erse Reaction Ev ent History CPS.1.7.2 Manage Patient CP.3.2 Manage Patient Advance Directives 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 Infrastructure Record Infrastructure3/1/2012 RED: delete, Blue: insert DRAFT WORKING DOCUMENT 9
  10. 10. Immunization Management Capability Conceptual Information Model (CIM) class CIM Immunization Management Capability Clinical and Clinical Support System Components is-a Registry - Registry EHR System Medical Dev ice Immunization (Public Health) CDS-Clinical Decision Support Encounter Clinical has-a Information 0..* 1..* 0..* has-a has-a Document or Note Ev ent List 0..* is-a is-a is-a is-a is-a ia-a is-a is-a Report Clinical Document Medication Immunization Allergy, Intolerance Immunization Medication or Note Ev ent Ev ent and Adv erse List List Reaction Ev ent is-a is-a is-a Reminder Adv anced Adv anced Immunization Immunization CDS Allergy, Intolerance Immunization Patients Requiring or Alert Directiv e Directiv e Ev ent Schedule Witheld Ev ent Update and Adv erse History Follow up List document or note Reaction List Template Terminology Problem List Record Infrastructure Trust Infrastructure3/1/2012 DRAFT WORKING DOCUMENT 10
  11. 11. Immunization Management Capability Information Exchanges Mapped-to Conformance Criteria (CC)class CP.6.2 IE Manage Immunization Administration CP.3.3#07 AS.4.1#04 Medical Device EHR System Demographic Registry Information other EHR - reminders or alerts (structured) - clinical information Systems - demographic information + manage() - organization (source) SHALL CCs have  bolded borders.  + Manage Do Not Recusitste"() - patientSee individual EHR‐S  - provider (source)Function’s slide deck  - type for CC details at: http://wiki.hl7.org/index.php?title=EHR_Interop - manage() erability_WG is-a Registry - AS.4.1#02 AS.4.1#05 AS.4.1#03 AS.4.1#01 Immunization (Public Health)3/1/2012 DRAFT WORKING DOCUMENT 11
  12. 12. Immunization Management Information Exchange Conformance Criteria (CC) Applicable to Information ExchangeCP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment, prosthetic/orthotic devices, medications, and notes to one ormore 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 informations related assessment of validity orapplicability 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.3/1/2012 DRAFT WORKING DOCUMENT 12
  13. 13. Advanced Directive Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)class RT Adv anced Directiv e SHALL CCs have  Ev ent bolded borders.  CPS.1.7.2#03 + date (occurence) See individual EHR‐S  + time (occurence) CP.3.3#09 Function’s slide deck  - change justification - circumstances for CC details at:  - clinical information Document or Note CP.3.3#11 http://wiki.hl7.org/index. - date (entry) + authenticator - date (review) php?title=EHR_Interop - description + author CP.3.3#10 erability_WG - duration + + date facility - information reviewed has-a CP.3.3#02 + patient - information source + type - information validator + status - location CP.3.3#03 CP.6.2#02 - mechanism + render() - metadata + capture() CP.6.2#06 - person-role CP.3.3#08 + update() - status CPS.1.7.2#01 + tag() - trigger CP.3.3#05 - type is-a CP.3.3#07 + deactivate() + justify() Adv anced Directiv e Type Enumeration CP.3.3#14 + manage() - Do Not Recusitate (DNR) Order - Durable Power of Attorney Clinical Document or CP.3.3#15 - Living Will Note Adv anced Directiv e Ev ent - other CP.3.3#17 - disposition - Preferred Interventions for Known Conditions CPS.1.7.2#02 + advanced directive captured :boolean - signature + person completing AD - structured :boolean CP.3.3#04 + relationship to patient + circumstances (of receipt) Adv anced - manage() CPS.1.7.2#08 CP.3.3#12 + circumstances (of review) Directiv e Rev iew + render() + date (received) + tag() 0..* - circumstances CP.3.3#01 CPS.1.7.2#07 + date (recinded) - date Adv anced + date (review) 0..* is-a - reviewer Directiv e Author + date (signed/completed) CP.3.3#16 + date (updated) Adv anced CPS.1.7.2#06 - date signed + Review Directiv e - name CPS.1.7.2#05 + type - relationship - time signed CPS.1.7.2#043/1/2012 DRAFT WORKING DOCUMENT 13
  14. 14. Advanced Directive Conformance Criteria (CC) Applicable to This ComponentCP.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 patients 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 futurefollow-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, orlaboratory 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 timeaccording 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 forknown 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.3/1/2012 DRAFT WORKING DOCUMENT 14
  15. 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 SHALL CCs have  bolded borders.  Ev ent See individual EHR‐S  + date (occurence) Function’s slide deck  + ti me (occurence) for CC details at:  - change j usti fi cati on Clinical - ci rcumstances http://wiki.hl7.org/index. Information - cl i ni cal i nformati on php?title=EHR_Interop - type - date (entry) erability_WG - 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 CP.6.2#09 - mechani sm - metadata - person-rol e CP.1.2#04 CP.1.2#25 - status - tri gger - type CP.1.2#16 CP.1.2#07 + deacti vate() CP.1.2#17 + j usti fy() + manage() CP.1.2#02 CP.1.2#19 i s-a CP.1.2#01 Allergy, Intolerance CP.1.2#22 and Adv erse CP.1.2#03 Reaction Ev ent CP.1.2#24 - data of revi ew CP.1.2#18 - reacti on type - severi ty CP.1.2#13 CP.1.2#26 - type + manage() CP.1.2#21 CP.6.2#043/1/2012 DRAFT WORKING DOCUMENT 15
  16. 16. Advanced Directive Allergy, Intolerance and Adverse Reaction Event Conformance Criteria (CC) Applicable to This ComponentCP.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 oradverse 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 interactionswhen 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).3/1/2012 DRAFT WORKING DOCUMENT 16
  17. 17. Clinical Decision Support Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)class RT Clinical Decision Support (CDS) SHALL CCs have  Ev ent bolded borders.  + date (occurence) See individual EHR‐S  + ti m e (occurence) - change j usti fi cati on Function’s slide deck  - ci rcum stances for CC details at:  - cl i ni cal i nform ati on http://wiki.hl7.org/index. - - date (entry) date (revi ew) php?title=EHR_Interop - descri pti on erability_WG - durati on - i nform ati on revi ewed - i nform ati on source - i nform ati on val i dator - l ocati on CPS.3.9#04 - m echani sm - m etadata - person-rol e - status CDS-Clinical Decision - tri gger Support - type CPS.3.9#01 - m ai ntai n() + deacti vate() + j usti fy() + m anage() i s-a CDS Update CPS.3.9#03 - date (update) - versi on - m anage() CPS.3.9#02 CDS Content CDS Rules 3/1/2012 DRAFT WORKING DOCUMENT 17
  18. 18. Clinical Decision Support Conformance Criteria (CC) Applicable to This ComponentCPS.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.3/1/2012 DRAFT WORKING DOCUMENT 18
  19. 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 + authenti cator CPS.1.7.2#01 + author Document or Note Type Enumeration + date CP.3.3#11 + faci l i ty - addenda CP.3.3#10 + pati ent - ori gi nal + type - updated by am endm ent i n order to correct + status CP.3.3#02 Document or Note + render() CP.3.3#08 Status Enumeration + capture() + update() CP.3.3#09 - fi nal + tag() - prel i m i nary CP.3.3#03 - si gned i s-a Clinical Document or Template CP.3.3#04 Note Disposition - type Enumeration CP.3.3#16 - future fol l ow-up Clinical Document or CP.3.3#14 - recal l pati ent - revi ewed and fi l es Note CP.3.3#15 - di sposi ti on - si gnature Clinical Document or CP.6.2#06 - structured :bool ean Note Type Enumeration - m anage() CP.6.2#02 «enum » + render() + ori gi nal + tag() CP.3.3#07 + addenda + update CP.3.3#12 i s-a CP.3.3#05 Adv anced SHALL CCs have bolded borders.  Directiv e CP.3.3#17 See individual EHR‐S Function’s slide  Unstructured deck for CC details at:  Document CP.3.3#01http://wiki.hl7.org/index.php?title=EHR_Int eroperability_WG CPS.1.7.2#04 CPS.1.7.2#053/1/2012 DRAFT WORKING DOCUMENT 19
  20. 20. Clinical Document or Note Conformance Criteria (CC) Applicable to This ComponentCP.3.3#01 The system SHALL provide the ability to capture and render clinical documentation (henceforth "documentation") including original, update byamendment 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 patients 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-mailconsult, 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 ormore 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, authenticatorand 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 animmunization.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 advancedirective documents and/or “Do Not Resuscitate” orders.3/1/2012 DRAFT WORKING DOCUMENT 20
  21. 21. Event Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)class RT Ev ent SHALL CCs have  bolded borders.  Terminology Clinical Information See individual EHR‐S  - code set Function’s slide deck  Trigger - type Enumeration for CC details at:  + manage() - drug CP.1.3#08 http://wiki.hl7.org/index. - environment php?title=EHR_Interop - food erability_WG - other CP.1.3#13 Person-Role Ev ent Type Enumeration Ev ent CP.1.2#15 - person identifier 1..* 1..* - advanced directive - role + date (occurence) - adverse reaction Demographic + time (occurence) - allergy Information CP.1.2#25 - change justification - CDS Alerts - date & Time - circumstances - CDS reminders Clinical Document or - clinical information - identifier - CDS update Note - date (entry) CPS.3.9#04 - location - clinical document or note - disposition - date (review) - discharge - signature - description - encounter - structured :boolean - duration CP.1.2#14 - intolerance - information reviewed - medication (pharmacist change) - manage() - information source - medication (prescription dispensing) + render() - information validator - medication (prescription filling) CP.1.3#10 Demographic + tag() - location - medication history received (external source) Information - mechanism - order (structured) - metadata - other Ev ent-Status - person-role CP.1.3#05 - procedure Enumeration - status - registry - trigger - reminders & alerts - active - type AS.4.1#02 - report - completed - deactive - surgical + deactivate() - transfer - erroneously captured + justify() CP.1.6#02 - pending + manage() 3/1/2012 DRAFT WORKING DOCUMENT 21
  22. 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 informations related assessment of validity or applicability for clinical, financial or administrative activities.3/1/2012 DRAFT WORKING DOCUMENT 22
  23. 23. Lists Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)class RT List List CP.1.2#12 CP.1.4#08 - define sort restrictions() - define sort criteria() - filter() - link to problem-treatment() CP.1.2#11 - manage() CP.3.3#06 - manage reason for change () is-a - sort() SHALL CCs have  bolded borders.  See individual EHR‐S  ia-a Function’s slide deck  is-a for CC details at:  http://wiki.hl7.org/index. php?title=EHR_Interop erability_WG Immunization List Allergy, Intolerance Medication Patients Requiring and Adv erse + analyze() CP.3.3#18 List Followup List Reaction List + manage()3/1/2012 DRAFT WORKING DOCUMENT 23
  24. 24. Lists Conformance Criteria (CC) Applicable to This ComponentCP.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).3/1/2012 DRAFT WORKING DOCUMENT 24
  25. 25. Immunization Event Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)class RT Immunization Ev ent CP.1.2#13 CP.1.6#02 Encounter Ev ent - differential diagnosis + date (occurence) CP.6.2#17 CP.3.3#12 - disposition + time (occurence) SHALL CCs have  - follow up activities - change justification - follow up needed :boolean - circumstances bolded borders.  - follow up results - clinical information See individual EHR‐S  CP.6.2#16 CP.6.2#03 - type - date (entry) Function’s slide deck  - date (review) + manage() - description for CC details at:  CP.6.2#21 CP.3.3#19 has-a - duration http://wiki.hl7.org/index. - information reviewed - information source php?title=EHR_Interop CP.6.2#22 CP.3.3#13 1..* - information validator erability_WG - location CP.6.2#06 - mechanism CP.3.3#18 CPS.3.9#04 - metadata - person-role CP.6.2#02 - status CP.1.2#20 - trigger is-a - type CP.6.2#23 Immunization Ev ent + deactivate() + date (recommended booster) + justify() + immunization type CP.6.2#18 Immunization Future + manage() + series (immunization) 0..* Booster - dose - educational information received :boolean CP.6.2#10 - immunization type 0..* - encounter - recommended date - future booster - healthcare organization CP.6.2#20 health care - immunization order organisation - immunization provider - justification-immunization refusal CP.6.2#05 - lot - manufacturer - ordered immunization due date CP.6.2#19 - receipt of immunization preference is-a Immunization Witheld - receiving entity (educational information) Ev ent - refusal of vaccine type CP.6.2#01 - route of administration + exception reason - time (administration) + withholding provider CP.1.6#05 CP.1.6#03 - type 3/1/2012 DRAFT WORKING DOCUMENT 25
  26. 26. Immunization Event Conformance Criteria (CC) Applicable to This ComponentCP.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 futurefollow-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 theevaluation 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, strengthand 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 timeaccording 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, whenrendering 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., vitalsigns).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 policyand/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 ofimmunization 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 immunizationadministration.CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are provided in a patient encounter.3/1/2012 DRAFT WORKING DOCUMENT 26
  27. 27. 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
  28. 28. 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 MAYs2. Criteria to determine the “See Also” Dependencies. – EHR-S Function dependency with other Functions conformance criteria – Dependency relationship with derived EHR-S Function’s entities3. 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 Dictionary3/1/2012 DRAFT WORKING DOCUMENT 28
  29. 29. 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) Normative 1. 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
  30. 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 consistency3/1/2012 DRAFT WORKING DOCUMENT 30
  31. 31. 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 areas3/1/2012 DRAFT WORKING DOCUMENT 31
  32. 32. 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_Package3/1/2012 DRAFT WORKING DOCUMENT 32
  33. 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: – 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
  34. 34. EHR‐S FIM Action Verb Hierarches Manage (Data) Manage-Capture Maintain Render Exchange Determine Data- VisibilityAuto‐ Store Update Remove Extract Present Transmit Export Analyze Decide De-IdentifyPopulate Import HideEnter Receive MaskImport Archive Annotate Delete Transmit Re-IdentifyReceive Backup Attest Purge Unhide Decrypt Edit Unmask Encrypt Harmonize Recover Integrate Restore Link Save Tag3/1/2012 DRAFT WORKING DOCUMENT 34
  35. 35. Notional Set of HL7 Artifacts within a SAIFEnterprise Compliance and Conformance Framework (ECCF) Enterprise Information Computational Engineering TechnicalECCF Dimension “Why” - Policy Dimension “What” - Content Dimension “Who/How” - Behavior Dimension “Where” - Implementation Dimension “Where” - Deployments  Business  Inventory of Reusable  Inventory of • Mission, • Scenarios • SW Platforms, Layers  Inventory of • Vision,  Inventory of Reusable • Business Activities • SW Environments • HW Platforms • Scope , • Entities • System Functions • SW Components Conceptual  Inventory of • Associations  Requirements • SW Services • HW Environments • Network Devices Perspective • Contracts - PSSs • Capabilities - RIM • Information  Information Models • Accountability, Roles • Conformance Criteria • Technical Requirements • Communication Devices • Policies  Data Models • Profiles, Behaviors • Enterprise Service Bus  Technical Requirements • Procedures • Interactions and  Key Performance • Info. Exchanges Parameters  Specifications • Scenario Events  Information Models • Use Cases  Models, Capabilities,  Models, Capabilities, • Domain IM • Workflow Use Cases  Business Policies Features and Versions for Features and Versions for • Detailed Clinical • Components Logical  Governance  Implementation Guides  Terminologies Interfaces • SW Environments • SW Capabilities • HW Platforms • HW Environments Perspective  Design Constraints  Value Sets  Content Specifications  Collaboration Actors • Collaboration Types • SW Libraries • Network Devices  Organization Contracts • SW Services • Communication • CCD • Collaboration Roles • SW Transports Devices • RMIM  Function Types  Interface Types  Service Contracts  Business Nodes  Schemas for  SW Specifications for  HW Deployment  Business Rules • Databases  Automation Units • Applications SpecificationsImplementable  Business Procedures • Messages  Technical Interfaces • GUIs  HW Execution Context Perspective  Business Workflows  Technology Specific • Documents • Services  Technical Operations  Orchestration Scripts • Components  SW Deployment  HW Application Bindings  HW Deployment Topology Standards • Transformations Topologies  HW Platform Bindings Responsibility: HL7 Organization | EHR-S FIM | HL7 WG Projects | Development Organization See notes page for ECCF description 35
  36. 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.3/1/2012 DRAFT WORKING DOCUMENT 36

×