HL7 EHR SD RM Project EHR System Design Reference Model
HL7 SAIF Alpha Project Report Documented in Appendix of The Practical Guide to SOA in Healthcare Volume II: Immunization Management Case Study For presentation at HL7 Rio Workgroup Meeting, 18 May 2010 Details available at Nancy Orvis, GovProjects; Stephen.Hufnagel, SOA Alean Kirnak, PHER; John Ritter, EHR EHR SD RM Milestones 2008 2009 2010 2011 Healthcare SOA Reference Architecture (H-SOA-RA) EHR SD RM Immunization & Response Management (IRM) Prototype HSSP Practical Guide for SOA in Healthcare Volume II: Immunization Case Study Informative Reference __________ EHR SD RM Informative Reference Jan EHR SD RM DSTU Oct Normative Standard DSTU is Draft Standard for Trial Use (ANSI standards development) Project Description The Practical Guide for SOA in Healthcare Volume II presents a case study,which adds an Immunization Management Capability (IMC) to Volume IsSampleHealths Service Oriented Architecture (SOA). We used theTOGAF Architecture Development Method (ADM) and HL7 ServiceAware Interoperability Framework (SAIF) Enterprise Conformance andCompliance Framework (ECCF). Volume II demonstrates the use ofHL7s EHR System Design Reference Model (EHR-SD RM) linkedartifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC,HSSP, IHE, NIEM, etc) to provide an initial architectural baseline suitablefor an EHR related SOA acquisition, development or certification project. The Practical Guide is available at EHR SD RM info is available at: ttp://hssp.wikispaces.com/Reference+Architecture Project Approach Two use cases from the Health and Human Services (HHS) American HealthInformation Community (AHIC) were used. The Immunization ResponseManagement (IRM) use case and its Vaccine and Drug Administration andReporting scenario and the Public Health Case Reporting (PHER) use case wereused to develop the business architecture, Information Exchange Requirements(IERs), data requirements, interoperability specifications and conformancestatements for the IMCs Services. EHR System Functional Model defined requirements HITSP Defined Interoperability Specifications IHE Defined Implementation Profiles SAIF Alpha-Project Conclusions
The TOGAF ADM is a rigorous process, which efficiently led us toproduce a set of clear, complete, concise, correct and consistentinteroperability specifications and conformance statements. The SAIF-ECCF is an architectural Exchange Architecture; we used itas an architectural executive summary to effectively present the IMCinteroperability specifications and conformance statements. Other architecture development methods or other architecturalframeworks, such as the Rational Unified Process, the Zachman or theDOD Architectural Framework can complement and benefit-from HL7sEHR-SD-RM and SAIF-ECCF to build and present an exchangearchitecture, interoperability specifications and conformance statements. Project Conclusions Effective SOA programs involve cooperation and coordination among a wide variety of business, technical andfunctional participants from across an organization, including senior management sponsorship, businesscommunity ownership, program management, governance, architecture, project level execution, test andcertification and sustainment teams. The HL7 EHR-SD-RM helps bring these communities together throughout aBusiness Capability Lifecycle. It maps capabilities and business Information Exchange Requirements (IERs) to the HL7 EHR System Functional Model (EHR-S FM), to Healthcare Information Technology Standards Panel (HITSP) Data Architecture, Security and Privacy Architecture, Harmonization Framework, Interoperability Specifications, Constructs and their referenced standards; Federal Health Information Model (FHIM); National Information Exchange Model (NIEM) Information Exchange Package Documents (IEPDs); Integrating the Healthcare Enterprise (IHE) profiles; Certification Commission for Health Information Technology (CCHIT) criteria and 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act selected standards forinteroperability and meaningful use objectives and criteria. Immunization Management Project Conclusions
The HITSP selected Immunization message is HL7 v2.5. Most existingimmunization repositories are using HL7 v2.31. It is difficult to justify theexpense to bring legacy system to current standards. This document shows an Immunization Management Capability technicalsolution; it does not address the more challenging Service Contract neededamong stakeholders (e.g., agencies, states, hospitals). Project Value Use Case One of the most difficult challenges facing healthcare organizations making ITinvestments today comes from deciding whether to go all-in with a particularvendor, or whether to self-integrate components from multiple vendors. Theappeal of the single-vendor solution is strong no finger-pointing, out-of-the-boxintegration, [US-based] EHR certification via the Certification Commission forHealthcare IT (CCHIT), and so on. This is contrasted with seemingly increasedrisk and work involved in a multi-vendor solution involving integration. A multi- vendor SOA solution can offer compelling best-of-breed options; where, a SOApromotes an easier integration and alignment across suppliers into a cohesive,testable and certifiable architecture. We demonstrated an approach that can buildand present consistent Interoperability Specifications (IS) and conformancecriteria for both best-of-suite and best-of-breed components and their exchangearchitecture. Having these ISs, exchange architectures, certification criteria andassociated business cases is the appropriate due diligence needed to help justifya best-of-suite vs. best-of-breed decision. Suggested SAIF ECCF Specification Stack Template Immunization Management ECCF Specification Stack
Subject Specification Viewpoint Why Policy Information What Content Computational How Behavior Engineering Where Implementation CIM (Conceptual) Inventory of Use Cases Capabilities-Services Requirements Contracts Stakeholders Business Scope Business Vision Business Objectives Policy & Regulations Domain Entities Roles, Activities, Associations. Information Models Conceptual Domain Inventories of Capabilities-Components, Functions-Services. Accountability, Roles Behaviors, Interactions Functional Profiles, Interfaces, Contracts Conceptual Functional Service Specifications Inventor of Platforms/ Environments. PIM (Logical) Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of architectural layers Components and Associations Localized Constrained Project Message Content Specifications Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts Existing Platform models, Capabilities, Libraries and Versions. PSM (Implementable) Business Nodes Business Rules Business Procedures Business Workflow Technology Specific Standards Database Schemas Message Schemas Transformation Schemas (e.g., XSD) Automation Unit Technical Interfaces Technical Operations Orchestration Scripts Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings SAIF Lessons Learned (slide 1 of 3)
An ECCF SS can be presented as an Architectural Executive Summaryor Information Exchange Architecture to add value to a project. A mature ECCF SS must be clear, complete, concise, correct, consistentand traceable, as a whole. ECCF documentation is misleading by sayingthat viewpoints must be horizontally consistent and vertically traceable. Architectural artifact granularity may not match ECCF categories (e, g,.component data and functions) SAIF Lessons Learned (slide 2 of 3)
The ECCF placement of architectural artifacts is not always intuitivelyobvious (e.g., structural specifications of modules and their information). Arguable, many of the Table 5 artifacts might be in both the Enterpriseand Computational Viewpoints, such as: Functional and non-functional Requirements Stakeholders and their roles and capabilities Use Case inventory and Use Case Specifications Capabilities and their Services Component inventory Function-Service inventory Contracts and business rules Strict viewpoint traceability would require all of the above artifacts being in the Computational Viewpoint. SAIF Lessons Learned (slide 3 of 3)
A value set of architectural artifacts, clear definitions and an ontology isneeded. Because of ambiguity, some architectural artifacts are listed inmultiple cells having different purpose and contents in the respective cells(e.g., business vs. requirements level and design level capability andcontracts). Within the ECCF, Function and Service mean the same thing,considering that the difference between a well specified function and aservice is that a service is public, reusable and has an associated ServiceAgreement or contract also known as a Distributed User ResourceSharing Agreement (DURSA). Questions? Nancy.Orvis@tma.osd.mil Stephen.Hufnagel.ctr@tma.osd.mil
BACKUP HL7 EHR SD RM Project EHR System Design Reference Model
Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture Healthcare SOA Reference Architecture Enterprise Information Model From HL7 and HITSP Artifacts Presented at HL7 Atlanta Meeting, January 2010 Details available at Dir Health Stds Participation Architect & System Engineer Last Updated 14 May 2010 EHR-SD RM Project Description and Plan
PROJECT DESCRIPTION: HL7 EHR System Design Reference Model (EHR SD RM) This project will mature the April 2008 Healthcare Services Oriented Reference Architecture (H-SOA-RA) version 1.0 into H-SOA-RA Version 2.0, for HL7 Architecture Review Board (ArB) consideration, and then integrate it into an EHR System Design Reference Model (EHR-SD RM), using the HL7 SOA-Aware Enterprise Architecture Framework (SAIF), HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS), EHR System Functional Model (EHR-S FM). Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by maintaining Information Exchange Requirements (IERs) and Data Requirements (DRs) traceability. Mapping and analysis of the HL7 product portfolio against the EHR-S FM will be used to integrate the reference architecture with HL7 product lines and initially mature the resulting model as a technical white papers, then an informative reference model and finally a standard reference model. An HSSP based prototype case study architectural specification will be built to validate the effort. Phases: For Project Information, see EHR SD RM Framework Populate the framework with HL7 EHR-S Functional Model content, candidate healthcare Information Exchanges, HITSP capabilities/ services and data architecture Information Model Loosely-coupled top-down Framework Rigorously specified bottom up structure/ content based on HITSP Data Architecture Socialize EHR SD RM (HL7 Meeting, Jan 2010) Collaborate with others within HL7 (ongoing) Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study(May 2010) Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept) HL7 Informative ballot (Oct 2010) HL7 Normative ballot(Oct 2011) 1 - Populate a framework of candidate healthcare services, with IERs, based on SAIF service categories Define priority Information Exchange Requirements (IERs) Define priority Data Requirements (DRs) along with IERs Map IERs and DRs to the framework of candidate healthcare services Build Catalog of candidate Services from 2008 H-SOA-RA work Show AHIC-HITSP traceability (e.g., AHIC IERs to HITSP ISs to standards) Show NHIN traceability (align with NHIN services) Show CCHIT traceability (align with CCHIT test criteria) Compare and contrast framework of candidate healthcare services with Canada Infoways SOA and/or other SOA 2 - Define EHR-SD RM Map Priority IERs and DRs to EHR-S FM Map candidate services to EHR-S FM Define EHR-SD RM based Business Transformation Architecture methodology for Identify gaps and overlaps in HL7s portfolio Identify artifacts that do not now exist but are indicated in the EHR-S FM Identify the extent of duplication that may exist across HL7 artifacts 3 - Create prototype EHR-SD RM validation case study prototype, using AHIC-HITSP Public Health and Emergency Response use cases and Interoperability Specifications Services Aware Enterprise Architecture Framework (SAIF) HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS) and HL7 HSSP Practical Guide for SOA in Healthcare sample health example specifications Include mapping to MHS and DOD specific IERs and DRs Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study To show HITSP, NHIN and CCHIT conformance criteria, use OMG Object Constraint Language and/or OWL Semantic Ontology specification language Contents Constructing a Future State EHR Reference Architecture HL7 EHR System Functional Model (EHR-S FM) Healthcare SOA Reference Framework HL7 RIM (Reference Information Model) HITSP Harmonization Framework HITSP Constructs HITSP Data Architecture HITSP Clinical Document Components HITSP/C83 Data Module Categories EHR Way Forward Business Architecture Specification Framework Future State EHR Reference Architecture Adding ARRA and FHIM Basic UMLLegend Abbreviations PART II: HL7 SAIF, Requirements Management, Architecture and Governance Processes PART III: Prototype (Immunization and Adverse Event Reporting) Constructing a Future State EHR Reference Architecture
OBJECTIVE:A system agnostic Future State EHR Business Architecture (BA)specified with alexicon, based upon HITSPs data architecture, HL7s SystemFunctional Model (EHR-S FM) and HL7sReference Information Model (RIM). A Health IT EHR BA can be modeled as clinical stakeholder requirements andtheirworkflow-orchestration of HL7 RIM compliant HITSP data modules manipulated by HL7 EHR-S FM functions. NIEM Information Exchange Package Documents An EHR Information Model, for a project or enterprise, can be constructed fromthe HITSP data models managed by the EHR Functions used within the EHR BA,categorized using the HL7 RIM Entity, Role and Actionfoundation classes. These concepts are the topic of this presentation HL7 EHR System Functional Model (EHR-S) > 160 System Functions in 4 level categorization (separate spreadsheet available for full enumeration) EHR-S FM functions can be grouped into Service Components aka Capabilities (e.g., Lab Order Capability, which does eligibility and authorization function as well as lab order function). System Functions Other O Electronic Resource Planning (ERP) O Finances O Other NOTE: Other Category - The EHR-S model does NOT include ElectronicResource Planning (ERP) / Logisticsand Financial components, which are needed for completeness of a Health IT Enterprise. 18 Healthcare SOA Framework Based on HL7 EHR System Functional Model & Thomas Erls SOA Layers
HL7 System Functions Direct Care Supportive Information Infrastructure Other Business Process Value Chains Composite Services Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Core Business Functional Areas + Focal Classes Entity Information Management Reporting and Management Agnostic Services C r o s sT e c h n I c a lCommon S e r v I c e s (e.g., Security, Privacy, Auditing, Logging) Application Ambulatory Care Systems, In Patient Care Systems Logistics Systems Financial Systems Decision Support Systems Data Marts Repositories Business Objects Implementation Profiles Integrated Healthcare Enterprise (IHE) Profiles Analysis Profiles CommunicationsProfiles/Stacks Implementation Profiles Re: Focal Classes: The issue is less the idea of a focal class than a business focal class. The difference is that when you model the service, you are generally modeling a service that willexpress the state changes of a business. For example, via analysis, you would find the states of a business focal class (canceled, new,active, signed, finalized in lab orders for example) and the trigger events that would correspond to state changes ("a lab is ordered", "alab is canceled", "a lab specimen is corrupted", and so on). You could say that a "patient" is a focal class, but a patient ID service generally doesn't expressoperations to modify the state of that "object". Rather, a patientID service would generallyencompass operations that would express information about the class (reconcileID or lookUpID,eg) rather than tying the service functional components to changes in the state of that class. It is not a subtle distinction - most clinical domains are focused on a focal class (an order, anencounter, an appointment, a schedule, a lab). A business service is focused with exposing that class to the enterprise. Infrastructure services (or the subset information services) are generally function calls or basedon exposing sets of information. The functional profiles of the service are generally not focusedon the state of the underlying information or in the trigger events that modify the state of thatinformation. They tend to be focused along different lines - typically along the lines of aninformation profile (a RIM-based patient class, eg, or a CDA-based CCD). The focal class is explicit in a business service, generally implicit in other services. 19 19 HL7 EHR_S-Based Functional Architecture/Services Analysis
ETC Infrastructure Functions Manage Business Rules Interoperability Infrastructure Services Security Policy Records Management Audit Terminology Registry Workflow Business Rules etc Terminology Unique ID, Registry, and Director Primary Care Critical/Emergency Care Dental Non-Surgical Specialty Care Laboratory Nursing Pharmacy Population Health Behavioral Health ETC. Information and Records Management Security Lines of Business Record Management Manage Patient History Preferences, Directives, Consents, and Authorizations Core Clinical Services Entity Identification Resource Location and Updating Services Decision Support Orders Management Scheduling Image Management Etc. Summary Lists Management of Assessment Cross-Cutting Direct Care/ Support Functions Care Plans, Treatment Plans, Guidelines, and Protocols Orders and Referral Management Documentation of Care, Measurement, and Results Record Patient Specific Instructions Clinical Decision Support Clinical Workflow Tasking Support Clinical Communication Support Knowledge Access ETC ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH IDENTITY TERMINOLOGY AUTHORIZATION SCHEDULING COREBUSINESSSERVICES SUPPLY CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT s DECISION SUPPORT PERFORMANCE DATA MANAGEMENT 21 INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together
Ancillary Systems INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together LABORATORY PT/OT/SPEECH RADIOLOGY PHARMACY SPECIALTY CARE RESPIRATORY CARDIOLOGY DIETARY IDENTITY TERMINOLOGY Inter-Service TEST ONLY AUTHORIZATION INPATIENT SCHEDULING Inter-Agency Federated Business Services SUPPLY CHAIN: (ORDERS/CHARGES) Core Business Services ER DOCUMENT RECORDS MANAGEMENT ASU Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc. DECISION SUPPORT Across Providers PERFORMANCE CLINIC DATA MANAGEMENT OUTPATIENT OTHER ANALYTIC Agnostic Services SUPPORT Data sets are defined for each system functional-capability-service module IT PLATFORM 22 HL7 RIM (Reference Information Model) Six Core Classes Defining a Semantic Framework which Maintains Clinical Data Context ENTITY ROLE ACT (aka ACTION) Participation Role link Actrelationship ACT something that has happened or may happen Entity a person, animal, organization, or thing Role a responsibility of, or part played by, an Entity Participation the involvement of a Role in an Act Act Relationship a relationship between two Acts Role Link a relationship between two Roles. The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages. Language / communication The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility) HITSP Constructs A HITSP Interoperability Specification (IS) defines a business context, supports a businessworkflow, constrains and orchestrates underlying constructs. A HITSP Capability (CAP) is a specification that assembles HITSP constructs to fulfill a businessneed for information exchanges. To use a Capability, an Interoperability Specification or animplementation conformance statement must assign Systems to one or more Capability SystemRoles and identify how the Capability Options are to be addressed. The use of a Capability shall: for each assigned Capability System Role, the responsibilities of the assigned System Rolemust be supported, includingall interfaces specified by the underlying HITSP constructsaccording to the conditions specified for the assigned System Role. If a Capability option is selected, the implementation must conform to the Capabilitysspecifications for that option. A HITSP Service Collaboration (SC) binds communications infrastructure, security and privacyconstructs together. A HITSP Transaction Package (TP), Transaction (T), Component (C) is where standards-basedInterface Design Specifications are specified and conformance requirements are defined. HITSP Harmonization Framework
IS Capability Service Collaboration Transaction, Transaction Package Components IS = Interoperability Specification Addressing Business Needs Available for Independent Implementation Providing Infrastructure, Security, Privacy Defining Information Content Data Architecture Base and Composite Standards HITSP Data Architecture within HITSP Harmonization Framework
HITSP Documents are available at Detailed HITSP Data Architecture is available online at GREEN indicates reusable elements HITSP Clinical Document Components
HITSP Reuse Paradigm: With HITSP/Capability Communication of Structured Documents, a HL7 Clinical Data Architecture (CDA) document can be composed, from any group of C83 data modules, and then it can be communicated. Benefit: agile system interoperability. HITSP/C83 Data Module Categories
Module Category Description Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person Support Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient Insurance Providers and Payers Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly Allergies and Drug Sensitivities This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses Medications This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities Immunizations This includes data describing the patient's immunization history Vital Signs This includes data about the patients vital signs Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and Procedures This includes data describing procedures performed on a patient Family History Data defining the patients genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patients health Social History Data defining the patients occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patients health Medical Equipment Medical Equipment includes implanted and external medical devices and equipment that a patients health status depends on, as well as any pertinent equipment or device history Functional Status Data defining the patients functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient Requirements Analysis Interface Design Analysis
EHR System Design Reference Model (EHR SD RM) Constructing a Future State EHR Reference Architecture Functional Analysis Object Analysis Requirements Analysis Interface Design Analysis Service Analysis Value Proposition of Standards Based Approach
Analysis Pre-Done: Analysts from throughout industry have vetted and contributed to the development of thorough specifications Less Customization: COTS vendors are already building applications to meet these specifications. Comprehensive View: Standards provide a way to ensure that requirements and design address all of the necessary issues Lack of unexpected dependencies late in project: All functions and specifications have been pre-analyzed and defined Better Interoperability:Standards based approaches will ensure development between all stakeholders are able to communicate at the project and technical level Across Project Visibility: Normalized requirements and design would allow for apples to apples comparison across the portfolio Basic UML Legend Abbreviations B-Case is Business Case BPM is Business Process Model
CCD is Continuity of Care Document CCHIT is Certification Commission for Health Information Technology CDRL is Contract Deliverable DBT is Defense Business Transformation IHE is Integrating the Healthcare Enterprise NHIN is National Health Information Exchange PCC is Patient Care Coordination RM-ODP is Reference Model of Open Distributed Processing SOA is Service Oriented Architecture PART II: Requirements Management, Governance, Architectural Processes and HL7 SAIF
EHR SD RM within the Requirements and Architecture Development Cycle The HL7 Services-Aware Interoperability Framework (SAIF) HL7 SAIF ECCF Specification Stack HITSP Within HL7 SAIF ECCF Specification Stack HL7, HITSP, FHIMS and NHIN Within HL7 SAIF ECCF Specification Stack Federal Enterprise Architecture (FEA) www.whitehouse.gov/omb/egov
Performance Reference Model - The FEA PRM is a framework to measure the performance of major IT initiatives and their contribution to programperformance. The PRM leverages performance measurement best practices from the public and private sectors, including the Balanced Scorecard,Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and the theory of constraints. There is an increasedemphasis placed on linkage of investment to agency program performance and the PRM will help agencies produce enhanced performanceinformation. Furthermore, the PRM will assist in: improving the alignment of program goals and objectives with Mission Area goals and objectives;improving communication of program contributions such as technology (input) to outputs and outcomes; and in identifying improvement opportunitiesthat span traditional organizational boundaries. Business Reference Model - The Business Reference Model (BRM) is a functional-driven framework for describing and organizing the day-to-daybusiness operations of the Federal Government into Lines of Business (LOBs), independent of the agencies that perform the business operation. TheBRM is the first layer of the Federal Enterprise Architecture and it is the organizing construct for the analysis of the other four reference models:performance, service components, data, and technology. Service Component Reference Model - The Service Component Reference Model (SRM) is a functional framework to evaluate to identifygovernment-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services deliveredby the government and assess if there is an opportunity to group like services and create leverage opportunities, such as reuse or shared services. Data Reference Model - The Data Reference Model (DRM) describes at an aggregate level, the data and information required to support the Lines ofBusiness (LOBs). The three elements of data exchange that have been standardized include data description, data context, and data sharing.Establishing a common data model streamlines the information exchange process within and across the Federal Government and facilitates the abilityto identify duplicative data resources. Technical Reference Model - The Technical Reference Model (TRM) establishes a common technical framework for categorizing standards,specifications, and technologies that support and enable the delivery of services. This framework can be leveraged to support the development,delivery, and exchange of business and application components (Service Components) that may be leveraged in a Component-based or ServiceOriented Architecture (SOA). Furthermore, it also serves as the foundation to advance the re-use of technology and best practices from each of theService Components on a government-wide basis. Linking Business and Technical Architectures EHR System Design Reference Model (EHR SD RM)
Supporting Requirements/ Architecture Development Cycle PROCESSINPUTS -Required Capabilities -Environments -Constraints EHR System Design Reference Model Capabilities, Functions, Information and Information Exchanges Stakeholder Requirements Definition Functions Dependencies Conformance Criteria Conformance is a recognition offormal testing, that prove that a system provides 100% support for a given standard. Requirements Loop Interface Specifications Requirements Analysis Specifications Loop Test Specifications Architectural Specifications Verification & Validation Loop Test Loop PROCESSOUTPUTS -System Architecture, -Test Specifications -Configuration ManagementBaselines 36 EHR SD RM Supporting Requirements/ Architecture Development Cycle
Stakeholder Requirements What is the system supposed to do? Where will the products of the system be used? Under what conditions will the products be used? How often?How long? Who will use the products of the system? Requirements Analysis (HOW? using Action Verbs) Analyze functions and Services Decompose higher level functions to lower level functions Allocate performance requirements to the functions Architecture Design (Which hardware/ software elements) Define the physical architecture Each part must perform at least one function Some parts may perform more than one function Test Specifications How Requirements-Specifications are validated Requirements Loop Ensure all requirements are covered by at least one function Ensure all functions are justified by a valid requirement (no unnecessary duplication) Design Loop Ensure all functions are covered by at least one hardware or software element Ensure all elements of physical architecture are justified by a valid functional requirement (no unnecessary duplication) Verification & Validation (V&V) Loop Each requirement must be verifiablethat the solution meets requirements and validated that it meets the users needs and expectations. V&V can be accomplished by: Inspection, Analysis, Demonstration, Test Test Loop Ensure all information is covered by test specifications Ensure all interfaces are covered by test specifications EHR SD RM Supporting Requirements, Governance & Architectural Processes The HL7 Services-Aware Interoperability Framework (SAIF)
SAIF Contains: Enterprise Conformance and Compliance Framework (ECCF) is based on RM-ODP Behavioral Framework (BF) Interoperability Scenarios supporting the RM-ODP Computational Viewpoint Governance Framework (GF) Governance is the overarching policy structure and set of related processes by which agroup exercises its authority and demonstrates accountability for accepted responsibilitieswithin a particular jurisdiction. SAIF Principles: Applicable within each of HL7s three Interoperability Paradigms (IPs), (i.e., messages, documents, and services). Provide support for measurable conformance and compliance. Define appropriate governance structures and processes. Provide support for directly implementable solutions. Address the growing disparity between the various solution sets emerging from HL7. Utilize existing V3/RIM artifacts and expertise to the maximum degree possible. HL7 SAIF Responsibilities Conformance and Compliance Framework (ECCF)
Policy Why Content What Behavior How Implementation Where Comutation Traceable Consistency HL7 SAIF Specification Stack Views Conformance and Compliance Framework (ECCF)
Topic Specification Enterprise / Business View WHY Information View WHAT Computational HOW Engineering WHERE Conceptual Business Context, Reference Context Domain Analysis (Information) Model Collaboration Analysis, Functional Profile(s), Service Roles and Relationships Existing Platform capabilities Platform- Independent Business Governance Project-oriented Domain Information Model, Constrained Information Model, Localized Information Model, Hierarchical Message Definition Collaboration Types, Interface Specification and Functional Groups, Interaction Types and Collaboration Participations, Contracts Parts Existing Platform models, libraries, etc. Specific Rules, Procedures Localized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Policy Content Behavior Implementation Policy Content Behavior Implementation Traceable Consistency HL7 SAIF ECCF HITSP Within HL7 SAIF ECCF Specification Stack
Topic Specification Enterprise / Business View WHY Information View WHAT Computational HOW Engineering WHERE Conceptual Business Context, Reference Context Domain Analysis (Information) Model Collaboration Analysis, Functional Profile(s), Service Roles and Relationships Existing Platform capabilities Platform- Independent Business Governance Project-oriented Domain Information Model, Constrained Information Model, Localized Information Model, Hierarchical Message Definition Collaboration Types, Interface Specification and Functional Groups, Interaction Types and Collaboration Participations, Contracts Parts Existing Platform models, libraries, etc. Specific Rules, Procedures Localized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Policy Content Behavior Implementation HITSP Security Framework HITSP Data Architecture HITSP Capability Harmonization Requests/ Use Case HITSP Capability HITSP Interoperability Specification HITSP Component HITSP Transaction, Transaction Package and Service Collaboration Traceable Consistency HITSP, HL7, HITEC, FHIMS, NIEM and NHINWithin HL7 SAIF ECCF Specification Stack
Topic Specification Enterprise / Business View WHY Information View WHAT Computational View HOW Engineering WHERE Conceptual Business Context, Reference Context Domain Analysis (Information) Model Collaboration Analysis, Functional Profile(s), Service Roles and Relationships Existing Platform capabilities Platform- Independent Business Governance Project-oriented Domain Information Model, Constrained Information Model, Localized Information Model, Hierarchical Message Definition Collaboration Types, Interface Specification and Functional Groups, Interaction Types and Collaboration Participations, Contracts Parts Existing Platform models, libraries, etc. Specific Rules, Procedures Localized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Policy Content Behavior Implementation HITEC MU HL7 EHRS FM HITSP Security Framework HL RIM FHA FHIMS HITSP DA HITSP Capability HL7 EHR-S FM Harmonization-Requests/ Use Case HITSP Capability Tomcat, JBoss, J2SE, Eclipse, GlassFish ESB, OpenSSO HITSP Interoperability Specification (IS) HITSP Component NIEMInformation Exchange Package NIEM, HITSP Transaction, Transaction Package and Service Collaboration HSSP and NHIN-Connect Services Traceable EHR-S FM is EHR System Functional Model EHR SD RM is EHR System Design Reference Model HITEC MU is 2009 HITEC Act Meaningful Use Objectives/ Criteria NIEM is National Information Exchange Model RIM is Reference Information Model FHIMS is Federal Health Information Model & Standards DA is Data Architecture Consistency PART III Prototype EXAMPLE
Vaccination and Adverse Event Reporting Prototype AHIC Use Cases EHR-S FM HITSP Capabilities Information Model EHR-SD RM Prototype [2008 AHIC Use Cases] Immunization and Response Management (IRM)
The IRM AHIC Use Case and HITSP Interoperability Specification are intended to support current interoperability approaches between EHRs and Immunization Information Systems while allowing for a migration toward emerging interoperability implementations and document sharing environments where PHRs are able to be included in the information flow The Interoperability Specification also allows for basic electronic information exchanges to enable requirement communications and alerting mechanisms and to lay the foundation for future clinical support capabilities Scenario 1: Vaccine and Drug Administration and Reportingand Scenario 2: Vaccine and Drug Inventory Reporting EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges EXAMPLE ARTIFACTVaccine and Drug Administration and Reporting Use Case Full use case available at: EHR-SD RM Prototype Information Exchange Requirements (IERs) Vaccine and Drug Administration and Reporting Use Case IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER40 Query for existing data IER42 Request/receive medical concept knowledge IER54 Query/response for clinical message data IER67 Send/receive clinical message IER78 Send/receive Vaccine Inventory Requirements IER79 Query/response for inventory usage data IER80 Send/receive Vaccine Inventory Data For details, see HITSP IS 10 Immunization and Response Management, available at EHR-SD RM Prototype Data Requirements (DRs) Vaccine and Drug Administration and Reporting Use Case
DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View For details, see HITSP IS 10 Immunization and Response Management, available at EHR-SD RM Prototype HITSP Security and Privacy Vaccine and Drug Administration and Reporting Use Case IER01 Provide authorization and consent IER02 Send data over secured communication channel IER03 Create audit log entry IER04 Synchronize system time IER05 Verify entity identity IER06 Provide proof of document integrity and origin IER55 Anonymize patient identifiable data IER56 Pseudonymize patient identifying information For details, see HITSP IS 10 Immunization and Response Management, available at EHR System Functional Model Interoperability Specifications
EXAMPLE ARTIFACTHL7 Requirements and Certification Criteria and HITSP Design HL7 EHR System Functional Model HITSP Interoperability Specifications EXAMPLE ARTIFACT EHR-S Requirements EXAMPLE ARTIFACT EHR-S FM Dependencies EXAMPLE ARTIFACT HITSP Interoperability Design Specifications IS10 IRM HITSP Constructs Mapped to Standards Contact Information Nancy Orvis Chief Integration Architect Office of the Chief Information Officer DoD Military Health System Steve Hufnagel Enterprise Architect, TIAG contract support