EHR System Function and Information Model (EHR-S FIM) Release 2 EHR System Function and Information Model (EHR-S FIM) Release 2.1 HL7 Project ID# 688 Executive Summary for EHR-S FIM Immunization Capability Prototype RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 Translate Record Entry Audit Trigger gary.dickinson@ehr-standards.com , EHR WG Co-chair Pat Van Dyke, vandykp@odscompanies.com , EHR WG Co-chair Stephen.Hufnagel.ctr@tma.osd.mil , EHR WG Modeling Facilitator Nancy.Orvis@tma.osd.mil, 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: 1-770-657-9270, Passcode: 510269#  The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG 9/21/2018

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 450 functions Approximately 2500 conformance criteria EHR-S FM R2 ballot package can be downloaded at: http://wiki.hl7.org/index.php?title=December_2011_Ballot_Package NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow 9/21/2018 DRAFT WORKING DOCUMENT

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

RED: Recommended deletion, Blue: Recommended Insertion RI.1.1.3 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 12.3.2 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.2.1.1.3); 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.1 1.3 and TI.2.1.1.3 notional scenarios are the same, because the EHR-S FM 2.x update plans to move TI.2.1.1.3 conformance criteria under RI.1.1.3. 9/21/2018 RED: Recommended deletion, Blue: Recommended Insertion

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

RED: Recommended deletion, Blue: Recommended Insertion TI.2.1.1.3 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.1 1.3 and TI.2.1.1.3 notional scenarios are the same, because the EHR-S FM 2.x update plans to move TI.2.1.1.3 conformance criteria under RI.1.1.3. 9/21/2018 RED: Recommended deletion, Blue: Recommended Insertion

RED: Recommend deletion, Blue: Recommended Insertion RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 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

DRAFT WORKING DOCUMENT RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 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

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

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

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

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.2.1.1.3 (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.2.1.1.3 (Translate Record Entry Audit Trigger). 9/21/2018 DRAFT WORKING DOCUMENT

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

TI.2.1.1.3 Translate Record Entry Content Conformance Criteria (CC) TI.2.1.1.3#01 The system SHOULD SHALL audit each occurrence when Record Entry content is translated. TI.2.1.1.3#02 The system SHALL capture identity of the organization where Record Entry content is translated. TI.2.1.1.3#03 The system SHALL capture identity of the patient who is subject of translated Record Entry content. TI.2.1.1.3#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.2.1.1.3#05 The system SHALL capture identity of the system application which translated Record Entry content. TI.2.1.1.3#06 The system SHALL capture the type of Record Event trigger (i.e., translation). TI.2.1.1.3#07 The system SHALL capture date and time Record Entry content is translated. TI.2.1.1.3#08 The system SHOULD capture identity of the location (i.e., network address) where Record Entry content is translated. TI.2.1.1.3#09 IF a user initiated a Record Entry translation, THEN the system MAY capture the rationale for translating Record Entry content. TI.2.1.1.3#10 The system SHALL capture a sequence identifier for translated Record Entry content. TI.2.1.1.3#11 The system SHALL capture the identifier and version of Translation Tools used for each translated Record Entry. TI.2.1.1.3#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

RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1 RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 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

RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1 RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 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.2.1.1.3 Manage Translate Record Entry Audit Trigger ACTION: As an EHR-S FM update, TI.2.1.1.3 conformance criteria will me moved under RI.1.1.3 OBSERVATION: RI.1.1.1 through RI.1.1.24 modeling will be similar. OBSERVATION: TI.2.1.1 through TI.2.1.24 modeling will be similar. 9/21/2018 RED: Recommended deletion, Blue: Recommended Insertion DRAFT WORKING DOCUMENT

RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1 RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 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

RI. 1. 1. 3 Translate Record Entry Content TI. 2. 1. 1 RI.1.1.3 Translate Record Entry Content TI.2.1.1.3 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

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

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

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

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!

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

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!

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