EHR System Function and Information Model (EHR-S FIM) Release 2 EHR System Function and Information Model (EHR-S FIM) Release 2.1 Prototype Executive Summary for Immunization Capability and its EHR-S FIM Stephen.Hufnage.ctrl@tma.osd.mil , EHR WG facilitator Nancy.Orvis@tma.osd.mil , DoD Point-of-Contact February 9, 2012 – Original February 24, 2012 – Last Update Call for Participation This work is being done by the HL7 EHR Interoperability Work-group, meeting every Tuesday at 4PM ET, dial-in: 1-770-657-9270, Passcode: 510269#  The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT Executive Summary For EHR-S FIM Release 2.1, this project has the purpose to add core information models for each EHR-S FM function make the EHR-S FM easier to use for analysts and engineers verify and validate EHR-S FM Release 2.0 Service Aware Interoperability Framework (SAIF) DSTU demonstration Support specific profiles (e.g., WG project DAMS, DIMS, DCMS). The plan is to use an architecture modeling tool to represent the EHR-S FIM and then generate appropriate views, reports, XML and HTML renderings of each EHR-S function’s scenarios, requirements, actors, actions/activities, dependencies, business rules, information & data The DoD-VA Joint Immunization Capability (JIC), HL7 EHR Diabetes project, ISO 13940 Continuity-of-Care harmonization are proposed as a set of demonstration prototypes of increasing complexity. 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT EHR-FIM Legend 7/13/2019 DRAFT WORKING DOCUMENT

Description of Diagrams The “Activities Mapped to System-Components” show Row 1: operational activities performed by the clinician, indicating dependencies on Row 2: The EHR System components, which support the clinician’s activities. The “CIM Mapped to EHR-S Functions” show System Components for the EHR-S Function being analyzed, mapped to the requisite System Components. The Conceptual Data Model shows Attributes & operations for each System Component. CDM Requirements-Traceability Shows Derivation of attributes and operations for each Component 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT Methodology Sparx Enterprise Architect views were used to create a separate slide set for an Immunization Management Capability based on the “See Also” Dependencies of CP.6.2 Manage Immunization Administration (defined on “Prototype Scope” Slide) following these steps: 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” Indicate SHOULD or MAY attributes or operations as “private” Create Conceptual Information Model view from step 1. Create Conceptual Data Model view from step 1. Map EHR-S Components to supporting EHR-S Functions (“See Also” Dependencies) Create Activity Model for the function. Map Activities to EHR-S Components This Executive Summary was created from the resultant model. 7/13/2019 DRAFT WORKING DOCUMENT

Immunization Management Capability Prototype Scope We started with CP6.2 and included its dependencies: CP.6.2 Manage Immunization Administration CP.1.6 Manage Immunization List CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List CP.1.3 Manage Medication List CP.3.3 Manage Clinical Documents and Notes 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 Record Infrastructure Trust Infrastructure See separate slide deck for each EHR-S Function 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT Issues 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 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 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 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT Conclusions EHR-S FIM can be the conceptual foundation for Interoperability Specifications, refined into: Logical Perspective Implementable Perspective Messages, Documents, Services EHR-S FIM can be composed into higher level capabilities by functional analysts and system engineers Encourage reuse Avoid duplication and “stovepipe applications” EHR-S FIM can populate portions of SAIF for HL7 WGs Information and Computational Dimensions Conceptual Perspective An Enterprise Architecture tool is essential to maintain consistency 7/13/2019 DRAFT WORKING DOCUMENT

Immunization Management Capability Models CIM for Immunization Management Capability CDM for Advanced Directive CDM for Allergy, Intolerance and Adverse Reaction Event CDM for Clinical Decision Support CDM for Clinical Document or Note CDM for Event for Lists CDM for Immunization Event CDM for Medication Event CIM is Conceptual Information Model CDM is Conceptual Data Model DRAFT WORKING DOCUMENT 7/13/2019

Immunization Capability Conceptual Information Model (CIM) The Immunization Capability was modeled as a set of linkable events & clinical information, documents-or-notes and lists linked into encounters. DRAFT WORKING DOCUMENT 7/13/2019

Advanced Directive Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT Advanced Directive Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC) 7/13/2019 DRAFT WORKING DOCUMENT

DRAFT WORKING DOCUMENT Allergy, Intolerance and Adverse Reaction Event Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Clinical Decision Support Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Clinical Document or Note Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Event Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Lists Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Immunization Event Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Medication Event Conceptual Data Model (CDM) 7/13/2019 DRAFT WORKING DOCUMENT

Reference Information EHR-S FIM Verb Hierarchy Observations by reviewers 7/13/2019 DRAFT WORKING DOCUMENT

EHR-S FIM Action Verb Hierarches Manage (Data) Capture Maintain Render Exchange Determine Manage- Data- Visibility Auto-Populate Enter Import Receive Store Update Remove Extract Present Transmit Export Analyze Decide De-Identify Hide Mask Re-Identify Unhide Unmask Archive Backup Decrypt Encrypt Recover Restore Save Annotate Attest Edit Harmonize Integrate Link Tag Delete Purge 7/13/2019 DRAFT WORKING DOCUMENT

Observation [David Baas] From where I’m sitting, deriving conceptual information models based on the conformance criteria could be useful for consuming a functional profile. I would assume it could be used as reference for developing a domain analysis model for a project, to fill in blanks of conceptual information not expressed by clinical SMEs, and to shorten the learning curve for projects required to adopt the conformance criteria. Regardless of how modeling evolved on the project, the CDM would still be a bridge to validate addressing information needs at a high level. I would not foresee using the CDM or other artifacts verbatim in modeling for a specific project because some the relationships/associations expressed appear to be more subjective than explicit representation of the conformance criteria. I suggest annotating whether the relationships in the CDM represent explicit conformance criteria or not. For those that are not explicit (SHALL), it should be clear implementers have no obligation to portray those relationships the way they are expressed in the model.  In reviewing the other artifacts (activity diagrams, and conceptual information model) I was a little concerned that the content suggested a more prescriptive view of EHR functionality, which I’m not sure is a good thing. In the case of the activity diagrams being prototyped, I can see they are not attempting to sequence how tasks within an activity are executed, but using activity diagrams suggests that is the intended direction. I think that path would be too restrictive for implementers. I think the CIM raises more questions than it answers. This is another one where I think it best left to specific implementation projects. Perhaps other folks will provide a different perspective, but I think the CDM content is the most useful for understanding the conformance criteria for greater adoption. 7/13/2019 DRAFT WORKING DOCUMENT

Observation [Kevin Coonan, HL7 Patient Care WG Co-chair] We have been having a lot of discussions in patient care, clinical statement, CIMI and MnM regarding representation of clinical content. One of the most important is the recognition and separation of dynamic uses / extracts of information one would see in an EHR-S GUI or CDA v. an information model suited for information exchange, persistence, transformation, analytics, decision support.  A good example of this is the common notions of a “problem list”, “allergy list” or “list of immunizations”.  These are artifacts we are used to seeing in paper charts, since there was no other effective means to address longitudinal data which otherwise would be scattered in the linear ordering progress notes.  In fact, HL7 defines these working lists as ‘..collects a dynamic list of individual instances of Act via ActRelationship which reflects the need of an individual worker, team of workers, or an organization to manage lists of acts for many different clinical and administrative reasons. Examples of working lists include problem lists, goal lists, allergy lists, and to-do lists.’ There are also design patterns well suited for static semantics from the (being revised for May ballot) Patient Care domain, all of which are different entry points into a common model.  These include a pattern for a Care Record, which corresponds best to the conventional notion of the documentation of an encounter.  The Care Record, however, has entries which follow the Health Concern pattern and the Care Plan pattern.    Health Concerns are anything which affects one’s health which need to be managed/tracked over time.  These includes risks, diseases, problems, allergies/intolerances to medications, social circumstances, and complications.   The Care Plan documents interventions, treatments and orders.  Care Plans can have embedded logic, e.g. stating a specific action should (not) be taken if a specific criterion is met.  So things like immunization schedules, insulin sliding scales/sick day rules, or complex oncology protocols have a common design basis.  While we are used to thinking of Concerns and Plans as future looking, the same pattern is used to document things which have happened (e.g. procedure which has been completed), so the Care Plan includes not just what is currently being done, what is planned, but also what has been done in the past. An instance of an encounter’s documentation therefore would have elements from the Care Record (e.g. the signs/symptoms discovered at the time of the encounter), Health Concerns (in a linear narrative like a CDA these typically are organized into the familiar ‘lists’, e.g. allergy list, problem list, PMH), and Care Plan (again in ‘lists’—e.g. medication list).  An encounter would also expect to generate new Care Plans and new Health Concerns as part of the clinical decision making.  (The A&P in Weed’s POMR). By separating the model of use (various lists) from model of meaning (the Patient Care Domain Model plus the derived detailed clinical models which bind terminology, etc.) we can most effectively devise those specifications needed for given use cases. 7/13/2019 DRAFT WORKING DOCUMENT

Observation [Kevin Coonan, HL7 Patient Care WG Co-chair] I am coordinating with Richard Savage (now working for CDC) on immunizations with Patient Care.  I don’t know who the modeling facilitator is for the new immunization project, but if it is a void I might fill in.  I am going to start tacking the immunization (JIC) (analysis/conceptual) models and see if I can get them into something which is a better approximation of  a real information model of the clinical content static semantics.  Do you think this is a good point to start to put together the background and socialization needed to come to some decision regarding the representation of static semantics for iEHR?  I see two related decisions:  #1 what modeling language is going to be used for design, and #2 what is the modeling language used for the wire format.  Obviously, with HL7 v3 there is close traceability between the graphic format in the Visio based RMIM Designer and the resultant MIF2 representation.  I believe that the UML based SMD also does this.  MIF2 è XSD, so there is a close tie between MIF and something which can be implemented.  Of course, we could also use HL7 templates (whatever those are) on top of a base model, rather than having all the explicit details in the MIF2.  We could even use ADL for this, if we were so inclined.  That still leaves us the question about ‘wire format’.  I.e. what one server says to another.  Eventually, I would expect a ‘cleaner’ modeling language to be used for design, with transformation to arbitrary implementable paradigms.  Hopefully CIMI will fill this niche.  Not in time to do the modeling for JIC, Pharmacy, etc. but hopefully just in time to model the core content of an ambulatory documentation system. 7/13/2019 DRAFT WORKING DOCUMENT

CP.6.2 Immunization Management “See Also” Dependencies DRAFT WORKING DOCUMENT RED: delete, Blue: insert 7/13/2019

EHR-S FIM Immunization Management Prototype Status EHR-S Function L A S t CC Notional Scenario Act CIM CDM RT See Also CP.6.2 Manage Immunization Administration 2/11 X CP.1.6 Manage Immunization List √ CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List CP.1.3 Manage Medication List CP.3.3 Manage Clinical Documents and Notes 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 √ = first draft done, X = Peer reviewed by WG CC=Conformance Criteria, Act=Activity Diagram, CIM=Conceptual Information Model, CDM=Conceptual Data Model, RT-A=Requirements Trace to Activities, RT-D=Requirements trace to Data 7/13/2019