1. Creating a Flexible EMR Architecture Doug Martin, MD

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

3. The CareWeb Framework

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

5. What It Isn’t A standalone application (not an EMR) Specific to healthcare Dependent upon a specific domain model

6. The Road to CWF 1998Consortium of VA Hospitals fund VistAtion project 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 1999VistAtion pilot commences at Atlanta VAMC 2000VA rejects VistAtion concept as “too open” 2001VistAtion  VueCentric 2002VueCentric-based EHR piloted at Crow Indian Hospital 2004IHS adopts RPMS-EHR as its official EMR 2008RPMS-EHR deployed in over 120 IHS sites 2009VueCentric  CareWeb Framework 2010CareWeb deployed across Indiana HIE 2011Gopher order entry system begins a new life as Gopher 3

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

8. 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!

9. 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)

10. Challenges Speed, speed, speed Scalability Cross browser support UI richness UI consistency Session interference Dependency management Versioning Workflow support

11. Key Technologies Java Spring Framework Spring Security ZK Framework JQuery JavaHelp Apache ActiveMQ Server Apache Tomcat Apache Maven CCOW

12. External Services External Services Internal Services Internal Services Architecture Order Entry Chart Search User Preferences Web Resources Web Resources Context Management Context Management Event Management Event Management Help Subsystem Help Subsystem Electronic Signature Electronic Signature Patient Context Patient Context Data Access Data Access Security Services Security Services User Context User Context Layout Manager Layout Manager Theme Support Theme Support Messaging Services Messaging Services User Interface User Interface Layout Designer Layout Designer Component Registration Component Registration Plug-in Widgets Plug-in Widgets Framework Services Framework Services Plug-in Services Plug-in Services Framework Services Framework Services Core Services Core Services Web Services Web Services Patient Selection Patient Selection Electronic Signature Electronic Signature User Authentication User Authentication Plug-in Services Plug-in Services SMArt Plug-in SMArt Plug-in Clinical Flowsheet Clinical Flowsheet Rule Authoring Problem List Medication List Allergy List

13. What’s inside the new Gopher? Data capture –Order entry –Note Writing –Observations –Patient Letters –Document uploader –Electronic signature –Problem list management –Allergy Management –Order Sets –Natural Language Processing Results display –Recent results –Flowsheet –Clinical abstract –Clinical documents –Encounter display –Order summary –Appointment history –Patient dashboard –Medication summary –Chart search Clinical Decision support –Alert display –InfoPanel –Rule Authoring –Relevance Adjustment Module –FDB Integration Setting-specific functionality –Outpatient –Inpatient –Emergency Department – Touch interface Administrative Tools –User management –Remote troubleshooting –Property management –Concept mapping –Disaster aid support System integration –McKesson portal –Relay Health portal –Docs4Docs integration Research –Randomization –Medication adherence –Medication reconciliation –Med profile visualization –ResNet study recruitment –SMART plug-ins Certifications –Meaningful Use Inpt / Outpt –NCPDP e-Prescribing Reporting –Population search

14. Summary Modular architectures promote – Agile development – Collaboration within and across organizations – Best-of-breed approach – Code re-use – Incremental evolution

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