Stream: clinFHIR
Topic: profile commenter
David Hay (Mar 12 2016 at 20:59):
One of the things that openEHR has that FHIR doesn't is a way to help collect clinical requirements, and to provide comments against profiles as they are being developed. I made a start here, but it's pretty basic (and not really exercised at all. I wondered if it was worth starting a stream to collect requirements for such a tool. If there's sufficient interest, then we could see if we can put together an Open Source project to build one.
David Hay (Mar 12 2016 at 21:01):
So you'd probably want some way to collect profiles in some form of 'project' - to bring together all the artifacts you need - could include ValueSets for example - possibly based the whole thing around an Implementation Guide??
David Hay (Mar 12 2016 at 21:02):
You'd want to be able to view the profiles in some user friendly way - perhaps the tree based logical views that people have developed.
David Hay (Mar 12 2016 at 21:03):
being able to generate an example from the profile might be helpful
David Hay (Mar 12 2016 at 21:03):
You'd obviously want some way of threaded comments (and maybe this could be zulip??)
David Hay (Mar 12 2016 at 21:04):
Specific projects might require moderation - and might even need to be developed privately (though I think that goes against the ethos of FHIR myself)...
Erik Sundvall (Mar 23 2016 at 08:41):
Instead of creating a parallel toolset and community to help collect clinical requirements, don’t you think it would be a good idea to integrate that work for FHIR and openEHR archetypes? It would be better if we can have one big global clinical community that discusses and collects requirements, rather than having two.
There is new open source tooling underway for openEHR archetype/template editing, see https://goo.gl/7Cd52R
Do you think we could somehow align or join this with the clinFHIR effort?
Michel Rutten (Mar 23 2016 at 09:38):
@David Booth Hay I can see how a notion of a conformance project would be useful. Forge tries to leverage the current ImplementationGuide resource to provide some sort of package concept. We've also been thinking about introducing application-specific project files, but I think it's beneficial to try and use standardized FHIR concepts.
Michel Rutten (Mar 23 2016 at 09:45):
BTW Currently the "Session Explorer" in Forge resembles the mentioned "logical view", as the explorer shows references to (external) package resources as child nodes of the package. However this approach also has some limitations/complications, e.g. dealing with unresolved entries and resources referenced by multiple packages. So we've been thinking about improving that part of the UI design.
Grahame Grieve (Mar 23 2016 at 10:18):
Erik, sure, we think that would be a good idea in principle, but there's not been a lot of progress in practice. It's hard to get priorities and processes aligned, and politics and personalities and past history doesn't help either
Grahame Grieve (Mar 23 2016 at 10:21):
did you read Thomas Beales post late last year? It didn't offer us hope that the effort you are talking would help us out
Erik Sundvall (Mar 23 2016 at 11:39):
Which of Tom's posts were you thinking of?
Grahame Grieve (Mar 23 2016 at 11:43):
http://wolandscat.net/2015/12/20/making-fhir-work-for-everybody/
Erik Sundvall (Mar 23 2016 at 13:10):
I'd consider Tom's post to partly be a (possibly somewhat impolite) probe to see if it would be an option to use FHIR as some kind of "transport layer" for things modelled in openEHR and other formalisms. I reckon from the discussion under that post and in http://www.healthintersections.com.au/?p=2415 the answer was a clear NO and I think I understand the logic reasons. After a NO other approaches will need to be looked at.
Am I correct in believing that FHIRs main purpose is _not_ to be an RM in a generic multi-level model where much of the clinical complexity is moved (http://www.healthintersections.com.au/?p=47) to an upper archetype level or similar? Rather FHIR takes care of and models some of the complexity as resource attributes etc and externalizes the rest to extensions/profiles. Is that a correct view?
So if we want to create a shared clinical requirements-gathering community/space/tooling, then a more interesting thing to do is to figure out ways to keep the clinical reqirement discussions in one place and then form archetypes, FHIR-Resources and profiles from the same disciussions using somewhat integrated tools. If that is done while being aware of and talking to each other, then mappings+extensions will be somewhat easier, and maybe in some cases mappings/profiles could be created and released together.
It might, or might not, be in the interst of Ocean Informatics (the company behind CKM-tool) to extend their tool to accomodate FHIR-artifact discussion/generation, I don't know, but I'd expect them to at least want to get paid for such extension work. I have long been arguing for moving the CKM-discussions to an open source environment to encourage extensions/modifications etc, but since openEHR gets the service free of charge this has naturally not been a priority for the openEHR Foundation since there are more urgent things to focus on.
Since it is in the interest of many of us in both openEHR, HL7 and ISO 13606communities to strive for one clinical reqirements-gathering community rather than many, I think we can figure out ways to align some tooling no matter what, if there is a will from all sides. That is the kind of probe I am sending out here...
(The new online archetype/template-tools are not controlled by Ocean Informatics by the way, and neither is the openEHR foundation.)
Grahame Grieve (Mar 23 2016 at 19:04):
several comments:
- the answer is not a clear no. We don't like some of hte consequences of the idea, that's for sure. But that doesn't mean we won't help if that's the kind of use people want. It's on our list
- FHIR is not a RM in a generic multi-level model, no. We agree that multi-level modeling is a useful tool, but the starting proposition of FHIR is that there is (or can be) enough agreement to a generic base to be a useful thing, And that you can build additional levels of models on top of that
- the fundamental battle is over this; methodologically, openEHR rejects that, and certain openEHR people reject that out of hand. Tom's post reflects this rejection, but sort of more from pragmatic reasons than theoretical ones.
- but it doesn't matter whether it's for theoretical or practical, as long as you assume that you can go ahead and design whatever models you want without having to account for the base level agreements in FHIR, then there's not going to be alignment there, and sharing tools isn't going to do anything for us
- I agree that we should have an open environment. We're working on an implementation guide for using resources to do the review process that CKM does; commodising the bits will enable people to mix open and free and paid in the way they want
Thomas Beale (Mar 26 2016 at 10:04):
The main distinction in my post was between model-based systems / environments and non-model based systems. Any system based on a reference model + semantic models approach (which I believe is the future of EHR) isn't going to be easy to access via native FHIR profiles - we are just back to the clashing models problem (talking technically here).
For non-model-based systems (the majority today), something like FHIR makes sense, because it just standardises the information contained within. I do think it's a pity that the FHIR models for doing that are not aligned (other than adverse reaction) with semantics models of the same content (CIMI, Intermountain, openEHR, 13606, even some CDA templates) because the latter are likely to be preferred models of semantic querying.
But there is another issue as well: there are a lot of useful semantics in the reference models of those multi-level modelling approaches. I am working at Intermountain on next generation workflow based architecture - and that reference model will be very powerful. On top of it will sit Intermountain and CIMI archetypes. But obviously Intermountain is using FHIR. So it would be genuinely useful to be able to expose that RM and the models on top of it in the FHIR environment.
Grahame Grieve (Mar 26 2016 at 10:06):
I really have to take issue with this, there's two falsehoods in this.
Grahame Grieve (Mar 26 2016 at 10:08):
The first is that there's aa binary distinction between model and non-model systems. All systems have some degree of formalism, and some community around them. You're arbitrarily drawing a line in the sand and pretending it's a clean division,
Grahame Grieve (Mar 26 2016 at 10:09):
i think you're trying to draw openehr as somehow special,,as opposed to yet another community with their own models (or, in the case of openehr, their on swarm of models).
Grahame Grieve (Mar 26 2016 at 10:10):
Using FHIR for interchange really isn't different between the different communities either - they have to map to the common form.. I think that it's intraoperability where you see a difference
Grahame Grieve (Mar 26 2016 at 10:13):
the second issue is that there's a single target for archetypes - as you know, it's just a technique; all the models are different. We consult all of them and often have large spreadsheets comparing them. I wonder why Cimi etc don't change course and join with FHIR. I think openehr is a harder problem because it has production system impetus
Thomas Beale (Mar 26 2016 at 10:14):
On the question of model-based - most commercial systems don't make their models available. Yes, you can obtain some kind of view table structure, often local in nature. The models of the clinical semantics certainly are not published, they are partly baked in, partly (mostly) built as form definitions. The real situation with working with data from current major vendor systems is that you don't have any standard semantic definitions to work with, you may have local form definitions, that's about it.
Grahame Grieve (Mar 26 2016 at 10:15):
That doesn't mean that the vendor doesn't have them to some degree
Thomas Beale (Mar 26 2016 at 10:15):
On the question of 'being different', it's not about openEHR, it's about model-based architecture. openEHR is just one architecture that does the same thing: based (very carefully designed) Reference Model + layers of semantics models that obey the RM. That's a style of architecture. openEHR is just one example.
Thomas Beale (Mar 26 2016 at 10:19):
The really key thing here that I think people are interested in is clinical people/domain experts being able to define semantic models independently and upstream of any particular implementation technology. There's a lot of power in being able to generate from a semantic model (a template for example) a) a code skeleton b) an XSD c) a JSON screen protoform d) a FHIR (or FHIR-like) profile e) an HTML5 display format f) a PDF g) .... etc
Thomas Beale (Mar 26 2016 at 10:21):
I don't argue with whether the vendor has them or not - if they don't internally, they're not even doing the basics. The point is whether those models are a) even expressed in a logical way (they aren't for the big vendors) or b) published or available for users (they aren't).
Thomas Beale (Mar 26 2016 at 10:23):
One thing to remember is that clinical semantics take a long time to get right, and involve expensive people time. It's surely worth providing a way to express them that is not specific to a particular downstream technology, but instead is re-usable over time?
Thomas Beale (Mar 26 2016 at 10:31):
BTW, in terms of orgs with major RMs... VA - FHIM.
Lloyd McKenzie (Mar 26 2016 at 14:19):
But, by your definition, FHIR *is* a multi-level model-based design. First, all of the clinical models are based on HL7's reference model - the RIM. Second, the FHIR models themselves are technology-independent - you can serialize them in XML, in JSON or in RDF. And you can render them in HTML too.
Lloyd McKenzie (Mar 26 2016 at 14:19):
The difference between FHIR and OpenEHR is not whether we're model-based or not. I see two main differences:
1. In OpenEHR, different communities are free to define their own archetypes covering the same space. That limits interoperability to within the bounds of each community. In FHIR, to be conformant, everyone must use the same resource (roughly the same as archetype) when they're sending a particular type of information. (Though there are edge cases where, for legacy reasons, there may be confusion about what resource a particular piece of legacy data corresponds to.)
2. In OpenEHR, the modeling process is biased towards "clinical idealism" - at least as perceived to be ideal by a particular community of clinicians. In FHIR, the bias is towards "what do implementers do?".
Lloyd McKenzie (Mar 26 2016 at 14:19):
I think there's benefit to adding more clinical rigor to FHIR, but not at the expense of reflecting the reality of what real systems (used by "real" clinicians) currently do.
Lloyd McKenzie (Mar 26 2016 at 14:19):
I don't think FHIR is willing to give up on #1 - which is the real sticking point of allowing OpenEHR models to be transmitted over the FHIR infrastructure. Doing that breaks interoperability. As things stand now, if someone sends an allergy or prescription or encounter in FHIR from any system anywhere in the world, I'll be able to parse it and able to understand most of the content, though there may be challenges with a few code systems. And I don't need to consult with the sender in order to have that understanding. That's very powerful and is something we're loath to give up - certainly not without drawing a very clear deliniation between interfaces where you can expect that degree of interoperability and those where you can't.
Thomas Beale (Mar 26 2016 at 19:36):
@Lloyd McKenzie The question of (semantic) 'interoperability' as you put it isn't controllable by technical means in either openEHR or FHIR. In openEHR, the RM is fixed, noone gets a choice on that. But it's easy for local groups to invent their own blood pressure measurement archetype. It just happens that they don't, by choice - there's only one such archetype, at openEHR.org. They do invent competing versions of less obvious things though (e.g. medication order), and sometimes it takes time for those to bubble up from the national level to international level. It's messy, but commonality does emerge, and there are many archetypes to show that. How well this process works is completely to do with organisational agreements, communication, cooperation, and only slightly to do with tools and technical aspects.
The same will be true in FHIR: it will be just as easy for 10 groups to create 10 profiles based on a core FHIR resource, each intended to model the same thing (say part of a pregnancy record), and they will come up with 10 different non-interoperable profiles. Since FHIR is more developer/IT oriented, it's also more likely that these models will reflect IT pre-occupations rather than clinical knowledge. See this post (http://wolandscat.net/2015/11/29/why-it-people-cant-build-information-systems/) for the reality of IT people trying to design clinical artefacts. This problem in FHIR will probably be greater even than in openEHR, because now we are talking thousands of developer companies, not just a small number of clinical modelling programmes. This isn't a criticism - it's just how anything that is like 'profiling' ends up working in practice.
openEHR, and other model-based architectures already have interoperability (including over REST), but we don't have it over FHIR. THere are customers who want a) semantic interoperability, b) clinical models that can be re-used in more places than just FHIR, c) but they want FHIR today (they've been told it solves everything...). It seems pretty clear how to achieve it, except that the obvious path is not currently open.
BTW, most 'real clinical systems' only approximately represent what clinicians do. Most are terribly badly designed and the clinical semantics are buried in the UI forms, not the database. Most lack formal models of business level process or content, and the most common schemas are just huge ER models that try to capture every known data point on every major logical 'type' they can think of.
Lloyd McKenzie (Mar 26 2016 at 20:29):
@Thomas Beale The difference is the granularity of the base model. The RM for OpenEHR is extremely abstract (sort of like the RIM, though with a different approach) with numerous ways of conveying the same thing. The semantics live in the archetype definitions, not the RM. In FHIR, the base model is semantic-rich and extremely concrete. The base model for MedicationOrder in FHIR has specific slots for prescriber, patient, medication, various aspects of dosage instruction such as start date, dose quantity, maximum dose/period, etc. So there's a significant degree of consistency enforced by the base model - the key semantics are defined in the base model and only more esoteric semantics (e.g. sophisticated components needed for chemotherapy protocols) are left to the profiling/archetypes level as extensions. The result is that, while there may be disagreement over what code system to use for medications, there's still a standard way to convey that medication and that dosage. If we bring in the OpenEHR models, then there becomes 11+ ways that same information might show up in an instance - and that's a problem. Right now, I know how to find the dose quantity of any FHIR prescription written anywhere in the world (if they capture dose as a discrete value). If we introduce the OpenEHR archetypes or other models, that won't be true anymore.
There are certainly advantages to having OpenEHR leverage the FHIR infrastructure, but for it to not disrupt the existing FHIR community, we'd have to compartmentalize the use of the specification so it's clear what degree of interoperability implementers can expect with a given system. Right now, we're working to convey the advantages of having OpenEHR at least partially within the tent and also how to properly delineate implementations.
Erik Sundvall (Mar 27 2016 at 08:30):
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 08:33):
Perhaps my comment above would fit better in the openEHR-stream instead. I'll copy relevant parts there and encouage you to do followup discussion there instead of here.
Koray Atalag (Mar 27 2016 at 09:06):
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:37):
Koray, I partly agree - Lets continue this in the openEHR stream - I'll copy your reply to that stream and answer there
Thomas Beale (Mar 27 2016 at 11:27):
@Lloyd McKenzie the models are of course different. FHIR clinical resources are designed as a single level model to which adjustments can be made; the opeEHR reference model is a model of generic structure plus context attributes (only the varying clinical semantics have to be added). One could think of the FHIR resource Condition for example as being similar to the compiled version of the openEHR Problem archetype, where compilation causes inheritance flattening of any lineage of archetypes onto the RM. Similarly, Fhir:MedicationOrder has similar attributes to be openEHR RM - Instruction (contains the generic attributes of orders) coupled with archetypes of various kinds of order, including Medication Order.
It appears that the resulting deployable models in each case somehow suit the various communities who create them. But the result in openEHR isn't 11 ways to describe Medication Order, there is just one (http://www.openehr.org/ckm/#showArchetype_1013.1.123_mindmap), but if national programmes want something different, they can define it. It's not up to a standards organisation to prevent that.
It's only a problem if the actual data sharers discover it is, e.g. across European borders. Then they become very interested in using the same model, and indeed that's what happens over time. This level of standardisation is driven by real-world mutual interest. Does it matter if the Australian Medcation order model is different from the international one? Not really. If it starts mattering, then relevant agencies will no doubt act.
So it's not really true to say that the technical possibility of there being more than one archetype for Medication Order poses a problem to FHIR. There will only be multiple versions of such a model when cross-border interoperability doesn't matter and no efforts are made to standardise. On the other hand, a great majority of detailed clinical data never go beyond their original systems - what is widely shared is in fact only about 5-10% of the total data in an EMR - i.e. the managed lists (Rx, Dx, allergies etc), basic demographics, family history, etc. So there's actually no sense in imposing a standard 'pregnancy record' model on the whole world when such a thing doesn't exist in reality; each country has its own and that's the way they want it.
I'm not bringing any of this up to be difficult (despite possible opinions to the contrary) - what I'm pointing out is that neither FHIR, nor openEHR, nor any other clinical standards like effort can impose the one model to rule them all on the world; it can only create tools and formalisms that provide capabilities. The rest is up to human institutional agreements.
I think the benefits of model-driven clinical data standards are pretty clear: single-source modelling, with multiple downstream deployments. At the moment, we can't easily connect that kind of framework to FHIR, but I am arguing that it would be a good idea. How else could 20,000 - 50,000 clinical content (and soon - workflow) data point models (= ~4,000 openEHR style archetypes) be deployed over FHIR? It's not going to happen by old-style custom mapping approach.
Obviously it would need to be done as a serious conversation between organisations (openEHR is just one of many), so that the various levels of tooling and models were properly managed and described, enabling developers. If we did this, the benefits could include:
- directly connecting large numbers of clinical model authors to the FHIR framework
- enabling a path for CIMI models to be natively deployed over FHIR
- enabling re-use of content models used in FHIR in other downstream technologies
- standardising the approach to using terminology from content models to the FHIR approach
- making FHIR 'profiling' and the archetype formalism (which appear to do the same thing) into one formalism
Most of this is aimed at reducing wheel invention and obtaining significant added value by connected currently disconnected large pieces of work in health informatics together.
Last updated: Apr 12 2022 at 19:14 UTC
