Time to light the FHIR

Community
21

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.

22

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.

23

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 (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 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).

5 Likes
24

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.

25

I’d say that interoperability is an inherent attribute of an open platform, rather than the end-goal.

1 Like
26

Agree 100% on this

27

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.

28

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.

1 Like
29

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 that helps to remember these relationships.

30

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…

1 Like
31

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.

2 Likes
32

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.

3 Likes
33

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.

34

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)

1 Like
35

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.)

1 Like
36

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.

37

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…:wink:

1 Like
38

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.

  1. 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

39

For fun, my list of reasons for failure of NPfIT from this blog post:

  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.
40

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.