OMG e-health platform summit Berlin 2013

I attended the OMG e-health summit this week, devised and facilitated by Ken Rubin (HP health vertical). The session drew participants from various countries and programmes, including Finland, Germany, UK NHS, Australia, Italy, US and others.


Some of the things I picked up during the open discussion, broadly on the general topic of ‘what lessons did we learn from e-health programmes / projects to date, that can inform a platform for the future?’:

  • Ken Lunn, NHS: don’t try to solve the general problem only, focus on specific problems [use cases]
  • Ken Lunn, NHS: don’t talk about ‘standards’, talk about ‘standardisation’, i.e. perfectly good standards can evolve from real world  processes, not just standards meetings;
  • any new efforts must be driven by clinical need [TB: implying that proper efforts must be made to identify and understand such needs]
  • Franck Oemig (Agfa, Germany): a platform ‘eco-system’ is only a good idea if there is only one. If there are many competing platforms, we are back to square one;
  • various: one ever-present challenge: the front-line clinicians who do more work as a result of richer data capture etc don’t reap the dividends; as a consequence, potential purchasers of new systems will realise that they won’t get their investment back in a short time [TB: I do think that new applications based on very efficient mobile technology and the new wave of UI can reduce the costs; coupled with a very agile platform, the overall ROI even in the short term should improve substantially.]
  • me: do we need a longer term platform roadmap? Who could provide this? [TB: I mentioned Microsoft Connected Health Framework 2.0 as an example of a services roadmap for e-health]
  • Nick Booth (NHS): discourse between health IT and clinicians to date has been poor; we can’t use management health information as a proxy for clinical care information
  • Paul Jones, ex-NHS CTO: graduated financial incentives for standards use are needed, and schemes need to be developed to make them work

There are just a few that I wrote down.

My synthesis of this thinking is that we therefore need technically:

  • an open platform definition (i.e. published APIs) addressing all levels from generic ‘EHR’ and demographic information, to high-level business functions like ‘shared medication list’ and ‘patient pathway’.
  • there needs to be a forum where an agreed roadmap is progressively developed (a constant work in progress) that pencils in these different services.
  • such a roadmap needs to try to ensure coherence between the services in terms of data and key semantics, otherwise, it is not a platform, it is just a lot of disconnected services; achieving coherence means adopting some generic standards for things like health data, clinical content modelling, guideline representation, process concepts on so on.
    • judicious integration with terminologies and ontologies is needed to help ensure coherence and utility; an ontology of health services
  • however, we might end up with not just one platform, but a small number of good quality platforms. We should have no problem with this if it becomes necessary.
    • A more dangerous vision is to try to force incommensurable concepts into a single platform which will never properly work. I can easily imagine a different kind of platform for US hospital  computing versus European community health computing.

Nick Booth mentioned the Professional Record Standards Body (UK), and said that this kind of activity was the kind of route for engagement of professionals in the domain to engage in clinical computing on their own terms (i.e. not being forced to speak IT languages or be a passive resource for IT ‘requirements gathering’). I agree with this.

My view (of course) is that we need to use tooling and concepts such as we have developed for archetyping, terminology subsetting and model management in openEHR, now the focus of the CIMI (other key references – the MDHT OHT project and of course Stan Huff’s brilliant clinical modelling ecosystem at InterMountain Health), to actually provide the technical means of those clinicians to state their requirements.

What can help from here?

  • OMG Health Services Specification Program (HSSP) is a growing locus for health services specifications ecosystem development:
    • in my view it might need to pay more attention to connecting services to a coherent underlying information definitions and semantic concepts – a ‘platform’ is not services alone – it is data and knowledge resources as well.
    • I also think more thinking about a roadmap and the coherence issue would make sense
  • Between openEHR, the 13606 community, CIMI and the new OMG Archetyping Modelling Language (AML) (this is a nascent RfP to bring archetypes in to the UML tooling mainstream – based on openEHR archetype formalisms and Dave Carlson’s MDHT tools) – a common archetype-based technology for content modelling and management is becoming mainstream
  •  We need to find ways of connecting clinical domain experts to this technology – that is setting up fora like the PRSB mentioned above and similar kinds of things in other countries. This is mainly a question of organising people rather than the technology. It’s being done differently in different countries.

Thanks to Ken Rubin for the invitation to come to the summit. My feeling from this (and hanging around for two more days of OMG) is that the wider e-health community is starting to crystallise a common mental picture for a platform-based future.

About wolandscat

I work on semantic architectures for interoperability of information systems. Much of my time is spent studying biomedical knowledge using methods from philosophy, particularly ontology and epistemology.
This entry was posted in Health Informatics, openehr. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s