A Framework to Organize-and-Assess VistA
Open-Source SOA-Stack Components
OSEHRA Community
Seong K. Mun PhD President and CEO
Mike Henderson Director, Open Source Product Management Peter Li, co-chair Architecture Work Group (AWG)
Chris Edwards Implementation & Test 15-Oct-2013 AWG Presentation
15-Oct-2013 DRAFT-G Update www.OSEHRA.org
An Open-Source VistA SOA Platform objective is to provide an
open-standards eco-system within which VA employees, large prime contractors,
healthcare professionals, innovative small companies, healthcare software
vendors, and entrepreneurs can all contribute to improving
‘the best care anywhere' being provided by VA today.
Introduction
SITUATION:
OSEHRA represents the open-source VistA EHR community;
where, VA’s “VistA Evolution” initiative proposes to transform legacy VistA
into a Healthcare SOA Platform that can leverage modern technologies
and “cloud” offerings. OSEHRA advocates for an open-source SOA stack
assessment framework, as described in this presentation; but, OSEHRA
does not advocate for a particular SOA stack. .
PRESENTATION OBJECTIVE:
Provide OSEHRA community’s
recommendations to the VA’s VistA-Evolution initiative, regarding an
approach to assessing and using open-source SOA stack components to
create an Open-Source VistA SOA Platform that can leverage modern
technologies and “cloud” offerings.
Assumptions &
Benefits Summary
Open–Source Components (OSC)
in an open-architecture require
clearly-defined standards-based component-boundaries, including web services:
•
AGILITY
: OSC can accommodate new, unexpected, or subtly differing requirements among
health providers, possibly due to improved medical domain knowledge, insight and
innovation.
– OPENNESS: OSC allows users or small-businesses to focus on supporting a limited domain (e.g., orthopedics) – FLEXIBILITY: OSC provides risk-mitigation alternatives in case COTS does not work or is inadequate
– SECURITY & PRIVACY: OSC can be vetted-and-tested by a broad audience of stakeholders
•
QUALITY:
OSC is a form of reuse; where, components are appropriately modularized and
are comprehensively documented, tested and peer reviewed.
•
AFFORDABILITY
: OSC may allow a less expensive option, where licensing costs are
prohibitive
.
LAYER Business User Business Processes Business Services Business Components Business Integration Business Resources
Clinicians Patients Partners
ESB
DMS
Ancillary
Serv ices Databank First VistA MUMPS VistA MUMPS VistA MUMPS Federated VistA
Notional (Federated)
VistA-Business SOA-Stack
adapted from: http://www.ibm.com/developerworks/webservices/library/ws-WSBFoverviewpart1/index.html
Notional VistA SOA Platform
5
Sample
Clinical/Business Services
1. 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)
2. 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
Sample
Data Management Services (DMS)
1. Retrieve, Locate, Update Service (RLUS
) façade is used to access and
harmonize heterogeneous data stores.
–
Extraction, Transformation and Load (ETL)
is an RLUS backend component.
2. Common Terminology Service (CTS) is used to harmonize terminology
3. Built in Test Environment (BITE)
is used to verify information exchange syntax and
semantics.
4. Clinical Template Repository (CTR) is used to standardize information exchanges.
5. Security and Privacy
–
SSO/CM/AM/ID=SSO (single sign on),
–
CM (context management),
–
AM (access management),
–
ID (identification).
ESB is intended to support
“Advanced SOA Maturity”
[Microsoft SOA Roadmap]
Notional SOA-Stack View of
Clinical Decision Support
(CDS) Services
ESB
DMS
Business
Resources
Gartner has described Clinical Decision Support (CDS) as the CPR Systems’ Crown Jewel, because, CDS has the potential to be the most valuable component of a CPR; as, CDS is evolving to be a clinician’s trusted mentor.
9 VistA RPCs RLUS - RPCs RLUS CDW Legacy Apps.
Notional SOA-Stack for
VistA Exchange-Architecture
A VistA Open-Architecture
Must Be Standards-Based
Clinical/Business Standards
• DICOM for radiology,
• LOINC for laboratory, anatomical pathology,
• LOINC document types for inpatient notes,
• HL7 CCD (HITSP C32), and CCDA-CCD for VLER Health data,
• RxNORM for pharmacy,
• ICD-10 and SNOMED CT for outpatient visits,
• ICD-10 and LOINC for admissions encounter,
• SNOMED CT for smoking status,
• CPT4 and HCPCS for procedures,
• PDA-F for scanned paper reports,
• CDC Race Codes for demographics,
• UCUM for units of lab measures,
• NUCC Health provider taxonomy for provider types,
• CVX and MVX for immunology,
• ICD9, CPT4/HCPCS, ICD9PCS for billing data.
Technical Standards
• CTS or Common Terminology Service
• RLUS or Retrieve Locate Update Service for heterogeneous database facades
• CDS or Clinical Decision Support API
• VPR or Virtual Patient Record
• FHIR or Fast Healthcare Interoperability Resource with RESTful API.
• RDF or Resource Description Framework for semantic web applications
• JSON or JavaScript Object Notation
• WS* or Web Service Standards
11
Notional Open-Source
Assessment Criteria
•
Applicability to need
–
Options and customizability
•
Software License
•
Maturity of Software
–
Documentation and Use Cases
–
Testable requirements-specifications
–
Test procedures, fixtures and results
–
Community size and scope
•
Supportability
–
Community and Commercial venders
–
Standards and Interoperability
–
Other users
•
Scalability & Performance
Example Open-Source Components
OSEHRA will not recommend a particular SOA solution stack
• Apache ServiceMix is a flexible, open-source integration container that unifies the features and functionality of Apache ActiveMQ, Camel, CXF, ODE, Karaf into an enterprise ready ESB exclusively powered by OSGi; where, The OSGi framework is a module system and
service platform for the Java programming language that implements a dynamic component model. It is released under Apache License v2. The main features are:
– reliable messaging with Apache ActiveMQ
– messaging, routing and Enterprise Integration Patterns with Apache Camel
– WS-\* and RESTful web services with Apache CXF
– loosely coupled integration between all the other components with Apache ServiceMix NMR including rich Event, Messaging and Audit API
– complete WS-BPEL engine with Apache ODE
– OSGi-based server runtime powered by Apache Karaf
• JBossESB offers Business Process Monitoring, Integrated Development Environment, Human Workflow User Interface, Business Process Management, Connectors, Transaction Manager, Security, Application Container, Messaging Service, Metadata Repository, Naming and Directory Service, Distributed Computing Architecture. JBossESB is part of an SOI (Service Oriented Infrastructure). (Parts of Jboss accepted on VA TRM)
– Drools 5 includes a Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing
13
• Mirth Connect is the Swiss Army knife of healthcare integration engines, specifically
designed for HL7 message integration. It provides tools for developing, testing, deploying, and monitoring interfaces.
• 3M Opens Access Healthcare Data Dictionary (HDD)
• Apelon Open-Source Common Terminology Service (CTS) version 2
• OpenID is about authentication (ie. proving who you are)
• OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.
• Paraview is a multi-platform data analysis and visualization application.
• 3D Slicer is an extensible medical-image visualization-and-analysis application.
14
Example Open-Source Components
OSEHRA will not recommend a particular SOA solution stack
Questions?
www.OSEHRA.org
How can OSEHRA help?
•
Seong K. Mun
Administration
•
Mike Henderson
Products
•
Peter Li
Architecture
•
Christopher Edwards
Implementation & Test
Thank You
Plan-of-Actions and Milestones
Participation Welcome
SITUATION:
OSEHRA represents the open-source VistA EHR community; where,
VA’s “VistA Evolution” initiative proposes to transform legacy VistA into a
Healthcare SOA Platform that can leverage modern technologies and Cloud
offerings. OSEHRA advocates an open-source SOA stack assessment
framework, as described in this presentation.
8 Oct (Tuesday) 4 PM AWG
•
AWG Discussion on 1
stdraft of this presentation
•
OSEHRA team create a Plan-of-Action for next week’s AWG.
15 Oct (Tuesday) 4 PM AWG
•
AWG Discussion on 2nd draft of this presentation
•
OSEHRA team creates a Plan-of-Action for next week’s AWG.
22 Oct (Tuesday) 4 PM AWG
•
OSEHRA provide finalized presentation to open-source community and VA.
•
Talend present their recommendations for “
VistA Service Backplane
”
Acronyms
API
Application Program Interface
AWG
Architecture Work Group
CDS
Clinical Decision Support
CDR
Clinical Data Repository (DOD)
CDW
Clinical Data Warehouse (VA)
COTS
Commercial off-the-shelf
CPR
Clinical Patient Record
CTS
Common Terminology Service
DMS
Data Management Services
ESB
Enterprise Service Bus
HDD
Health Data Dictionary
JASON
Javascript Object Notation
RLUS
Retrieve, Locate, Update Service
RPC
Remote Procedure Call
SOA
Service Oriented Architecture
17Tom
Munnecke’s
VistA Onion
TALKING POINTS:
Notional
VistA’s
-Business SOA-Stack
Based on http://www.infoq.com/articles/SOA-enterprise-data
1. User Facing Layer provide support for users (both inside and outside the enterprise) to view and control the execution of the enterprise business processes and/or services. These users can be either humans using Web or rich clients or B2B connections (e.g., VLER) supporting intra-enterprise business processes.
2. Business Processes Layer, such as Orders Management, allow for creation of complex business protocols through orchestration of business services.
3. Business Services Layer, such as Ancillary Services, provide high-level business functionality throughout the enterprise. This layer effectively bridges between the "ideal" business model and the existing enterprise IT assets - applications and business components.
4. Business Components Layer, such as Laboratory, uses Service Orchestration to produce deployable units of software that provide the functionality required by business services. These components can be either newly developed or "wrappers" using integration layer to access the functionality of existing enterprise resources (e.g., Virtual Patient Record (VPR)).
5. Integration Layer uses various technologies (e.g., JASON, RLUS API) to expose existing
enterprise resources (e.g., data stores, laboratory test machines) and operational systems
(e.g., VistA) so resources could be used by business components.
6. Enterprise Resources Layer represents the portfolio of Operational Systems and existing
TALKING POINTS:
Enterprise Service Bus (ESB)
•
The enterprise data bus provides access to the VistA enterprise data and
other DOD and VA databases. ESB based business components
implement business logic based on the existing functionality; but, data
access is implemented through the ESB; where,
– the ESB advantage is explicit separation of concerns between implementation of the service functionality (business logic) and enterprise data support logic; because,
– the ESB creates an abstraction layer shielding business functionality from enterprise data access and transformations among enterprise semantic data model and data models of enterprise applications.
•
Because all service implementations have access to all enterprise data,
implementations significantly reduce coupling among services; because,
–
actual data accesses are implemented by the service itself using enterprise data bus.
•
The potential disadvantage of this approach is performance,
– due to the amount of concurrent synchronous accesses, which should be mitigated by Virtual Patient Record (VPR) local data caches.
Enterprise Data Access
Issues Mitigated by ESB
Based On http://www.infoq.com/articles/SOA-enterprise-data
1. Consolidation of data between multiple applications. DOD and VA
data is scattered between multiple silo applications; where there is
potential data redundancy among applications creating inconsistent
enterprise data representations of "master" data stored for
particular functionality/unit.
As an SOA implementation is attempting to represent enterprise-wide functionality it
needs to operate based on a well-defined enterprise data model. This means that
enterprise data access from service implementations is required to correctly align and
consolidate data from multiple existing applications and ensure propagation of data
changes to all applications, using this data.
21
10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution.
VISION
: Federated SOA-Enabled VistA + ESB + Data Management
Services (DMS) = Healthcare SOA Platform that can leverage
modern technologies and Cloud offerings.
ISSUE
: VistA’s M-implementation tightly couples functionality, data
Enterprise Data Access
Issues Mitigated by ESB
2. Ownership of enterprise data by services
is the foundation of the
modern service definition technique; where, functional decomposition is not
easily mapped to the enterprise data. For example, the notion of the patient
(and corresponding data) is usually shared between multiple functional
services; where,
1. The problem is that functional and data decompositions are driven by completely different rules.
1. Functional decomposition is defined based on the enterprise business processes - enterprise functionality; whereas,
2. Data decomposition is defined based on the enterprise data taxonomy - underlying enterprise data model. As a result, aligning of the enterprise data with enterprise services becomes a daunting task.
3. Interface definitions
. Because service invocations are often remote,
service design strives towards large granularity interfaces, aiming at
minimizing service traffic (chattiness) between service consumers and
providers; where,
1. Data access can require fine granularity of interfaces to meet functional requirements and
2. Data access typically implements pure CRUD (Create, Read, Update, Delete)a where as
Open Source is not Free
•
Open source
is often called a "community" and there is a good reason why:
most open source projects depend on volunteers, some of whom may be
paid by their employer. People who are skilled and motivated get involved
in open-source projects to help bring useful-ideas to life.
–
User “skin-in-the game” generally provides better results; where,
–
It is important to realize that successful organizational use of open-source software
implies resource investment for the betterment of the Open-Source community as well
as a particular organization’s betterment; and where,
–
Open-Source communities are meritocracies; where, leadership in a meritocracy is
based on intellectual talent, demonstrated achievement and resource contribution.
•
Although not free, open-source development can be:
–
FASTER
: Community participation encourages faster results.
–
BETTER
: Community peer-review of products & tests encourages quality.
–
CHEAPER
: Community software reuse encourage agility, economy and quality.
23
