Recommendations for
iEHR-OSEHRA Win-Win Success
Presentation to
OSEHRA Board and than
Interagency Program Office (IPO)
September 6, 2012-d
Seong K Mun PhD, OSEHERA President
Stephen P Hufnagel PhD, Architecture Work Group
1
Proposed
iEHR Technical Vision
iEHR (integrated Electronic Health Record) is a component-based HSP
(Healthcare Services Platform) for the standards-based integration of
interoperable COTS (Commercial Off the Shelf), GOTS (Government Off the
Shelf) and OSC (Open Source Component) applications and services;
furthermore, OSEHRA is the marketplace for pre-tested and pre-certified “plugand-play” iEHR capabilities, which can be configured to meet operational
needs, in accordance with scope-of-practice, organizational policy, iEHR
governance and jurisdictional law.
2
Discussion
Open–Source Components (OSC) require clearly-defined standards-based
component-boundaries, including web services:
• OSC can accommodate new, unexpected, or subtly differing requirements
among health providers, possibly due to improved medical domain
knowledge, insight and innovation.
• OSC allows users or small-businesses to focus on a limited domain
• OSC provides risk-mitigation alternatives in case COTS does not work or is
inadequate, or
• OSC may allow a less expensive option, where licensing costs are
prohibitive, such as for education and non-governmental organizations.
3
Objectives
1. iEHR publish its APIs (Application Program Interfaces)
– Standards-based information exchanges
– SOA Suite and Enterprise Service Bus
– Virtual Data Repository (VDR) and User Experience (UX) Framework
– Clinical/Business components/services
2. Open-source competes on “best-value” to the Government basis
– Better Modularization, Reuse and Security, due to extensive use and review
– Lower Total Lifecycle Cost, due to shared investment and no license fees
3. Open-Source Solutions are a COTS risk-mitigation strategy.
– Repurposed VistA can transition as one-or-more iEHR components
– Funding is needed to develop, integrate, test, certify open-source alternatives
– Open-source is not free
4
Process Issues
Hindering Success
1. Current capability RFI/RFP process is backwards
– Specifying iEHR capabilities as “systems” will result in stovepipes
2. RFI / RFP pre-condition must include:
– Published iEHR Healthcare Services Platform (HSP) Specifications
• Data and Terminology models
• Infrastructure Services and Business / Clinical Services
• User Experience (UX) Portal Framework and
• Virtual Data Repository (VDR)
3. Individual capabilities must build upon the HSP foundation
– iEHR Service Governance must prevent duplicative services
– Service catalogue / registry must be accessible to all
5
For Open-Source
to Compete, we need
• iEHR to be a Healthcare Services Platform (HSP), with well-specified
– Data and Terminology Models, Infrastructure, Business and Clinical Services
– User Experience (UX) Portal Framework and Virtual Data Repository (VDR)
• All medical specialty-domains are an orchestration of (replaceable) HSP
services; where, each medical-specialty domain has its own
– data-and-terminology models, business-rules, workflows, reports and displays
– in accordance with scope-of-practice, organizational policy, iEHR governance and
jurisdictional law.
• An iEHR Integration Contractor to Operationalize Innovation
– Specify HSP data and service interfaces, prior to RFI/RFP releases
– Facilitate open-source alternatives within standards-based Service Oriented Architecture
• Small Business Innovation Research or similar VA-I2 funding to catalyze
– Open-Source Community participation without onerous contract-vehicle requirements
– Vista open-source component/capability repurposing to iEHR
6
Backup / Questions?
iEHR N-Tier Conceptual Architecture
7
Assumptions
1. iEHR is intended to be a Healthcare Services Platform (HSP)
– emphasizing the reuse of high quality
• clinical/business and ESB infrastructure services and
• User Experience (UX) framework
• Virtual Data Repository (VDR)
2. The HSP is intended to be an interoperability-framework for
– COTS (Commercial Off-The-Shelf),
– GOTS (Government Off-The-Shelf) and
– open-source components.
8
Assumptions
3. All medical specialty domains, should be an orchestration of
– HSP services;
– each medical-specialty domain having user-managed domain-specific
• Capabilities/Applications,
• data-and-terminology models,
• business-rules,
• workflows,
• user-interactions and reports
in accordance with scope-of-practice, organizational policy, iEHR governance
and jurisdictional law.
9
Clinical/Business Services
1.
2.
Virtual Patient Record (VPR) Service to collate data from legacy sources
–
RLUS (Retrieve, Locate Update Service) fronted databases and COOP / performance caches
–
CIIF (Common Information Interoperability Framework)
Care Coordination Services enabling “medical-home” type patient-care management
– Problems, including Diagnosis and Allergies
– Treatments, including Medication List and Procedures
– Diagnostic Test Results, including Radiology, Pulmonary Function Tests, Electrocardiograms,
Laboratory, Microbiology, Pathology
– Demographics, Advance Directives and Patient / Family Preferences
3.
Orders Management Service, ideally, provided within the Care Coordination Service
4.
Note Writer Service, ideally, provided within the Care Coordination Service
5.
Inventory and Funds Control Management Services
6.
CDS (Clinical Decision Support), possibly built from the Business Rules Service
7.
UX Portal Framework enabling SSO/CM/AM/ID and medical-domain-specific portlets
SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification).
10
Design Principles
The recommended solution separates and componentizes:
– Data, Business Rules, Application Code
– Presentation framework services
– Common services
• SOA Suite, Enterprise Service Bus
• Security, UX User Experience) Framework and Reporting Tools
• Scheduling
– Clinical/Business Services
– Orchestrated Business Workflow
– Business “Value Chain” Services
11
Medical Department
Customization
• The recommended solution uses orchestrated core HSP services to support
–
–
–
–
local work-flow,
domain specific data-and-terminology
both enterprise and local business rules
UX
in accordance with scope of practice, organizational policy, iEHR
governance and jurisdictional law.
• for FOC, the 3M HDD will be used; and,
• for FOC the CIIF data and terminology services will be used.
12
KEY TO SUCCESS is iEHR
Software Development Kit
1.
Joint DOD & VA Information Exchange (IE) tool: legacy & iEHR IEs mapped-to
1.
capabilities, activities, system functions, content & exchange standards, information
and terminology model views
2.
Joint DOD & VA SOA “Enterprise Application Architecture (EAA)” document, which
discusses principles and guidelines for development or acquisition of components within
a Service Oriented Architecture (SOA)
3.
Joint DOD & VA “SOA Technical Framework (SOA TF)” document, which discusses
SOA specification and implementation guidelines.
4.
Joint DOD & VA “SOA Governance Framework (SOA GF)” document, which discusses
the required governance to support a SOA.
5.
Joint DOD & VA “Technical Standards Profile (TSP)” document, which lists the DOD-VA
information sharing approved standards for interoperability.
6.
iEHR “Technical Reference Model (TRM)” document, which list approved software
components and tools for use within iEHR
13
KEY TO SUCCESS is
Software Development Kit
7. iEHR Catalogue/Registry of Infrastructure Services, including ESB and
CIIF services
8. iEHR “CIIF Requirements and Architectural Vision” Document, which
provides a iEHR Conceptual View and lists non-functional
requirements (NFRs).
9. iEHR Catalogue/Registry of Core Business Services
10. iEHR Catalogue/Registry of Capability Services
11. Sample code, ether for direct use or which defines an API. Since we
can generate Java code directly from the HL7 v3 information models
with MDHT (Model Driven Health Tool), this is an important tool for
developers and integrators. This has been very useful, for example, in
CDA r2 exchanges.
14
KEY TO SUCCESS is
Software Development Kit
12. Similar to what NIEM does (we should create IEPD-like bundles for
people to download), we should include the relevant XML Schema and
XML based conformance tools (i.e. XPath expressions and/or
Schematron).
13. A human readable (PDF) implementation guide that defines the
interactions, the information models, value sets, standards used, and
the conformance criteria.
14. A separate IG for iEHR web services that discusses how to use the
CIIF, how services are orchestrated, how/when/why to use the
enterprise rules engine/workflow system/complex
planning/scheduling/event processing framework, logging/audit trails,
monitoring, security, overall design paradigm, etc.
15. A MDHT (Model Driven Health Tool) based validation engine to
support the BITE (Built In Test Environment).
15