Uploaded on

Dr Douglas Kingsford …

Dr Douglas Kingsford
General Practitioner
CEO, Caseweaver Development Ltd

  • 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
789
On Slideshare
0
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