Stream: openehr
Topic: how to create EHR from FHIR resources?
Koray Atalag (Mar 25 2016 at 11:35):
Leaving aside the hype I have a fundamental question: so if there are people thinking they can do it all with FHIR what is their basic assumption to create a lifelong, longitudinal and persistent EHR? In particular I'm interested to know if there's an architectural or conceptual framework to pull resources together to represent as such. One distinguishing feature of openEHR is that it defines an EHR architecture (and has conformance statement to ISO 13808 - EHR Architecture Requirement). Did anyone try to look at FHIR's conformance?
René Spronk (Mar 25 2016 at 11:55):
Undoubtedly there will be some attempts to use a "FHIR Repository" as the basis for an EHR. I'm not aware of such projects as of yet, but they're bound to occur. (We've seen the same when it comes to using the v3 RIM as a persistence model, and even an EHR based on a HL7v2 data model). In general I think people don't see FHIR as the basic building block for an EHR, but for what it is, which is interoperability. Yes there will be FHIR Resourse Repositories that will support workflows and analytics. Could one support an entire EHR with that? I don't think so (and I'd certainly not recommend it) but we won't know until somebody tries.
Thomas Beale (Mar 25 2016 at 13:27):
That would seem a very odd thing to do? Why would anyone try to use FHIR to build an EHR system? It means they don't know what an EHR system is (and maybe they don't know what FHIR is either!)
Erik Sundvall (Mar 25 2016 at 14:14):
@Thomas Beale I think @René Spronk is probably right about that someone will try building EHRs based on FHIR - and that it is probably not the best idea. Let them try and discover the pros and cons compared to other options (like the option to use an openly available EHR architecture you know very well).
Wasn't Oracle once involved in doing an EHR or EHR repository platform based on HL7 V3-stuff? I think they kind of sold the idea/product to a Swedish region, and it was not the cheapest Swedish not so successful project... If nobody could stop Oracle from trying that, then others will try similar things.
Thomas Beale (Mar 25 2016 at 14:24):
It seems like a bizarre thing to do - normally one needs an EHR information architecture to build an EHR system. I can see how a FHIR data cache for an integration engine environment could make sense. But FHIR for EHR? Hm, some people need to go and learn some basic health informatics...
Erik Sundvall (Mar 25 2016 at 14:36):
And the same (reading up on health informatics) goes for national archetyping efforts that don't see the point of using or contributing to international archetyping work. But with your experience neither that nor a FHIR-EHR attempt should be surprising - and crazy usage attempts do not necessarily mean that the openEHR or FHIR aproches are bad themselves.
I'd suggest we get back to the FHIR-scope/hype-thread to see if we can learn from each other's thoughts and perspectives and possibly also agree on some pedagogical teaching material that can point out different purposes and contexts of FHIR and openEHR. You asked a question of FHIR scope, and I am interested in that too.
Thomas Beale (Mar 25 2016 at 14:41):
Well the reason for the scope question is serious: if we can understand what FHIR thinks its architectural purpose is, we can potentially start to work together on describing an overall architectural vision in which model-based EHR systems and FHIR-based interfaces work together.
At the moment, my belief is that the resource partitioning approach (as per my 'Making FHIR work for everyone' blog post) is the best approach from an engineering point of view. Anything else looks like difficult and endless mapping. This is a primary question for FHIR and CIMI within HL7 by the way; it just happens that I would try to solve openEHR+FHIR using the same approach.
I'd really like to see a statement of the architectural vision and scope.
René Spronk (Mar 25 2016 at 14:42):
@Erik Sundvall I'm sure we look forward to seeing your initial draft ;-) (to suggest is to volunteer...)
Thomas Beale (Mar 25 2016 at 14:43):
@René Spronk we are talking about FHIR scope & architectural vision (at least I am!) - that's for FHIR people to describe...
René Spronk (Mar 25 2016 at 14:48):
AFAIK its scope and vision is documented in the FHIR spec. But I was reacting to Eriks suggestion to create some education material to compare and contrast.
Thomas Beale (Mar 25 2016 at 14:50):
@René Spronk I think we could certainly contribute to that. But I'd like to be sure of what the FHIR architectural vision and scope statement is. I thought I understood it, but I am hearing people talking about FHIR persistence, EHR systems (?!), and Grahame seems to be implying a wider scope than REST interfaces to EMR... that's why I'd like pointers to the definitive vision / scope statements, just so we are all clear.
Lloyd McKenzie (Mar 25 2016 at 15:37):
FHIR persistence is not an official part of the FHIR scope. It's an unapproved use, though may be appropriate in some cases. (The relatively small number of resources and the built-in extensibility as well as the constrained search expectations may make it attractive for this use in some situations.) FHIR is also being used/proposed for use as an internal data representation for some systems and as a way of expressing decision support rules and quality criteria. We won't actively discourage such uses - people can use FHIR wherever they find it useful. But we likely won't make design accommodations to enhance such use either.
Erik Sundvall (Mar 25 2016 at 16:24):
Ok @René Spronk I can start a draft of a short educational material after the easter holidays. By what date would you and @Ewout Kramer need a first draft in order to do some review rounds (helped by all in this forum) and use it as part of your Vitalis presenetation? Any thoughts about length? 5 PPT slides?
René Spronk (Mar 25 2016 at 17:28):
Whilst I'm interested in having such a slide deck there is no way to guarantee that those slides, or parts thereof, will be a fit with the topics we're asked to cover at Vitalis. Such slides would for example be appropriate as part of our http://ringholm.com/training/standards_overview_1d_en.htm training course. Our http://ringholm.com/training/13606_openehr_HL7_CDA_en.htm training course covers this issue in much more depth, but we haven't delivered that training course for the last couple of years for lack of interest (at least amongst our regular target audience, which is IT-minded and 'interoperability oriented'). At Vitalis I'll mainly be covering the relationships between IHE XDS, CDA and FHIR - so it won't be appropriate for me to discuss clinical requirements models nor intraoperability.
René Spronk (Mar 25 2016 at 17:31):
@Ewout Kramer wil do an introductory pitch of FHIR at Vitalis - it's obviously up to him to decide as to what the content of his presentation will be.
Koray Atalag (Mar 25 2016 at 22:54):
OK I'll give a concrete example from NZ: recently the govt made an official statement that openEHR will not be used in NZ EHR - that IS our national EHR project! They have also released strong endorsements, even mandating, the use of SNOMED and FHIR prior to that. So how will other goverments and other project leaders will read this? It is dead clear. So I think there is something we can do to provide a balanced and fair view of the situation: I suggest as FHIR and openEHR Management Boards go on to draft a whitepaper answering the fundamental question: FHIR or openEHR vs. FHIR and openEHR. As a Board member of HL7 NZ and at the same time being in openEHR Management Board my stance has always been to promote the idea of openEHR AND HL7 (and of course others like IHE, DICOM, SNOMED and other pertinent terminology etc.). Obviously each of existing standards each have their merit and an important role in improving health IT (not limited to interoperability but also things like safety, data quality etc.). If we fail to agree on a collaborative and constructive approach and act on it I don't think we will gain much in undermining the other - certainly governments and vendors (and people) will lose valuable resources and time.
Andy Bond (Mar 26 2016 at 01:34):
The problem for investors is that there is no clear proposition what FHIR and OpenEHR working together means. There are various combinations of contribution each can make to a national solution space but it is not obvious what the optimal use may be. And there are significant overlaps and in both cases unique contributions (where that uniqueness may very well change as each charts its growth and maturity). In the various abstractions (whether implicit or explicit), their roles in requirement specification, design, and platform delivery is complex. Optimising one perspective or use over another sounds great in isolation but, for instance, ignoring existing investments in large clinical systems is problematic. While the clinical content model is important, so is the context and behaviour of the system. As has been noted, FHIR is a very broad tool that can support content at rest and in transit but it also is becoming more strongly aligned to the behaviour of systems with a maturing of FHIR services, operations, and workflows. This is far richer than models of the past. Everyone appreciates that model mapping is painful but it is worse when the mapping occurs further away from the owner of the requirement, hence the dilemma. The case for co-existence and mutually beneficial contribution is not clear cut and becomes more complex when you take into account the rapid evolution of something like FHIR.
Grahame Grieve (Mar 26 2016 at 05:06):
Right, my initial response is that it sounds like a good idea, but I'm doubtful we could come up with a single statement that enough people could agree too. And both projects are in motion...
Koray Atalag (Mar 26 2016 at 05:39):
Thanks Grahame, it certainly would be a good first step - it'd be great if both communities at management levels discuss this challenge and act responsibly to avoid any further damage. I'm not entirely sure if and how it would be possible to restore sanity in NZ but I will certainly look at publishing some concrete ideas/findings in constructive ways and work closely with health informatics community.
Richard Kavanagh (Mar 26 2016 at 12:06):
(deleted)
Richard Kavanagh (Mar 26 2016 at 12:07):
Good reply @Andy Bond that certainly correlates to the feedback I am getting.
Erik Sundvall (Mar 27 2016 at 08:37):
@Koray Atalag getting enough of the upper management to agree in both organisations might take some time - us techies could start discussing technical consequenses of different options even if we sometimes disagree on the commercial/political likelyhood of different scenatios. I find the technical discussions here very enlightning in order to understand each other's perspectives and clear some misunderstandings.
Erik Sundvall (Mar 27 2016 at 08:38):
COPY FROM THE "clinFHIR"-STREAM IN ORDER TO CONTINUE DISCUSSION IN THIS "openehr"-STREAM:
This is a great discussion and it really helps in understanding each other's perspectives. I think we'll be able to agre on what to agree and disagree on at least from a technical perspective.
Interesting to see how FHIR openly dictates a larger part of the clinical semantics than the openEHR RM (or previous HL7 initiatives) have done. (Are national FHIR-endorsing programmes aware of this?)
OpenEHR could probably also use a set of (more or less) dictating core parts of some important core archetypes (perhaps expressing the mandatory parts as templates) that you need to abide to in order to certify your system (or national program) as an "internationally compliant" implementation. Those cores of core archetypes could probably in most cases have internationally maintained and shared FHIR-mappings too. Mappings do not need to be 1:1 in source models but should be algorithmically transformable (Is that what CIMI calls iso-semantic?). Any thoughts on that? Would that encourage increased openEHR+FHIR collaboration on clinical modelling?
Erik Sundvall (Mar 27 2016 at 09:37):
@Koray Atalag wrote 11:06 AM in the clinFHIR streram:
"I agree I've learned a lot from these discussions than any other reading or training. I really appreciate your determinedness to get base model shared and mandated. I think we as openEHR community should also agree on some core clinical semantics you're right that RM is all too abstract."
Erik Sundvall (Mar 27 2016 at 09:42):
@Koray Atalag The openEHR RM is _not_ too abstract to e.g. build good EHR systems and tools from (13606 and CIMI RMs are even more abstract), the abstraction level of the openEHR RM is a pretty good fit for building EHR systems with GUIs, queries, clinical decision support etc.
But believing that the RM alone without a core set of (more or less mandatory internationally agreed) archtyped semantics is enough to achieve decent inter- or intraoperability is too naive. This is no news to openEHR techies - but maybe too poorly communicated to national programmes and others that thought that just adopting openEHR tools/tech will solve "everything" the same way others believe that adopting FHIR will solve "everything".
Koray Atalag (Mar 27 2016 at 09:54):
Yeah the context was interoperability...I would even go on to say openEHR is not primarily an interoperability standart but an EHR one so it's main premise is the ease with which EHR systems can be built and more importantly maintained. Interoperability comes as bonus as parties reuse clinical models. Important part of complexity is delegated from UI, DB schema and program code to clinical models. That's the key difference between these two formalisms. It is not really intraoperability but having a sound EHR architecture, expressivity, and being able to drive UI, query, persistence and decision support off the same model of information.
Erik Sundvall (Mar 27 2016 at 12:45):
@René Spronk I was not talking about creating any huge slide deck, rather a maximum of 5 slides, where at least one will be on intraoperability vs. interoperability a topic that you shoud cover anyway if talking in a Swedish setting. The FHIR sessions at Vitalis are approx 2 hours in the morning and 3+ hours in the afternoon, that is a _very_ long time in these contexts. I can help you if you need, I'll be in the audience.
Erik Sundvall (Mar 27 2016 at 13:12):
René, regarding "lack of interest" in your openEHR-related training courses I believe that is depending on your context/enviromment since we in november had 130+ participants in a Swedish openEHR/archetype-themed full day training session with some of the participants also staying for a second day of hands om tutorials. The 130 included participants from the 3R project and other healthcare regions,there were also participants from national authorities and many members of HL7 Sweden. I think several people in your VItalis audience will have been there.
Erik Sundvall (Mar 27 2016 at 13:22):
Also the biggest EHR system in Sweden (or second biggest depending on what parameter you measure) is already using openEHR in their CDS solution and introducing it in other parts in the new version now being rolled out. @Ewout Kramer and @René Spronk I think it would be wiser of you to cover the relation between openEHR and FHIR briefly but properly using some slides during your presentations than leaving it to Q&A sessions in the end.
You will look poorly prepared if you just refer to openEHR as a possible method for clinical requirements gathering, rather than something that is acually is starting to get used for cooperating on definitions of EHR forms etc in Sweden and Norway. There will be increasing archetyping work going on in Sweden by organisations interested in cross-organisational intraoperability even if national bodies would happen settle for just interoperability (e.g. using FHIR) We have regions visiting the Norwegian archetyping effort and planning to start collaboration.
At Vitalis you will have at least the two competing vendors, DIPS and Cambio, that both continuously increase openEHR usage inside their previously legacy systems - so at Vitalis it would be unwise to say something along the lines of that openEHR is just an academic or theoretical approach for requirements gathering. Even Cerner Nordics have archetyping and opeEHR competence after buying Siemens' EHR business, if they'll use it or not is another question.
Lloyd McKenzie (Mar 27 2016 at 13:58):
@Erik Sundvall You asked
Are national FHIR-endorsing programmes aware of this?
It's pretty hard to not notice :) That said, it's always possible someone's just listened to the hype and not actually looked at the spec.
Lloyd McKenzie (Mar 27 2016 at 14:16):
So there's sort of three different approaches to FHIR/OpenEHR collaboration:
1. What we've done thus far, which is to harmonize existing OpenEHR archetypes with FHIR resources. Thus far we've done one - AllergyIntolerance. It was a lot of work, but it was beneficial for both, I think. But we have challenges in terms of how to maintain the alignment - we update the resources in response to change requests regularly. As well some of our resources exist at a different (typically larger) granularity than OpenEHR. This can make alignment challenging. Plus, we both need to put in the resources to start doing more of this.
2. To look at using FHIR as a technology for transporting arbitrary OpenEHR instances as @Thomas Beale had proposed. We're actively exploring how to make this work. However, due to interoperability issues, we need to figure out a way of partitioning this from the "pure" FHIR spec - and also need to sell the value proposition within HL7
3. Look at defining a set of OpenEHR archetypes that are fully aligned with FHIR resources. (This could start with #1, but would go further and is going to be a significant stretch for OpenEHR folks. It also creates challenges for the OpenEHR community in terms of migration.)
There may be other opportunities too.
Lloyd McKenzie (Mar 27 2016 at 14:59):
@thomas beale
The notion that you address interoperability across borders only when/if national programs decide it's a problem is a very different perspective. If two different jurisdictions have already implemented and later decide they'd like to have data be shared, that implies a lot of rework for either or both. As well, regardless of whether the national programs are interested in sharing, the *implementer community* has a significant interest in being able to use the same structures across different environments. One of the reason implementers are so keen on FHIR is that there's only one schema throughout the world.
It is absolutely within the mandate of SDOs to define how things should be done. Standardization does mean, at its core, doing things the same way. Standards remove optionality where there's consensus to remove that optionality. Implementers (and jurisdictions) are free to decide whether they're going to comply with the standard or not.
So in FHIR, we clearly say that MedicationOrders must all look a specific way. If you're sending information about a request/order/proposal for a medication to be administered and the data doesn't comply with the MedicationOrder resource, you're not conformant with FHIR. And that's a core piece of how FHIR works. That's why introducing an alternative way of expressing the same information using the OpenEHR model is concerning.
That doesn't mean that FHIR dictates everything. The resources still allow variation around the edges - through extensions and constraining what data elements must be present, what terminology is used, etc. And it's still possible to define collections of resources to be shared (or collected) in a particular context, such as a pregnancy record.
You certainly can connect single-source modelling with multiple downstream deployments with FHIR as it stands now. FHIR expects a great deal of profiling to occur and 20-50k is probably conservative in terms of the number of profiles that will eventually be created. The difference is that while openEHR envisions ~4000 archetypes, we envision around 150 resources - some of which are likely outside the scope of what openEHR covers.
The fundamental challenge is that FHIR *is* re-inventing the wheel. Our implementer-centric approach means we can't simply take existing OpenEHR archetypes and use them "as is". Some elements that are part of the openEHR archetypes would be relegated to extensions in FHIR space because they're not commonly supported by existing implementations. And some aspects of the modeling are more heavily influenced by implementation than clinical desire. That doesn't mean that FHIR can't or shouldn't benefit from the clinical expertise present in openEHR. I think both models benefited from what we did with AllergyIntolerance. Though we do have a governance challenge in that the final arbiter of FHIR resource content isn't (and can't be) the harmonization process - it's the ballot. And right now, we're in a continuous improvement phase.
(And I don't think you're being difficult - the notion of harmonizing these models that have come from very different places with different approaches simply *is* difficult. It's good that the conversation is taking place.)
Thomas Beale (Mar 27 2016 at 19:21):
@Lloyd McKenzie I don't think #3 above will happen as a clinical modelling exercise by clinical people, because their design approach is a more theoretical / ideal one, aimed at producing a formal definition of possible data points of some topic X (Medication order or whatever) in a preferred structure, and with preferred terminology bindings. My observations of FHIR modelling is that it is driven by 2 things: a) trying to get high coverage of data of that type as it exists in existing systems and b) very concrete implementation needs. So we are talking two different types of professionals doing modelling in two different ways. In general they won't arrive at the same models, although the real differences might not always be that great - have a look at openEHR:Problem and FHIR:Condition for an interesting comparison. All of these comments apply to CIMI.
However, it might be the case that openEHR-based modellers want the equivalent of a FHIR resource (one of the 150) in the archetype space; they could achieve this easily enough by essentially replicating the model structure and terminology bindings. So I think we can take as given that where this kind of 'model-mirroring' is needed, it will be done.
The problem area is the other 3,500 models of clinical content (or just today, something like 350 archetypes with no FHIR equivalent). There's no obvious way to serve these on a FHIR infrastructure - it would require a huge amount of manual mapping to ~arbitrarily chosen generic resources, but for no real gain that I can see - the data structures required by the customers are already as stated by the archetypes and derivative templates. Mapping to those FHIR resources just introduces a needless transformation that noone wants and a lot of work and cost.
Thus, the problem here is really one of semantic scalability. There are many customers who want clinical content as expressed by archetypes (or CEMs, or workflow content models coming in the future) and who want the convenience of using the FHIR REST API model, terminology binding and infrastructure resources (data types, identifiers, demographic entities)... right now there's no path to that. And the same argument applies if you go right outside openEHR, CIMI and think about CDISC BRIDG users and many other communities with their own models. It's just not the case that everyone will want to use the FHIR model X for their X-like data. I think this is a general challenge in e-health, one we need to think about collectively.
I may be beating my head against a wall, but there's an obvious engineering approach to achieving 4,000 models of clinical content (Stan Huff would say 40,000 finer grained ones of the style used at IHC) over FHIR, and it isn't manual mapping. I am very sure that as time goes on, some FHIR users are going to hitting a wall as well, as they try to crunch data into resources that don't reflect a) the data at source or b) the intended structures. That's not a criticism of FHIR resources - just a reality that there is a lot of diversity in the real world. So I think that opening up the FHIR standard to other resource 'partitions' would greatly help even the 'native' FHIR community over time. There would need to be agreements on how to do this to achieve best outcomes in health, but I think that we in the health informatics layer can only provide good formalisms, tools and guidance, we can't force everyone into one-size-fits-all health data models. If they want to go there, great, but I predict that such a migration will be a multi-year project, reflecting the slow, careful adjustments made in real world systems, while trying to preserve (primarily) patient safety.
Lloyd McKenzie (Mar 27 2016 at 19:38):
@Thomas Beale I think you're right about #3. It would be a significant shift which is unlikely given the nature of the community.
When you say there's 350 archetypes with no FHIR equivalent, that's somewhat surprising. FHIR intends to meet all of the use-cases (for exchange at least) that openEHR covers, so I'm curious as to some examples.
Mapping to FHIR is needless effort only if there's no expectation for the data to ever be consumed by non-openEHR systems. If you don't map, the data is only consumable by those who know your particular model. FHIR is not a generic transport for arbitrary models. It's both a transport and a set of models. If you don't use the models, you eliminate a good chunk of the interoperability. Thus the need to partition.
There's no question that there's a lot of diversity in the real world. However, interoperability only comes when diversity is minimized at the interface level. For some systems, converting to and from FHIR is easy. For others it's painful. We try to minimize the pain for the majority of systems. Those who find it painful have to evaluate whether it's worth the cost. But we don't adjust the standard to the point that anyone can do whatever they wish - if that were the case, we wouldn't have a standard at all.
Please don't hear that HL7 is saying "no" to being able to transmit openEHR models over FHIR transport. But if those models aren't the FHIR models, we can't call the result "FHIR" because they won't interoperate with other FHIR systems. Our struggle right now is how to appropriately draw the boundaries.
Thomas Beale (Mar 27 2016 at 20:00):
@Lloyd McKenzie #3 isn't a value judgement BTW, it's just how it works in our community - clinical models get done by MDs, RNs and so on. IT people only get involved at the template level. But let's leave that for now.
Have a look in CKM (http://www.openehr.org/ckm/), navigate in the left-hand explorer to 'Cluster' and have a look at the archetypes there. Double click to view. Easiest view to get a picture initially in the main panel will be the mindmap, which is the little hollow black ellipse button. Now you'll see mindmaps of archetypes, Details can be seen by hovering over the small yellow document icon on each node. You'll often see a node with a 'world' as its left hand icon - hovering over the document icon will get you a list of archetypes that plug in there. I think the number of archetypes just there is 158. The total under all categories is 495 (with another 100 deprecated/rejected).
A lot of this is detailed clinical content. I have to admit, I can't see what FHIR modelling looks like for this content. Or even Blood pressure, for that matter (friendly challenge ;-). Why not provide a way to just use it? Note that I'm not saying that openEHR models are somehow magically perfect, they are just what they are. But they are clinician-built, and they are upstream.
A more important point: this is just the international CKM. The various national CKMs have some additions of national interest, and some divergences from central archetypes, but mostly they just reference the international ones. But by and large the superset is probably only in the 700 range. A significant number of archetypes get built in local implementation contexts. We think these tend to be about 10-15% totally new, and the rest as proper specialisations of the central archetypes. All of this probably corresponds to about 30% max coverage of medicine that is intended in the long run. Add in the IHC/CIMI lab archetypes and we start getting up into that 4,000 - 5,000 range.
I understand the branding problem. But I don't think making the brand more powerful will hurt it ;-)
Erik Sundvall (Mar 27 2016 at 21:32):
Tom, I think the idea of using FHIR as transport for other formalisms has been described enough. Now try to understand the FHIR concerns. Example: should a medication CDS implementer use the FHIR-resource based medication order model or the FHIR-wrapped/transported openEHR one if they are treated as equals inside FHIR and both branded as FHIR models. There is a valid concern regarding likely confusion that needs to be handled... Re-read the discussion from that perspective too.
Erik Sundvall (Mar 27 2016 at 21:39):
The semantic scalability issue on the other hand is one of the main concerns that I don't see FHIR addressing. That is better delegated to intraoperability-approaches like a) openEHR or alternatively b) one of the other "force all involved parties to use the same big vendor's EHR system"-method.
Thomas Beale (Mar 27 2016 at 21:39):
@Erik Sundvall well they'll use whichever one suits their needs best. If they're an organisation that is using clinical models they would probably want that model; if they are not they will presumably want the native FHIR model. It's just whichever model limits needless transformation (a source of patient safety risk) and best corresponds to what they are trying to do.
Lloyd McKenzie (Mar 27 2016 at 22:37):
@Thomas Beale Blood pressure (and all vital signs, all lab tests and a bunch of other things) are all handled using Observation. You can see a blood pressure example here: http://www.hl7.org/fhir/observation-example-bloodpressure.html
FHIR does have a slight value judgement around who models. We want clinicians to be involved, but never want to have models that aren't thoroughly vetted (and tested) by the implementer community. In the end, something that's theoretically ideal from a clinical perspective but that implementers can't/won't implement or don't feel they can sell isn't useful. Interoperability occurs when real systems share data, so just a clinical perspective isn't sufficient to meet our objectives.
Transformation is a given in interoperability no system functions internally exactly the same as any other system. So data must always be transformed. Obviously implementers would ideally love to share their data in a format identical with their internal syntax, but doing so either means they won't interoperate or they push the need to transform onto the recipient.
The notion that implementers will use whatever model they want means a much weaker standard - not a stronger one. Obviously there's variability that is permitted within FHIR too, but much less than is tolerated by openEHR. So from that perspective, allowing non-compatible models represents a dilution of value rather than an increase, at least from one perspective. I grant that it adds value from other perspectives, but that's not going to be sufficient to avoid the need to protect the FHIR brand in some way if non-compatible models are introduced.
Thomas Beale (Mar 27 2016 at 22:50):
@Lloyd McKenzie agree - clinicians are not on their own enough. But only they really understand the data and workflows at a semantic level. So after they have done their work, system analysts and implementers work on the template level (templates are built from archetypes) and make adjustments. I don't know if it ever happens that implementers can't work with or 'sell' archetype structures. I don't know why that would be. Anyway, what happens is that different types of professionals are involved in relevant stages. Clinicians upstream, devs downstream.
Re: transformation - all I meant is that it is incumbent upon all HIS developers to minimise data transformations, i.e. avoid anything gratuitous.
Re: implementers using 'what they want' - I just meant out of the available models. If there happened to be one FHIR Condition resource and one openEHR Problem template, that would be the choice - still controlled, but more open, and catering to different communities.
David Hay (Mar 27 2016 at 23:49):
Hi Tom. When you say 'after' clinicians have done their work, do you mean a sequential process where the requirements are completed then handed over to implementers?
Lloyd McKenzie (Mar 28 2016 at 02:43):
In FHIR, implementers are providing input to the solution in parallel with clinicians. The resources reflect what real systems actually do and we try to avoid taking too many steps towards any particular clinical group's notion of what systems *should* do. Should dos are handled at the profiling level, not in the core spec. The point of FHIR's resources is that one resource serves the needs of all communities. The MedicationOrder resource is intended to work for humans & veterinarians and to meet the needs of the US, China and Zambia. It should support inpatient and outpatient and handle everything from "aspirin, once per day" to complex chemotherapy protocols. Obviously it won't meet every single requirement in all of those spaces, but the base resource is intended to reflect what most systems across that entire breadth support. Which means that most of the important data elements are recognized and understood by everyone. We don't *want* to be more open than that because that will reduce interoperability. And interoperability is the purpose of the standard - not providing a way for various community groups to develop models.
Erik Sundvall (Mar 28 2016 at 04:51):
I believe an (international) openEHR archetype is also meant to cater for the same breadth of clinical and geographical needs. But the process is different staring at the maximum dataset end and then narrowing down to speciality/geography using templates and sometimes specializations. (Not all national programs have chosen to "understand" this though... The Norwegian program does however seem to get it.
Ian McNicoll (Mar 28 2016 at 07:35):
@Lloyd McKenzie I feel there are some false distinctions being drawn here between 'implementers' and 'clinicians'. In reality, openEHR implementers provide key input into the design of archetypes, particularly since they are ones who are pushing the requierments thorugh the use of the archetypes inside their systems. openEHR modelling is not in any way divorced from implementation. Its prime purpose is to be implemented to support EHR/EPR development but they also have to play nicely with the outsode world, which is why we work very hard to make sure that we have good alignment with FHIR resources.
The statement you made about the breadth and scope of medication order (other than vet use) is just as applicable to the openEHR equivalent.
So we definitely have some commonality of scope and intent. As Erik has said, the difference in methodology is our willingness to be more inclusive in the requirements to support what people need within systems vs. what is needed right now between systems. I don’t think it is surprising that the Allergies work, whilst contentious, did not divide over FHIR/openEHR lines, nor that the lab test, condition or prcedure models are actually highly aligned without any real effort. These are all mature ideas that have been worked through in multiple communities with a high degree of cross-pollination, and in the case of labs, market acceptance around V2.
The challenges will come as the demand grows for new and novel content, where we get into much more granular/ detailed requirements and where global consensus proves harder to achieve. Even complex, localised data generally needs to be shared, and sometimes the outlier requirment can become normalised very quickly.
It has also been suggested that openEHR is more abstract than FHIR, and of course it does, by design, lack some concrete classes like allergy, condition etc. OTOH it has many more ‘first-class’ models like blood pressure pulse etc, where these are ‘second class’ profiles and extensions in FHIR. openEHR, of course, also has second-class’ artefacts via templates, so this is not meant as criticism, just to point out that it is not as simple to say openEHR abstract vs FHIR concrete.
In reality, around key models, there is quite a high degree of alignment. In particular, I think there is a very common approach to the use of terminology, and something of a push-back against attempts to use complex terminology features.
René Spronk (Mar 28 2016 at 15:17):
@Erik Sundvall At Vitalis we've been asked to address interoperability issues related to FHIR, FHIR Apps, XDS, CDA, MHD. Whilst I'm ware that one way to achieve interoperability is to first achieve intraoperability, we haven't been asked to address that aspect of interoperability, and IMHO it's mostly out of scope given the focus of our presentations. Should you wish to see this topic on the agenda I'd refer you to your Swedish HL7/IHE colleagues.
Lloyd McKenzie (Mar 28 2016 at 16:07):
@Ian McNicoll There's certainly a good foundation for alignment.
Thomas Beale (Mar 28 2016 at 16:36):
@David Hay well we are not talking waterfall software development - the archetype authors are not generally the clinicians of some provider where an implementation is being done. The openEHR international archetypes are designed without looking at specific context (i.e. any particular hospital or vendor product) as a design exercise by clinicians who know the various kinds of data. That design work happens in an independent space, human network, publication cycles, from any specific implementations.
When you get to a specific implementation context, then local docs, analysts, devs get involved in how to use those archetypes to create templates for the development, and they make all kinds of further choices e.g. specific terminology bindings. They may build some local archetypes for data sets that are not in CKM; they'll also specialise some that are there. But they're not going to change the central archetypes (to do that they need to join the CKM community).
There is a middle level in some countries with a national level of modelling. This is fairly independent of particular implementations as well, but much more sensitive to e.g. govt requirements (minimum data sets etc).
Lloyd McKenzie (Mar 28 2016 at 17:17):
@Thomas Beale In FHIR, implementers are involved at the start. Something that clinicians are interested in or might consider "best practice" but is not commonly implemented in existing systems throughout the world is unlikely to make it into the core specification unless the implementer community agrees they want to take it on. It may well get defined as extensions and included in profiles in more limited environments, but won't be considered part of the official standard. So implementers are just as "up-stream" in FHIR as clinicians are and are as (and occasionally even more) influential in how the base specification evolves. In the end, FHIR is not written for clinicians, it's written for software developers, so their needs are first and foremost. Grahame has also talked about there being a next step in driving clinical interoperability and that's around standardizing clinical practices. That's something beyond FHIR (and likely beyond HL7 too). In that space, clinicians would need to take the lead.
Erik Sundvall (Mar 28 2016 at 20:10):
@René Spronk, sure, who is your Swedish HL7 contact that ordered the specific content for Vitalis, is it Gustav Alvfeldt or somebody else?
Thomas Beale (Mar 29 2016 at 09:16):
@Lloyd McKenzie This seems reasonable: FHIR is trying to work at the implementation level with some clinical semantics; openEHR and similar approaches are working at the clinical semantics level with implementation as a downstream activity.
But we are still left with two challenges: a) how can model-based projects (and even countries) deploy data on FHIR? and b) how could FHIR make better use of clinically developed semantic models (i.e. the FHIR/CIMI question). The ideal narrative of both FHIR and openEHR and its like don't apply universally, so we need ways of solving these two challenges which don't fit the ideal plan, but are very real.
I understand that opening up FHIR is seen as some sort of risk in HL7, but there are benefits as well. So I think it would be very useful if we can investigate how FHIR can provide those benefits (and I would argue, pretty well change the whole e-health standards environment) by enabling new resource partitions to be added.
Clearly HL7 wants to make sure FHIR is 'done right' and managed well etc. That's fine and expected. So is there a way to move forward?
Lloyd McKenzie (Mar 29 2016 at 14:11):
@Thomas Beale The preferred path for implementers who have "model-based projects" (which I think is most, if not all implementers) is for them to map data from whatever their internal models are to FHIR for exchange. Doing so will allow them to interoperate with other FHIR systems, take advantage of SMART apps and allow their downstream partners to do the same.
The less preferred path is to let implementers share data in a small community over whatever model paradigm they wish, foregoing that broader interoperability. You end up with silos where some systems exchange based on the openEHR model, some based on the v3 model, others using BRIDG or CDISC or v2 or FHIM or any number of alternatives. Same technology platform, but no ability to share data with each other without a lot of extra work.
It's possible to move down both paths in parallel. And I think we're doing that. Though there's a risk that opening up the second path will remove energy/incentive from pursuing the "preferred" path.
The first path means going through more harmonization efforts like we did with AllergyIntolerance/AdverseReaction and figuring out how to maintain that alignment as FHIR continues through its rapid-evolution stage. The second means convincing more people at HL7 that, while less preferred, some path is better than no path and that we should support it. It also means agreeing on the label and terms of use such that no one's confused about what they're getting (and aren't getting) and that we minimize the risk of losing energy to pursuing the preferred path. Grahame and I are working on HL7's end of the second path. I think openEHR's side of the second path is engaging in a discussion about whether and why HL7 believes the first path is preferred and whether you can buy into that. Agreement there will go along way towards smoothing enabling path 2 as an alternative/limited/incremental step.
Thomas Beale (Mar 29 2016 at 14:38):
@Lloyd McKenzie ok, for environments where the jurisdictions want data in the shape of FHIR resources, that's fine and that's what would happen. But there are many environments where the shape of the data are known and designed in advance using templates or other semantic models, and the interoperability in that environment is based on those models, not FHIR resource definitions or some other model. Everybody's semantic environment (including FHIR-based) is by that definition some sort of silo, but that doesn't really say anything interesting. In such environments, there is very high interoperability and high ability to share the data across systems based on those definitions. This is how things already work in a lot of environments. It's no different from an environment where there are HL7v2 messages; those messages don't dictate the shared semantic models for the overall environment, they are converted to semantic model form.
I don't really understand why you say 'less preferred'. In model-based environments, the semantic models are _the_ preferred models of data. FHIR enthusiasts mightn't like it I guess, but they aren't the jurisdiction or customer. Being able to deploy the data as the customer has defined it is just what the customer wants, otherwise they wouldn't bother defining it at all.
Imagine we are talking about a BRIDG-based environment. BRIDG is the model of data in such an environment. There's no hope of squashing BRIDG data into FHIR resource form (it's a 200 class model that bears almost no relation to FHIR resources), but why would anyone want to do that anyway? The real world simply consists of a diversity of semantic model environments and frameworks, not just one. It's just a reality.
Above you say there is 'no ability to share data with each other without a lot of extra work'. But today, there is no _built in_ ability to share FHIM with BRIDG or openEHR or FHIR. It's always a lot of extra work. If that's the problem to be solved, trying to map those models through FHIR resources doesn't help, it gets in the way, other than in the case where FHIR is the intended source or target. FHIR's clinical resources are clearly most useful where either or both of the following are true: a) the users want their data retrieval to be in FHIR structures; b) there is no published or preferred model of data that is to be extracted from some system, e.g. EMR etc.
In the end, the choices about how to deploy openEHR on FHIR aren't really an openEHR question, they are a customer / jurisdiction question. There are three cases:
a) give us some data in FHIR form => we implement FHIR over openEHR;
b) give us the data in the model-based form we asked for;
c) possibly a mixture, since FHIR resources only cover a few % of the openEHR content space.
right now we can't implement b) or c). I've been told that one approach is to fork FHIR, rename it, and then implement the resources we need. Is that what we should do?
Ian McNicoll (Mar 29 2016 at 14:43):
@Lloyd McKenzie I don't see things as quite such a stark choice. First of all openEHR is an implementer community - we take the requirements of real openEHR systems and those expressed in non-openEHR systems as a key part of design. Most of the archetypes you see will have had their origin in some expressed or existing requirement. Of course, our implementer focus is a little different, since this is primarily about data inside systems not just about exchange, but these implementers also have to exchange data with others, so those aspects expressed via FHIR, CDA are equally important. It would be very foolish for us develop archetypes that, ignored what is expressed in FHIR models. In any case all of these various 'implementer' requirements are actually originally 'clinical requirements'. The reasons that they differ is that the original clinical opinions differed, not always for bad reasons.
Right now FHIR has a lot of momentum, an enthusiastic development community and a degree of vendor engagement around the 'big ticket' resources. That is to be welcomed and applauded, and also makes it possible to push the interoperability story forward, at least in terms of some 'mandated' resources.
The queston is how this will work out once the need arises to enforce profiles or the elaboration of these models needs much more input.
Lloyd McKenzie (Mar 29 2016 at 15:42):
@Thomas Beale It's not a question of what jurisdictions want or even what implementers want internally. The question is "what does it mean to interoperate using FHIR?" And if you want to interoperate using FHIR, then you have to map to and from whatever model you use (regardless of whatever it is) to the FHIR model. If you don't do that, you won't interoperate with other FHIR systems. And that, in the end, is the objective of the FHIR standard. FHIR doesn't dictate what your internal data model is any more than v2 does. But it does expect particular data elements to be sent in specific places - just like what v2 does.
The "transport only" option is less preferred because it creates interoperability silos. It'd be equivalent to using v2 where all data is conveyed using jurisdiction-specific Z-segments. Sure, you can parse the content, but unless you belong to that particular jurisdiction, you can't understand any of the data you've parsed. The power of a standard (v2, FHIR, whatever) is the degree to which systems built independently using the base standard can reliably understand data from each other. v2 was "ok but not great" in this space. v3 was a disaster. FHIR strives to be stronger than v2, but recognizes that absolute interoperability isn't feasible given different regional practices.
It's absolutely possible to convey all BRIDG data in FHIR. It will require mapping and will require extensions, but there's no reason an implementer who uses BRIDG as an internal data model can't convey all of that data using FHIR. And if they want to interoperate using FHIR, they have to. If they don't, they can't use SMART, they can't use any of the FHIR test cases, they can't comply with any of the standard FHIR implementation guides, etc.
There's no question it's extra work. Implementing standards is always extra work - you have to bridge the cap between what your internal syntax is and what
Keep in mind too that very few systems actually use "standard" reference models internally. Very few in the pharma world use BRIDG as their internal data model. They would just map to it. (I've worked with a few who have tried to use it as an internal model and it's quite challenging). BRIDG is all about mapping. All sorts of specifications and projects map their internal data model to BRIDG. The effort to interoperate with FHIR is exactly the same.
And I disagree with your assertion that FHIR only covers a small percentage of the openEHR space. Right now, I'd say we probably cover 80%+ and the intention would be to cover 100%. There'll never be a FHIR resource for something like "blood pressure" because that data would be conveyed using the Observation resource - so you'd map the blood pressure data elements to Observation. openEHR granularity is smaller than FHIR's. But that doesn't mean the content isn't expressible in FHIR.
You certainly have the right to grab any of the public domain content from FHIR, rename it and do what you wish. But you won't be able to use the FHIR name in any way with it at all. And as FHIR continues to evolve, you'll be on your own trying to remain in sync. The alternative is to continue to work with us. I think we will come up with a way to let implementers use FHIR as a "transport only" spec, but there's essentially no chance that will be considered a "full" FHIR implementation. It will have to be labeled as some sort of second-class citizen because it doesn't provide interoperability except within a closed community. We can however work together to come up with a label that's mutually agreeable. Something like "FHIR-transport conformant" or something like that. And I think we should continue to work on harmonization between the FHIR data model and the openEHR data model so that those who are interested in using FHIR for general interoperability (with openEHR systems, v2 systems, BRIDG systems, or whatever else) can do so easily.
Lloyd McKenzie (Mar 29 2016 at 15:44):
@Ian McNicoll I didn't mean to imply that openEHR didn't have an implementer focus too. I just think the balance is a little different in the FHIR space than the openEHR space and that will be one source of difference that will make harmonization between the models a bit more challenging.
Thomas Beale (Mar 29 2016 at 16:04):
@Lloyd McKenzie I think I must be missing something here. If a community that uses a certain set of models to define its semantics was to use the FHIR transport mechanism, why is this 'closed'? If the set of models being used is the FIHR resources, that's 'closed' by the same definition. It's just an alternative (and very recent) model set. I don't really understand the 'second class citizen' terminology, it sounds very subjective to me. There are just communities that use well-defined model libraries to do their work; we can call them 'siloes' if we like, but I don't see how that's useful.
What I had hoped we could consider was whether there is a way to deploy the models of a community like openEHR (or it could be CIMI, IHC, CDISC, or others) on the FHIR transport + infrastructure resources.
What I am hearing is that this is not something HL7 wants to work on.
Lloyd McKenzie (Mar 29 2016 at 17:58):
It's "closed" because it's limited to that community. I.e. It's a specific silo. While FHIR is itself a silo, we're trying to avoid the problem we had with v3 that every implementation jurisdiction becomes its own silo. If you say "I'm FHIR conformant and I support resource x", then you should have a reasonable degree of confidence that you can interoperate on at least the core data elements with any other system anywhere in the world that is also FHIR conformant and has implemented the same resource. (Accepting variability in code systems and support for certain data elements). What you're proposing is that there'd be openEHR FHIR and BRIDG FHIR and FHIR FHIR and a bunch of others, none of which could interoperate. FHIR is intended to foster interoperability (and ability to leverage software solutions, templates, decision support rules, SMART apps) etc. *across* implementer communities.
Lloyd McKenzie (Mar 29 2016 at 17:59):
HL7 (or at least parts of it) are open to the possibility of enabling transport of non-FHIR models over FHIR infrastructure. But we can't claim that any system doing that is fully FHIR conformant.
Thomas Beale (Mar 29 2016 at 18:20):
well those X-on-FHIR implementations would not interoperate automatically. But consider that if they needed to, _what_ needs to be shared is usually a small % of the total data within the respective contexts. To engineer interop of 10% of openEHR with say CIMI or CDISC BRIDG when openEHR-on-FHIR exists and CDISC-on-FHIR exists greatly reduces the problem - since they'd already share:
- FHIR data types
- FHIR terminology referencing approach and maybe even actual terms / value sets
- FHIR identifier types
- FHIR demographic entity representation
and other FHIR representation generalities. So I'd suggest that quite a lot of value is available for the taking here.
I don't mind at all what HL7 want to call the different flavours.
Lloyd McKenzie (Mar 29 2016 at 18:31):
Grahame and I both agree there are benefits and we're working on selling those within the FHIR space. I'm pretty sure we'll succeed. Part of the issue is drawing the bounding box around what's fully conformant and what's partially conformant as well as what label to use. I'm sure we can come up with something that will be acceptable.
Please note that I'm not saying that implementers have to interoperate using FHIR - implementers can use whatever models they like and whatever transports they like. We can set up a way to allow transport of arbitrary models across FHIR transport for those that find that beneficial. But that's not going to make those interfaces full FHIR interfaces. What HL7 needs to figure out is the process for allowing arbitrary model transport without labeling them as "full FHIR". That discussion is happening now within the FHIR Management Group and the FHIR Governance Board.
Lloyd McKenzie (Mar 29 2016 at 18:34):
Side note: What I'm reflecting here is a mixture of my own opinions as well as discussion that's happened within the FMG and FGB. In the end, it'll be the latter two (possibly with vetting from higher levels within HL7) that will decide exactly what the mechanism for transport of alternative models over FHIR will be. I'm pretty sure we'll find a way to make that happen. But I'm also pretty sure that the result won't be able to be called a FHIR implementation without putting some sort of qualifier on the front that makes it clear what degree of interoperability is being achieved (and not).
Thomas Beale (Mar 29 2016 at 19:28):
@Lloyd McKenzie ok that sounds good. We can work with HL7 on doing this properly if people would like participation. I realise it's a non-trivial piece of work, and it needs to be done carefully. So let's see how to do it. Or at least when/if you get past the internal convincing stage...
Lloyd McKenzie (Mar 29 2016 at 19:50):
While that's in progress, what are your thoughts around further FHIR/openEHR harmonization efforts? (And also a way to support review of the ongoing maintenance that's happening in the FHIR space - there've been changes to AllergyIntolerance since we last worked.)
Thomas Beale (Mar 29 2016 at 21:18):
@Lloyd McKenzie well I don't know what the grand plan might be, but it seems like an obvious early strategy to take a few FHIR resources that are thought to be in good shape and start comparing them to the openEHR equivalents. The goal can't be to arrive at exactly the same place, since FHIR resources will probably have a few things that are implem/protocol related. But they should go close. I suggest, having made a cursory inspection that Condition (despite the debate about its name, which although it might be wrong, we don't care about) is not that different from Problem/Diagnosis, and Procedure could also be a reasonable match. Observation is going to be hard work, and isn't a direct hit on anything (except parts of the openEHR RM), so how we make that work is going to be a different kettle of fish.
W.r.t. a strategy for dealing with subsequent changes in models that were compared / cross-reviewed at some easier point in time - right now all I can think of is that there is an agreed single place to notify design changes in such resources & archetypes. So there needs to be a list of models that FHIR and openEHR mutually work on/ have worked on, and we agree to post changes on those - e.g. it could be as tasks on an agreed Jira tracker somewhere (or even on each other's trackers).
Lloyd McKenzie (Mar 29 2016 at 22:57):
Doing Condition next sounds reasonable and doing Procedure would be great as it's an important but fairly "weak" model - not a lot of implementation or review yet. FHIR is looking at migrating from gForge to Jira, so that's a possibility
Andy Bond (Mar 29 2016 at 23:48):
It seems many people look at interoperability as an absolute rather than a set of layered agreements and disagreements that allows systems to be coaxed into working togther. Ideally that coaxing is negligible if everything lines up but in reality it is almost never so. I'm a fan of @Thomas Beale co-existence of content models as a stepping stone. I think it creates a stronger likelihood of growing alignment than not having any foundation of agreement at all.
Erik Sundvall (Mar 30 2016 at 00:11):
I agree with @Andy Bond here.
Keeping the especially the clinical requrements gathering/discussion and associated community together would be very helpful and helps keeping up with the constatntly changing clinical reality. It will be changing even faster in the future so we should avoid duplicating that work as far as possible...
Koray Atalag (Mar 30 2016 at 02:57):
I think we ought to make an effort to keep key clinical FHIR resources and core openEHR archetypes well aligned - and also make sure they stay aligned along the way. We'll take these points to our management/governance boards and report back. The inevitable question is of course who's going to pay for this - always a challenge!
Thomas Beale (Mar 30 2016 at 08:09):
@Andy Bond 'interoperability: a set of layered agreements and disagreements that allows systems to be coaxed into working together' - that should be engraved in stone somewhere. We are indeed in the 'coaxing' business...
Ian McNicoll (Apr 02 2016 at 18:22):
@Koray Atalag "I think we ought to make an effort to keep key clinical FHIR resources and core openEHR archetypes well aligned" and for condition, allergies, procedures, medications, labs, imaging, I donlt think that will be too demanding if we 'play nice'. The equivalent resources/archetypes actually line-up very nicely, even without the formal process we undertook with allergies, probably because there has a high degree of alignment and stability of these ideas across formalisms and industry over some years which are now quite mature.
Also agree with @Andy Bond's great quote though I would probably argue that the coaxing of systems is largely about coaxing the clinicians whose ideas these systems represent!!
Ian McNicoll (Apr 02 2016 at 18:27):
@Lloyd McKenzie agree - Condition and Procedure are good next targets. Labs is pretty well there already. We will be reviweing these shortly and Labs already incorporates most/?all aspects of the FHIR models. I don't think we need to get 100% alignment right now and that will be tricky given the different publication timescales and processes and agree with @Andy Bond +++
Last updated: Apr 12 2022 at 19:14 UTC
