# Common Interface Mechanism project **Category:** [Endeavour Health](https://openhealthhub.org/c/endeavour-health/20) **Created:** 2016-04-27 06:53 UTC **Views:** 9650 **Replies:** 60 **URL:** https://openhealthhub.org/t/common-interface-mechanism-project/356 --- ## Post #1 by @kakoni Hello! Why is access to CIM source code restricted? http://cim.endeavourhealth.org/ --- ## Post #2 by @pacharanero That's an interesting question! I'd like to know as well. --- ## Post #3 by @DavidStables I wonder why also. Who is in charge? ...seems its me.... now open --- ## Post #4 by @pacharanero @DavidStables excellent! https://github.com/endeavourhealth/CIM-Interop-2015 If only everyone did that! M --- ## Post #5 by @raza 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 --- ## Post #6 by @mayfield.g.kev 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) --- ## Post #7 by @DavidStables 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. --- ## Post #8 by @mark Presumably you actually meant ... 'large enough' number ... there, David. :wink: --- ## Post #9 by @DavidStables 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 --- ## Post #10 by @mark 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. --- ## Post #11 by @ewan 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 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 *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 Follow me on Twitter View my profile on LinkedIN Director HANDIwww.handihealth.org --- ## Post #12 by @mayfield.g.kev 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). --- ## Post #13 by @mayfield.g.kev 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. --- ## Post #14 by @ewan 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 great presentation for some helpful insights Tom Beale's blog for the basis of assertion about the scale of the problem . 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 *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 Follow me on Twitter View my profile on LinkedIN Director HANDIwww.handihealth.org --- ## Post #15 by @kakoni 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? --- ## Post #16 by @mayfield.g.kev 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 --- ## Post #17 by @mayfield.g.kev 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. --- ## Post #18 by @raza 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. Raza www.razatoosy.com --- ## Post #19 by @mayfield.g.kev [quote="raza, post:18, topic:356"] Isn'tanother option to take a simplified sub set of OpenEHR/FHIR then manage thebusiness logic within each of the suppliers applications? [/quote] 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. --- ## Post #20 by @wolandscat 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](https://wolandscat.net/2015/12/20/making-fhir-work-for-everybody/). 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. --- ## Post #21 by @DavidStables The confusion arises because the Geeks (us lot) after 30 years have still not properly defined the boundaries between the semantic and structural concepts and instead of constantly trying to simplify, we simply end up creating confusion that no one in the real world can understand. And by the real world I include suppliers and clinical informaticians. In other words Intellectual arrogance. FHIR risks moving from a simple to understand set of NoSQL fields covering clinical system content to a mega bucket of unintelligible scope creeps. openEHR should move back towards a simplification space either by constraining itself or dividing into its component parts, each of which need to be recognizable as separate from each other. Both tribes should stop claiming the intellectual high ground as should of course the Snomed lot! --- ## Post #22 by @wolandscat David, I am very happy to take criticism of this sort from people with long and serious implementation experience (indeed, UK GP computing still has a great deal to teach the world). Although I would need some details to better understand what you think openEHR should concretely do (better). [Aside: openEHR has in the last year split its specifications into well-defined components - [see here for a picture](http://www.openehr.org/files/programs/specification/SpecProgStr.png) and the 'Specifications' table on [this page](http://www.openehr.org/programs/specification/workingbaseline); whether this is the kind of separation you would like is another question.] Re: intellectual high ground: I'm not interested in being on high ground. I am _very interested_ in having _solid theories_ underpinning architectural design and consequent implementations. Implementations with no theories will always hit walls in the end, sometimes so large as to require a ground up rebuild / relaunch. We are in desperate need of good theories in health informatics, but there are not many documented. Instead, we have a mass of standards taking the place of theories and architectures. The costs of the NPfIT era attest to this. In openEHR I think it is reasonable to say that we have made a solid effort to be theoretically as well as practically grounded. The specifications have been created based on deep knowledge from European health informatics projects over the years, our own implementations, as well as the incomparable pool of knowledge from what I might call the 'British health informatics intelligentsia' - mostly from the GP computing arena, for which I have great respect. Even as recently as two years ago, Ian McNicoll and I were analysing the structures of EMIS problem lists and rethinking how the problem list archetype should be designed. Please don't underestimate our dedication to understanding good principles and design ideas and incorporating them where we can in the openEHR architecture. There is never any guarantee we have done a good enough job of course, and we can only rely on concrete critique and advice from the rest of the world. On where we should be trying to go collectively: it has to be a health computing platform framework of some description. We should forget the obsession with (formal) standards clubs as such, and concentrate on standardising elements of this open platform architecture, including sustainable processes for generating shareable, computable models of clinical semantics forever (that includes archetypes, terminology value sets, guidelines e.g. proForma, workflow definitions, and much else). Without a coherent platform approach, I fear we will forever be paying the significant costs of trying to stitch together siloed standards that don't on their own come anywhere near solving the whole problem, but may like to think they do... --- ## Post #23 by @mayfield.g.kev I was thinking more along the human side of things. It was simple when I worked in primary/military health care to get clinical input into a problem and so prove the model worked. Since I've moved into secondary+community, from my perspective the clinician is now at the centre of an 'onion'. Yes your correct, the technical architect/senior developer and clinical modeller can understand CDA/HL7v3 and openEHR but we have several layers to work through. At each layer someone will want to use a 'Manchester screwdriver' [Using a hammer to fix a screw]. Another way of saying this is people will try to bend the requirements to using FTP, CSV, text files or PDF. The non 'manchester screwdriver' version of this - HTTP/REST/SOAP in place of FTP, format XML or JSON in place of CSV, messaging (HL7v2/FHIR)/resource API (FHIR)/API (HL7v3) in place of CSV+text and data transfer object (openEHR/CDA) in place of PDF. It's another set of layers to work through (more onions!). Another point to consider here: in primary IT the managers/senior staff will be from a software/health background, in secondary/community they are from hardware/SQL background/health admin. The experience I've had over the last few years is the model needs to be described in easy to understand chunks, how you present that model changes depending on the audience. e.g. UML sequence diagrams for technical staff, BPMN for project staff and an overview BPMN diagram for all, FHIR terminology (NOT FHIR itself) works for BPMN/process flow/sequence flow discussions. Also stick to known software patterns when discussing technical interactions - staff in other sectors (council) should be able to understand these [Quite a few use the Martin Fowler series of books i.e. Enterprise Integration Patterns] It's all about communication and getting through the 'onion' layers. I did mention using FHIR terminology but that tends to be natural, even if staff don't know FHIR - this is the biggest reason why I expect FHIR to move forward quickly. --- ## Post #24 by @ewan Hi, Having built what was to become one of the larger GP system suppliers and remained its Managing Director for 10 years (AAH Meditel (Number 2 with 1500 practices when Torex took it over in 1999 and I left) I would echo you comments about Primary Care (military primary care was surprising similar) There are many reasons why UK GP Computing was a success both compared to other care settings in the UK and in a global context - We led the UK and the world in the use of computers at the point of care. Putting aside the obvious prime reason - my own personal brilliance! - some of these related to the specifics in the environment (business and clinical) of UK primary care. We were just lucky they worked in our favour and they are not easily repeatable elsewhere. However, there are some other factors that we can learn from and apply elsewhere. At the top of this list was the fact that GPs drove system design - My original system was written by Dr David Marwell (then a GP trainee - Now the high priest of SNOMED) with a bit of help from Dr James Read (a Loughborough GP and originator of the Read Codes, which became part of SNOMED) Lots of GPs worked in our development team who have since become famous (or infamous) in health IT, Dr Glyn Hayes, Dr Mike Bainbridge, Dr Peter Johnson, Dr Jon Rogers and many others. In VAMP (now INPS) we had Dr Alan Dean, succeeded for may years by Dr Mike Robinson EMIS had Dr Peter Sowerby and Dr David Stables - "Written by Doctors for Doctors" In TPP we have Dr John Parry and Frank Hestor's wife is a GP (which I bet keeps even Frank focussed on delivering systems that work for GPs) My problems in AAH Meditel started (some will remember the pain with System 6000 that was eventually to become iSoft Synergy), when I and my medical colleagues started to believe that the techies (who clearly knew lots of clever techie stuff that we didn't understand) might have a better idea of how to design a GP system - You can add that to the top of my long list of mistakes over the past 35 years in this business. openEHR provides an abstraction from the technical shit that clinicians find comfortable to work with. Its focus is on content rather than work-flow (as is FHIRs) so I find it interesting that much of what Kevin talks about in work-flow. Here I think things like BPMN, Drools, ProForma and openEHR GDL have a place. Exactly what that place is is something I and others are trying to work out in Synapta.org.uk 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 Follow me on Twitter View my profile on LinkedIN Director HANDIwww.handihealth.org --- ## Post #25 by @mayfield.g.kev [quote="ewan, post:24, topic:356"] openEHR provides an abstraction from the technical shit that clinicians find comfortable to work with. [/quote] Interesting terms :) I think I'm following a similar train of though but we also may need a system that non techies and non clinicians are comfortable with. Would be interested to hear other peoples views but the non tech/clin side of projects seems to take 95%+ of the time. A lot of this is workflow and consent related. I'm not mentioning BPMN2 as a computer system, just a tool to convey ideas between parties - (so it doesn't have to be technically correct). Don't mind what we use to express these ideas - just suggest we use something that most people understand (it's not any of the HL7 standards). IHE has used UML in the past and has done some more recent work using BPMN2. --- ## Post #26 by @mayfield.g.kev Could I go back a bit and ask a question about openEHR. Over the last weekend I generated a number of observations about me (a bit of a selfish post!). I generated weights, blood pressures, heart rate and exercise data where would they go into openEHR? It sounds like they would go into the reference model but it also seems archetypes is the answer? --- ## Post #27 by @wolandscat @mayfield.g.kev all openEHR data are always instances of the reference model (which is an orthodox information model, i.e. what you see [expressed in UML in the specs](http://www.openehr.org/releases/RM/latest/docs/index)). The RM is like most fairly generic information models: you can express sensible stuff in it, and also nonsense. Mathematically, the nonsense possibilities are astronomical in number (think of how many ways your kids can build nonsense structures out of Lego bricks). Archetypes and templates enable the sensible possibilities to be modelled. In a real openEHR implementation, the vital signs you mention will be recorded in an openEHR template, which is an artefact that combines bits and pieces of certain archetypes. You might use a 'nurses observations' template that has BP and HR in it, and maybe another exercise related one that has the weight and exercise information in it. But you could use any template that had the right data points - e.g. a GP visit template. The underlying archetypes define the data, in terms of valid RM structures (think: Lego instruction sheets). You can find the first three you mention here: * [BP](http://www.openehr.org/ckm/#showArchetype_1013.1.130_MINDMAP) * [HR](http://www.openehr.org/ckm/#showArchetype_1013.1.170_MINDMAP) * [weight](http://www.openehr.org/ckm/#showArchetype_1013.1.132_MINDMAP) Depending on what you mean by 'exercise data', there may be something but probably not much yet, e.g. if you want a record of times for 2k on the rowing machine, 5k running (with start and finish heart rates maybe?) etc, I don't think there is an archetype for that yet. Modelling that properly might be done by sports medicine specialists, but clearly some ad hoc archetypes for it could easily be built. Anyway, assume the archetypes you wanted all existed, you would create one or more templates using the bits you wanted (i.e. cut out the bits you don't want) and deploy those in an openEHR system. You would build app screen forms based fairly closely on the template data set(s). Ian McNicoll (@ian) regularly demonstrates this kind of stuff, and it's routine in openEHR implementation environments. When you run your app, fill out the forms (or the data sets might be created by an app that talks to wearable devices - no UI input forms needed), and save the data, you are saving openEHR RM data. It all contains markers indicating which bit of which archetype each piece of data relates to. But it conforms to the RM - i.e. all openEHR data, all around the world, conforms to the one (stable) Reference Model. --- ## Post #28 by @mark @mayfield.g.kev That stable and consistent reference model is one reason why the openEHR clinical information structures are so popular with clinicians. --- ## Post #29 by @mayfield.g.kev Thanks. Would openEHR accepts an Observations (with a SNOMED code) and place it in the correct archetype? I was thinking of data I've recorded automatically in the Strava cycling app and wondering how it would be added to an openEHR system. So I'd have heart rate values and maximum heart rates - I'd want to use a API not a UI to add data. I am correct in thinking openEHR acts as a recipe or lego instructions set for presenting information to clinicians. I might be getting the wrong impression but I would assume I'd use for FHIR to add my observations (from Strava/devices) into a database and use openEHR as a set of instructions to get the data (via FHIR) from the database to present it to a clinician. This doesn't match what I'd previously heard about openEHR though. --- ## Post #30 by @ian Hi Kevin, If you send me or point me to the Strava dataset, I can set up an openEHR template for you and quickly take you through how you would get data in to openEHR via the Code4Health Ehrscape API. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL --- ## Post #31 by @wolandscat openEHR is a representation for the DB. FHIR is essentially a web message format. I guess you could store that if you need to store such things, but it won't be very queriable, nor does it obey a standard reference model - it would be like storing HL7v2 messages instead of writing into (say) EMIS or INPS in their native formats. openEHR isn't specifically to do with presentation (I am intrigued as to where that idea came from), it's all about back-end EHR data and querying. Of course, having well-defined data sets means that UI forms can be easily designed, and in some cases generated straight from the template. --- ## Post #32 by @mayfield.g.kev Thanks Ian. Can I take up the offer at a later date? I'm swamped with work at the moment and I want to read up on openEHR. _I think I'm not getting the openEHR vrs FHIR discussion - I don't think the question is valid, each has a purpose which may sound similar but they aren't_ wolandscat.. You wouldn't store the message in the database. With EMIS systems, any observations within the HL7v2 would be stored in the Observations table or global (they would all be quite similar). I would assume a openEHR receiving HL7v2 or FHIR would behave in the same way - it would store the data in a format it wants and so we have loosely coupled systems. For the HR rate example. My device just sends a stream of observations to my phone, so the raw data is something like: 2016-05-04 09:28:10, 176 2016-05-04 09:28:20, 179 2016-05-04 09:28:30, 180 2016-05-04 09:28:40, 188 Strava would supply the data in a similar format but with a person identifier. If I was to convert to FHIR/v2 - I'd be adding the SNOMED code to indicate the observation type. (The process has a number of similarities to Lab Point Of Care - see http://wiki.ihe.net/index.php/Laboratory_Point_Of_Care_Testing. Strava API can be found here: http://strava.github.io/api/ and Heart Rate device http://api.wahoofitness.com/interface_w_f_heartrate_data.html ) --- ## Post #33 by @wolandscat Your heartrate example is an example of a query result data structure. The data might be stored like this in some simple app, but in an EMR/EHR system, there will be a lot more data - units, context, potentially information on measuring device, audit, and so on. So the data structure is just one possible query result from the underlying data, but it's not a definition of the underlying data - that requires a proper model. In openEHR, we define these structures very easily as AQL queries (based on archetypes), and we can obtain any of the underlying data like that. No special models are needed to query - you just query what you want. --- ## Post #34 by @raza Hi Tom Reading this thread with interest and thanks for getting further clarity on OpenEHR/FHIR. Just another query if I may. Would OpenEHR need to have a hosted server to manage the AQL queries or would they be managed on the client? I suspect the former and if it is the hosted environment, how would this be synced with the Data from the supplier feed? --- ## Post #35 by @wolandscat Well there will already be a hosted server of some kind with an openEHR implementation - that's where the EHR data are. Now, when I say that, I don't mean it's necessarily _the_ EHR data of course. In a UK location with say Cerner, or a GP location with one of EMIS, TPP, etc, those systems contain what is considered the 'EMR' in the business sense of the word. The openEHR system will have been deployed in these cases as some kind of additional EHR, or 'EHR extract', to do some specific job, e.g. support smart querying, some particular apps or whatever. So think of the openEHR server as an 'EHR cache' in these kinds of environments. As with any cache or 'overlay server', there is the question of a data bridge, synchronisation, and the event model driving that. That will usually differ according to needs, but one method is for application 'commit' events to be trapped for certain apps, and the data set written to both main EMR and openEHR persistence. Another model is for a job (say in an IE, on a timer, or event driven) to run and extract needed data from the EMR to openEHR. It depends heavily on whether the openEHR service is being used for a 'thin slice' of data (e.g. just diabetic patient related) or 'everything'. In other environments, openEHR really is the main EMR. So - in all cases, there will be an openEHR DB and EHR services sitting on top of it. To get an idea of what these might be, [see this picture](http://oceaninformatics.com/files/platform/oceanehr_platform.png). That happens to be the Ocean picture, but all the suppliers (Marand, DIPS, Code24 etc) have similar core services. So you will see in there a 'Query service'. This is AFAIK on the server side for all the openEHR implementations, and for serious systems, you have to do that in order to manage load balancing and latency of responses (i.e. making sure some difficult research query doesn't kill nurses ward screens). This query service takes [AQL queries](http://www.openehr.org/releases/QUERY/latest/docs/AQL/AQL.html), and runs them over the physical database, which will look different in each implementation. --- ## Post #36 by @mayfield.g.kev [quote="wolandscat, post:35, topic:356"] To get an idea of what these might be, see this picture. [/quote] Is that a typical system? If so it explains a lot. FHIR would likely become the common format for you Integration Engine (or more realistically most of the those systems are likely to provide a FHIR API). Also my heart rate example wouldn't need to use openEHR - the date would go to a LIS or EPR system instead. Is that how Endeavour is expected to be used (it will part of the Integration Engine or the Integration Engine)? --- ## Post #37 by @raza So under the hood is the openEHR Server a normalised Database (eg SQL Server) and AQL Query Service just maps to SQL queries to return required datasets in the form of Json/XML/DTOs which are returned to their destination via FHIR? Raza www.razatoosy.com --- ## Post #38 by @wolandscat Within openEHR environments, we don't need another format for integration; the openEHR models provide all the formats for messaging and documentation. Creating FHIR-like data can be done in services, and is being done in some environments, particularly in the UK. But FHIR only covers about 5% of the clinical content defined in openEHR. So there's no simple trick to turn everything in openEHR into FHIR. Manual mapping is required, and that takes time. FHIR resources are also a moving target at the moment. So while putting up a simple heart-rate or BP is easy enough, serving the 5,000 - 10,000 data points needed in a real system using FHIR is not possible today. Your heart rate data might be in the LIS, more likely in the EPR. The problem is that it will be in a different form in every system you want to interrogate. There are hundreds of these systems in any hospital. For heart rate, maybe its easy to figure out which one to talk to, but for a lot of other data, it is not. And you are unlikely to be able to obtain a published model of what the clinical data you want actually is. What openEHR is aimed at doing is creating very flexible models of this content, making those available so that there is a standard, public, model-based representation of clinical content. The various Clinical model repositories around the world have something like 8,000 - 10,000 clinical data points modelled. From those, various downstream formats can be generated including XSD, JSON, Java APIs, C'# APIs, HTML and so on. FHIR is more complicated because it imposes its own clinical content resources, so tends to be a manual mapping. --- ## Post #39 by @ian Hi Raza, Not necessarily!! There is definitely some kind of database in there but it can be SQL, NoSQL or use some sort of O-R Hibernate type layer. There are examples of all of these including efforts based on Mumps, MongoDB and xml databases out there but the industry leading examples tend to use non-normalised SQL tables with some kind of binary or native structured data handling. See https://github.com/ethercis for an example. This one of the back-ends being used by the Ripple project https://github.com/RippleOSI , using the Code4Health Ehrscape API (a simple RESTful wrapper around the common openEHR service API). (AQL in process of development) You are correct that AQL is ultimately mapped to the native query method of whatever physical db is used. The clever bit is that adding or adapting new clinical content does not require any technical re-factoring - no new technical information modelling, no new db re-design. Uploading the archetype definitions (as templates) and you are ready to go right away. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL --- ## Post #40 by @wolandscat Yep. Ian beat me to it, but the varieties of physical storage go a long way outside of a classical 3NF database schema approach, including blobs, path-based, and so on. Some are implemented in an RDBMS, others not. --- ## Post #41 by @raza Ian, Tom Yep, bigger scope than I thought but understand it conceptually. From what I understand it has some parts of an ORM like Entity Framework or NHibernate to manage the back end ie not worry about the implementation of the back office/persistent data but with a standardised way of extracting that data in the middle both in inputting queries and templates and in their return. FHIR is just a standard way of parsing the data. A lot of work would be in maintaining a persistent synchronised back end from several sources in whatever way you need to store the data. I assume the hooks to link into these database to be able to query AQL are in place. 2 more queries then I'll leave you 1. Going back to the original thread does CIM implement OpenEHR or are there thoughts of doing this? From what I can gather CIM takes data from the source and uses FHIR to standardise or maybe it does have OpenEHR but I can't see it mentioned on the web page. 2. Are there any examples of OpenEHR in .net I can play around with that you know of? Thanks. --- ## Post #42 by @mayfield.g.kev Thomas, I don't agree with your assertion that FHIR and openEHR are in competition or fighting over the same problem domain. FHIR is providing a resource API and a canonical data model, it's not a clinical model. I beginning to see where I would use FHIR with openEHR and where I wouldn't, conversely where I wouldn't/would be inclined to use openEHR and also where it be useful to use both. I'd go with the best tool for the job. p.s. The 5% point is very misleading - I've not found a major dataset FHIR can't cover within the NHS and that's stable FHIR not draft. --- ## Post #43 by @wolandscat The dissonance comes where we expose openEHR (or indeed any clinical) data that have a native published format. To put them in to FHIR requires mapping to FHIR resources, e.g. Observation, which creates a certain amount of complexity. For easy data it's easy, for more complex data it's harder. Converting say all the openEHR vital signs to FHIR (probably 50+ data points in various structures) requires a reasonable amount of work. In an openEHR environment, we publish the data in its native form, i.e. directly based on openEHR Reference Model. So just pointing out the obvious here. In terms of coverage, there are about 8,000 clinical data points in the openEHR.org CKM, produced by hundreds of clinical people. I have not counted FHIR recently, but I think it is still in the low hundreds. If it was 400, then that's a 20x difference, which is 5%. I have no intention to mislead, only to try to find ways to get them working together. That means looking objectively at the facts of technologies, not hype. --- ## Post #44 by @ian Hi Raza, If you want to play around with openEHR, I can easily setup a Code4Health platform domain for you. This is being gradually built out but for now exposes an openEHR service layer as a Restful interface, which you should be able to consume/write to easily enough from .net. This [guide to using Postman with the C4H Platform](https://github.com/freshehr/postman-ehrscape) should give you enough info to be able to re-work for .net Although the specifications needed to develop a back-end openEHR server are freely available, I also recommend that people get familiar with the technology first of all by consuming an existing service. Indeed the philosophy is that the vast majority of 3rd party developers will make use of an existing service, rather than try to develop their own full stack, which is do-able but not easy engineering. Needs to be seen in the same light as "why would I want to build my own new SQL / NoSQL engine?" - definitely required but most devs will use an existing product. Just ping me privately and I can get your domain setup. Ian --- ## Post #45 by @raza Thanks Ian, will be in touch. --- ## Post #46 by @mayfield.g.kev [quote="raza, post:41, topic:356"] FHIR is just a standard way of parsing the data. [/quote] HAPI FHIR might be useful http://jamesagnew.github.io/hapi-fhir/doc_jpa.html. It stores the FHIR as JSON so suitable for NoSQL, you can recode the JPA/hibernate layer to store in traditional SQL tables. [We're evaluating HAPI as a API to use with our clinical portal (javascript). We're changing our PAS system to EPR and we need to change existing API's over to the EPR and FHIR/HAPI offers very similar API's (the EPR doesn't have a FHIR api in the UK just US). We will feed HAPI via HL7v2 messages] I've used similar java open source (apache* and spring) to put FHIR front ends to a Lab IS, ED, Document Management Systems. The main reason for using FHIR in these cases is it normally matches the underlying database structure or API - it's a simple mapping exercise and it is what developers expect to see. FHIR tends to match the database structure (and API) because both FHIR and PAS/LIS/EPR Databases have been strongly influenced by HL7v2. So in a way FHIR is not new and not immature, it's a combination of a number of trends. _[Note: I'm a bit unsure about a number of the newer resources(1) in FHIR - do we(/UK) have experience to make these decisions, is openEHR a better solution, is the Pathway/CarePlan/workflow just going to work for US/Canada]_ CIM probably used FHIR for same reasons. (As an ex-EMIS developer I was probably conditioned to make the same decision :) ). They also use java, apache camel, spring, etc. [As does Ripple]. Would it not be easier for openEHR to support retrieving data via FHIR, so develop once and reuse many times? It would help avoiding all the legacy interface mechanisms to source systems. (1) I'm classing resource with a zero next to them as new http://www.hl7.org/FHIR/resourcelist.html --- ## Post #47 by @raza Thanks Kev I'll look this up, thanks for the pointers. The problem I face is most open source technology isn't .net so it's a steep learning curve to jump into a new language and work on a full stack. Being a GP I'd be stupid to know anything more than just - be aware of the technology - be able to handle calls to and from a Restful service and inject IP into the UI - help out with mapping of the middle stack - help with any system analysis Raza www.razatoosy.com --- ## Post #48 by @mayfield.g.kev Understand the learning curve. We use HAPI FHIR JPA Server to get around some of that, it's simple to install (no java knowledge) and our UI developers (javascript) are insulated from this java/open source layer. We do similar with our FHIR facades, UI developers would work with REST Api only (FHIR) and (os/java) servers work with other systems (sql, api (rest or soap), csv, etc). Idea is to keep the api simple and remove complexity away from UI. --- ## Post #49 by @wolandscat Well, openEHR already has a standard way of exposing resources - as native openEHR RM data. You can obtain them in a number of ways: * via a standard EHR service interface (e.g. [Java](https://openehr.atlassian.net/wiki/display/spec/Marand+Think%21EHR+service+interface); [C#](https://openehr.atlassian.net/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface)) * the above includes AQL Query results, which are essentially tables of openEHR RM objects * via [EhrScape.com](https://www.ehrscape.com/) (API Explorer > Electronic Health Record APIs > /view > choose an example and do 'Try it out') If you do the last of these, and choose SpO2, you'll see the following result. The URIs in this interface were generated via a standard algorithm from the archetype paths. ``` [ { "time": "2014-03-03T07:28:33.000+01:00", "spO2": 97.5 }, { "time": "2014-02-27T14:37:43.000+01:00", "spO2": 96.5 }, { "time": "2014-02-27T01:35:11.000+01:00", "spO2": 99.9 }, { "time": "2014-02-25T21:17:11.000+01:00", "spO2": 97.3 }, { "time": "2014-02-06T08:26:28.000+01:00", "spO2": 98.5 }, { "time": "2014-01-22T17:30:10.000+01:00", "spO2": 96.7 } ] ``` All I am saying with respect to FHIR is that now we, like everyone apparently, must map to a new set of message content. Each of these mappings will necessarily be manual (that's the same for everyone), and therefore create work that could have been avoided. In my view, the missed opportunity here is that we already have large libraries of openly published content models (and as I said, 20 times the size of FHIR's resources), as well as the benefit of all openEHR data obeying a single schema globally. There are actually two such libraries in the UK - [HSCIC](http://ckm.hscic.gov.uk/ckm/) and [clinicalmodels.org.uk](http://www.clinicalmodels.org.uk/ckm/), as well as [openEHR.org](http://www.openehr.org/ckm/); these already contain significant UK-developed content. Using these libraries as a basis for data access as per the EhrScape approach above means no translation into any foreign formats, or data conversion work. The openEHR AQL query language is also mature and widely used, enabling access to ad hoc collections of data. So it seems we are back to mapping to messages again. Of course we'll all do it and declare success somewhere along the line. But I do wonder when people will realise the [message mentality](https://wolandscat.net/2016/04/05/e-health-standards-beyond-messages/) has far outlived its usefulness, and that we should be working in a single-source, model-based paradigm. --- ## Post #50 by @mayfield.g.kev Yes we've applied messaging to wrong solutions. They don't read well so not easy to follow and understand (HL7v2/IHE PDQ queries), API replacements have had similar issues (e.g. IHE PDQv3/HL7v3/ITK Spine + SOAP) but mostly around the bloated xml needed for a simple lookups. REST is a far better solution. --- ## Post #51 by @wolandscat Well REST is a mechanism for obtaining content. It's technically better in various ways than SOAP or messages (who ever thought XML was a sensible idea for a high-performance network interface?! But let's not go there for now...) but the question remains: should we be imposing specific _manually built_ content i.e. payload, in the REST interface, when the source system already has its data completely and comprehensively modelled? This is still a message mentality where the wire protocol is imposing the content definition. My [proposal](https://wolandscat.net/2015/12/20/making-fhir-work-for-everybody/) to avoid this is to make FHIR open, rather than being a closed (and rather limited) content silo. It would mean we do all agree to the following from FHIR: * data types * identifiers * other infrastructure types * terminology referencing approach (no OIDs!) * profiling, assuming it works properly (it is a copy of some elements of the [archetype formalism](http://www.openehr.org/releases/AM/latest/docs/index)) This can be understand as an _open FHIR protocol platform_. Then, clinical content should be modelled in distinct partitions containing resources specific to the model base in use - it may be openEHR, VA FHIM, 13606, CDISC, CIMI, and so on. It's important to remember that FHIR is just one concrete technology in use in clinical systems. Don't forget - object-level APIs, message XSDs, JSON UI proto-forms, display HTML, interactive HTML, PDF and much more. The key thing is to have the model libraries upstream of all of that. I've been talking to Grahame recently about this; it seems that HL7 is interested although wary, as one might expect. --- ## Post #52 by @DavidStables If one accepts the principle that nothing should be stored that cannot be communicated and all concepts should be present in a taxonomy of some kind then the only question is how things will be communicated and what taxonomies will be used. Both Snomed-CT and FHIR have a momentum in the UK. Thus if one accepts that Snomed-CT IS the taxonomy and FHIR IS the transport mechanism for transactional data items in the UK , then openEHR-UK must adapt. I think that means making sure that the archetype attributes must be Snomed concepts with snomed relationships, and all archetypes and templates have a FHIR transforms built in at the authoring and review stage to validate the fact that they can be communicated. I accept that this means that all of the compromise comes from the openEHR community which of course is irksome but I see no alternative if it is going to survive in the UK. I aplaud attempts to build the bridges with for example open FHIR but suspect its not enough. I remember a similar debate in 2002. openEHR lost out to HL-V3 and Snomed. I urge a compromise this time to avoid a repeat of history --- ## Post #53 by @wolandscat Hi David, it's not only a question of 'how things get communicated', and in any case, there are many ways to communicate data. Apart from 'communication', there is visualisation, data entry, programming APIs, and so on - you know better than anyone. Most of these require design-time models or schemas to be realised at runtime. That's the simple argument for single-source modelling, where the semantics are separated out from each of the many and changing concrete implementation technologies, so that they can be machine mapped into those same technologies as _we routinely do today_ in openEHR, and as is _routinely done outside of e-health_ for decades (at least since RPC was invented). There is no question of 'not adapting' - of course EHR technologies like openEHR need to work with messaging and terminology. But while SNOMED CT may be 'the taxonomy' for the UK, it is not for the world, and openEHR therefore was designed from the outset to enable SNOMED CT _and all other terminologies_ and ontologies. This is what enables an openEHR archetype to be used in 150 countries rather than only IHTSDO member countries (most of which are not close to fully implementing SNOMED CT). If you look at the [DNACPR archetype in clinicalmodels.org.uk](http://clinicalmodels.org.uk/ckm/#showArchetype_1051.32.185_MINDMAP), you'll see SNOMED CT codes right there. If you look at other archetypes, you'll see LOINC codes, ICD codes, ICPC2 codes and many others. It just depends on what is available and what is in use. With respect to FHIR, as I stated earlier, it's easy to see how to map openEHR content to FHIR - it's the same as it is for anyone else: each mapping is a case by case situation, and creates its own work. As I have pointed out, openEHR currently has around 25-30 times the number of formally defined, reusable clinical models as FHIR, so manual mappings have to be found from all of those over time to FHIR resources. This is the same problem that anyone faces with mapping to a communications standard that imposes its own idea of content. It's completely doable, it's just totally inefficient. The method I have been discussing with some in HL7 is a far more scalable approach that solves the problem properly. With respect to HL7v3 in the UK, I would not say 'openEHR lost out...'. Common sense, UK GP vendors and the British taxpayer lost out. openEHR as such was not even in consideration to my knowledge. All some of us argued was for some basic modelling, software engineering and IT principles to be observed. Instead we were all told we were wrong, and that _the_ silver bullet had arrived. We all know how well that went. Today the talk is all of the new silver bullet. In sum, openEHR is just there to provide a useful semantic-models based EHR platform. It works with SNOMED CT and other terminologies, and works with FHIR, just like anything else does. However, I believe we should be interested in leveraging semantic models and terminologies to drive all aspects of clinical computing. That's where real scalability and sustainability can come from. --- ## Post #54 by @ian Hi David, Interesting :slight_smile: [quote="DavidStables, post:52, topic:356"] If one accepts the principle that nothing should be stored that cannot be communicated and all concepts should be present in a taxonomy of some kind then the only question is how things will be communicated and what taxonomies will be used. [/quote] Whilst that is, of course true as an aspiration, I don't see it as a reality for many years, particularly outside of the very constrained GP world. Requirements to build data models for use inside systems will continue to far outstrip that capacity / need for them to be communicated. Having said that, I agree that in principle when a data model is created we want to maximise shareability. [quote="DavidStables, post:52, topic:356"] Both Snomed-CT and FHIR have a momentum in the UK. Thus if one accepts that Snomed-CT IS the taxonomy and FHIR IS the transport mechanism for transactional data items in the UK , then openEHR-UK must adapt. [/quote] I agree that both FHIR and SNOMED-CT have momentum and that any models created by openEHR should take those into account and I would expect a number of archetypes and templates to have both SNOMED-CT bindings and to be easily transformed to/from FHIR profiles. However I don't agree that this should be routine, that all archetype attributes should be SNOMED-CT concepts + relationships or that all openEHR concepts should immediately be expressed as FHIR profiles. We have been down the road of trying to 'do' clinical models with terminology and relationships already - remember the Logical Record Architecture project? SNOMED-CT is a great asset when used within it's comfort zone but one of the things that has really delayed progress in this space IMO, has been an over-expectation of how much will be handled by terminology. One of the strengths of FHIR has actually been to push back on this kind of blind commitment to terminology, to a much more nuanced usage. [quote="DavidStables, post:52, topic:356"] I remember a similar debate in 2002. openEHR lost out to HL-V3 and Snomed. I urge a compromise this time to avoid a repeat of history [/quote] I am tempted to say that 'we know how well that worked out', and indeed 'avoid a repeat of history'. ;) Just to be clear, I am very happy to support and promote the uptake of both SNOMED-CT and FHIR in the UK. I just want to make sure that we do so with an understanding that.. Modelling clinical data, particularly in secondary situations, registries, feral systems etc is way more complex than in primary care. SNOMED-CT excels at representing bio-medical concepts and their relationships. It is however a much poorer fit for the documentation of care, which is as much about clinical context, methodology, circumstances, timing etc. Where SNOMED-CT concepts exist they can be helpfully bound to documentation of care concepts but there are very many gaps, and the binding activity itself is hugely resource-intensive, both in working out the correct bindings or in filling the gaps by asking TC for new terms. FHIR is a very welcome development which will predominate in the market for the next few years and where it makes sense for openEHR-UK ( as currently resourced) to align with FHIR resources and UK profiles, that will happen but I am not convinced that this automatically means that openEHR-UK should commit to creating FHIR profiles for every modelling artefact. If there is demand, I would expect these to emerge quickly. If, of course, that was part of a broader resourced and supported strategy in the UK, e.g for PRSB to use openEHR to underpin clinical modelling, and for that then to be used to understand the sensible/optimal use of SNOMED-CT and from which to derive appropriate FHIR profiles, then that sounds like a very sensible compromise position, which plays to the strengths of all 3 formalisms. Ian --- ## Post #55 by @DavidStables Both Valid arguments and well elaborated. Which comes first? 1. Communication and sharing of the data already being recorded, in a form that is as consistent as we can get it, via the use of a common message structure and common taxonomy mapped from legacy data. 2. The construction of new clinical structures for use in clinical systems The two are not of course exclusive but perhaps that is where I am coming from, attempting to converge both when I should accept the fact that the second will evolve independently of the first, which of course it always has. In a sense that makes life easier as I am focused on the first because I believe that there is a set of reasonable solutions to that problem and that gets us to the starting point for the next generation of IT systems, which are likely to be different from that which we can predict just now anyway. --- ## Post #56 by @wolandscat David, the only flaw in item 1 is that the 'common message structures' (FHIR resources and profiles) are all 'new' with respect to any real system such as EMIS or TPP or Cerner - they are imposed content that you can't escape, and that don't look much like the real system data except in a very generic way. So given that new models are being created, doesn't it make sense to adopt a strategy whereby: a) we use models that can be re-used across _entirely different technologies_, of which FHIR is just one? b) the models are created by clinical people (FHIR models are by their own admission, IT-developer oriented)? c) we don't impose any payload content in the REST layer, we just _use the models already developed_, appropriately serialised? d) we start with an already available, _extensive_ library of models? Point c) is just normal comms engineering. A protocol layer should never impose content. If it does, it just competes with the real content and causes extra work. What's the sense in that? --- ## Post #57 by @ian Hi David, I do not seem either option as having priority, or being in conflict. We do, of course, have a pressing need to get systems talking to each other, and certainly in and around GP systems we do have a pretty good idea of exposable legacy system content. Better still, in the UK, through the work of GP2GP, it is pretty mature and can take advantage of substantial terminology use. For the immediate future, I think we can easily have the best of both worlds. Using the GP Connect profiles as an example, I can see lots of good work but, particularly around medications, lots of gaps and difficulties. Many of these could be resolved by referring, either to the UK medication models developed with PRSB (and based on GP2GP) or indeed the international medication archetypes, which fold in most of the UK ideas. Looking at the other profiles, I think we are pretty close but need work e.g. clarifying the SNOMED bindings for causative agent, and making sure this is aligned to PRSB. So I think we can forge ahead and meet your aims, but at the same time couch this work and the much bigger tranche of work coming up in a way that helps us as clinicians and clinical informaticians directly define and elaborate our content requirements as they emerge, whether for use within systems or moving data between systems, where these require adaptations to existing content models or completely new content models. INTERopen and GP Connect are great initiatives but lets do them right. Bringing together a sensible blend of openEHR, FHIR and SNOMED-CT, I believe we can do that without compromising agility or speed of delivery and keeping in line with PRSB aims. --- ## Post #58 by @DavidStables Tom FHIR resource profiles match extremely well to GP (legacy) system content which is very simplistic and generic. Being relatively simple to implement as well helps. One issue will come in with Snomed-CT post coordination but that's easily tackled down the line as no one is doing it currently. Ian Alarmed by your comment on the FHIR medication profiles and gaps and difficulties. Have you checked both HSCIC and Endeavour profiles and what is the problem? --- ## Post #59 by @ian Hi David, I remain a bit confused by the GP Connect profiles, which seem like only a partial representation of GP meds, and have resources for administration and dispense that don't seem like a good fit for GP (certainly core). I guess I am struggling to understand the scope of this work. Some of the naming is also a bit confusing e.g. Review date under Dispensing, and including structured timing seems premature if, as we know all GP dosage is for now text only. I'm not meaning to critical, as I am aware that ' GP Connect' is at an early stage. I just want to make sure that it draws upon the considerable expertise that already exists out there in terms of understanding current GP system data around meds. I have just had a quick look at the Endeavour meds profiles ( have not done so for a while) and feel much more encouraged and on comfortable ground :) Authorisation, rather then Admin, dispensing. Extra fields for patient guidance, endorsements etc. I will have a more detailed look now and see how well these marry up with the PRSB meds archetypes and international meds archetypes. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL --- ## Post #60 by @DavidStables Ian Yes, you are right. I have checked and it seems there is a problem with some of the GP connect as it would appear they have started from scratch. I have now offered to go through a reconcile process with HSCIC between the HSCIC and the Endeavour profiles, as Endeavour profiles fully map to EMIS and System 1 and therefore GP2GP Interesting to see which way the suppliers go. GP suppliers are working with HSCIC and 30 suppliers are working with Interopen (including GP suppliers) so I suspect that more collaborative working will be essential --- ## Post #61 by @mayfield.g.kev Just looked at the Interopen 'Call to arms'. I think it needs to reference HL7 FHIR correctly as per the license https://www.hl7.org/fhir/license.html _When referencing the FHIR® standard in a web site, document, presentation, or otherwise, please in a place of prominence refer to it as the "HL7® FHIR® standard". In subsequent uses, please refer to it as the "FHIR® standard" or "FHIR®", using the ® symbol as often as is practical, at least once on each page of printed matter, generally in connection with the first or dominant usage._ --- **Canonical:** https://openhealthhub.org/t/common-interface-mechanism-project/356 **Original content:** https://openhealthhub.org/t/common-interface-mechanism-project/356