Creating a Flexible EMR Architecture Doug Martin, MD The Need for Innovation • Traditional EMR architectures tend to be monolithic in design, which may.

Download Report

Transcript Creating a Flexible EMR Architecture Doug Martin, MD The Need for Innovation • Traditional EMR architectures tend to be monolithic in design, which may.

Creating a Flexible
EMR Architecture
Doug Martin, MD
The Need for Innovation
• Traditional EMR architectures tend to be monolithic
in design, which may limit configurability and
extensibility
• Novel modular architectures support collaborative
EMR development through
– Built-in extensibility
– High level of configurability
– Flexible UI
The CareWeb Framework
What It Is
• A foundation for component-based applications
• Highly extensible through plugin modules
• Flexible, supporting user-designed layouts
• A coordinator of shared functions (events, contexts)
• A facilitator of collaborative development
What It Isn’t
• A standalone application (not an EMR)
• Specific to healthcare
• Dependent upon a specific domain model
The Road to CWF
• 1998 Consortium of VA Hospitals fund VistAtion project
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1999
2000
2001
2002
2004
2008
2009
2010
2011
Integrate commercial note authoring tool into CPRS
Monolithic, closed → open, modular, extensible architecture
Monopolistic → collaborative development culture
Needed a supporting framework (VistAtion Framework)
Modularize CPRS → VistAtion components
VistAtion pilot commences at Atlanta VAMC
VA rejects VistAtion concept as “too open”
VistAtion  VueCentric
VueCentric-based EHR piloted at Crow Indian Hospital
IHS adopts RPMS-EHR as its official EMR
RPMS-EHR deployed in over 120 IHS sites
VueCentric  CareWeb Framework
CareWeb deployed across Indiana HIE
Gopher order entry system begins a new life as Gopher3
Rationale for Re-engineering
• Software platform reaching end of life
• Systems reaching limits of extensibility
• Difficulty recruiting engineers with relevant
experience
• Diminishing compatibility with evolving
infrastructure
• Limited ability to leverage contemporary tools
• Complexity of maintaining multiple systems
Goals of New Platform
•
•
•
•
•
•
•
•
•
Technology convergence
Web-based
Leverage existing open source technologies
Extensible architecture
Modular design
Emphasis on component re-use
Ease of development
Minimal configuration
Support our research mission!
What We Already Knew
•
•
•
•
•
•
•
Component-based frameworks work
Separation of domain from framework is important
Given the proper tools, users will innovate
Don’t design to perceived workflows
Let users adapt software to workflow
Ability to share custom layouts is huge
Deployment can be a pain (lots of moving parts)
Challenges
•
•
•
•
•
•
•
•
•
Speed, speed, speed
Scalability
Cross browser support
UI richness
UI consistency
Session interference
Dependency management
Versioning
Workflow support
Key Technologies
•
•
•
•
•
•
•
•
•
•
Java
Spring Framework
Spring Security
ZK Framework
JQuery
JavaHelp
Apache ActiveMQ Server
Apache Tomcat
Apache Maven
CCOW
External
Services
Internal
Services
User
Interface
Architecture
Order Entry
Chart Search
Clinical
Flowsheet
Rule Authoring
SMArt
Plug-in
Plug-in
Widgets
Patient
Selection
Problem List
Medication List
Allergy List
Web
Resources
Plug-in
Services
Layout
Manager
Layout
Designer
User
Authentication
User
Preferences
Electronic
Signature
Framework
Services
Electronic
Signature
Patient
Context
User
Context
Context
Management
Event
Management
Component
Registration
Help
Subsystem
Data
Access
Security
Services
Messaging
Services
Web
Services
Plug-in
Services
Theme
Support
Framework
Services
Core
Services
What’s inside the new Gopher?
•
–
–
–
–
–
–
–
–
–
–
•
•
•
Recent results
Flowsheet
Clinical abstract
Clinical documents
Encounter display
Order summary
Appointment history
Patient dashboard
Medication summary
Chart search
Alert display
InfoPanel
Rule Authoring
Relevance Adjustment Module
FDB Integration
Setting-specific functionality
Randomization
Medication adherence
Medication reconciliation
Med profile visualization
ResNet study recruitment
SMART plug-ins
Certifications
–
–
•
McKesson portal
Relay Health portal
Docs4Docs integration
Research
–
–
–
–
–
–
•
User management
Remote troubleshooting
Property management
Concept mapping
Disaster aid support
System integration
–
–
–
•
Outpatient
Inpatient
Emergency Department
Touch interface
Administrative Tools
–
–
–
–
–
Clinical Decision support
–
–
–
–
–
•
Order entry
Note Writing
Observations
Patient Letters
Document uploader
Electronic signature
Problem list management
Allergy Management
Order Sets
Natural Language Processing
Results display
–
–
–
–
–
–
–
–
–
–
•
–
–
–
–
Data capture
Meaningful Use Inpt / Outpt
NCPDP e-Prescribing
Reporting
–
Population search
Summary
Modular architectures promote
– Agile development
– Collaboration within and across organizations
– Best-of-breed approach
– Code re-use
– Incremental evolution
What’s Next?
• Ongoing work
– SMART platform support
– Clinical abstraction layer
– EMR adaptors
•
•
•
•
VistA
RPMS
OpenMRS
Commercial systems
• Open source
– Community building
– Infrastructure for collaboration