The Future of Standards


Published on

Presented by John D. Halamka MD
Harvard Medical School

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Future of Standards

  1. 1. The Future of Standards John D. Halamka MD
  2. 2. Agenda • The requirements based on the Healthcare Reform timeline • The 2014-2015 Workplan for the Standards Committee • • • Care Management goals Reflecting on where we are and where we need to go Questions
  3. 3. Workplan Activities Topic Image Exchange Data Transport Topic Description and Notes Standards to support image exchange Status Assigned to the Clinical Operations WG Additional standards to support transport of data to and from TASK COMPLETED patients Result High High Standards which support flexible platforms for measuring and   reporting quality High Standards to support closed loop referral workf1ow   High Record Locator Services Standards which support Record Locator Services   High Care Plans Standards to record care plans/care team   High Quality reporting and measurement Referral Workflow
  4. 4. Workplan Activities Topic Topic Description and Notes Status Result Content Gaps (Lab Orders) Clinical Operations WG reported out during June HITSC Medium Standards Supporting Digital Signature CMS presented to HITSC on July 17; Medium   Medium Parsing and record sharing Improvements to standard to facilitate unambiguous parsing,   longitudinal record sharing, and bulk record sharing Medium Advanced Directives Standards to record advanced directives/care preferences   Medium APIs Standards for application programming interfaces supporting   modular application integration Medium CDS Standards for clinical decision support, both knowledge representation and application programming interfaces (APIs) for query/response to knowledge resources Medium Lab Orders Digital Signature Terminology Content Gaps (Terminology)  
  5. 5. Workplan Activities Topic Topic Description and Notes Defect Reporting Standards which support defect   reporting to PSOs Medium Standards needed for registry support including structured data capture and transmission to third party repositories Medium Registry Support / SDC Query/Response of PDs and Patient Identity Status   Standards which support query/response of provider and   patient identity in directories Result Medium
  6. 6. Workplan Activities Topic Topic Description and Notes Status Standards which support consent in a query/response architecture such Query/Response Consent as granular patient privacy   preferences hosted in a managed Management service ("pull") and sent as part of the request for records ("push") Data Segmentation for Privacy Standards supporting data segmentation for privacy P&S WG and COWG reviewed DS4P Project, which upon completion was handed work over to HL7 to develop standard; DSTU scheduled for Sept release. Standards for clinical documentation Clinical Documentation supporting new payment models   for New Payment Models (includes ICD10, smart problem lists, computer assisted coding) Local and Targeted Queries Standards which support query of data within organizations and targeted query for patient data   Result Medium Medium Medium Medium
  7. 7. Care Management Goals • Identifying cohorts and creating queues with rules • Managing queues with guidelines/protocols • Real time alerts and reminders • Scheduling/Registration decision support • Test results tracking
  8. 8. Measure Expectation 11/11/13 EHR Capability 99
  9. 9. M R od H Ex i f E s Standards d ie p e ie d e lit c i ct D n b at at a a h p io a n a ns E C Measure Expectation 11/11/13 Usability & Workflow EHR Capability
  10. 10. Patient Profile Screen
  11. 11. Self Service Web Interface
  12. 12. Patient-Level Information Assets BIDPO QDC - -
  13. 13. Provider Measure Scorecard Slide title Massachusetts eHealth Collaborative © MAeHC. All rights reserved. - -
  14. 14. Decision Support Service Providers
  15. 15. Where we are • Content • Vocabulary • Transport
  16. 16. Content • The HL7 RIM is important for creating content standards but should be invisible to implementers • A 16 year old without healthcare domain knowledge should be able to create an arbitrary structured content document with novel data fields • In the near term, CCDA and FHIR must co-exist. In the future FHIR may supplant CCDA • • JSON is easier to generate and parse than XML HL7 3.0 is not going to be widely used for messaging in the US
  17. 17. Vocabulary • The Value Set Authority Center has collected almost all needed vocabulary and code sets • There are a few gaps - uniform adoption of LOINC for allergy/severity/reaction, UCUM for units of measure, EHR support for structured data capture
  18. 18. Transport • RESTful approaches that use OAuth2 and OpenID are easier to implement than SMTP/SMIME or XDR with PKI. • Trust fabric solutions are still evolving and trust anchor exchange is what is working now • Push, Pull and View are all valid interoperability architectures
  19. 19. “Healthcare is not special” • We need to abandon the idea that healthcare needs unique approaches to exchanging payloads of data. • HTML and HTTP = FHIR and REST/OAuth2/OpenID • Simple and functional is more important than addressing every edge case
  20. 20. Where We Need to Go • Certification needs to be redesigned to focus on interoperability using real clinical scenarios • Optionality needs to be eliminated (OR means AND and destroys in interoperabilty) • • Modularity needs to be enabled • How do we create an “app” ecosystem in a world of EHR consolidation/attrition? Implementation Guides should not be based on “indirection” but should stand alone
  21. 21. The Next 3 Years • For now, continue version 2.x for messaging transactions in the US - ADT, orders, results until it can be replaced by FHIR • For now, continue CCDA for transitions of care until it can be replaced by FHIR • Aspire to a future of FHIR over REST using JSON with OAuth2/Open ID authentication • • Reduce optionality - OR means AND Focus on the building blocks and not narrow fixed use cases i.e. require APIs in all EHRs as part of Meaningful Use Stage 3
  22. 22. Questions? • •