1 / 15

Creating a Flexible EMR Architecture

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

december
Télécharger la présentation

Creating a Flexible EMR Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 ActiveMQServer • Apache Tomcat • Apache Maven • CCOW

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

  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 • ResNetstudy 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

More Related