Douglas Kingsford is a practicing GP and CEO who is interested in artificial intelligence, workflow, and electronic health records (EHRs). He discusses that EHRs are about interoperability, sharing data, and collaborating in patient care. However, achieving true interoperability is challenging and requires open standards, clinician input, and good governance. Simply putting data in centralized repositories or expecting everyone to use the same system will not work due to the proprietary needs of various stakeholders and desire for clinicians and patients to control personal data. True interoperability will require new types of cooperation and business models between all involved parties in a distributed system with no central control.

1. BRINGING THE
ELECTRONIC 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’t
we?

5. FIRST WE FIGURED OUT INTEROPERABLITY
First 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 documents
3. 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 INTEROPERABLITY
Then 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