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, WI

1. Establishing an EMR Application Ecosystem
An Open Interface Approach
Presented by: Keith M. Toussaint, Executive Director,
Collaborative Development, Global Business Solutions
Ken Bobis PhD, Administrator, Chief Technology Office
Mayo Clinic
November 2013
Track category - Session #

2. Conflict of Interest Disclosure
Keith M. Toussaint &
Kenneth G. Bobis
Have no real or apparent
conflicts of interest to report.
Slide 1

3. Agenda
• Definitions
• The problem
• Solution vision
• Business value
• An example
• Further research
Slide 2

4. Definitions
• EMR Application
• Interface / API/ Protocols
• Ecosystem
• Open Interface
• Open Innovation
• ReST-ful
Slide 3

5. EMR Application
• Application that is integral to the
delivery of patient care, but not
found in the institution’s core
Electronic Medical Record
Slide 4

6. Interface
• 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
Source:
http://toni.org/2007/01/30/open-source-vs-open-apis/
Slide 5

7. 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 6

8. Open Interface
• open (small ‘o’)
 May be used by others
 Control retained by the author
• Open (big ‘O’)
 Author-independent
• Open Interface <> Open Source
Slide 7

9. Open Innovation
• Using the market rather internal
hierarchies to source and
commercialize innovations
Slide 8

10. ReST-ful
• Stands for: Representational
State Transfer
• Layered System
• Client-Server
• Stateless Interfaces
• Uniform Interfaces
Slide 9

11. 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 10

12. Current State
User Interface
Viewer 2
Viewer 1
Monolith Y
EHR X
Core Clinical
Informatics
Functionality
Tool 2
Tool 1
Data Storage
and Computing
Infrastructure
Legend:
Vendor provided, Mayo Managed
HCO provided and managed
Slide 11

13. 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 12

14. Future State
User Interface
PoC Tool 1
PoC Tool 2
PoC Tool 3
Open; ReSTful:
EHR
Core Clinical
Informatics
Functionality
HCO 1
Vendor 3
Vendor 1
Vendor 2
Open; ReSTful:
Data Storage
and Computing
Infrastructure
Legend:
Vendor provided and managed
HCO provided and managed
Slide 13

15. Business Value
Slide 14

16. Strategic value to HCOs
•
•
•
•
•
Leverage common core capabilities
Minimize capital expenditures
Enable rich collaboration
Focus on differentiating technology
Reduce vendor “lock-in”
Slide 15

17. Financial value to HCOs
• Common platform to meet MU
• Establish common application frameworks
• Improved Innovation on reporting and
analytics
• Cost savings through shared physical
infrastructure
Slide 16

18. Operational Value to HCOs
• Enabling Pay-as-you-go tools
• Minimal up-front costs
• Same quality tools for all
Slide 17

19. Value to newcomers
• 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
Slide 18

20. Existing Efforts
Slide 20

21. Industry examples
•
•
•
•
•
CommonWell Alliance
Smart Platforms.org
Continua Health Alliance
OpenEHR
OpenMRS
Slide 21

22. Previous Forays from Tech
• Microsoft HealthVault
• Google Health
• Optum Health Cloud
Slide 22

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 23

24. Wrap up/Summary
•
•
•
•
•
•
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
Slide 24

25. *END* Main Presentation
Slide 25