Open Platforms for Healthcare Applications
•Transferir como PPTX, PDF•
1 gostou•822 visualizações
Today's Electronic Health Record (EHR) offerings inhibit the ability to develop the next generation of clinical applications for providers to provide the best possible care and patients to become more engaged. Such offerings are designed as monolithic silos of storage and end-user experience that use proprietary methods for accessing key functionality. While large health care providers typically have physical control over their data, they lack in having functional control. This barrier makes it virtually impossible for data to be easily accessed by other applications without very costly and time-consuming migration strategies. As a result, the pace of innovation is greatly stymied by closed systems that appear to be all-too-prevalent in the healthcare industry. This session presents a strategy of vendor-neutral, public, open Application Programming Interfaces (APIs) and advocates for their use in developing open platforms for healthcare applications.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (13)
Semelhante a Open Platforms for Healthcare Applications
Semelhante a Open Platforms for Healthcare Applications (20)
Último
Último (20)
Open Platforms for Healthcare Applications
- 1. HIMSS MN Presents: Open Platforms for Healthcare Applications Thursday, August 21, 2014
- 2. Thank you to all our Annual Sponsors!
- 5. Partner Level Sponsors Tanson Logo Here?
- 6. HIMSS MN 2014-2015 Event Calendar Month Format August 21st Webinar – Open Platforms for Healthcare Applications September Webinar October Expert Panel November Midwest Fall Technology Conference (Chicago) December Webinar January Advocacy Event February Webinar March Networking Event April HIMSS National Chapter Reception (Chicago) May 14th Annual Spring Conference June 3rd Annual Charity Golf Tournament June Twin Cities Summer Social July SE Minnesota Summer Social August Webinar Dates and topics TBD Please take HIMSS MN survey to guide your chapter on topic selection! Opportunity to win $100 Amazon gift card.
- 7. Today’s Speakers Keith Toussaint Executive Director Collaborative Development Mayo Clinic Ken Bobis Administrator Chief Technology Office Mayo Clinic
- 8. An Open Interface Approach Presented to HIMSS MN August 21, 2014 Keith M. Toussaint Ken G. Bobis, PhD
- 9. Definitions The problem Solution vision Business value An example Further research
- 10. Health Care Organization (HCO) EMR Application Interface / API / Messaging Standard Ecosystem Open Interface
- 11. Application that is integral to the delivery of patient care, but not found in the institution’s core Electronic Medical Record ◦ Document Viewer, EMR Viewer, Pt. Itinerary, smartplatforms.org
- 12. Interface ◦ A point where two systems, subjects, organizations, etc., meet and interact Tape data transfer; interface engine API ◦ Application Program (API) or Web Services (WS) Interface A callable program interface ValidatePatientNumber, ValidateDate Messaging Standard ◦ Rules by which an interface is maintained ◦ An agreed upon message format HL7, FHIR
- 13. (biological) A biological community of interacting organisms and their physical environment ◦ Rain Forest, Prairie, Coral Reef (software) A set of businesses functioning as a unit and interacting with a shared market for software and services, together with relationships among them ◦ Wintel, iOS, Android, Java
- 17. open (small ‘o’) ◦ May be used by others ◦ Control retained by the author ◦ Traditional view of “open” Open (big ‘O’) ◦ Author-independent ◦ Emerging view of “Open” Open Interface <> Open Source
- 18. Practice functionality needs are huge ◦ More than a single provider organization 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
- 19. User Interface Core Clinical Informatics Functionality Data Storage and Computing Infrastructure EHR X Monolith Y Viewer 1 Tool 1 Viewer 2 Tool 2 Legend : Vendor provided, HCO Managed HCO provided and managed
- 20. Embrace Open APIs ◦ Author-neutral interfaces ◦ Reduce product lock-in Layered architecture ◦ Separating application, platform and storage functionality New Value Network ◦ New problems require new solutions ◦ New business models with new value network participants Common infrastructure ◦ Available to all – but not required
- 21. User Interface Open interfaces Core Clinical Informatics Functionality Open interfaces Data Storage and Computing Infrastructure EHR PoC Tool 1 PoC Tool 2 PoC Tool 3 HCO 1 Vendor 3 Vendor 1 Vendor 2 Legend Vendor provided and managed HCO provided and managed
- 22. Business Value
- 23. Leverage common core capabilities Minimize capital expenditures Enable rich collaboration Focus on differentiating technology Reduce vendor “lock-in”
- 24. Common platform to meet MU Establish common application frameworks Improved Innovation on reporting and analytics Cost savings through shared physical infrastructure
- 25. Enabling Pay-as-you-go tools Minimal up-front costs Same quality tools for all
- 26. 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
- 27. Existing Efforts
- 28. FHIR HealthKit CommonWell Alliance Smart Platforms.org Continua Health Alliance OpenEHR OpenMRS
- 29. HL7 Fast Health Interoperability Resources Fast and easy to implement Implementation libraries Free for use Interoperability out-of-the-box Path from HL7 Version 2 and CDA Web standards compatible Support for ReSTful architectures Human-readable message formats http://www.hl7.org/implement/standards/fhir/summary.html
- 30. Is it big “O” open? Yes! ◦ Non-proprietary standards ◦ Enables local extension of the standard ◦ Well-defined process for evolving the standard What is missing? ◦ Definition of layered architecture ◦ Clear description of “separation of concerns” ◦ Example of such an architecture: A Robust Health Data Infrastructure prepared by JASON for ONC: http://healthit.gov/sites/default/files/ptp13- 700hhs_white.pdf
- 31. User Interface Core Clinical Informatics Functionality Data Storage and Computing Infrastructure
- 32. Microsoft HealthVault Google Health Optum Health Cloud
- 33. 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
- 34. Current State is sub-optimal Loosely-coupled architecture Open APIs ◦ Understanding the difference between small ‘o’ and big ‘O’ Now possible to make a shift Can be driven by providers Opinions invited on how to proceed
- 35. Today’s Speakers Keith Toussaint Executive Director Collaborative Development Mayo Clinic toussaint.keith@mayo.edu Ken Bobis Administrator Chief Technology Office Mayo Clinic bobis.kenneth@mayo.edu
- 36. An Open Interface Approach Presented to HIMSS MN August 21, 2014 Keith M. Toussaint Ken G. Bobis ,PhD
Notas do Editor
- Ken
- Ken
- Ken Be sure to highlight the sub-bulleted when defining … Interface / API/ Protocols FHIR ReST KMT: Took out the “Open Innovation” bullet point. Concerned that it added too much to the discussion. Open Innovation is a positive, but not a *requirement* for an ecosystem (Apple appstore ecosystem is a good example of a viable ecosystem that is *not* an Open Innovation environment
- Ken Smartplatforms.org FHIR used in integrate to Cerner and Epic, Seen in HIMSS - 2014 Interoperability showcase, read-only
- Ken
- Keith Definitions: Biological Ecosystem: http://www.oxforddictionaries.com/us/definition/american_english/ecosystem Software Ecosystems: David G. Messerschmitt and Clemens Szyperski (2003). Software Ecosystem: Understanding an Indispensable Technology and Industry. Cambridge, MA, USA: MIT Press. ISBN 0-262-13432-2.
- Keith Definitions: Biological Ecosystem: http://www.oxforddictionaries.com/us/definition/american_english/ecosystem Software Ecosystems: David G. Messerschmitt and Clemens Szyperski (2003). Software Ecosystem: Understanding an Indispensable Technology and Industry. Cambridge, MA, USA: MIT Press. ISBN 0-262-13432-2.
- Keith Definitions: Biological Ecosystem: http://www.oxforddictionaries.com/us/definition/american_english/ecosystem Software Ecosystems: David G. Messerschmitt and Clemens Szyperski (2003). Software Ecosystem: Understanding an Indispensable Technology and Industry. Cambridge, MA, USA: MIT Press. ISBN 0-262-13432-2.
- Keith Definitions: Biological Ecosystem: http://www.oxforddictionaries.com/us/definition/american_english/ecosystem Software Ecosystems: David G. Messerschmitt and Clemens Szyperski (2003). Software Ecosystem: Understanding an Indispensable Technology and Industry. Cambridge, MA, USA: MIT Press. ISBN 0-262-13432-2.
- Keith: find document that spells out distinctions between open interfaces/source/formats/protocols There are various definitions of open that might be employed here Open API Not to be confused/conflated with “Published” API. For example if you go to open.epic.com, you will see what Epic defines as an ‘open’ API. By our definition, this in no way meets the requirement of Open API. An open API is explicitly not owned by any one entity. It is freely available to use (like OpenStack) Open Source Open Format For the purposes of our endeavors in Mayo Clinic IT, our definition of Open should be centered on Open APIs. https://collab.mayo.edu/team/TSAT/Architecture%20Working%20Group/Working%20Documents/Clean%20and%20Open/Defining%20Open%20and%20Clean.docx
- Ken
- Ken The current state of EHR systems and clinical software in general is characterized by the ‘monolithic silo’ of data storage, core clinical informatics functionality and user interface as depicted above. At the time that the mature EHR systems were developed, this approach was considered state-of-the-art. However, there are numerous disadvantages to this approach, among them being vendor ‘lock-in’ and significant impediments to innovations based on rapidly evolving clinical needs. In the intervening years, however, modern computing architecture has emerged that is predicated on layered architecture employing standard computing interfaces between those layers. Eric Schmidt translation: The current state of EHR systems and clinical software in general is characterized by the ‘monolithic silos’ of homogeneous data storage (living in non-virtual compute infrastructure) proprietary interfaces to core clinical informatics functionality and sub-optimal user interfaces designed not by the those delivering care, but by the infrastructure/technology companies. At the time that the mature EHR systems were developed, this approach was considered state-of-the-art. However, there are numerous disadvantages to this approach, among them being vendor ‘lock-in’ through opaque architecture and proprietary interfaces and significant impediments to user interface innovations based on rapidly evolving clinical needs. In the intervening years, however, modern computing architecture has emerged that is predicated on REST principles that call for layered, stateless architecture employing standard computing interfaces between architectural layers. Further, the ability to leverage the emerging Business of APIs requires adherence to these architectural principles.
- Ken: Describe the term “new value network”
- Keith The current state of EHR systems and clinical software in general is characterized by the ‘monolithic silo’ of data storage, core clinical informatics functionality and user interface as depicted above. At the time that the mature EHR systems were developed, this approach was considered state-of-the-art. However, there are numerous disadvantages to this approach, among them being vendor ‘lock-in’ and significant impediments to innovations based on rapidly evolving clinical needs. In the intervening years, however, modern computing architecture has emerged that is predicated on layered architecture employing standard computing interfaces between those layers. Eric Schmidt translation: The current state of EHR systems and clinical software in general is characterized by the ‘monolithic silos’ of homogeneous data storage (living in non-virtual compute infrastructure) proprietary interfaces to core clinical informatics functionality and sub-optimal user interfaces designed not by the those delivering care, but by the infrastructure/technology companies. At the time that the mature EHR systems were developed, this approach was considered state-of-the-art. However, there are numerous disadvantages to this approach, among them being vendor ‘lock-in’ through opaque architecture and proprietary interfaces and significant impediments to user interface innovations based on rapidly evolving clinical needs. In the intervening years, however, modern computing architecture has emerged that is predicated on REST principles that call for layered, stateless architecture employing standard computing interfaces between architectural layers. Further, the ability to leverage the emerging Business of APIs requires adherence to these architectural principles.
- Ken
- Ken
- Ken
- Ken
- Ken
- Keith
- Keith (AR): Go into some detail about FHIR (separate slide?), incorporate ReST into the FHIR discussion HealthKit: Note that it is not an open standard, Walled Garden Samsung: … other new ones Examples: Providers could develop or purchase at limited cost solutions that meet their clinical needs They about your own case of what applications you are still waiting for
- Keith
- Keith (AR): re-do this slide (and previous?) FHIR does not specify how the layers are fit together
- Keith Does this look familiar (show previous architecture)
- Keith
- Keith/Ken
- Ken/Keith Current State is sub-optimal for doing all we need to do meet the needs of the health care system of the future Disparate departments Population health needs Complex revenue cycle Complex integration between organizations Need to move to Now possible? Why? Rest architecture proven at scale Driven by providers? Technology industry has been reluctant to drive major change HCOs have the best incentives to drive change Time is now to move forward? Crossroads in health care Replacing emr shift is happening (1st to 2nd generation) Time to rearchitect how we do things Small percentage of automation done today … adapt or die (agility) How do we do it? Consortium Open marketplace Need to hear your views