Accelerating Health Data Interoperability Unique Device Identification for Postmarket Surveillance and Compliance Workshop

Transcription

1 Accelerating Health Data Interoperability Unique Device Identification for Postmarket Surveillance and Compliance Workshop Joy Keeler Tobin September 13, 2001

2 A SIMPLE FRAMEWORK FOR HEALTH DATA EXCHANGE

3 Who is MITRE and Why are we interested? Who is MITRE? Independent, not-for-profit organization Chartered to work in the public interest Free from conflicts of interest 50+ years of systems engineering experience Center for Transforming Health has deep healthcare and technical expertise Why is MITRE interested? As a public interest company, MITRE works in partnership with the government to address issues of critical national importance. It s MITRE s Mission to address issues of critical national importance To advance the Nation s progress towards an integrated healthcare system with improved access and quality at sustainable costs 3

4 Challenge Leverage Electronic Health Records (EHR) to make health care more cost-effective Barrier Complexity of current standards inhibits interoperability hdata Approach Influence or create Health IT standards based on modern, scalable technology to ease implementation and speed adoption

5 Strong MITRE Foundation Builds upon MITRE experiences Project Laika Open source tool to test electronic health record compliance with health IT standards Used for Electronic Health Record (EHR) Interoperability Certification Learned that the C32 is very difficult to implement; challenging to support the health IT goals of the country Health IT engagement with public and private sectors NIST, HIT Policy and Standards Committee, HITSP and IHE Standards Development Organizations (SDO s) such as HL7 Project pophealth Project hquery! Simple data exchange standards succeed 5

6 Philosophical Approach Current Health IT standards can be used to create interoperable systems Existing standards can be refined to allow for greater interoperability Tools can be created to lower the barriers to entry and increase implementation Keep it simple. Keep the implementation cost as low as possible. Design for the little guy. Do not try to create a one-size-fits-all standard. Separate content and transmission standards. Create publicly available vocabularies & code sets. Leverage the web for transport ( health internet ). Support implementers. 6

7 Building on Foundational Standards Clinical Document Architecture (CDA) Continuity of Care Record (CCR) Standards Development + = Continuity of Care Document (CCD) Data Standards Specify: Data Semantics Data Content Data Structure Leveraged and Reused HITSP Harmonization of Standards (Interoperability Specifications) hdata Semantics Content Structure Same Flexible (Same +) New HITSP + CCD = Component 32 (C32) CCD and C32 represent the dedicated work of many medical professionals and continues to drive the data content and data semantics of health exchange 7

8 The hdata Approach hdata Technical Specifications hdata Record Format hdata RESTful Transport hdata Content Profiles (HCP) - define the content Defined by Communities of Interest and Standards Organizations Could be a single medication, medical image, or an entire EHR Initial set adapted from C32 HL7 hdata Specifications Technical Specifications hdata Content Profiles HL7 hdata Record Format CDA Content Profile HL7 hdata RESTful Transport HL7 v2/3 Message Profile Custom Security Mechanism green CDA Profile

9 hdata RESTful Transport Supports RESTful operations Everything is a URL with extensible security Atom Feeds result in a living document Simple way for software programs to check for updates to medical records (subscription service) Benefits Easy to implement compatible with wide range of tools Internet scalability up to 100 Millions of users Result: faster development cycle, more innovation Record base URL Section(s) Path Document

10 hdata: Departure from Tradition Traditional health records are a snapshot in time Paper based: copy of current records are shipped CDA-based EHRs: electronic representation of point-in-time records Possible updates through HL7 messaging An hdata Record is a living document Once an hdata Record resource location is known, services can subscribe to a content feed Automatic, timely updates and changes based on open standards Can support drug interaction alerts, and other time critical services, as the feed is updated Service consumers can copy an entire hdata Record information for point-in-time documentation purposes Subscription access can be cut off for privacy/security For example: A patient changes their specialist and the specialist no longer requires access to the patient s hdata Record; the subscription is terminated (or simply times out) 10.

11 hdata Summary Separation of technical & clinical matters Built on proven, scalable Internet technologies Software developer friendly Information is described in small chunks Simple to learn, simple to use Interoperability is designed in from day one Will support privacy and security requirements Leverages other open source projects Extensible to other Health IT use cases 11.

12 hdata Current Status Standards documents written Reference implementations open sourced hdata up for HL7 Draft Standard for Trial Use vote in Sept 2011 Accelerating interest among government sponsors and industry (Cerner, Partners, Emdeon) Developing prototype for a mobile implementation of hdata 12

13 Top Ten Recommendations from the Implementation Workgroup of the HIT Standards Committee 10/29/09 1. Keep it simple. Think big, but start small. Recommend standards as minimal as required to support a necessary policy objective or business need, and then build as you go. 2. Don t let perfect be the enemy of good enough. 3. Keep the implementation cost as low as possible. 4. Design for the little guy. 5. Do not try to create a one-size-fits-all standard. Go for the 80 percent that everyone can agree on. Get everyone to send the basics (meds, problems, allergies, labs) before focusing on the more obscure. Minimize the costs associated with implementation of standards, including royalties, licensing fees and other expenses. Open the NIST interoperability certification testing processes. Make sure the endorsed standards are as broadly implementable as possible, so diverse participants can adopt it, and not only the best-resourced. Do not mandate or attempt to create a one-size-fits-all standard that adds burden or complexity to the simple use cases.

14 Top Ten Recommendations, continued 6. Separate content and transmission standards. 7. Create publicly available vocabularies & code sets. 8. Leverage the web for transport ( health internet ). 9. Position quality measures so they motivate standards adoption. 10. Support implementers. Separate content standards from transmission standards; i.e., if CCD is the html, what is the https? Separate the network layer from the application layer. Avoid linking changes between senders and receivers. Ensure they are easily accessible and downloadable, with straightforward means to update or upgrade. Use what already works in transporting information securely on the internet. Decrease complexity as much as possible to shorten the learning curve of implementers. Strive for quality reporting to be an automated byproduct of using certified technology and standards, lowering the administrative burden of reporting to the lowest extent possible. Make Implementation Guides available that are human readable, with working examples and testing tools. Facilitate implementers use of Implementation Guides with effective national communication plans. Publish open source reference implementations.

15 DISCUSSION