1. 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
, EHR WG facilitator
, DoD Point-of-Contact
February 9, 2012 – Original
February 28, 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: , Passcode: #
 The most current artifacts are at:
5/23/2019
DRAFT WORKING DOCUMENT

2. 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 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 Continuity-of-Care harmonization are proposed as a set of demonstration prototypes of increasing complexity.
5/23/2019
DRAFT WORKING DOCUMENT

3. Immunization Management Capability Scope, (Including Dependent EHR-S Functions)
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 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
For details, see separate slide deck for each EHR-S Function.
All referenced EHR-S Functions are available at:
5/23/2019
DRAFT WORKING DOCUMENT

4. DRAFT WORKING DOCUMENT
EHR-FIM Legend
5/23/2019
DRAFT WORKING DOCUMENT

5. DRAFT WORKING DOCUMENT
Methodology
Sparx 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:
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 “-”
Create Conceptual Information Model (CIM) view from step 1.
Create Conceptual Data Model (CDM) 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
Create Information Exchanges Mapped-to Conformance Criteria
This Executive Summary was created from the resultant model.
5/23/2019
DRAFT WORKING DOCUMENT

6. 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
5/23/2019
DRAFT WORKING DOCUMENT

7. DRAFT WORKING DOCUMENT
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
5/23/2019
DRAFT WORKING DOCUMENT

8. Notional Set of HL7 Artifacts within a SAIF Enterprise Compliance and Conformance Framework (ECCF)
Enterprise Dimension
“Why” - Policy
Information Dimension
“What” - Content
Computational Dimension
“Who/How” - Behavior
Engineering Dimension
“Where” - Implementation
Technical Dimension
“Where” - Deployments
Conceptual Perspective
Business
Mission,
Vision,
Scope ,
Inventory of
Contracts - PSSs
Capabilities - RIM
Policies
Procedures
Inventory of Reusable
Entities
Associations
Information
Information Models
Data Models
Inventory of Reusable
Scenarios
Business Activities
System Functions
Requirements
Accountability, Roles
Conformance Criteria
Profiles, Behaviors
Interactions and
Info. Exchanges
Inventory of
SW Platforms, Layers
SW Environments
SW Components
SW Services
Technical Requirements
Enterprise Service Bus
Key Performance Parameters
Inventory of
HW Platforms
HW Environments
Network Devices
Communication Devices
Technical Requirements
Logical Perspective
Business Policies
Governance
Implementation Guides
Design Constraints
Organization Contracts
Information Models
Domain IM
Detailed Clinical
Terminologies
Value Sets
Content Specifications
CCD
RMIM
Specifications
Scenario Events
Use Cases
Workflow Use Cases
Components Interfaces
Collaboration Actors
Collaboration Types
Collaboration Roles
Function Types
Interface Types
Service Contracts
Models, Capabilities, Features and Versions for
SW Environments
SW Capabilities
SW Libraries
SW Services
SW Transports
Models, Capabilities, Features and Versions for
HW Platforms
HW Environments
Network Devices
Communication Devices
HL7 Service Aware Interoperability Framework (SAIF)
Enterprise Compliance and Conformance Framework (ECCF)
The DoD and MHS EHRWF ECCF’s goal is to ensure Working Interoperability (WI) among various healthcare organizations; WI is also known as compatibility among healthcare systems. Working Interoperability is an instance of two “trading partners” –- human beings, organizations, or systems, successfully exchanging data or information, or coordinating behavior to accomplish a defined task, or both. The ECCF’s purpose is to manage the relationship between architectural artifacts and implementations of those artifacts. The objective of a fully qualified ECCF is to be a clear, complete, concise, correct, consistent and traceable interoperability specification, which is easy to use. An ECCF can be an assessment framework, which supports configuration management baselines and risk assessments throughout a business-capability lifecycle. The ECCF is used to specify information exchange interoperability and conformance statements for documents, messages and services. An ECCF Implementation Guide contains definitions of terms, such as conformance, compliance, consistency and traceability. An ECCF provides a template, called a Specification Stack (SS) that allows you to specify business objects, components, capabilities, applications and systems organized as a matrix of Dimension columns (Enterprise, Information, Computational, Engineering and Technical) and Perspective rows (Conceptual, Logical and Implementable)., as is shown in the slide.
DoD and VA must define their common SAIF Implementation Guides, which define their architecture development methodologies and architecture artifacts. To foster consistency, VA has agreed to build a common DoD-VA EHRWF Implementation Guide, based on DoDAF, TOGAF and HL7 SAIF. This slide shows a notional Interoperability Specification template, using the HL7 SAIF ECCF SS. This is a super set of common architectural-artifacts. All the listed artifacts may NOT be required in the DoD-VA EHRWF Implementation Guide; other artifacts may be included. Within each cell
You place or reference and discuss appropriate architectural artifacts and specifications.
You define or reference conformance statements, which are testable-representations of assumptions that the specifications make.
You manage traceability within columns and consistency across layers.
An implementation of a Specification Stack (SS) asserts, as true or false, that one-or-more conformance assertions are met; certification asserts as true, that some set of conformance assertions are met.
You identify and mitigate risks across the organization’s component development life cycles.
Implementable Perspective
Business Nodes
Business Rules
Business Procedures
Business Workflows
Technology Specific Standards
Schemas for
Databases
Messages
Documents
Services
Transformations
Automation Units
Technical Interfaces
Technical Operations
Orchestration Scripts
SW Specifications for
Applications
GUIs
Components
SW Deployment Topologies
HW Deployment Specifications
HW Execution Context
HW Application Bindings
HW Deployment Topology
HW Platform Bindings
Responsibility: HL7 Organization | EHR-S FIM | HL7 WG Projects | Development Organization
See notes page for ECCF description

9. Immunization Management Capability Models
CP.6.2 Clinician-Activities Mapped-to System-Components
CP.6.2 Conceptual Information Model (CIM) Mapped to EHR-S Functions
CP.6.2 Information Exchanges Mapped-to Conformance Criteria (CC)
CP.6.2 CDM Requirements-Traceability
CP.6.2 Dependencies
CIM for Immunization Management Capability
CDM for Advanced Directive
CDM for Allergy, Intolerance and Adverse Reaction Event
CDM for Clinical Decision Support (CDS)
CDM for Clinical Document or Note
CDM for Event
CDM for Lists
CDM for Immunization Event
CIM is Conceptual Information Model
CDM is Conceptual Data Model
DRAFT WORKING DOCUMENT
5/23/2019

10. 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 “Information Exchanges Mapped-to Conformance Criteria” show
Basis for information exchanges
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
5/23/2019
DRAFT WORKING DOCUMENT

11. CP.6.2 Manage Immunization Administration Clinician-Activities Mapped-to EHR-S Components
5/23/2019
RED: delete, Blue: insert
DRAFT WORKING DOCUMENT

12. CP.6.2 Manage Immunization Administration Conceptual Information Model (CIM) Mapped to Supporting Functions
RED: delete, Blue: insert
5/23/2019
DRAFT WORKING DOCUMENT

13. CP.6.2 Manage Immunization Administration Information Exchanges Mapped-to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

14. DRAFT WORKING DOCUMENT
CP.6.2 Manage Immunization Administration Components mapped to Requirements
NOTE: SHALL conformance criteria have bolded borders
5/23/2019
DRAFT WORKING DOCUMENT

15. DRAFT WORKING DOCUMENT
CP.6.2 Manage Immunization Administration Components mapped to Requirements
NOTE: SHALL conformance criteria have bolded borders
5/23/2019
DRAFT WORKING DOCUMENT

16. DRAFT WORKING DOCUMENT
Immunization Management Capability CP.6.2 Manage Immunization Administration Dependencies
DRAFT WORKING DOCUMENT
5/23/2019

17. Immunization Management Capability Conceptual Information Model (CIM)
DRAFT WORKING DOCUMENT
5/23/2019

18. Advanced Directive Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

19. Allergy, Intolerance and Adverse Reaction Event Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

20. Clinical Decision Support Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

21. Clinical Document or Note Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

22. Event Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

23. Lists Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

24. Immunization Event Conceptual Data Model (CDM) Traceable to Conformance Criteria (CC)
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
5/23/2019
DRAFT WORKING DOCUMENT

25. Reference Information
EHR-S FIM Verb Hierarchy
Observations by reviewers
5/23/2019
DRAFT WORKING DOCUMENT

26. DRAFT WORKING DOCUMENT
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).
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.
5/23/2019
DRAFT WORKING DOCUMENT

27. 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
5/23/2019
DRAFT WORKING DOCUMENT

28. 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.
5/23/2019
DRAFT WORKING DOCUMENT

29. 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.
5/23/2019
DRAFT WORKING DOCUMENT

30. 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.
5/23/2019
DRAFT WORKING DOCUMENT

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