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! https://github.com/endeavourhealth/CIM-Interop-2015
If only everyone did that!
M
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?
Raza
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. 
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.
Hi,
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
http://www.woodcote-consulting.com/moscow-ehealth-a-model-for-the-uk/
which uses openEHR + IHE-XDS. This model has inspired the work of myself
and others on the NHS Code4Health Platform
https://code-4-health.org/platform and the Ripple
http://rippleosi.org/ project which uses openEHR is actively planning
to add IHE-XDS.
In my blog
http://www.woodcote-consulting.com/defining-an-open-platform/ 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 <openehr.org>, Ripple, Code4Health,
Endeavour Health <www.endeavourhealth.org/> and Synapta <synapta.org.uk>
With support for the concept of an open innovation platform coming from
the big consultancies likeMcKinsey
http://www.mckinsey.com/industries/healthcare-systems-and-services/our-insights/how-healthcare-systems-can-become-digital-health-leaders
and accenture
http://www.heartofnorway.no/en/innovation/a-future-vision-for-healthcare-in-norway.html?utm_source=Twitter-paid&utm_medium=AccentureHealth&utm_content=2&utm_campaign=NO-HSE-Health
Now, is the time to act
Ewan
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 www.woodcote-consulting.com/blog
http://www.woodcote-consulting.com/blog
Follow me on Twitter https://twitter.com/WoodcoteEwan
View my profile on LinkedIN
https://www.linkedin.com/pub/ewan-davis/0/742/747
Director HANDIwww.handihealth.org http://www.handihealth.org
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.
Hi
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 digitalhealth.net 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
endorsement
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
https://docs.google.com/presentation/d/1NV8pJ6esVZ18IsmiRiyr1TVYGAKs8lk2qQmrzjG7ApM/edit#slide=id.gb73c117b4_0_68great
presentation for some helpful insights
Tom Bealeās blog for the basis of assertion about the scale of the
problem
https://wolandscat.net/2014/12/15/semantic-scalability-the-core-challenge-in-e-health/.
and some insights as to why Why IT people canāt build information
systems (on their own)
https://wolandscat.net/2015/11/29/why-it-people-cant-build-information-systems/
And if you want a quick view of openEHR + FHIR this piece
https://wolandscat.net/2016/04/10/openehr-technical-basics-for-hl7-and-fhir-users/
Ewan
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 www.woodcote-consulting.com/blog
http://www.woodcote-consulting.com/blog
Follow me on Twitter https://twitter.com/WoodcoteEwan
View my profile on LinkedIN
https://www.linkedin.com/pub/ewan-davis/0/742/747
Director HANDIwww.handihealth.org http://www.handihealth.org
Reading the JASON report (https://www.healthit.gov/sites/default/files/2014-JASON-data-for-individual-health.pdf) 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
- Via GPSOC with a unified API (with suppliers and third parties in
different lots) - Via the suppliers own API through their partner program and via the MIG
(ie vendor specific) - 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.
Raza
www.razatoosy.com
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.
etc
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.