Common Interface Mechanism project

Hello! Why is access to CIM source code restricted?

1 Like

That’s an interesting question! I’d like to know as well.

I wonder why also. Who is in charge? …seems its me… now open

1 Like

@DavidStables excellent!

If only everyone did that!


Sorry new into this landscape although I’ve read a few blogs from Ewan. Who
owns this and how many are contributing? Are there any other similar
projects and how far are we apart from just diagrams?


Is this the right place to ask questions?

If so, am I correct in thinking the common API is FHIR (UK).

Also in many cases the proprietary API will also be FHIR but different flavours (eg US FHIR for cerner or epic) or bespoke API’s (Lorenzo, EMIS, trakcare, etc).

The diagram looks like a trust integration engine, so would the connections be configurable? (Think it’s similar but think I’m wrong here)

Background. Project funded by Endeavour and was a collaboration between Endeavour, NHS England and HSCIC. The idea was to prove that the legacy “hidden” GP system supplier APIs could be mapped to a common standard - the CIM which are a set of UK profiles based on the US resources. Since this has now been proved, GP system suppliers have rightly now committed to move to the standard FHIR based APIs themselves. This is being taken to standard and contracting under a program called “GP Connect”. Suppliers may be ahead of, or behind, this process but remains to be seen.
Meanwhile parallel activity to look at multi-domain / multi-directional has commenced with the C4H interoperability community and the supplier action group which is forming. Same principle, can we get common profiles for cross domain bidirectional, or if not do we get a small enough number to make it cost effective. Starting with these UK profiles.
The reality is that it is up to suppliers if they wish to set the pace, can be SMEs, large suppliers or both.

Presumably you actually meant … ‘large enough’ number … there, David. :wink:

Nope… and yes… Resource Profiles are expensive to design. If there were 3000 e.g. developing them for single use cases would be onerous and unaffordable. If there were 30 in total that would be easy, so the fewer the better. There will be many more APIs than resource profiles. And just to confuse matters, FHIR calls the specification of a bundle of resource profiles “profiles” so many of these yes

Ah ha. I had a misgiving as I typed that; that I was missing something in your point. I wasn’t seeing whether the number of profiles was relatively large or small.


I’m not sure what you think I own - I’m keen to promote the concept of
an open platform based health and social care ecosystem. In the best
tradition of open source my ideas are based on those of others re-used
and recycled (stolen?)

If you are looking for a mature implementation of a platform based on
open standards then I’d say it’s that in Moscow
which uses openEHR + IHE-XDS. This model has inspired the work of myself
and others on the NHS Code4Health Platform and the Ripple project which uses openEHR is actively planning
to add IHE-XDS.

In my blog I tried
to suggest some general principles for an open platform and the Apperta
Foundation has been working to try and coordinate the approach of
various activities in the UK around what is now emerging as an open
platform community including openEHR <>, Ripple, Code4Health,
Endeavour Health <> and Synapta <>

With support for the concept of an open innovation platform coming from
the big consultancies likeMcKinsey
and accenture
Now, is the time to act


Ewan Davis - Director - Woodcote Consulting

Voice +44(0)207 148 7170 Mobile +44(0) 7774 272724 USA +1 347 688-8950
Skype ewan.davis (by prior arrangement only)
Read my blog at
Follow me on Twitter
View my profile on LinkedIN

So we (this forum/site) could agree to use the same profiles (I’ve not seen anything that odd in the profiles that excludes secondary care use). All we’d need to do at base level is to agree to use REST+FHIR maybe oauth2.

It should be too hard to have a connectathon along these lines and connect ripple, open dento, endeavour, etc.
Possibly just Patient, Appointments, Conditions - not many.
I suppose this is a baseline.

Then move onto documents interchanges for the next one. Eventually XDS/ITK document sharing and Openehr.
Rapid baby steps rather than leaps in tech (and avoiding committees).

Sorry Ewan - just read your post. It’s the small steps I’m in favour of. Not against XDS/openehr - I’m just not sure how to get the majority of the NHS to move to that level without some stepping stones.


We needs lots of stepping stones and I not yet sure exactly where they
need to take us. This is why in my attempt to define what an open
platform is. I didn’t mention any specific standards and acknowledge
that there were a potential a number.

My current view is that for defining content openEHR is the only game in
town with a mature methodology, tools and community HOWEVER when it
comes to how you implement these shared models then it a much more open
question. If you were starting from scratch then using the whole openEHR
stack has many benefits, but for existing systems an alternative
approach may be better. My next column on is going to
be about this.

But some thoughts in advance, drawing heavily on the work of Thomas Beale.

We need to define in excess of 4,000 bits of clinical content to cover
clinical medicine (never mind the whole scope of health and social care)

  • “bits” might be a openEHR archetype or a FHIR resource, such things
    on average probably have around 10 - 20 data points each. This is a BIG
    task which needs to be done once for everybody. It needs:

    o Governance - International, but allowing multiple levels of
    subsidiarity; regional, national, local
    o To be able to handle dissonance - There are multiple version of
    the truth
    o A community of engaged clinicians
    o Mechanisms for creation, curation, peer-review, publication and
    o Tools able to support all of the above

openEHR has all of this, anyone else (say HL7 FHIR) will have to either
use it or reinvent it (the later being a massive waste of time and
resources) - I believe David Stables plan to build a openEHR - FHIR
bridge to enable openEHR models to be use to generate FHIR resources.

This is a job for clinicians not modellers

Have a look at Wai Keong’s
presentation for some helpful insights

Tom Beale’s blog for the basis of assertion about the scale of the

and some insights as to why Why IT people can’t build information
systems (on their own)

And if you want a quick view of openEHR + FHIR this piece


Ewan Davis - Director - Woodcote Consulting

Voice +44(0)207 148 7170 Mobile +44(0) 7774 272724 USA +1 347 688-8950
Skype ewan.davis (by prior arrangement only)
Read my blog at
Follow me on Twitter
View my profile on LinkedIN

Reading the JASON report ( is interesting;

  • “The problem with this approach is that the CDA is really only a container
    for the information. In principle, the use of XML will allow disaggregation
    of the atomic data, but the parsing would be left to the particular application and each provider of the information would have to publish details of their particular XML schema. Because it is in some sense such an openended
    standard, supporting it is made quite difficult.”
  • “The recent introduction of FHIR by HL7 is in JASON’s view a signifi­cant improvement over CDA.”

So whats the future for CDA?

I don’t think FHIR and openEHR are tackling the same problem. You could say openEhr, XDS, CDA and hl7v3 are similar and hl7v2 and FHIR are also similar. V2 and FHIR do a lot of leg work moving small bits of data around an organisation.
Looking at a dental system it would use FHIR or v2 to talk to a patient system, same for point of care devices observations and document systems. Moving the dental record around it would use openehr maybe using rest+FHIR. Searching for the dental record, it could be via a XDS SOAP but more probably XDS FHIR RESTful interface (doubt we’d use the older soap technology in the UK as our adoption is low at the moment we would probably jump to XDS FHIR).
Going outside of the organisation… ITK, XDS soap, FHIR+ITK and the contents FHIR equivalent of CDA or openEHR or hl7v3/CDA

We also don’t need to model many of the transactions, just use simple common and the back of a fag packet - FHIR allows that.

David - Nice touching base with you after such a long time and thank you
Rod for Tom’s and your links. I’m impressed with your drive. Your and Tom’s
post are brilliant.

My apologies if some of these comments might seem naive but we have to
start somewhere!

In the end of the day it’s all about getting text from one physical
location to another and presenting/managing the data in line with business
requirements. At the moment the data is held with system suppliers from
primary and secondary care and from what I undestand we are looking at a
way of moving it to third party suppliers.

For GP data at least I can see 3 methods how this data is moved into a
mashable form

  1. Via GPSOC with a unified API (with suppliers and third parties in
    different lots)
  2. Via the suppliers own API through their partner program and via the MIG
    (ie vendor specific)
  3. This CIM though an Open Source. Nb Open Source doesn’t mean free, it
    means shared.

How far away are we from getting feeds through CIM agreed from current
suppliers? GPSOC is slowly moving forward from what I understand and I
doubt all the suppliers will agree when they get more granular. We’ll end
up with more generic agreed methods It’s similar to the analogy with Web
Apps (aka GPSOC) and Native Apps (aka Third Party APIs).

I’m impressed with CIM and what it can offer. From what I understand it
follows the Mantra of “Connecting All” rather than “Replacing All” but to
get real time feeds in and out of clinical systems at scale is a task esp
if you looking to datasets from different supplies with no Proxy. It will
probably more suited to patient level activity or need feeds into a local
server which syncs the data. And to have this two way!

Also I’m not sure how FHIR integrates with OpenEHR. They look like 2
standards that need to be mapped but I’m probably missing a piece of the
jigsaw here.

Also playing devils advocate a bit, aren’t we complicating matters? Isn’t
another option to take a simplified sub set of OpenEHR/FHIR then manage the
business logic within each of the suppliers applications? OpenEHR seems to
have both form (schema) and funciton (business logic) and I’m not sure how
long it will take to add business logic at scale to make it fit for
purpose. Nowadays (thank god) I don’t even deal with much SQL anymore. I
map extracts (in XML via the EMIS API at the moment) to objects and let
LINQ do it’s thing and create the business logic I require. With Entity
Framework or other ORMs I can have persisting data without worrying about
the nitty gritty. But I’m sure you’ve discussed this in other forums.

Finally is there still at team working on the CIM/method to help from a
clinicians point of view? Everybody seems to be talking but it’s difficult
to tell how much is out there and what is actually going on.


You use them for different things, horses for courses?

Clinician use openEHR
Project staff process model using: flowcharts (hmmmm) or ideally BPMN
DB/Reporting: build their entity relationship diagram or object model
Technical staff take the clinicians model, create a BPMN technical model from process model and use FHIR for donkey work.

If clinicians want to see/use openEHR fine. personally I’d probably build it using a number of FHIR queries (or something like it) - in secondary care the data for the model maybe in several different systems (this would apply to CDA too). As a developer I want good documentation to show what I’m trying to build.

I would put it differently. What clinicians need is reliably defined semantics: clinical data points, workflow activities and so on. What software developers need is the same, plus usable semantic definitions - stuff they can program with.

The model-based approach (openEHR, HL7 CIMI, VA/ONC FHIM, CDISC, Intermountain Healthcare and others) is to do this modelling in a layer above the concrete implementation, which may be FHIR, HL7v2, CDA, JSON, some other XML etc.

At the moment there is a tension between FHIR resources, which have a few hundred data points, and the needed number of clinical data points, currently around 15,000 (openEHR + Intermountain, which is providing a current model set for CIMI). It’s also a question of structure, typing and much else. Within HL7, a major current question is: shouldn’t CIMI drive the definition of FHIR resource definition? Because if not, there are two parallel siloes of semantics definition going on. However FHIR resource definitions are not readily re-usable in any other concrete form, whereas CIMI, openEHR etc are design to be translated into any concrete form, including UI, XSD, APIs and so on. Secondly, it is not clear how clinical content modelling can scale in the FHIR approach, when one considers the numbers. This question is the central one in the discussion about CIMI and FHIR.

There is another approach available, which considers FHIR resources as a ‘default’ set of built-in content, for systems / environments that don’t have any other content definitions. For those that do (see the list above), the need is to be able to use FHIR protocol, data types, ids, terminology binding etc, but to carry their own content.

I have documented this idea here. This is being discussed within HL7, and I am told there is recogition of the need, and that other organisations have asked for the same thing.

In my view, the key thing is to have a single coherent set of clinical semantics defined in a library fashion that enables re-use in multiple downstream formats, of which FHIR is one. This library needs to include WF definitions eventually.

Aside: I am working at Intermountain Healthcare, a recognised leader in WF research, on a project called Activity-based Design, which aims to model adaptive and cooperative workflows. We’ve determined that BPMN is OK for imperative (deterministic) workflows, but for managing on the fly changes, something else will be needed. The underlying core of their workflow formalism is a flavour of archetypes. This research project will make its outputs available openly over time, so could be quite useful to the wider standards community trying to connect workflow definitions to health data.