Meaningful Use and Beyond - O'Reilly press - errata

Technical (archive)
21

Op 18-02-2012 22:24, pablo pazos schreef:

The key here is that within an openEHR based system, other standards
like HL7, DICOM, SNOMED, MeSH, UMLS, ICD10, ... could be implemented
to, each one for it's own task.

Supplementary to what Pablo wrote, I have a real life example.

In the Netherlands, HL7v3 messaging would have become mandatory for
every Health-related-system, from the kitchen in a health-institution, a
GP-system, or a medical-specialist system.
The idea was (very simply said) to create a message-oriented "network"
where all these systems should connect.
Every health-related system was expected to run Hl7v3 messaging on top
of it, or the system would be excluded from this "network" and, as a
result, possibly also excluded from business in healthcare.
So the pressure was big, and most systems succeeded in producing and
reading HL7 messages. Most systems, of a big variety, architectural,
platform, etc, can now implement HL7v3 messaging, an OpenEHR-system,
with all its flexibility can also.

22

Fred,

that’s pretty much it. We can disagree whether we should solve the sem-interop problem now (us; harder, longer) or later (you; get more going faster), but that’s not a real debate - in some places our view makes more sense, in others yours is the practical sensible approach. Our main aim is to enable intelligent computing on health data; doing that means semantic interoperability has to be solved. Otherwise, there is no BI, CDS or medical research based on data.

My only worry about not taking account of semantic / meaning issues now is that it will cost more later, than if it were included now. I still think that there is synergy to be explored in the coming 12m-2y between the openEHR community and the open source health Apps community (if I can call it that).

  • thomas
23

Hi Fred,

Thanks for coming along here. It has been an interesting discussion. I
just wanted to pick up on one point you made ..

"In my view once data is being exchanged on a massive scale, the
political tensions that the absence of "true meaning" creates will
quickly lead to the resolution of these types of problems."

Whilst I agree that you need to take one step at a time and get simple
connectivity going first, our experience from the UK is that once this
is established, the small trickle of demand for semantics grows very
quickly.

In the absence of some kind of agile mechanism/ framework to meet this
demand and quickly reconcile differences across very different
communities and specific use cases, projects and vendors just resort
to doing their own thing. So in the UK, in spite of full connectivity,
adherence to syntactic standards, and some local successes with
semantic exchange, we have at least 8 different semantically
incompatible expressions of 'GP Medication' having to be dealt with by
producers/consumers of messages.

Getting this right is extremely difficult but I believe the
'archetype' approach of openEHR/ CIMI and tools like CKM, are the only
realistic way of getting a handle on this.

This has much in common with the PCAST idea of 'molecules' - see Wes
Rishel's excellent summary

http://blogs.gartner.com/wes_rishel/2011/02/13/pcast-documents-vs-atomic-data-elements/

Regards,

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org

24

Hi Fred,

Apropos to Tom I’d say openEHR is also equally to do with software maintainability; thanks to the dual or multi-level modelling and model driven development. This is my main research area as well as open source software. I agree with Tom’s comments that being open source by itself is not enough (for any software quality aspect I believe) and must be accompanied with open standards. If I was asked to explain openEHR to my mother I’d probably say: ‘it is about getting information right in healthcare’. I usually find this statement as the starting point when talking to other audiences such as computer scientists and developers. Perhaps you’ll find useful as well.

Cheers,

-koray

25

Dear all,

It's great to see some healthy debate over these issues of openEHR vs "the rest" of open source in healthcare.

I know enough of Fred Trotters writings to know he must be a good guy, raising awareness of open source in healthcare for the common good.
Equally I've been an advocate of openEHR for some years now.
While some of the issues raised may make some uncomfortable there is no value in shooting the messenger here at all and I appreciate this discussion.
So Fred thank you for making the effort to mail this list, honestly admitting some issues with your original article and usefully exposing other key issues here...
..such as, why many folks (including ourselves!) may not yet easily understand the right place for openEHR in the world.

Fred and Tom have already had a useful exchange which illustrates some of the gap between those who promote open source and openEHR.
That there is any gap in understanding across these niche fields illustrates how early this informatics science is.
We all need to communicate the place of open source and openEHR better.
Please see my related articles here which I hope are a help. (Further feedback welcome and I'll make these easier to find from openEHR.org)
http://frectal.com/book/healthcare-change-the-way-forward/

Healthcare Informatics needs to pursue not just the holy grail of semantic interoperability at an international/ national level, but a better fit with the complexity of healthcare and core clinical processes at the frontline. Furthermore better usability, scalability and maintainability of locally/nationally developed solutions are all required.
My original involvement in openEHR stemmed from these interests in healthcare improvement and the people process & technology issues within.
As I've looked at the diverse Complex Adaptive System that is healthcare, amidst the many teams I work with I see common patterns in process everywhere... such that I believe healthcare needs a generic, clinical process oriented, service oriented architecture platform, which I believe openEHR and its two-level modelling can offer.
http://frectal.com/book/healthcare-change-the-way-forward/healthcare-openehr’s-potential-to-handle-complexity-diversity/
This complex system & people/process/technology approach is key for me in explaining both the value of openEHR and open source.

On the other hand if we make the case for openEHR as key to semantic interoperability alone, the layman would be rightly confused as semantic interoperability currently has several other champions (HL7/IHTSDO etc)).

In the past the openEHR archetype & template paradigm has usefully allowed me to design clinical templates for chest pain, abdominal pain, head injury pathways that reuse the same clinical components (archetypes). Yet I would be the first to accept Freds useful criticism that openEHR designs (inc my own) have not yet been usefully/widely implemented at the frontline.

So I've come to the view that there is a key gap between the eHealth standards efforts (inc. openEHR et al) and innovators at the frontline.... which I believe open source and related tooling will be key to bridging. Which is one of the reasons I've more lately turned to more pragmatic frontline efforts (such as a local open source clinical portal development).
http://frectal.com/2011/10/21/leeds-takes-a-lead/
So I share the view that open source is a key ingredient required in the healthcare ecosystem. However I'm aware that a myriad of open source efforts may just perpetuate the disconnect in healthcare, i.e. open source approaches are not enough to address healthcares problems alone.
Therefore I suggest that open source and openEHR efforts should be compared/aligned/combined where possible.

Therefore the way forward should not be about choosing between pragmatic open source efforts (eg NHIN Direct/Connect) and a more purist openEHR way.
We simply need to align the efforts of those tackling frontline challenges with pragmatic open source efforts and the long term goal that openEHR serves.
Such is the approach we are now taking here in Leeds, where we are planning to align our open source clinical portal effort with a small number of clinically useful openEHR archetypes (ie Adverse Reaction, Diagnosis etc) within our Service Oriented Architecture plans.

Finally I would not wish to see openEHR explained as a rare and purist aspiration, nor open source as a cheap shortcut - but both offering key useful elements into the healthcare ecosystem that we are all trying to improve.

Hope that helps,
Kind regards,

Tony

Dr. Tony Shannon
Consultant in Emergency Medicine, Leeds Teaching Hospitals NHS Trust
Clinical Lead for Informatics, Leeds Teaching Hospitals NHS Trust
Honorary Research Fellow, University College London
Director, Frectal Ltd.
+44.789.988 5068
www.frectal.com