1. EHR System Function and Information Model (EHR-S FIM) Release 2
EHR System Function and Information Model (EHR-S FIM) Release HL7 Project ID# Executive Summary for EHR-S FIM Immunization Capability Prototype RI Translate Record Entry Content TI Translate Record Entry Audit Trigger
, EHR WG Co-chair
Pat Van Dyke, , EHR WG Co-chair
, EHR WG Modeling Facilitator
EHR WG Proponent
Mar 13, 2012 – Original Working-Draft
Aug 28, 2012 – Last-Update to Working-Draft
Call for Participation
This work is being done by the HL7 EHR Interoperability Work-group,
meeting every Tuesday at 2 PM ET, dial-in: , Passcode: #
 The most current artifacts are at:
9/21/2018

2. EHR-S FM Release 2.0 Contents
Overarching (OV) – 2 major subsections
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
EHR-S FM Release 2.0 has
Approximately functions
Approximately 2500 conformance criteria
EHR-S FM R2 ballot package can be downloaded at:
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow
9/21/2018
DRAFT WORKING DOCUMENT

3. DRAFT WORKING DOCUMENT
Introduction
The EHR-S FIM vision is for analysts, engineers or testers to efficiently compose and refine the architecture-and-workflow agnostic EHR-S FIM into interoperability-specifications, which meet their system acquisition, architectural, implementation or test needs.
The Immunization Management prototype has the purpose to
Add conceptual information and data models for each EHR-S function
verify and validate EHR-S FM Release 2.0
make the EHR-S FM easier to use for analysts and engineers
ultimately, be the basis for Model Driven Design
Harmonize with the FHIM and HL7 RIM
Support specific profiles (e.g., DAMs, DIMs, DCMs, CIMI).
As a part of the Immunization Management Prototype, Record Infrastructure (RI) and it’s Trust Infrastructure (TI) dependencies were modeled to assess RI & TI modeling style and complexity. The results are presented here.
9/21/2018
DRAFT WORKING DOCUMENT

4. RED: Recommended deletion, Blue: Recommended Insertion
RI Translate Record Entry Content Statement, Description and Example
Statement: Translate content of Record Entries (1 or more instances)
Description: Occurs when Record Entries are amended to include translation of content – typically to transform coded data from one coding/classification scheme to another, also from one human language to another.• Translated (amended) Record Entry content is the responsibility of translating System – which invokes mapping/translation rules for each relevant record attribute.• The translation amendment becomes part of the Record Entry revision history, where original content and any previous amendments are retained without alteration.• After translation amendment, the System is responsible for retention of the Record Entry and its revision history (including the translation event).• An Audit Trigger is initiated to track Record Entry translation. Reference: ISO 21089, Sections and 12.4.
Example: (notional scenario based on conformance criteria) As an EHR System manages patient healthcare information, it may use an attribute rules-and-mapping system to translates record entries from one coding/classification scheme to another or from one human language to another. The EHR system manages new versions of Record Entries without alteration to previous versions and conforming to function “Translate Record Entry Audit Trigger” (TI ); thereby, capturing the full set of identity, event and provenance audit metadata, including the key who, what, when, where, why metadata and any additionally specified metadata. NOTE: The RI and TI notional scenarios are the same, because the EHR-S FM 2.x update plans to move TI conformance criteria under RI
9/21/2018
RED: Recommended deletion, Blue: Recommended Insertion

5. RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger “See Also” Dependencies
DRAFT WORKING DOCUMENT
RED: delete, Blue: insert
9/21/2018

6. RED: Recommended deletion, Blue: Recommended Insertion
TI Translate Record Entry Content Statement, Description and Example
Statement: Manage Audit Trigger initiated to track Record Entry translation.
Description: Capture Record Entry translation events, including key metadata (who, what, when, where, why).
Example: NOTE: The RI and TI notional scenarios are the same, because the EHR-S FM 2.x update plans to move TI conformance criteria under RI
9/21/2018
RED: Recommended deletion, Blue: Recommended Insertion

7. RED: Recommend deletion, Blue: Recommended Insertion
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger Infrastructure Activities Supporting Core EHR-S Activities
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
9/21/2018
RED: Recommend deletion, Blue: Recommended Insertion

8. DRAFT WORKING DOCUMENT
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger Conceptual Information Model (CIM)
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
9/21/2018
DRAFT WORKING DOCUMENT

9. RI.1.1.3 Translate Record Entry Content Context
9/21/2018
DRAFT WORKING DOCUMENT

10. TI.2.1.1.3 Translate Record Entry Content Context
9/21/2018
DRAFT WORKING DOCUMENT

11. DRAFT WORKING DOCUMENT
RI Translate Record Entry Content Conceptual Data Model (CDM) Mapped to CC
9/21/2018
DRAFT WORKING DOCUMENT

12. RI.1.1.3 Translate Record Entry Content Conformance Criteria (CC)
RI.1.1.3#01 The system SHOULD provide the ability to render coded Record Entry content translated from one coding/classification system to another.
RI.1.1.3#02 The system SHOULD provide the ability to render coded Record Entry content translated from one value set to another.
RI.1.1.3#03 The system MAY provide the ability to render Record Entry content translated from one human language to another.
RI.1.1.3#04 The system SHOULD maintain the original and all previously amended versions of the Record Entry, retaining each version instance without alteration.
RI.1.1.3#05 The system SHOULD capture a new uniquely identifiable version of the Record Entry, incorporating translated content.
RI.1.1.3#06 The system SHOULD conform to function TI (Translate Record Entry Audit Trigger), including specified metadata.
RI.1.1.3#07 The system SHOULD capture the full set of identity, event and provenance Audit Metadata, conforming to function TI (Translate Record Entry Audit Trigger).
9/21/2018
DRAFT WORKING DOCUMENT

13. DRAFT WORKING DOCUMENT
TI Translate Record Entry Content Conceptual Data Model (CDM) Mapped to CC
9/21/2018
DRAFT WORKING DOCUMENT

14. TI.2.1.1.3 Translate Record Entry Content Conformance Criteria (CC)
TI #01 The system SHOULD SHALL audit each occurrence when Record Entry content is translated.
TI #02 The system SHALL capture identity of the organization where Record Entry content is translated.
TI #03 The system SHALL capture identity of the patient who is subject of translated Record Entry content.
TI #04 IF a user initiated a Record Entry content translation, THEN the system SHALL capture identity of the user initiating Record Entry content translation.
TI #05 The system SHALL capture identity of the system application which translated Record Entry content.
TI #06 The system SHALL capture the type of Record Event trigger (i.e., translation).
TI #07 The system SHALL capture date and time Record Entry content is translated.
TI #08 The system SHOULD capture identity of the location (i.e., network address) where Record Entry content is translated.
TI #09 IF a user initiated a Record Entry translation, THEN the system MAY capture the rationale for translating Record Entry content.
TI #10 The system SHALL capture a sequence identifier for translated Record Entry content.
TI #11 The system SHALL capture the identifier and version of Translation Tools used for each translated Record Entry.
TI #12 The system SHALL capture a reference (e.g., link, pointer) to pre-translation data for each Record Entry translation.
9/21/2018
DRAFT WORKING DOCUMENT

15. RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger 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
Audit
Conform
Translate
Version
Delete
Purge
Black Bold = Maps to Conformance Criteria (CC)
Blue Bold = included in CC; but missing in verb hierarchy
Orange – duplicate verbs
9/21/2018
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
DRAFT WORKING DOCUMENT

16. RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger Issues, Actions, Recommendations, Observations & Conclusions
EHR-S FM 2.0 should use verbs, such as “manage”, in the RI and TI functions; where, verbs are modeled as activities and nouns are modeled as classes. This verb/noun convention was followed in CP, CPS and AS.
RI.1 Manage Record Lifecycle and Lifespan
RI.2 Manage Record Synchronization
RI.3 Manage Record Archive and Restore
TI.1 Manage Security
TI Manage Translate Record Entry Audit Trigger
ACTION: As an EHR-S FM update, TI conformance criteria will me moved under RI.1.1.3
OBSERVATION: RI through RI modeling will be similar.
OBSERVATION: TI through TI modeling will be similar.
9/21/2018
RED: Recommended deletion, Blue: Recommended Insertion
DRAFT WORKING DOCUMENT

17. RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger Issues, Actions, Observations, Recommendations & Conclusions
CONCLUSION: OV-1 Manage EHR-S (New) is needed
OV.1.1 Manage Events
OV.1.2 Manage Lists
OV.1.3 Manage Documents and Notes
OV.1.4 Manage Terminology
OV.1.5 Manage Encounters
OV.1.6 Manage Patient Information
OV.1.7 Manage Schedules
OV.1.8 Manage Business Rules (may belong under CPS)
OV.1.9 Manage Workflow (may belong under CPS)
OV.1.10 Manage Registries (may belong under CPS)
9/21/2018
RED: Recommended deletion, Blue: Recommended Insertion
DRAFT WORKING DOCUMENT

18. RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1
RI Translate Record Entry Content TI Translate Record Entry Audit Trigger Issues, Actions, Observations, Recommendations & Conclusions
RECOMMENDATION: Move the following under OV-1 Manage EHR-S (New) or CPS
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
9/21/2018
RED: Recommended deletion, Blue: Recommended Insertion
DRAFT WORKING DOCUMENT

19. Questions? Backup Slides Follow
9/21/2018
DRAFT WORKING DOCUMENT

20. DRAFT WORKING DOCUMENT
EHR-FIM Model Legend
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
9/21/2018
DRAFT WORKING DOCUMENT

21. Glossary for Key UML Connector Concepts
An Association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type.
An Aggregation connector is a type of association that shows that an element contains or is composed of other elements. It is used in Class models, Package models and Object models to show how more complex elements (aggregates) are built from a collection of simpler elements (component parts; for example, a car from wheels, tires, motor and so on).
A Composite Aggregation is a stronger form of aggregation used to indicate ownership of the whole over its parts. The part can belong to only one Composite Aggregation at a time. If the composite is deleted, all of its parts are deleted with it.
A Dependency is a relationship between two modeling elements, in which a change to one modeling element (the independent element) affects the other modeling element (the dependent element).
A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of 'implementation' is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable.
9/21/2018
DRAFT WORKING DOCUMENT

22. Information Models
Information models define the intricate details of how clinical information comes together in a cohesive fashion to allow clinical decision support, automation of routine care measures, epidemiological and research use of clinical data; ultimately, Information models must specify a level-of “working-interoperability” among system components, capabilities and services. Information models are created for a specific purpose; such as, providing a specification from which implementation artifacts can be derived and conformance can be assured. A particular implementation type (e.g., messages, documents, services) may constrain the content-and- style of information models and the choice of modeling environments.
Conceptual Information models-of-use are closely related to functional requirements.
Logical Information models-of-meaning require explicit semantic specifications to govern persistence, processing, and information exchanges.
As an emergency care example, well-specified information models-of-meaning should allow- the-potential for initial-care-site triage-information to help subsequent care givers understand diagnostic-imaging done prior-to acute-injury-stabilization and ultimately to help other health care professionals, potentially years later, help patients achieve maximum recovery.
9/21/2018
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

23. Methodology
Sparx Enterprise Architect views were used to create a separate slide set for an Immunization Management Capability based on CP.6.2 Manage Immunization Administration and its “See Also” Dependencies :
Gather A core set of reusable components appropriate for the function
Create Model-of-use (Activity Model based on conformance criteria).
Map functions/Activities to EHR-S Components
Add CDM components and content, based on conformance criteria.
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
Bold SHALL conformance criteria to expedite test traceability
Indicate SHALL attributes or operations as “public” with a proceeding “+”
Indicate SHOULD or MAY attributes or operations as “private” with a proceeding “-”
Create CIM based on Information Patterns (e.g., encounters, events, lists, documents)
Show supporting EHR-S Function associations and dependencies.
Map EHR-S Components to supporting EHR-S Functions (“See Also” Dependencies)
Add Specific Information Exchanges, based on conformance criteria.
Iterate to refine models.
This Executive Summary was created from the resultant model.
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
9/21/2018
DRAFT WORKING DOCUMENT

24. Information Model Types
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).
Conceptual Information Models identify the highest-level conceptual components in a domain (e.g., EHR) and their relationships; however, data content is not specified.
Conceptual Data Models (CDMs) specify conceptual components and their content, without regard to how they will be physically implemented.
Sub-domain and realm-specific CDMs (profiles) typically refine the following:
Conceptual components and their relationships
conceptual components and their content
date element optionality (e.g., MAY, SHOULD, SHALL) are constrained
Business terms for concepts and attributes are agreed upon and used. (These terms should be part of the agreed upon common terminology, which may vary by domain-and-realm.)
Primary keys (keys identifying specific entities within a class) for concepts may be specified.
Foreign keys (keys identifying the relationship between different entities) among concepts may be specified.
Normalization, based on reusable components, may occur.
Terminology (code and value sets) binding may occur.
Logical Data Models are fully-qualified CDMs, which can be transformed into deterministic and testable physical schema for a specific implementation.
9/21/2018
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

25. Observation Where is the Patient?
Healthcare is patient-centric; but, EHR-S FIM is system-centric; consequently, EHR-S FIM does not reflect patients and their healthcare interactions.
EHR system is modeled as a repository for encounters; (patient) encounters are composed of events and associated (clinical) information; events can be composed into lists; lists can be composed into documents. Each of the above concepts can be specified as types (e.g., problem vs. medication list) and linked.
9/21/2018
DRAFT WORKING DOCUMENT