• Save
EHR Interoperatbility
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,214
On Slideshare
1,214
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. BRINGING THEELECTRONIC HEALTH RECORD TO LIFE Dr Douglas Kingsford MBCHB, PhD (Engineering) • Practising GP in Auckland • CEO, Caseweaver Development Ltd (medical decision support) • Particular interest in artificial intelligence, workflow, EHR • Served on relevant HISO Expert Committees HINZ Seminar, 21 June 2012
  • 2. EHR IS ALL ABOUT INTEROPERABILITY It’s about sharing data And collaborating in patient care Sounds simple So what needs to happen?
  • 3. HERE’S WHAT’S NEEDED Open interoperability standards Developed through collaboration of vendors, healthcare providers, patient representatives and technical experts Clinician led, clinicians choosing what works best With good, transparent governance, accreditation, incentives/enforce ment
  • 4. We’re there now… … aren’twe?
  • 5. FIRST WE FIGURED OUT INTEROPERABLITYFirst we discussed how we need something along the lines of:1. Agreed format (syntax and grammar) – data model (instantiation of information model, eg. R-MIM), mechanism for defining content (document and form templates, eg. openEHR Templates), messaging structure (eg. HL7 v3 Messages).2. Equivalent datatypes – for elements in the messages and documents3. Common semantics – reference model, domain information model (what is meaningful to say), terminologies and bindings to domain information model (vocabulary), mechanism for declaring post-coordinations (openEHR archetypes, HL7 v3 templates, SNOMED CT terminology expressions)
  • 6. THEN TYPES OF INTEROPERABLITYThen we moved on to: Functional Interoperability – HL7 v2/3, web services, DICOM, etc - agreement on message structure and how to send/receive messages - prior agreement on meaning of message elements, plus agreed coding for detail - but inherent weaknesses (HL7 v2)– optionality, can’t easily represent context, post-coordinations, etc Semantic Interoperability – openEHR, HL7 v3, CDA, SNOMED CT, etc - supposedly the laudable ability to consume and interpret clinical data without prior agreement on message content or data dictionary - work has trended towards templates, archetypes - which are really agreement on a common information model - but with competing reference models (HL7 v3, openEHR) - and so sending agreed v3 messages is kind of back to functional interoperability again, with prior agreement, and details of meaning delegated to the terminology Workflow Interoperability – BPEL, BPMN, YAWL, HL7 v2/3, IHE XDW (Oct 2011), etc - ability to coordinate business processes – orchestration and choreography - yet to really see this in health outside monolithic systems and dynamic behaviour of
  • 7. AND USUALLY ENDED UP WITH… Complex proposed reference architectures (Connecting For Health, Canada Health Infoway, now NZ Interoperability Reference Architecture) Recommendations for large central data repositories Convergence on a few, large vendors
  • 8. BUT THERE ARE SOME PROBLEMS…
  • 9. BUT THERE ARE SOME PROBLEMS… There’s little actual progress outside monolithic systems (It’s easy - if everyone would just agree to use one system!)
  • 10. BUT THERE ARE SOME PROBLEMS… Everyone wants to protect their investment in existing systems And those systems often aren’t as expressive as the reference architectures would like.
  • 11. BUT THERE ARE SOME PROBLEMS… Whilst IT people see data centralization as logical Clinicians want to retain control of their patient’s data Patients may resist having their info in systems outside the control of those they personally trust And some clinicians perceive they are adding value by building up the richness of their patients’ records.
  • 12. BUT THERE ARE SOME PROBLEMS… Clinicians tend to want to use a single system if they can (eg. their EMR) But not necessarily the same single system as the guy down the road Or the systems of a central agency.
  • 13. BUT THERE ARE SOME PROBLEMS… Vendors want to continue to deliver unique value to their customers And may be resistant to key functionality slipping away into “the cloud”. Which is a problem, because vendors are key to the deployment of innovation to the point of care.
  • 14. WHICH SUGGESTS…
  • 15. WHICH SUGGESTS… The proprietary needs of the various participants in healthcare delivery are real And must be acknowledged and respected If we are to have progress beyond monolithic centralized systems.
  • 16. WHICH SUGGESTS… There will always be important information held in source systems that is not passed to central repositories The complex many-to-many interactions that already exist between the participants in healthcare delivery will need to be supported In an environment where many of these participants do not want to be controlled by others.
  • 17. WHICH SUGGESTS… New types of cooperation will be required between patients, providers, government agencies and vendors. New business models will be required to motivate cooperation between all the involved stakeholders. It shouldn’t matter where the data sits.
  • 18. SO WHAT ARE WE GOING TO NEED?
  • 19. SO WHAT ARE WE GOING TO NEED? An environment of open interoperability standards With good governance, incentives and accreditation – Promoting innovation, lowering barriers to entry, facilitating evolution and competition Enabling new ventures to plug niche advancements into existing systems
  • 20. SO WHAT ARE WE GOING TO NEED? Interface and data standards that support:  distributed queries for data held in source systems  decentralized workflow – with extended information models that better encompass workflow – not just the “integrated workflow” of centralized, single-vendor systems An approach that allows for incremental increases in sophistication by participants over time.
  • 21. THE VISION Seamless interoperability across a distributed system featuring diverse components and no central control – much like the internet itself. An environment for collaboration and competition that drives innovation and boosts overall functionality/capability. An ecosystem of specialized, niche players that allow composite “best of breed” solutions to arise by evolution - “survival of the fittest”, based on fitness for purpose as