# Time to light the FHIR **Category:** [Community](https://discourse.openehr.org/c/community/10) **Created:** 2020-03-09 20:47 UTC **Views:** 1645 **Replies:** 39 **URL:** https://discourse.openehr.org/t/time-to-light-the-fhir/438 --- ## Post #1 by @ewan Hi All, You may have seen [my piece on Digital Health Intelligence](https://www.digitalhealth.net/2020/03/time-to-light-the-fhir-and-get-to-grips-with-standards/) It's generated quite a few comments. Including one from Richard Kavanagh which describes openEHR as futile. I will respond in due course, but would be good if others from our community added their thoughts. Ewan --- ## Post #2 by @heather.leslie Great article. Congrats. Ed Hammond & I co-presented on clinical modelling at the Feb HL7 'Clinicians on FHIR' meeting in Sydney. One of his best one liners: "If you're solving today's problems, you're out of date!" is food for thought. --- ## Post #3 by @florianbriand The first thought I have on the subject is : "If you're opposing FHIR and OpenEHR, you're out of date!" ;) It's two different approach, which are complementary. Move an existing system to OpenEHR is not "easy", as the "magic universal healthcare model" doesn't exists in practice. So an existing system have to spend a lot of time modelizing how they will put their current model into the OpenEHR one. So for existing ones, FHIR is "lightweight" : you don't change your system, you just deploy a facade. And if you need 5 different representation of your model, you deploy 5 different profiles. And maybe 2 or 3 facades. But if you are able to "take back" your closed & private vendor's models to convert them to OpenEHR, let's do it. But anyway, you will have to maintain interoperability with other systems, all the ones with FHIR facades. (FHIR Interoperability VS OpenEHR Intraoperability) I don't know if this subject move a lot these last months, but I think OpenEHR community & companies should work on that : build good "true" FHIR facade for OpenEHR. (I mean by "true" taht we need a real full mapping, not just CDA encapsulation, with OpenEHR bundles injected as documents ...) --- ## Post #4 by @johnmeredith Generally agree @florianbriand but for one point; "true FHIR facade" depends not just on an openEHR representation but also the FHIR is ised effectivly by the interop community. I don't think it is, and I hear a lot of "FHIR-like". We could take the moral high ground and say, within the openEHr community we are going to do this "right". But unfortunatly I don't think that would neessarily make things easier when the light weight nature of FHIR is its major selling point. --- ## Post #5 by @johnmeredith Unfortuntly Richard's comment speaks of the tail wagging the dog. Not in the suppliers interests, ongoing threat to business model yadda yadda. There is a responsibility on institutions at a high level to state that this is not "nice to have" but a hard requirement for procurement and development. --- ## Post #6 by @ian.mcnicoll Hi Florian, Completely agree. There are some openly available openEHR-FHIR mappings and the community is building some more. https://github.com/AppertaFoundation/openehr-care-connect-adaptor Ian --- ## Post #7 by @yampeku [quote="florianbriand, post:3, topic:438"] FHIR Interoperability VS OpenEHR Intraoperability [/quote] I think that this quote (originally from @erik.sundvall?) has been quite misunderstood, to the point that I don't think it's useful anymore: openEHR 'intraoperability' contains the 'interoperability' part, which probably isn't obvious at first glance of the 'VS'. In other words, you can do interoperability with openEHR. --- ## Post #8 by @ian.mcnicoll We actually do not want interoperability!! I am starting to say that openEHR is all about trying to avoid the need for 'interoperability' at all. Interoperability is a sticking- plaster to a problem which need not be there in the first place, it is not an end-goal in itself. We cannot 'bake-in' interoperability, what we need is to gradually bake-out the need for interoperabillity. This will take time and face oppositon but no reason not to make a start --- ## Post #9 by @yampeku One thing is that we despise and want to get rid of the term and another saying that you cannot achieve that with openEHR, which I think it's the message being transmitted --- ## Post #10 by @johnmeredith So @yampeku is playing the short game, and @ian.mcnicoll is the long game ;-) --- ## Post #11 by @thomas.beale Just the latest in concrete, technical problems with FHIR: https://wolandscat.net/2020/03/09/fhir-fixes-the-choice-construct-part-i/ I have mail from senior experts in ontology, modelling, CDS, and .. FHIR .... agreeing with this, and the other stuff I have posted. I can't repost their private responses here unfortunately, but there is a growing consensus that FHIR won't work for CDS (at all), won't be scalable in terms of models, will cause all kinds of problems in software (due to things like choice), and may make interoperability worse, due to a proliferation of local / private models of common things like vital signs. FHIR doesn't even represent a systolic BP if collected on its own versus collected with diastolic, pat position etc, in the same way (the first is Observation.value, the second it Observation.component.xyz). There really are so many basic problems that are not being addressed in the headlong rush for going normative, that it's hard to see how it's going to work. It's a pity, because a modicum of change to process and methodology now could save it. --- ## Post #12 by @thomas.beale [quote="ian.mcnicoll, post:8, topic:438"] We cannot ‘bake-in’ interoperability, what we need is to gradually bake-out the need for interoperabillity. This will take time and face oppositon but no reason not to make a start [/quote] haha good quote, I'm stealing that one... --- ## Post #13 by @thomas.beale [quote="yampeku, post:9, topic:438, full:true"] One thing is that we despise and want to get rid of the term and another saying that you cannot achieve that with openEHR, which I think it’s the message being transmitted [/quote] sorry if I repeat myself, but I think we should stick to the mantra that '[interoperability is an emergent property](https://wolandscat.net/2019/09/06/why-using-hit-standards-fails-to-achieve-interoperability/) (i.e. output variable) of a coherently engineered open platform, not something you can impose with random pipes (i.e. input variables) connecting existing systems'. Ian's baked-in / baked-out metaphor captures this even more succinctly. --- ## Post #14 by @johnmeredith ha ha @thomas.beale ... @ian.mcnicoll does have some flour-ey language. Let's hope the analogy proves over time. --- ## Post #15 by @yampeku [quote="thomas.beale, post:13, topic:438"] sorry if I repeat myself, but I think we should stick to the mantra that ‘[interoperability is an emergent property](https://wolandscat.net/2019/09/06/why-using-hit-standards-fails-to-achieve-interoperability/) (i.e. output variable) of a coherently engineered open platform, not something you can impose with random pipes (i.e. input variables) connecting existing systems’. [/quote] Sure, but lets not throw stones over our own roof by dismissing how everyone else understands the term. I understand what you mean, but someone (i.e. decision makers) who come across this kind of quote would say: "I don't want intraoperability, I demand interoperability!" without going deeper into the implications of each word meaning. --- ## Post #16 by @GerardFreriks LS, OpenEHR/En13606 can be used both for: an interoperability solution between proprietary systems, and for a true interpretability solution. - OpenEHR is designed to define meta-information that can represent ALL possible health data used in a system. - Systems that conform to inside to a standard such as OpenEHR/EN13606 do not have a serious interoperability problem. - Systems that are proprietary inside can conform to any exchange standard such as: Edifact, HL7v2, HL7v3 (CDA) and FHIR or one Template based on OpenEHR/EN13606. And since there are many varieties of dialects in these message standards, interoperability is a serious message deployment problem. Gerard Freriks +31 620 34 70 88 ‭+31 182 22 59 46‬ gfrer@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #17 by @tonyshannon In case you missed it , though most of those on this thread are already aware.. we have come up with a simple yet pragmatic approach to addressing the challenge of working with both FHIR and openEHR in our open source Ripple stack, thanks to the work of @rtweed QewdJS and his JSON transformation work. I won't get into the merits of openEHR v FHIR etc etc as dont have the time for that discussion today/imho its not worth having as the reality for now is there is merit in being able to work with both.. Can highly recommend this brief but instructive 7 minute video from 2017 on how its done https://youtu.be/iaGGGgJdWvM Also to bring things up to date, ICYMI link to slides from Robs recent related presentation at Rewired last week. https://forum.digitalhealthrewired.com/t/the-ripple-stack-making-the-case-for-coherent-open-source-healthcare-technology-components-rob-tweed-and-tony-shannon/71 If someone finds a better way of working with openEHR & FHIR I'd like to see it.. All open sourced as the idea is to encourage collaboration in this space.. the barrier to entry being a knowledge of JSON.. ie about as low as it can be .. Hope this helps the discussion Tony --- ## Post #18 by @florianbriand Sorry - not sorry -, but as startuper, I don't care about "intra-operability". I don't care about the X% of systems having moved to OpenEHR. I only care about being able to plug my tool on most of the systems, by providing profiles you should follow. And I don't want to wait 1 year, 5 year, 15 year to have that. Because I don't have the money to wait. And patient are dying because we are not using data we could use to save them. So the ideal solution, with the ideal model, even with a government building an ideal model and making it mandatory ... I don't believe in it. I would, because it would be wonderful and save so many people. But I have to fight with the reality : some hospitals will not change their system before many years. So they will not build anything on OpenEHR. So they have to deal with FHIR. But indeed, as Thomas said, as Australian are doing : you can build profiles using CKM, because it's a wonderful tool. And FHIR have a lot to learn from OpenEHR, sometimes about the models, sometimes about the governance. But please, stop the fight, it's not the good way to save people life. --- ## Post #19 by @ian.mcnicoll I don't see anyone really disagreeing with your position Florian. Everyone I know who is developing openEHR-based systems recognises that FHIR is a reality , and if nothing else a far better means of exchanging data between systems than we have had before. Every one of the se companies has or is building FHIR adaptors around their systems but these are by definiton quite local and often quite limited in specific countries , atl least in terms of actual deployment. That's not a criticism, just a fact. It is hard to build good quality profiles - I know as I was closely involved in the UK work. Any more heated discussion with the FHIR community tends to come when some people claim that FHIR can and should do everything - clinical data modelling, CDRs. That is pushing FHIR outside its original comfort zone and into unproven territory with a fair amount of real-world experience which says that it has and is not likely to work well. It does sometimes get a bit frustrating when sensible conversations about the best use of each technology turn on 1) Well you should try to build CDRs since the legacy vendors will not like it and then in the same phrase but FHIR data models and processes are perfectly good for CDRs. --- ## Post #20 by @ReneSpronk Standards like FHIR, or the v3 RIM, or DICOM were never meant to be used as persistence models, but somehow some people have found it convenient to use them as the foundation for a CDR. That's fine, but use at your own risk, as (besides the pros) there are many cons to such an approach as well (as many on this forum will be well aware of). At least a discussion like this causes a flurry of messages to be exchanged on this board, whereas it is usually pretty quiet. We do have to take however not to rehash the same old party lines too much. Having long term goals is the name of the game, as a trainer I usually ask trainees 'how does one ensure that clinical data will still be interpretable 100 years from now' ? (after 10 database/system migrations). But that's a data life span that's seldom envisioned even by those who create standards. --- ## Post #21 by @ian.mcnicoll Just a note and apologies that some of you have had to wait to be 'approved' . We had setup this 'Communiity' category in that way so that it was not inappropriately flooded with inappropraite messages. Trying to keep up and approve posts as fast as possible. --- ## Post #22 by @Bert_Verhees I want interoperability. I believe in innovation and the power of the free market. I know this is very unbritish, they believe in a single competition-less healthcare market. But I don't, so I need interoperability and that should be brought to high levels, again by that same free market. That is why I think, FHIR is great, not perfect, just great. And it will get better. --- ## Post #23 by @erik.sundvall Sometimes it takes some basic rigid standardisation to create a **free market** in practice, instead of corporate or national lock-in effects. The question is just what to standardize and how far to standardize it, that is a tricky balance. The telecom market has both good and bad examples of standardisation. The [GSM standard](https://en.wikipedia.org/wiki/GSM) (followed by 3G. 4G etc) created a market for mobile phones and telecom networks with more international competition, innovation and consumer choice than before. One can argue that the phone-inventors and network operators got less "freedom" when choosing to abide by GSM standards, but consumers and network operators certainly got more choice and freedom. Also, new actors and innovators got a way to enter the market. Instead of competing regarding data- and transfer formats, the phone manufacturers compete on a higher level regarding things built using the standards. And telco-network equipment manufacturers ar subjected to free market forces and forced to innovate more instead of enjoying lock-in protection from market forces. A warning example from telco is when de-jure telco standardisation organisations tried to [standardize the computer network stack](https://en.wikipedia.org/wiki/OSI_model) but academia and the market chose to go by TCP/IP etc instead... Now, how to apply the above things to openEHR and HL7 FHIR is not obvious and will be interpreted differently by different people. I for example think healthcare providers are better served by a market where vendors competing on a higher "application" level (and also competing on underlying standardized CDR-platforms and tools) than competing on the basic reference models and detailed clinical models (like archetypes) used inside. Most end users likely care more about being able to reuse data (and having the power to collaboratively improve models), than they care about how technically innovative a proprietary reference model is. (Also many of the proprietary models are "legacy" rather than innovative). --- ## Post #24 by @johnmeredith I think that @Bert_Verheesis so far off base it isn't funny. If so unBritish, then explain the voting in of a majority government that is based on free market principles? Identity politics has no place in this argument. And you clearly have no idea of how the NHS works, nor its digital sector otherwise there would be little need for Ewan's post in the first place. Don't confuse the principals of "free at the point of need" healthcare with the range of technologies needed to deliver that ambition. That's just as stupid as comparing openEHR and FHIR. --- ## Post #25 by @heather.leslie [quote="thomas.beale, post:13, topic:438"] ‘[interoperability is an emergent property](https://wolandscat.net/2019/09/06/why-using-hit-standards-fails-to-achieve-interoperability/) (i.e. output variable) of a coherently engineered open platform [/quote] I'd say that interoperability is an inherent attribute of an open platform, rather than the end-goal. --- ## Post #26 by @yampeku Agree 100% on this --- ## Post #27 by @ian.mcnicoll [quote="heather.leslie, post:25, topic:438"] I’d say that interoperability is an inherent attribute of an open platform, rather than the end-goal. [/quote] and that is exactly what I meant by 'We do not want interoperability' - we need it right now and we need what right now it tries to deliver (rather badly) but it is the free-flow of information between applications that we need, not 'interoperability' per-se assuming, as many do, that interoperability implies exchange between systems with heterogenous information models. --- ## Post #28 by @heather.leslie Yep. I just blogged along those exact lines, using Ed Hammond's tower of interop analogy, FHIR as an interim step but also Ed declaring that HL7 needs a universal health language. It won't be openEHR but... at least he gets it. --- ## Post #29 by @thomas.beale [quote="florianbriand, post:18, topic:438"] So the ideal solution, with the ideal model, even with a government building an ideal model and making it mandatory … I don’t believe in it. I would, because it would be wonderful and save so many people. But I have to fight with the reality : some hospitals will not change their system before many years. So they will not build anything on OpenEHR. So they have to deal with FHIR. [/quote] Well the 2 key things to understand about openEHR are: * it doesn't rely on a 'perfect models', but instead on library(ies) of data point/group definitions (archetypes) like data elements for BP, diagnosis, obstetric history etc, which can be *recombined* into data sets (templates) which fit your use cases * no matter how you did that recombining, querying on the data will still work, because it's based on archetype paths. [Here's a diagram](https://www.openehr.org/media/uploads/2019/12/04/openehr_4pillars_v2.svg) that helps to remember these relationships. --- ## Post #30 by @thomas.beale [quote="erik.sundvall, post:23, topic:438"] academia and the market chose to go by TCP/IP etc instead… [/quote] Slight historical correction: academia in 1985 on (when I did networking in a CS course), for some years, had the ISO OSI stack as *the* future of networking e.g. in textbooks like Andrew Tanenbaum's (used by much of the western world I suspect), and TCP/IP was hardly mentioned. I don't know what year this got changed in these kind of books, but the market was already using something that worked 'pretty well', but was not well specified. The specifications we have today were mostly done post hoc... --- ## Post #31 by @thomas.beale [quote="johnmeredith, post:24, topic:438"] If so unBritish, then explain the voting in of a majority government that is based on free market principles? [/quote] Well, he was talking about the NHS, on the (common) misunderstanding that because it is an monolith at the policy and funding level, it does purchasing that way. As it happens, purchasing occurs at the level of trusts, CCGs (regional areas) and other entities - the market is very much alive, and standardisation and 'platformisation' is (objectively) very weak. The best quality structured data in the UK is still the large GP systems like EMIS and TPP, and they were not made so in response to any NHS programme, but as part of a historical path of innovation among GP health informatics enthusiasts and experts over the decades. --- ## Post #32 by @ian.mcnicoll And on that helpful (and I think very accurate) clarification, I think we should step away, in this topic, from politico-socio-economic discussions of the relative merits of approaches to healthcare funding/ mgt as a whole. --- ## Post #33 by @ian.mcnicoll And I have now blocked a response - I'm sorry to do this but there are many other places to have this discussion. I will block others on the same basis. --- ## Post #34 by @Bert_Verhees Erik, telephone standards are technical standards of a very low level which allow a broad range of variations and technical solutions on top of it. The stand at the bottom of the OSI model of communication and data exchange, they don't even define the data to be exchanged.. They can not be compared with the semantic rich standards which are in healthcare data exchange. Because these standards are the end of the stacked protocols which allow data-exchange. They stand on top of the OSI model. I don't know if it is true, but it could be that the 7 in HL7 refers to the 7th layer of the OSI-model (which is the top-level or also called application-level) --- ## Post #35 by @erik.sundvall Yes I know and agree that GSM is a technical standard and not strictly comparable, to EHR-related or semantic standards. My main point was something completely different though: that the "freedom" reduced (e.g. for vendors/innovators) by standardisation of something opens up other freedoms for other actors (e.g. customers). I exemplified that principle within an EHR context. (And yes HL7 referred to the 7:th layer.) --- ## Post #36 by @Bert_Verhees Standards reduce freedom, I agree, and some base of standards would be beneficial. We all like the ISO standards because it are standards. It guaranties compatibility and interoperability. The discussion is on which level there should be standardization, and there should be room for alternatives, but that is my opinion, what I think is best. And why do I think that? Because I don't want to be pushed aside by some large market dominating players which mostly deliver less quality and are expensive. What good is it that OpenEhr has insight to all data, when there is no other system allowed to convert the data to. This is when the NHS would decide to purchase software centralized like it purchases drugs also centralized. --- ## Post #37 by @johngrant4est NPfIT/Connecting for Health was a failure in the UK, not because it sought to stifle competition, but because it was over ambitious in trying to bring vendors together around a common set of standards, most of which didn't exist at the time. You might argue that now is the right time to try again, not with "Clusters" but with a mature reference model and components built around it that vendors have to use, or risk being excluded from the market. Now that's real competition. Don't get me started on Gordon Brown and Tony Bliar...;) --- ## Post #38 by @ewan Hi Grant, I’m afraid I can’t agree with your analysis of why the NPfIT failed in England. I was in the heart of it and it failed for two overarching reasons. 1. A brief from on high that there were two groups who had stifled progress: Firstly, the existing vendors who were a bunch of under capitalised cowboys, but most of all the bloody doctors who had objected to everything since and including the foundation of the NHS. Success required that both were ignored. Richard Granger took the simple approach with the vendors not chosen to be part of the programme by famously telling them to "fuck off". He had the wisdom to know you could not talk to the doctors like that and set up extensive sacrificial structure to protect his core team from the “bloody doctors”. This allowed him to claim, correctly, that he had consulted with over 1,000 doctors. He failed to add “and ignored everything they told me” There were lots of good and able people working in the NPfIT and they eventually realised that they needed the knowledge and experience of these two groups and many of us were recruited to the programme, but the die was cast, it was too late. 2. The outsourcing structure was bizarre and went against the advice of the big system integrators (who did actually know how to do outsourcing). The brief from on high, driven by Political concerns, was that proposals that involved TUPEing NHS staff would not be considered. This meant that, unlike in a normal outsourcing , where the entirety of the problem (including staff and existing vendors) are passed to the SI to sort out, we ended up with; LSP contracts that only included the delivery of new systems (creating a perverse incentive to rip-and-replace) and the ghastly two headed structure of LSPs + LPfITs who spent their time marking each other's homework and meant that vendors (that knew how to implement systems) were disconnected from end-users (who knew what they needed and understood the reality of the front line). NPfITs attempts at "Ruthless Standardisation'', which actually meant standardising on the proprietary systems they had chosen, was neither here nor there. Fundamentally the NPfIT failed because HMG failed to listen to the advice of those who knew what they were talking about. Sound Familiar? Ewan --- ## Post #39 by @thomas.beale For fun, my list of reasons for failure of NPfIT from [this blog post](https://wolandscat.net/2018/10/28/why-npfit-failed/): 1. The **basic requirements were not understood** by those running the programme, even though many are actually fairly obvious. The NHS’s favourite published scenario to solve was a Scottish person on holiday in Cornwall getting sick. However the vast majority of all health system interactions are local. A locally devolved but standardised and federated system architecture was required. Instead a nonsensical centralised system (the ‘Spine’) was devised. 2. The **basic science of interoperability of health** information had not been worked out. You have to science before you can do engineering. A 5y industrially oriented research programme should have been funded instead for say £250m 3. The **wrong IT standards** were chosen, primarily HL7v3 and CDA. I provided a 25 page report in 2005 as to why they wouldn’t work. And they didn’t. This choice killed the possibility of the main problem being solved by any vendor, even had the requirements been properly analysed. 4. **Not one incumbent hospital system supplier** **had a product** even remotely **capable of communicating information outside the hospital boundary** (other than routine lab data). None had any kind of shared health record concept. And yet they were awarded massive contracts to provide a cross-enterprise health record system. 5. **Not one system integrator company had a single previous installation to which they could point as evidence of experience.** And yet they got paid massive amounts of public money to blunder about in the dark. I heard accounts of meetings where it was clear that noone had any idea of how to proceed. 6. **Clinical experts were barely consulted** . Without deep knowledge of the information and processes of the domain, building a large IT solution is guaranteed to fail. 7. **Critical errors were made in commercial arrangements** , resulting in huge payments to corporations such as BT and CSC, with no adequate requirements definition provided by the NHS, and no proof of prior success by the suppliers. --- ## Post #40 by @GerardFreriks When I remember correctly: - NpFiT was conceived in one afternoon in Tony Blairs Office - discussing HealthIT developments with a senior consultant from Cisco: Kevin Dean. --- **Canonical:** https://discourse.openehr.org/t/time-to-light-the-fhir/438 **Original content:** https://discourse.openehr.org/t/time-to-light-the-fhir/438