Health Management Platform
March 28, 2012
Presentation for iEHR Engineering Deep Dive
1
Why Was the Initiative Created?
“Transform Healthcare Delivery through Health Informatics”
(Health Informatics Initiative or hi2) was created by
Secretary Shinseki in May 2010 with these missions:
 Provide foundational IT and Informatics components for VHA’s transition
from a medical model to a patient-centered model of care.
 Build a sustainable collaborative approach, capacity, and tools to deliver
informatics solutions to transform health care delivery to Veterans
through three major projects or Workstreams.
2
Initiative Workstreams
A. Workstream A: Adopt a Health/IT Collaborative
Supporting Rapid Product Development and
Delivery Methods.
B. Workstream B: Build a Health Management
Platform to Transform Patient Care.
C. Workstream C: Create Health Informatics
Capacity
D. Workstream D: Deliver Communication and
Drive Change
3
Health Management Platform
Healthcare Team-facing
1.
•
•
•
•
Patient-facing
2.
•
•
3.
Browser-based, healthcare team user-interface modules
Workflow driven, role-based activity systems
Knowledge-driven, context-based decision support
Team-based, multi-patient care environment
Meaningful patient use, population reach and impact
Engage patients in their care
System/Population-facing
• Feedback to clinicians for panel management
• Population and epidemiology-like studies
• Measure how the “system” is performing – real-time visibility
4
4
4
Clinical Context
5
5
5
Key Concepts
 Four Key Clinical Concepts
 Comprehensive, integrated coded data
 Team-based, multi-patient care
 Workflow-driven, role-based activities
 Knowledge-driven, context-based decision
support
 Within an open source/open architecture
environment
6
6
6
Comprehensive, Integrated Coded Data
 Comprehensive: Data can be accepted from
various sources including: VA facilities, DOD,
NwHIN, and others - Architecture ready to
accept multiple sources
 Integrated: System assumes all patient data is
available and creates integrated views of data Virtual Patient Record (VPR), Search Service
 Coded: The data is standardized and coded via a
terminology system
 Demo: Multiple facilities data, data
grids/details, Search service
7
7
7
Team-based, Multi-patient Care
 Single Patient and Multi-patient (Panel) views are
supported by the system - Roster/Panel services
first phase is available.
 Team-based care is designed into the system
 Tools to manage and communicate with the
clinical care teams is provided.
 Demo: CHF Panel, Index Panel, Roster Builder
and Service, Integrated multi and single patient
views
8
8
8
Workflow-driven, Role-based Activities
 System understands user’s role. Role determines
views, menus, choices and inputs presented to user Modularity and data driven starting point, roles
 System no longer linear, but works the way user wants
to work. Documentation created as a by product.
Order anywhere.
 Supports various work-flows - Modularity
 Work-flows are definable and flexible - Worksheets
 Demo: Modular framework, worksheet beginnings
with ordering service from worksheet, Free form
pages
9
9
9
Knowledge-driven, Context-based Decision Support
 Knowledge-driven systems behind scenes provide links,
guidelines for decision support tools - Info Buttons
 System understands various contexts including: Role-
based, Problem-driven, and Time-based. - CHF
 Decision support tools drastically expanded to aid in
planning, assessment, and goals of patient care.
 System is smart and provides suggestions as clinical
care is given.
 Demo: Info Button & Search Service, CHF specific
pages
10
10
10
Technical Framework Accomplishments
Legacy
HMP
Presentation
User Application
Platform
CPRS
CART
Care Plan
 Virtual Patient Record VPR
PHR
Med Rec
 HMP/MDWS application
VistA
Application Services
Provider
packages
Order Entry
Search
Rosters
Consistent Data Store
Business Logic
Data
Info But
VPR
services
 Modular, data-driven user
interface approach
 Resulting in a modern, tiered
architecture
MDWS Data Services
Patient Data
Local National
11
NwHIN
DoD
CDW
11
11
Virtual Patient Record (VPR)
 Solves issues: Proprietary, LAN based, inefficient data
Presentation
access
 VPR
 New VistA routines return a web-friendly, complete
patient data XML document
VistA
 Rebuildable cache - kept fresh
 HiTSP informed, non-proprietary data model
Data
Business Logic
Consistent Data Store
VPR
12
Multiple data sources - computable data set

Highly indexed for performance
 HMP/MDWS patient data web services
MDWS Data Services
Patient Data
Local
Local
National

(REST/SOAP)
NwHIN
DoD
CDW
12
12
HMP/MDWS Application Services
 Web application services
Presentation
 Contribute to/consume from ESB
 Expose VistA capabilities
VistA
Application Services
 Patient data service
Provider
packages
Order Entry
 Roster/panel service
Search
Rosters
Info But
 Order entry service
Business Logic
 Provide new clinical capabilities
 Information button “Info Button”
service
Data
 Patient chart search service
13
13
13
Modular Data Driven User Interface Approach
Presentation
User Application
Platform
CPRS
CART
Care Plan
 Flexible, industry best practice
 Demonstrate 3 modularity modes
 Application level
PHR
Med Rec
 Page level
 Summary module
 Shared Context - user, patient, clinical
objects
Business Logic
 Visible and business logic components
registration at runtime
Data
 Data driven view with “view specifications”
14
14
14
Technical Framework Summary
Legacy
HMP
Presentation
User Application
Platform
CPRS
CART
Care Plan
PHR
Med Rec
VistA
Application Services
Provider
packages
Order Entry
Search
Rosters
Consistent Data Store
Business Logic
Data
Info But
VPR
 Virtual Patient Record VPR
 HMP/MDWS application
services
 Modular, data-driven user
interface approach
 Resulting in a modern, tiered
architecture
MDWS Data Services
Patient Data
Local National
15
NwHIN
DoD
CDW
15
15
Technical Framework
Migration
Legacy
HMP
Presentation
User Application Platform
CPRS
Care Plan
CART
PHR
VistA
Provider
packages
Order Entry
Search
Terminology
Exposed Data Layer
• Temporary cache from multiple data sources
• Longitudinal, standards encoded
• Promotes interoperability & data exchange
VPopR
PED
MDWS Data Services
CDW
Business Logic
Data
16
• HMP/MDWS application services
(e.g. Roster, Search)
• Contributes to/consumes from ESB
• Open Source model
• REST, SOAP interfaces
Population
Analytics
ADT
VPHR
MDWS read/write data services
NwHIN
DoD
• Industry best practice web environment
• User-adaptable interfaces
• Context-based modules
• Widget technology
• Device agnostic mobile apps
Service Layer
Consistent Data Store
VPR
Patient Data
Local National
etc.
Application Services
Info But
Population
packages
Med Rec
Epinome
Rosters
Patient
packages
Presentation Layer
???
• Merged HMP/MDWS data services
• Richer, consistent data
• XML format
• NwHIN extracts for VLER
16
16
iEHR and hi2 Health Management Platform (HMP)
Common Architectural Areas
Presentation
(Common GUI)
HMP
Modules
Janus
Modules
Other
Modules
Applications and Services
DoD Unique (16)
Battlefield
Care
Military
Readiness
Enroute
Care
Common (Joint) Applications & Services (30)
Personal
Health Record
Pediatrics
Pharmacy
Obstetrics
Disability
Evaluation
HMP/MDWS
Inpatient
Emergency
Services
Orders Mgmt
Dept Care
Dental Care
(e.g. Roster, Search,
Consult
OE,
OM,& Note Writer)
Immunization
Veterinary
Laboratory
Referral Mgmt
VA Unique (6)
Blood Mgmt
Nursing
Home
Long Term
Care
Document
Mgmt
Rehabilitative
Services Transient
Care
Outreach
Operating
Room Mgmt
OE, OM, Note
Writer)
Pharmacy
Occupational
Mail Order
Health (VA)
HMP/MDWS
(e.g. Roster, Search,
Common Interface Standards
Common Services Broker
(includes Enterprise Service Bus (ESB) and Infrastructure Services)
HMP/MDWS Services (e.g. Patient Data Services)
Common Interface Standards
Common Data Centers
Common Information Interoperability Framework (CIIF)
17
17
17
iEHR & hi2 – Current Collaboration (Jan 2012)
 CIIF (Common Information Interoperability Framework)
 hi2 will inform and support CIIF
 iEHR Presentation Layer
 Similar development tools/environment and approach
 Data Read/Write - MDWS
 Merging hi2 read/write services into MDWS
 Service Layer - ESB
 hi2 will attend iEHR meetings (ESB selection pending)
 North Chicago & Tripler
 Clinical Decision Support
 hi2 coordinating with iEHR
18
18
iEHR & hi2 – Moving Forward (Jan 2012)
 Create strategy and definition of convergence by June 2012
 Foster technical collaboration
 Brief VA and DoD clinical community
 Establish a plan with options for:

Idea/Information exchange

Consensus building between VA/DoD

Socializing/Marketing expectations across departments

Engagement opportunities

Execution/Implementation considerations

Training and Sustainment realities
19
19
iEHR & hi2 – Moving Forward (Jan 2012)
 Acknowledge shared vision and goals
 Modern, tiered architecture
 Open Source
 Developer/end user collaboration
 Data/terminology standards
 Integration of disparate data sources
 Agree to establish an internal/external communication strategy
 Bi-weekly conference calls – hi2 & VHA iEHR leads
 Coordinate external communication with OIA and VHA
20
20
Health Management Platform – FY12 Goals
 Continue to build AViVA foundation and infrastructure
 Stand-up development teams for Patient and System/Population
 Install and test HMP Module 3 in Production at pilot sites
 San Diego, Indianapolis, Portland, Loma Linda
 Build and expand development partnerships
 CART, VINCI, MDWS, iEHR
 Publish Collaborative Development Environment
 Leverage Health Management Platform and AViVA framework to
initiate “democratization of IT”
 Communicate & educate stakeholders
21
21
Collaborative Development Environment
 1° GOAL - Position the Collaborative Development Environment (CDE)
in a cloud with internet access to allow wide open source development
participation and stakeholder and user engagement.
 Currently setting up CDE in Innovations virtual environment. Getting
necessary ports opened up and resolving performance issues.
 Other options include an environments like RackSpace or similar.
 2° GOAL – get into a cloud that offers a non-SQL database such as
MongoDB (MongoHQ-hosted version) so we can explore as an option
and evaluate performance.
 Similar to B-Tree structure, and schema design is a function of the data
and the use case (unlike more rigid schemas in relational DBs)
 Fast, efficient, flexible aggregation, scalable, open source
 These types of databases are now being used by many major companies
22
22