VistA Architecture
D R A F T Talking-Points
For current PowerPoint file, go to
http://osehrca-mgmt.wustl.edu:8080/share/page/repository#filter=path%7C/User%2520Homes/stephen_hufnagel&page=1
open-source EHR custodial-agent
17-Jun-11
17-Aug-11 (estimated)
17-Oct-11 (estimated)
Contract Signed
Custodial Agent Established
Custodial Agent Fully Operational
www.OSEHRA.org , HufnagelS@OSEHRA.Org, editor
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 1
Preface
In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates
agreed on a common EHR technical architecture, data and services and exchange
standards for the joint EHR system (aka iEHR), where the joint EHR will include both
proprietary and open source software. The secretaries of the Veterans Affairs and Defense
Departments met on May 2 and June 23, 2011 to determine their next steps toward
developing a single electronic health record, for the two agencies.
“VA is developing an open source track to modernize VistA and will incorporate
the approach in the joint EHR", Shinseki said. “One of my objectives is to have minimal
disruption in the hospitals as we evolve from VistA to the joint EHR system What I think you
will see us do is replace modules, do incremental upgrades.” … “In five or 10 years, there
may not be one line of code left from VistA. And in my ideal world, the users will have no
idea that I have made any changes,” VA Secretary Eric Shinseki said.
“Our goals are to bring in as many private sector modules as possible and
selecting the same thing to run between VA and DOD so that we end up with a single,
common electronic health record system,” Roger Baker, VA CIO said.
This presentation is the start of the journey to implement the vision expressed above.
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 2
Executive Summary
“Open Source Electronic Health Record Agent (OSEHRA) is a notfor-profit corporation established under the sponsorship of the
Department of Veterans Affairs of the United States. The Office
of Information and Technology of VA is responsible for the
development and maintenance of the Veterans Health
Information Systems and Technology Architecture (VistA), VA’s
Electronic Health Record (EHR). The OSEHRA’s responsibility is to
facilitate the rapid rate of innovation and improvements of VistA
that have been isolated from private sector components,
technology, and outcome-improving impacts. This responsibility
is to be executed by adopting the open source business model
built within incipient VistA code base and migrate it to Open
Source EHR, which is an openly architected, modular, and
standard-based platform suitable for deployments in a variety of
healthcare settings, such as government, private, and
international.”
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 3
Open Source Principles
Principle 1: There are more smart, creative, innovative people outside of the organization than inside
Principle 2: Software is human Knowledge Transformed into Code…
It Needs Operators, Maintainers an engaged Community to Thrive
Principle 3: Closed projects die from intellectual starvation … Software is never a finished product
Principle 4: Attract Interested People … With Shared Goals … and, then Earn Their Trust!
Principle 5: Transparency, Transparency, Transparency …
Remove Walls and Locked Gates to Information
Principle 6: The Community is a Meritocracy based on Autonomy, Mastery and Purpose
Principle 7: Release Early … Release Often
Principle 8: Avoid Private Discussions
Principle 9: Establish Credibility … Forge Strong Relationships with other Open Source Communities
Principle 10: Welcome the Unexpected … Contributors Will Always Surprise … Listen Carefully!
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 4
Introduction
Distributed development without an architectural vision
is virtually impossible.
•
The architectural vision, presented here, is a pragmatic, but, non-prescriptive starting point, which will
be adapted based on the open-source community’s feedback.
•
An objective is that VistA’s architectural transition maintain interoperability with the legacy VistA
MUMPS and the DoD-VA iEHR architectural vision as well as accommodating commercial vendors.
•
The key to future-state VistA success is standards-based Virtual layers that support plug-and-play
applications (e.g., the smartphone application market model) and various data repositories.
Innovation is fostered at the component level and is Darwinian.
•
This approach must support
– legacy or modern hardware and software platforms, languages, applications and databases.
– scalability from minimal-cost individual-clinician-systems to enterprise massively-parallel highperformance grids running on commodity-hardware-platforms (i.e., amazon.com, google.com).
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 5
VistA Architecture
Outline
Conceptual View
–
–
–
–
–
–
–
–
2011 VistA Architecture: Conceptual View
Task 5.9 Manage EHR Open Source Architecture
Task 5.11 Manage EHR Open Source Product Definition
Future-State Architecture: Goal & Objective
Future-State Architecture: Conceptual View
Future-State Architecture: Notional List of Applications
Future-State Architecture: Legacy-Vista Problems Being Addressed
Software Product Certification
Getting Started
Backup
• SOA Approach
• 2011 VistA Packages
• Contact Information and Initial Plan
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 6
2011 VistA Architecture (Conceptual View)
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 7
Task 5.9 Manage EHR Open Source Architecture
TASK 5.9: The Custodial Agent shall provide a clear and accessible definition of the components of the
codebase, how they function, and how they interact. The Contractor shall provide, within thirty (30) days
after activation of the CA, initial documentation of the existing architecture and shall provide regular
updates, as needed.
DELIVERABLE: VistA System Architecture (SA) model. The SA model will be based-on and include
links-to the VistA documentation library * codebase, test fixtures and test and certification results . The VistA
SA tool will contain architectural artifacts, including but-not-limited to:
• VistA Components modeled as UML classes, showing
* The VistA Documentation Library is
– Component descriptions and functions
available at http://www.va.gov/vdl/
– Component-to-component dependencies
** help needed to identify these artifacts
– Component-to-data dependencies
– Links to VistA Documentation,* code,** test fixtures,** test reports,** certifications. **
•
•
•
Task 5.9 & 5.11 quarterly Contract-Deliverables (CDRLs) will be an SA-tool-generated report.
OSEHRA website will contain an SA-tool-generated HTML-navigable VistA SA model.
Future updates will be vetted within the open-source communities Architecture Working Group (AWG).
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 8
Task 5.11 Manage EHR Open Source Product Definition
TASK 5.11 (A)The CA shall maintain a definition of the Open Source EHR product including a functional
description of the software and features as well as supported components (such as client and server operating
systems, database managers, application program interfaces, etc.). The product definition shall include an
installable version of the EHR Open Source product. The Contractor shall provide an initial definition of the
Open Source EHR product within thirty (30) days following activation of the CA.
TASK 5.11 (B) The Contractor shall provide a product roadmap reflecting a series of product releases,
estimated to occur quarterly (e.g., beginning 17 Dec 2011).
DELIVERABLE: Over the first year, the Task 5.9 VistA SA model fidelity and deliverables will be incrementally
extended to include:
* Help required to access
– Application Program Interfaces (APIs)
or obtain copies of these
– Component functional-descriptions linked to VistA component UML classes
internal artifacts
• based on HL7 EHR System Functional Model (EHR-S FM),
** Help required from KRM
• Including EHR-S FM conformance criteria to support test and certification,
• Including ARRA Meaningful use objectives and criteria, mapped via EHR-S-FM,
• Including HHS mandated HITSP-constructs, mapped via EHR-S-FM,
• Including HHS/ONC EHR standards and certification criteria, mapped via EHR-S-FM.
– Interface Interconnect Agreements (IIA) & Database Interchange Agreements (DBIA) *
– Component-level codebase-analysis conclusions-and-recommendations & Aviva prototype *
– GT.M & Cache deployment environment components & APIs modeled as UML classes **
• Patch sequence order to update deployed systems (as distributed internal within VA) *
– Roadmap of configuration-baselines of product-deployment release-contents (quarterly)
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 9
Legend & Glossary for VistA System Architecture Model Elements and Constructs
3/23/2016
See Notes Page for Glossary
www.OSEHRA.org - 10
Future State Architecture
GOAL
Incremental
Little Impact on links
between components
(e.g., Interoperability)
Innovation
Modular
Innovation
OBJECTIVE
A change-immune domain-specific
component-architecture emphasizing
interoperable standards-based services,
resulting-in simpler, loosely-coupled,
and less-costly module-level innovation.
Great impact on
components
Little impact on
components
PROBLEM
Little innovation, long lead
times and high costs
resulting from complex
highly-coupled components
Architectural
Innovation
3/23/2016
Start
Great Impact on links
between components
(e.g., interoperability)
D R A F T Talking Points
Radical
Innovation
www.OSEHRAorg - 11
Future-State Architecture (Conceptual View)
3/23/2016
D R A F T Talking Points
www.OSEHRA.org -12
12
Future State Architecture
Notional List of Applications
Registration
Patient Education
NCAT (TBI Testing)
Disability Evaluation
Disease Management
Blood Mgmt.
Transient Outreach VA
Outpatient Orders Mgmt.
Optical Fabrication
Optical Ordering
Laboratory
Patient Education
XML Forms Tool
Inpatient Orders Mgmt.
Profiling DoD
Radiology Ancillary
Patient Self Reporting
Documents Mgmt.
Nursing Home VA
Environmental Health
Private Sector Data
Access
Registries
Dental Care
Global Image Access
Rehabilitative Care VA
Patient Consent
Nutrition Care
Pharmacy Mail Order VA
Medical Dental
Forensics
Medical Logistics
Genomics
Alerts and Reminders
Personal Health Record
Long Term Care VA
En-route care DoD
Anesthesia
Documentation
Document
Management
Emergency Dept. Care
Operating Room
Management
Special Duty
Programs DoD
Neurocognitive
Assessment Tool
(NCAT/TBI)
Patient Questionnaire
Occupational Health VA
Anatomic Pathology
Immunization
Patient Safety Reports
Occupational Health DoD
(Military)
Encounter Coding
Commander
Situational
Awareness
Consult and Referral
Management
Inpatient Pharmacy
Single Sign On (SSO)
Scheduling-Appointing
Outpatient Pharmacy
Barcoding
Clinical Context Mgmt.
Tele-Consultation
3/23/2016
Battlefield Care DoD
Inpatient Documentation
Business Intelligence Outpatient Documentation
D R A F T Talking Points
Utilization Mgmt.
Clinical Decision
Support
www.OSEHRA.org - 13
Software Product Certification Criteria:
Safe, Compliant and Functional (1/3)
Certification is the attestation and ultimately verification that the code is:
1. Safe: For the purposes of the certification process, code is safe when the
individual code units do not cause errors in other components of the system and the
code is robust to all code paths-and-conditions. We will certify code as safe using a
combination of:
• Regression Testing
– Test that each routine/function correctly performs operations
• Stress Testing
– Test the robustness of the system under all code pathways (exception handling)
Bold Blue indicates “supported by Architecture”
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 14
Software Product Certification Criteria:
Safe, Compliant and Functional (2/3)
Certification is the attestation and ultimately verification that the code is:
2. Compliant: For the purposes of the certification process, code is compliant when
it meets the agreed upon code contract and is adherent to all applicable external laws
and regulations. We will certify code as compliant using a combination of:
• Architectural Verification – architecture has been defined and the actual code is consistent
– defined community standards and conventions (SAC)
– Module-to module dependencies
– Module-to-data dependencies
• Interoperability Testing
– Test that all module APIs are defined and met
Bold Blue
indicates
“supported by
Architecture”
• Section 508 Testing
– Test that the User Interface is compliant with section 508 of the Rehabilitation Act
• Governance Compliance Testing
– Software Development Kit (SDK), Community Standards and Conventions (SAC), Licenses
• Privacy Protections and Systems Security
– Test that privacy and security requirements are defined and met
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 15
Software Product Certification Criteria:
Safe, Compliant and Functional (3/3)
Certification is the attestation and ultimately verification that the code is:
3. Functional: For the purposes of the certification process, code is functional when it
has a defined set of requirements; when its execution satisfies the defined requirements;
when execution occurs within an acceptable performance window; and when it satisfies
a customer need. We will certify code as functional using a combination of:
• Confirm that requirements have been defined and met
– Map functionality to test conformance criteria
• Performance Testing
– Verification that the system meets its key performance (speed, availability) specifications
• Customer Satisfaction is validation testing which is not part of the certification process;
but, it will be monitored as part of the Community Engagement function and will be
presented using the certification dashboard.
Bold Blue indicates “supported by Architecture”
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 16
Future State Architecture
Legacy- VistA Problems Being Addressed
1.
Innovation to revitalize VistA
2.
Interoperability among DoD, VA, IHS and purchased care partners
–
Heterogeneous legacy-implementation schemas, terminology & tools
3.
Transition from legacy systems and data to a future-state-architecture
4.
Agility to respond to rapid healthcare change and related legislation
5.
–
ICD 9  ICD 10
–
ARRA Meaningful Use Objectives and criteria Stages I, II, III
–
HHS Mandated HITSP-constructs and HHS mandated standards
High Costs of change and sustainment.
–
Separate DoD and VA systems
–
Semantic Interoperability among trading partners (e.g., consults and transfers-of-care)
–
Application acquisition or development
–
Commercial Off the Shelf (COTS) Integration
–
Sustainment
–
Test and certification
6.
Patient Safety issues resulting from software changes.
7.
Open Source Community Enablement
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 17
Future State Architecture
Outline
Conceptual View
Getting Started
–
–
–
–
–
–
–
Software Development Kit (SDK)
Security Principles
Security Services & Standards
Security Process
Enterprise Compliance & Conformance Framework
Approach to Architectural Traceability
Future-State Architecture: Addressing Legacy-VistA Problems
Backup
• SOA Approach
• 2011 VistA Packages
• Contact Information and Initial Plan
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 18
Future-State Architecture
Software Development Kit (SDK)
Draft Specifications needed by Fall 2011 *
1. Built-In-Test-Environment (BITE) Service Specification to support
automated fault-detection resulting from distributed ad-hoc partners & plugand-play applications.
– Model-Driven Health-Tool defines run-time schematron test fixtures.
– Performance-Monitoring-Component Service-Specification to trace runtime execution pathways and measure latency to support, system tuning,
automated testing and certification.
– Code-Coverage Regression-Test and Stress-Test Tool-Specification, to
support automated testing and certification of “happy path” and fault
recovery pathways.
– Cross-Reference Tool-Specification to automatically map module-module
and module-data dependencies and certify no unexpected changes.
– Pretty-Printer Tool-Specification to certify software-module Standards and
Conventions (SAC) & to do syntax verification and readability reformatting.
* Must be done in collaboration with DoD-VA joint iEHR initiative and open source community.
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 19
Future-State Architecture
Software Development Kit (SDK)
Draft Specifications needed by Fall 2011 *
2. SAIF ECCF Implementation Guide (IG) for documenting component
Interoperability Specifications, which will support new development,
repurposing, reimplementation, automated testing and certification.
3. SAIF ECCF Tool Specification to manage module Interoperability
Specifications, which will support new development, repurposing,
reimplementation, automated testing and certification.
4. ESB Services Specification of iEHR Tier 1-2 Application VirtualizationLayer of federated standards-based services.
5. Database Services Specification of iEHR Tier 2-3 Database
Virtualization-Layer of federated standards-based services.
6. Standards and Conventions (SAC), updated to modern SOA software
engineering practices, as defined by Thomas Erl.
* Must be done in collaboration with DoD-VA joint iEHR initiative and open source community.
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 20
SDK Benefits
Consistency across
– Architecture(s) for Legacy VistA transition to iEHR
– Services/ Engineering Service Bus (ESB)
– Interoperable Plug-and-Play Applications
– Ad-hoc Trading Partners (also requires CIIF)
– Interoperable Virtual Database APIs scalable from
• Legacy MUMPS-globals acting as a DB to CDR/HDR to HAIMES II to
• Massively-parallel high-performance grids running on commodity-hardware-bladeplatforms (i.e., amazon.com & google.com models).
– Acquisitions (SDK as GFI for RFIs and RFPs)
– VA, DoD and IHS offices, staff and contractors
– Open Source Community
3/23/2016
D R A F T Talking Points
21
NIST 7497 Security Architecture *
Design Principles
1. Perform Information Assurance Risk assessments of shared
information;
2. Create “master” trust agreements describing requirements for a
trust domain;
3. Separate authentication/credential management and
authorization/privilege management;
4. Develop data protection capabilities as plug-and-play services;
5. Maintain a standards-based, technology-neutral, and vendorneutral architecture.
* NIST IR 7497, Security Architecture Design Process for Health Information Exchanges (HIEs), Sept. 2010,
available at http://csrc.nist.gov/publications/PubsNISTIRs.html
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 22
NIST 7497 Security Architecture
Enabling Services
1. Risk Assessment is a Security and Privacy Principles, which means to identify security
and privacy risks to HIE operations based on threats, assets, vulnerabilities, and likelihood
of threat success.
2. Entity Identity Assertion (Authentication) is HITSP Construct * SC110 & C19, which
ensures that an entity is the person or application that claims the identity provided.
3. Credential Management is a Security Principles, which means to manage the life cycle of
entity credentials used for authentication and authorization.
4. Access Control (Authorization) is HITSP Construct * SC108 & TP20, which ensures that
an entity can access protected resources if they are permitted to do so.
5. Privilege Management is a Security Principles, which means to manage the life cycle of
an entity’s authorization attributes (e.g., roles, permissions, rules) for making access
control decisions.
6. Collect and Communicate Audit Trail is HITSP Construct * SC109 & T15, which defines
and identifies security-relevant events and the data to be collected and communicated as
determined by policy, regulation, or risk analysis.
* HITSP constructs are available at www.HITSP.org
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 23
NIST 7497 Security Architecture
Enabling Services
7.
Document Integrity is HITSP Construct * T31, which validates that the contents of a
document have not been changed in an unauthorized or inappropriate manner.
8. Secured Communication Channel is HITSP Construct * SC109 & SC112, which
ensures that the mechanism through which information is shared or transmitted
appropriately protects the authenticity, integrity, and confidentiality of transactions to
preserve mutual trust between communicating parties.
9. Document Confidentiality is a Security Principles, which means to prevent the
unauthorized disclosure of a document that is exchanged or shared.
10. De-identification is a Privacy Principles, which means to remove individual identifiers
from a health record, or replace them with other information such as pseudonyms, so that
it cannot be used to identify an individual.
11. Non-Repudiation of Origin is HITSP Construct * C26, which provides the proof of the
integrity and origin of data in an unforgettable relationship which can be verified by any
party.
12. Manage Consent Directives is HITSP Construct * TP30, which ensures that individually
identifiable health information is accessed only with an individual’s consent.
* HITSP constructs are available at www.HITSP.org
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 24
NIST 7407 Security Architecture
Web-Service Security-Standards
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 25
NIST 7497 Security Architecture
Notional Development Process
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 26
HL7 Service Aware Interoperability Framework (SAIF)
Enterprise Compliance and Conformance Framework (ECCF)
ECCF
Conceptual
Perspective
Logical
Perspective
Implementable
Perspective
Enterprise
Dimension
Information
Dimension
Computational
Dimension
“How” - Behavior
“Where” - Implementation
“Where” - Deployments
 Inventory of
• Domain Entities
• Activities
• Associations
• Information
Requirements
• Information Models
o Conceptual
o Domain
 Inventory of
• Functions-services
 Requirements
• Accountability, Roles
• Functional
Requirements, Profiles,
Behaviors, Interactions
• Interfaces, Contracts
 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
 Business Policies
 Governance
 Implementation Guides
 Design Constraints
 Organization Contracts
 Information Models
 Terminologies
 Value Sets
 Content Specifications
 Specifications
• Use Cases, Interactions
• Components, Interfaces
 Collaboration
Participations
 Collaboration Types &
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
 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
“Why” - Policy
 Inventory of
• User Cases, Contracts
• Capabilities
 Business Mission, Vision,
Scope
“What” - Content
Engineering
Dimension
Technical
Dimension
Five (5) Categories: Capability | Mission | Business Process | Infrastructure/Enterprise Architecture | Interoperability
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 27
Approach to Architectural Traceability
Core Projects
Interoperability Projects
Plan for New, Improved, Sustained or Sunset
Capabilities
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
CUIs
Architectural
Business
Viewpoints
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
CUIs
Inventory of Systems and their
Capabilities and Functions
CUIs
Architectural
Information
Viewpoints
System
Architecture
CUIs
CUIs
CUIs
CUIs
CUIs
Architectural
Engineering/Technical
Viewpoints
Innovation/ Prototype Projects
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Product Line
Inventory
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Architectural
Behavioral
Viewpoints
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Key to Traceability
Traceability is achieved by using Concept Unique (numeric) Identifiers (CUIs) from the HL7 EHR System Functional Model (EHR-S FM)
as attributes to all artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 28
Future State Architecture
Addressing Legacy-VistA Problems
1.
Innovation to revitalize VistA.
– Services within a standards-based component-architecture encourage lower-cost component innovation without
requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and avoids stovepipes.
2.
Interoperability among DoD, VA, IHS and purchased care partners.
– CIIF canonical information and terminology models can be used to map among heterogeneous system
information exchanges. By adopting common CIIF data, terminology, and communications standards; multiple
organizations can share and ultimately harmonize Electronic Medical Records.
3.
Transition from legacy systems and data to an interoperable EHR architecture.
– Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and opensource applications, scaleable databases and infrastructure to coexist.
4.
Agility to respond to rapid healthcare changes and related legislation.
– Services within a standards-based component-architecture encourage faster and lower-cost changes to be made
and tested within components without requiring enterprise-wide expertise and testing.
5.
High Costs of change and sustainment.
– Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and
infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeablecomponents can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built
In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. .
6.
Patient Safety issues resulting from software changes.
– Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety.
7.
Open Source Community Enablement
– Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications,
databases and infrastructure, which may be combinations of MUMPS, COTS, GOTS and open source code to
meet the specific-needs of various stakeholder-and-user communities.
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 29
Future State Architecture
Outline
Conceptual View
Getting Started
Backup
• SOA Approach to Putting the Pieces Together
–
–
–
–
–
–
–
–
–
EHR data reuse across encounters
Encounter within a Case Management Scenario
Hl7 EHR System Functional Model (EHR-S FM)
SOA Layers
SOA Service Model
Healthcare SOA Reference Architecture (H-SOA-RA)
Anatomy of an Ancillary System
INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together
Addressing Real Business Issues Through H-SOA-RA based
Integrated Requirements-Design
• 2011 VistA Packages
• Contact Information and Initial Plan
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 30
PROVIDERS’ EHR DATA REUSE
ACROSS EPISODES OF CARE
Previous Episode
Of Care EHR
Current Episode
Of Care EHR
Reusable Services
IDENTITY
3/23/2016
• Patient Demographics
• Provider Demographics
• Insurer Demographic
Data Must Be Verified
And Updated
Terminology
• Chronic Diagnoses
• Procedure History
Document
• Patient History
• Summary Lists
- Medication List
- Allergy/Adverse Reaction List
- Immunization
www.OSEHRA.org - 31
Case-Managers’ EHR Data Reuse
Across the Continuum of Care
c CARE, PROVIDERS and LOCATIONS
COORDINATION ` ACROSS LEVELS OF
Wartime
Theater
ER
Acute
Inpatient
Acute
Rehab.
Skilled
Long
Term
Care
Chronic
Rehab.
Custodial
Long
Term
Care
Home
Health
Outpatient
Prevention/
Wellness
Care Continuum
Coordination ACROSS SOAS
ASSESSMENT
CARE
PLANNING
ORDERS
&
SCHEDULING
BENEFIT
MANAGEMENT
AUTHORIZATION
&
UTILIZATION MGT.
COMMUNICATION
(FACILITATION
ADVOCACY)
DISCHARGE/
TRANSFER
PLANNING
REFERRAL
RECORD
EDUCATION.
TRANSPORT
ROLE OF CASE MANAGER
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 32
32
HL7 EHR System
Functional Model (EHR-S)
(> 230 System Functions in 4 level categorization
(see attached spreadsheet for full enumeration)
Business
Choreography
System Functions
Business
Entity
(Information)
Business
Infrastructure
Entity
(Information)
Service Types
Choreography
Infrastructure
Infrastructure
Infrastructure
Business
Choreography
Other
3/23/2016
O-1
Electronic Resource Planning (ERP)
O-2
Finances
O-3
Other
NOTE: “Other” Category - The EHR-S model does
NOT include Electronic Resource Planning (ERP) /
Logistics and Financial components, which are
needed for completeness of a military EHR.
33
SOA Layers
Focus on the Business Processes
and Services
Business
Capabilities
and Services
Services
interface layer
Business
process layer
[Thomas Erl]
orchestration service layer
business service layer
application service layer
Application
layer
System
Components
and Services
Source: Service-Oriented
Architecture, Thomas Erl
.NET
3/23/2016
J2EE
D R A F T Talking Points
Legacy
www.OSEHRA.org - 34
SOA Service Models
Potential Service Layers
[Thomas Erl]
Service Model
Application
Service
Business
Service
Controller
Service
Coordinator
Services
Entity-centric
Business Service
Hybrid
Service
Integration
Service
Process
Service
Task-Centric
Business Service
3/23/2016
Description
A generic category used to represent services that contain logic derived from a solution or technical
platform. Services are generally distinguished as application services when creating abstraction layers.
A generic category used to represent services that contain business logic. When establishing
specialized service layers, services that fall into the business service layers are collectively referred to
as business. However, individually these services are classified as entity-centric (e.g., information) or
task-centric business services.
A Service that composes others. Variations of this model exist, depending on the position of the
controller in the composition hierarchy. The patent controller service can be classified as the master
controller and a service that composes a subset of a larger composition can be labeled as subcontroller.
Three service models are derived from the concept of coordination: the coordinator, the atomic
transaction coordinator, and the business activity coordinator. All three models are specific to the WSCoordination specification and related protocols.
A business process-agnostic variation of the business service that represents one or more related
business entities. This type of service is created when establishing a business service layer.
A service that contains both business and application logic. Most services created as part of traditional
distributed solutions fall into this category. When organizing services into abstraction layers, hybrid
services are considered part of the application service layer.
An application service that also acts as an endpoint to a solution for cross-referencing integration
purposes.
A service that represents a business process as implemented by an orchestration platform and
described by a process definition. Process services reside in the orchestration service layer.
A business process-specific variation of the business service that represents an atomic unit of process
logic. Task-centric services are different from process services in that the process logic is provided by
the underlying service logic, not by a separate process definition.
D R A F T Talking Points
www.OSEHRA.org - 35
Healthcare SOA Reference Architecture (H-SOA-RA)
Based on HL7 EHR System Functional Model & Thomas Erl’s 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
Services
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Entity
Services
Information
Management
Information
Management
Information
Management
Information
Reporting and
Management
C r o s s T e c h n I c a l “Common S e r v I c e s”
(e.g., Security, Privacy, Auditing, Logging…)
Agnostic
Services
Application
Services
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
Communications
Profiles/Stacks
Implementation Profiles
D R A F T Talking Points
36
ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
s
ENABLING BUSINESS SERVICES
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
SUPPLY CHAIN (ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 37
PERFORMANCE
DATA MANAGEMENT
ANALYTIC
SUPPORT
IT PLATFORM
INTEGRATED
REQUIREMENTS
DESIGNS:
Putting the
H-SOA-RA
Pieces Together
Federated
Business
Services
TEST ONLY
OUTPATIENT OTHER
RECORDS MANAGEMENT
ASU
DOCUMENT
DECISION SUPPORT
Agnostic
Services
Inter-Agency
SUPPLY CHAIN:
(ORDERS/CHARGES)
Across
Providers
SCHEDULING
ER
AUTHORIZATION
CLINIC
Enabling Business
Services
TERMINOLOGY
INPATIENT
IDENTITY
Inter-Service
Ancillary
Systems
Federated Services,
may be categorized by:
-- Encounter Types
-- CMS billing category
-- Record type
-- Care setting type
-- etc.
Data sets are defined for
each system functionalcapability-service module
38
Addressing Real Business Issues
Through H-SOA-RA based
Integrated Requirements-Design
•
•
•
•
•
•
•
•
•
•
•
•
Incomplete/Inaccurate Demographic Data
Incomplete/Inaccurate Insurance Information
Unauthorized Service
Diagnosis/Procedure Coding Errors
Service Delays
Incomplete and Inefficient Charge Capture
Non-indicated or Contra-indicated Services
(Identity Service)
(Authorization Service)
(Authorization Service)
(Terminology Service)
(Scheduling Service)
(Supply Chain Service)
(Decision Support/
Authorization Services)
Delays in EHR Document Production and Provision
(Document Service)
Billing Delays and Errors
(Supply Chain/ Billing/
Collection Services)
Not fully coordinated Scheduling
(Scheduling Service)
Lack of fully integrated Patient Assessment and Treatment Plan (Document Service/
Decision Support Service)
Delayed or Lack of Medical Record Access
(Record Service)
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 39
Future State Architecture
Outline
Conceptual View
Getting Started
Backup
• SOA Approach
• 2011 VistA Packages (166)
–
–
–
–
Clinical Application Packages (81)
Infrastructure Application Packages (37)
Administrative-Financial Application Packages (36)
HealyheVet Application Packages (12)
• Contact Information and Initial Plan
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 40
2011 VistA Clinical Application Packages
http://www.va.gov/vdl/section.asp?secid=1
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Admission Discharge Transfer (ADT)
Ambulatory Care Reporting
Anticoagulation Management Tool (AMT)
Automated Service Connected Designation (ASCD)
Beneficiary Travel
Blind Rehabilitation
Care Management
Clinical Case Registries
Clinical Procedures
Clinical/Health Data Repository (CHDR)
Computerized Patient Record System (CPRS)
CPRS: Adverse Reaction Tracking (ART)
CPRS: Authorization Subscription Utility (ASU)
CPRS: Clinical Reminders
CPRS: Consult/Request Tracking
CPRS: Health Summary
CPRS: Problem List
CPRS: Text Integration Utility (TIU)
Dentistry
Electronic Wait List
Emergency Department Integration Software (EDIS)
Functional Independence Measurement (FIM)
Group Notes
HDR - Historical (HDR-Hx)
Home Based Primary Care (HBPC)
3/23/2016
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Home Telehealth
Immunology Case Registry (ICR)
Incomplete Records Tracking (IRT)
Intake and Output
Laboratory
Laboratory: Anatomic Pathology
Laboratory: Blood Bank
Laboratory: Blood Bank Workarounds
Laboratory: Electronic Data Interchange (LEDI)
Laboratory: Emerging Pathogens Initiative (EPI)
Laboratory: Howdy Computerized Phlebotomy Login Process
Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form
Laboratory: Point of Care (POC)
Laboratory: Universal Interface
Laboratory: VistA Blood Establishment Computer Software (VBECS)
Lexicon Utility
Medicine
Mental Health
Methicillin Resistant Staph Aurerus (MRSA)
Mobile Electronic Documentation (MED)
Nationwide Health Information Network Adapter (NHIN)
Nursing
Nutrition and Food Service (NFS)
Oncology
Patient Appointment Info. Transmission (PAIT)
D R A F T Talking Points
www.OSEHRA.org - 41
2011 VistA Clinical Application Packages
http://www.va.gov/vdl/section.asp?secid=1
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
Patient Assessment Documentation Package (PADP)
Patient Care Encounter (PCE)
Patient Record Flags
Pharm: Automatic Replenish / Ward Stock (AR/WS)
Pharm: Bar Code Medication Administration (BCMA)
Pharm: Benefits Management (PBM)
Pharm: Consolidated Mail Outpatient Pharmacy
Pharm: Controlled Substances
Pharm: Data Management (PDM)
Pharm: Drug Accountability
Pharm: Inpatient Medications
Pharm: National Drug File (NDF)
Pharm: Outpatient Pharmacy
Pharm: Prescription Practices (PPP)
Primary Care Management Module (PCMM)
Prosthetics
Quality Audiology and Speech Analysis and Reporting (QUASAR)
Radiology / Nuclear Medicine
RAI/MDS
Remote Order Entry System (ROES)
Scheduling
Shift Handoff Tool
Social Work
Spinal Cord Dysfunction
Standards & Terminology Services (STS)
3/23/2016
76.
77.
78.
79.
80.
81.
Surgery
VistA Imaging System
VistAWeb
Visual Impairment Service Team (VIST)
Vitals / Measurements
Womens’ Health
D R A F T Talking Points
www.OSEHRA.org - 42
2011 VistA Infrastructure Application Packages
http://www.va.gov/vdl/section.asp?secid=2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Capacity Management Tools
Duplicate Record Merge: Patient Merge
Electronic Error and Enhancement Reporting (E3R)
Enterprise Exception Log Service (EELS)
FatKAAT
FileMan
FileMan Delphi Components (FMDC)
Health Data Informatics
HL7 (VistA Messaging)
Institution File Redesign (IFR)
KAAJEE
Kernel
Kernel Delphi Components (KDC)
Kernel Toolkit
Kernel Unwinder
List Manager
MailMan
Master Patient Index (MPI)
Medical Domain Web Services (MDWS)
M-to-M Broker
Name Standardization
National Online Information Sharing (NOIS)
National Patch Module
Network Health Exchange (NHE)
Patient Data Exchange (PDX)
3/23/2016
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
Remote Procedure Call (RPC) Broker
Resource Usage Monitor
Single Signon/User Context (SSO/UC)
SlotMaster (Kernel ZSLOT)
SQL Interface (SQLI)
Standard Files and Tables
Statistical Analysis of Global Growth (SAGG)
Survey Generator
System Toolkit (STK)
VistA Data Extraction Framework (VDEF)
VistALink
XML Parser (VistA)
D R A F T Talking Points
www.OSEHRA.org - 43
2011 VistA Financial-Administrative Application Packages
http://www.va.gov/vdl/section.asp?secid=3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
3/23/2016
Accounts Receivable (AR)
Auto Safety Incident Surv Track System (ASISTS)
Automated Information Collection System (AICS)
Automated Medical Information Exchange (AMIE)
Clinical Monitoring System
Compensation Pension Records Interchange (CAPRI)
Current Procedural Terminology (CPT)
Decision Support System (DSS) Extracts
Diagnostic Related Group (DRG) Grouper
Electronic Claims Management Engine (ECME)
Engineering (AEMS / MERS)
Enrollment Application System
Equipment / Turn-In Request
Event Capture
Fee Basis
Fugitive Felon Program (FFP)
Generic Code Sheet (GCS)
Health Eligibility Center (HEC)
Hospital Inquiry (HINQ)
ICD-9-CM
IFCAP
Incident Reporting
Income Verification Match (IVM)
Integrated Billing (IB)
Integrated Patient Funds
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
D R A F T Talking Points
Library
Occurrence Screen
Patient Representative
Personnel and Accounting Integrated Data (PAID)
Police and Security
Quality Management Integration Module
Record Tracking
Release of Information (ROI) Manager
Veterans Identification Card (VIC/PICS)
Voluntary Service System (VSS)
Wounded Injured and Ill Warriors
www.OSEHRA.org - 44
2011 VistA HealtheVet Application Packages
http://www.va.gov/vdl/section.asp?secid=4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
3/23/2016
Clinical Information Support System (CISS)
Electronic Signature (ESig)
HealtheVet Web Services Client (HWSC)
My HealtheVet
National Utilization Management Integration (NUMI)
Occupational Health Record-keeping System (OHRS)
Patient Advocate Tracking System (PATS)
Person Services
Registries
Spinal Cord Injury and Disorders Outcomes (SCIDO)
VA Enrollment System (VES)
Veterans Personal Finance System (VPFS)
D R A F T Talking Points
www.OSEHRA.org - 45
Contact Information
and Initial Plan
• tiag® is the prime contractor. tiag® is an SBA certified 8(a)
woman-owned, small disadvantaged business. Corporate
Headquarters: (703) 437-7878 • 1760 Reston Pkwy Suite 510,
Reston, VA 20190
• Seong K. Mun, PhD of Virginia Tech serves as the acting
Senior Program Coordinator of the CA. He can be reached at
'Mun, Seong Ki' (munsk@vt.edu)
• OSEHR Inc. will be an independent not-for-profit organization.
• Open source EHR custodial agent (OSEHRA) milestones:
– 17-Aug-11: incorporated as a 501-c6 Non-Profit Org.
– 17 Sep-11: Deliver System Architecture and Product Definition
– 17-Oct-11: fully operational
• Additional information is available at www.OSEHRA.org
3/23/2016
D R A F T Talking Points
www.OSEHRA.org - 46