BRINGING THEELECTRONIC HEALTH RECORD         TO LIFE Dr Douglas Kingsford MBCHB, PhD (Engineering)    •   Practising GP in...
EHR IS ALL ABOUT INTEROPERABILITY   It’s about sharing data   And collaborating in patient care   Sounds simple   So w...
HERE’S WHAT’S NEEDED   Open interoperability standards   Developed through collaboration of    vendors, healthcare provi...
We’re there now…                   … aren’twe?
FIRST WE FIGURED OUT INTEROPERABLITYFirst we discussed how we need something along the lines of:1.   Agreed format (syntax...
THEN TYPES OF INTEROPERABLITYThen we moved on to:   Functional Interoperability – HL7 v2/3, web services, DICOM, etc    -...
AND USUALLY ENDED UP WITH…   Complex proposed reference architectures    (Connecting For Health, Canada Health Infoway, n...
BUT THERE ARE SOME PROBLEMS…
BUT THERE ARE SOME PROBLEMS…   There’s little actual progress outside    monolithic systems   (It’s easy - if everyone w...
BUT THERE ARE SOME PROBLEMS…   Everyone wants to protect their investment in    existing systems   And those systems oft...
BUT THERE ARE SOME PROBLEMS…   Whilst IT people see data centralization as    logical   Clinicians want to retain contro...
BUT THERE ARE SOME PROBLEMS…   Clinicians tend to want to use a single    system if they can (eg. their EMR)   But not n...
BUT THERE ARE SOME PROBLEMS…   Vendors want to continue to deliver unique    value to their customers   And may be resis...
WHICH SUGGESTS…
WHICH SUGGESTS…   The proprietary needs of the various    participants in healthcare delivery are real   And must be ack...
WHICH SUGGESTS…   There will always be important information held    in source systems that is not passed to central    r...
WHICH SUGGESTS…   New types of cooperation will be required    between patients, providers, government    agencies and ve...
SO WHAT ARE WE GOING TO NEED?
SO WHAT ARE WE GOING TO NEED?   An environment of open interoperability    standards   With good governance, incentives ...
SO WHAT ARE WE GOING TO NEED?   Interface and data standards that support:     distributed queries for data held in sour...
THE VISION   Seamless interoperability across a distributed    system featuring diverse components and no    central cont...
Upcoming SlideShare
Loading in …5
×

EHR Interoperatbility

1,002 views
882 views

Published on

Dr Douglas Kingsford
General Practitioner
CEO, Caseweaver Development Ltd

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,002
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

EHR Interoperatbility

  1. 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. 2. EHR IS ALL ABOUT INTEROPERABILITY It’s about sharing data And collaborating in patient care Sounds simple So what needs to happen?
  3. 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. 4. We’re there now… … aren’twe?
  5. 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. 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. 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. 8. BUT THERE ARE SOME PROBLEMS…
  9. 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. 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. 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. 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. 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. 14. WHICH SUGGESTS…
  15. 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. 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. 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. 18. SO WHAT ARE WE GOING TO NEED?
  19. 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. 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. 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

×