establishing an emr application ecosystem
DESCRIPTION
Presentation the argument for establishing an Electronic Medical Record (EMR) application ecosystem building on existing EMR capabilities. Such an approach would leverage modern ReST principles and open (*truly* open) APIs to broaden the value network for health information technology services. Presented at the 2013 HIMSS Midwest Fall Technology Conference November 22, 2013 Milwaukee, WITRANSCRIPT
Establishing an EMR Application Ecosystem
November 2013
Presented by: Keith M. Toussaint, Executive Director, Collaborative Development, Global Business Solutions Ken Bobis PhD, Administrator, Chief Technology Office Mayo Clinic
Track category - Session #
An Open Interface Approach
Slide 1
Keith M. Toussaint & Kenneth G. Bobis
Have no real or apparent
conflicts of interest to report.
Conflict of Interest Disclosure
Slide 2
Agenda
• Definitions • The problem • Solution vision • Business value • An example • Further research
Slide 3
Definitions
• EMR Application • Interface / API/ Protocols • Ecosystem • Open Interface • Open Innovation • ReST-ful
Slide 4
• Application that is integral to the delivery of patient care, but not found in the institution’s core Electronic Medical Record
EMR Application
Slide 5
• A point where two systems, subjects, organizations, etc., meet and interact Application Program (API) or Web Services
(WS) Interface • Establishes the contract between two
systems
Interface
Source: http://toni.org/2007/01/30/open-source-vs-open-apis/
Slide 6
Ecosystem
• A biological community of interacting organisms and their physical environment
• A set of businesses functioning as a unit
and interacting with a shared market for software and services, together with relationships among them Software Ecosystem, Messerschmitt. D.G & Szyperski,
C., 2005
Slide 7
• open (small ‘o’) May be used by others Control retained by the author
• Open (big ‘O’) Author-independent
• Open Interface <> Open Source
Open Interface
Slide 8
• Using the market rather internal hierarchies to source and commercialize innovations
Open Innovation
Slide 9
• Stands for: Representational State Transfer
• Layered System • Client-Server • Stateless Interfaces • Uniform Interfaces
ReST-ful
Slide 10
The Problem
• Practice functionality needs are huge More than a single HCO can satisfy Years to implement workflows in existing products New capabilities removed from “The Gemba”
• Closed architectures No access to data sources and business logic
• Product lock-in Product B may be more conducive but … switching
costs are prohibitively high
Slide 11 Slide 11
Current State
Data Storage and Computing Infrastructure
Core Clinical Informatics Functionality
User Interface
EH
R X
Monolith Y
Viewer 1
Tool 1
Viewer 2
Tool 2
Legend: Vendor provided, Mayo Managed HCO provided and managed
Slide 12
Solution Vision • Open Innovation via Open APIs • Public Interfaces Author-neutral interfaces
• Common infrastructure Available to all – but not required
• Layered architecture Separating application, platform and storage functionality
• New Value Network New problems require new solutions New business models with new value network participants
Slide 13 Slide 13
Future State
Data Storage and Computing Infrastructure
Core Clinical Informatics Functionality
User Interface
EH
R
PoC Tool 1
Vendor 1
Legend: Vendor provided and managed HCO provided and managed
Vendor 2
HCO 1 Vendor 3
PoC Tool 2 PoC Tool 3
Open; ReSTful:
Open; ReSTful:
Slide 14
Business Value
Slide 15
• Leverage common core capabilities • Minimize capital expenditures • Enable rich collaboration • Focus on differentiating technology • Reduce vendor “lock-in”
Strategic value to HCOs
Slide 16
• Common platform to meet MU • Establish common application frameworks • Improved Innovation on reporting and
analytics • Cost savings through shared physical
infrastructure
Financial value to HCOs
Slide 17
• Enabling Pay-as-you-go tools • Minimal up-front costs • Same quality tools for all
Operational Value to HCOs
Slide 18
• Enable new value network of application innovation Shared core functionality New capabilities on existing ‘stack’ Enabling consistent tools across the
spectrum of care • Reduce innovation friction
Value to newcomers
Slide 20
Existing Efforts
Slide 21
• CommonWell Alliance • Smart Platforms.org • Continua Health Alliance • OpenEHR • OpenMRS
Industry examples
Slide 22
• Microsoft HealthVault • Google Health • Optum Health Cloud
Previous Forays from Tech
Slide 23
Further Research
• Cloud-based deployment architecture • Catalog of required of services • Flesh out business value • Operational policies & procedures for
member HCOs • Protocols for EMR & Ecosystem
interactions • Common local & public architecture
requirements
Slide 24
• Current State is sub-optimal • Loosely-coupled architecture • Open APIs • Now possible to make a shift • Can be driven by providers • Opinions invited on how to proceed
Wrap up/Summary
Slide 25
*END* Main Presentation