Stream: openehr
Topic: scope, hype and reasonable expectations
Erik Sundvall (Mar 23 2016 at 09:02):
Hi!
During the Swedish Vitalis Conference there will be interesting FHIR-activities on April 6 when @Ewout Kramer and @René Spronk will be conducting FHIR seminars/workshops.
Being a memeber of both openEHR and HL7 and working as information architect for one of the Swedish Healthcare regions (that is using an EHR where archetypes are being introduced), I am noticing a certain confusion in Sweden regarding the scope/overlap/cooperation of the different efforts.
I have read many great posts (by e.g. @Grahame Grieve ) and seen nice presentations online (by e.g. @Ewout Kramer ) and others in the well-informed FHIR-team, and I have quoted/reused materal from you several times. But from many people outside the core team (including colleagues returning from HIMMS etc) I hear inflated FHIR-hype that will be damaging to both FHIR, openEHR and Health infromatics in the long run.
Is this web forum a good place to discuss ways to present both FHIR and openEHR in non-hyped ways that helps people get reasonable expectations and fewer dissapointments in the long run?
René Spronk (Mar 23 2016 at 09:41):
Sure, why not? This forum is what we make it.. It is true we've been asked to speak at the Vitalis conference. The organziers have asked Continua to speak, and for me and Ewout to speak about the (potential) relationships between FHIR, the Swedish national architecture, and the 3R project. We'll certainly discuss the need for FHIR Profiling as well as the necessity to capture the (clinical) requirements prior to rolling out standards like FHIR. Focus (as you'd expect) is on the implementable standards however. I gather however that the chat you'd like to initiate is a generic one and not about this particular conference.
René Spronk (Mar 23 2016 at 09:45):
In general I'd say that those who present FHIR and have been active in this industry for a while will know they should stress the importance of gathering (clinical) requirements, where OpenEHR is one of the methods of doing so. At the same time OpenEHR presenters will be aware that they'll have to combine their standard with standards such as XDS, HL7v2 and FHIR. As presenters we don't have to cover everything, but we have to raise awareness how they co-exist, how they are positioned with respect to each other, and how combinations of standards are used in current projects.
Grahame Grieve (Mar 23 2016 at 10:09):
Hi Eric. We would like it if people stopped with the hype, but we have no control over that
Grahame Grieve (Mar 23 2016 at 10:11):
i think that rene's scheme where openehr is a method of gathering clinical requreirments, but this is often associated with people not knowing what is already agreed in the wider community, and either unknowingly or deliberately ignoring them, and thereby creating downstream chaos
Grahame Grieve (Mar 23 2016 at 10:13):
And, of course, gathering requirements - clinical or otherwise - is critical
Grahame Grieve (Mar 23 2016 at 10:14):
the challenge for us to be receptive to people's requirements in a timely fashion while also maintaining continuity for the existing community
René Spronk (Mar 23 2016 at 11:43):
As for the hype: there's not a lot we can do about that. Even if Grahame were to point out some of its weaknesses in the Keynote at HIMMS, people would chose to believe it will be the answer to all their problems. That's human nature. We'll have to ride the hype curve, it'll come down once people start using this in earnest (in larger numbers as they do today, and with a larger scope in terms of content). In the mean time my focus at least is to collect the best practices of actual implementers, to put some substance behind any statements (or: presentations and training courses) about FHIR.
Erik Sundvall (Mar 23 2016 at 12:12):
One of my main concerns in Sweden now is the requirements specification in some major upcoming procurements (3R and others) in one sense 3R is now 2R since one of the 3 regions got a Cerner deal.
If buyers/decision makers think as René said that FHIR "will be the answer to all their problems" (or even just to all their interoperability problems) then they might miss the point of asking the vendors to support ways to collaborate regarding alignment at the Clinical "input" end. It is of course an option to ignore the input end and trust the vendors to take care of all requirements gathering, but some of the design principles behind the options should be presented (like in the very well written http://www.healthintersections.com.au/?p=820 ).
I Think the realistic warning texts like in https://www.hl7.org/fhir/extensibility.html are great :
"...situations will very likely arise where different applications exchanging information with each other are supporting different sets of extensions. This specification makes some basic rules that are intended to make management of these situations easier, but they cannot resolve them"
...and I would love if you could highligt such things in conjunction with mentioning/comparing them with formal ways of capturing requirements in a global Clinical Community such as the openEHR and CIMI archetyping work.
Several of the regions in Sweden are aware of and following the Norwegian archetyping translation- and modeling-work, and I think it would be a pity if people came from Vitalis believing that they should stop doing that because FHIR will solve all such issues for them.
Erik Sundvall (Mar 23 2016 at 13:40):
Perhaps the openEHR SEC (where many have experimented with FHIR) and the FHIR technical core/architect-team (what are you called?) could agree on a set of 1-5 powerpoint slides describing the relationship and differences in approaches between openEHR and FHIR? They could highlight both agreements and things/perspectives that are different in the approaches. There are some good blog posts from @Grahame Grieve that could be used as a starting Point: http://www.healthintersections.com.au/?p=47 and http://www.healthintersections.com.au/?p=820 and http://www.healthintersections.com.au/?p=1924
Erik Sundvall (Mar 23 2016 at 13:43):
@René Spronk, regarding combining openEHR with XDS, HL7v2 and FHIR I believe you are already aware of several such examples, right? If not I can give you some links.
René Spronk (Mar 23 2016 at 13:56):
From an interoperability standpoint, OpenEHR adds a layer for capturing the clinical requirements, and we'd need to know about projects that have mapped those requirements to FHIR profiles. From an intraoperability standpoint (to use Grahames term) FHIR adds another possibility to add an interoperability layer to an EHR. We'd need to know about projects that have templated archetypes for use with FHIR resources. The English NHS is an example of the first approach (although I dont think they have the tooling in place right now), Marant is an example of the second. References are always useful, as I tend to hear about OpenEHR implementations only occasionally (not being an academic there's not a lot of venues where one comes accross OpenEHR implementation oriented talks).
René Spronk (Mar 23 2016 at 14:04):
I have always welcomed, and will do so in the future, any software-implementation presentations by OpenEHR implementers, at any of the HL7 AID meetings (or at the FHIR DevDays in Amsterdam). I did invite Ian to talk about the OpenEHR/FHIR relationships at last years DevDays, but he had a conflicting meeting. Should you know of anybody willing to present on the topic, and to do so in front of an HL7 audience, please let me know..
Erik Sundvall (Mar 23 2016 at 14:21):
@Oskar Thunman You might also want to join this conversation since you'll be presenting an HL7-talk at Vitalis this year. (The one you did last year might have been a bit FHIR-hype-contributing...) ;-)
Grahame Grieve (Mar 23 2016 at 19:05):
Rene, we could ask Ian again; that would be good.
Grahame Grieve (Mar 23 2016 at 19:05):
or else I can talk about it, since upper level modeling is done using CKM in this country
Ian McNicoll (Mar 24 2016 at 10:16):
Hi Grahame, Rene,
Very happy to talk about both the clinical modelling aspects from a UK perspective, and how the FHIR and openEHR worlds are interacting at implementation level, via the RippleOSI and Endeavour projects. There is in my estimation a real sweet-spot here these two technologies can come together and add considerable value. FHIR does things that openEHR cannot and vice versa. More in a bit ..
Grahame Grieve (Mar 24 2016 at 19:46):
Ian, awaiting your comments with interest. I think it could work well, but I don't see any willingness to make it work well for most particiapants
Koray Atalag (Mar 24 2016 at 22:28):
In NZ we have envisioned such complementary working of openEHR and HL7 standards (v2 & CDA at that time) in our Interop Reference Architecture back in 2011 (see:http://www.ithealthboard.health.nz/content/health-information-exchange-architecture-building-blocks) with predominantly enthusiasm of David Hay to get the clinical information requirements right. Since FHIR came into existence unfortunately NZ has taken a clear approach that FHIR is all that is needed - including the new national EHR project. I'm pretty upset about this situation and I hope this discussion will provide a more balanced and fair view on things. I sincerely think FHIR is one of the best innovations in health IT and it is a brilliant standard for health information exchange but it is definitely a good stretch if it positions itself as the sole formalism to solve all interoperability (especially using Grahame's definition of intraoperability) - it certainly cannot at the moment.
Grahame Grieve (Mar 24 2016 at 23:24):
We don't think it's the sole way to do everything, we just try to work with people to make what they want to do possible. We've not often said no, but we can. We do tell people what FHIR is good at and what it's not. And on that line, we never intended to be a modelling formalism.
Grahame Grieve (Mar 24 2016 at 23:28):
However there's a cross roads coming for openehr: if it wants to be part of the picture that's been enumerated above: FHIR for the exchange, openehr for the modelling / requreirments, then the openehr community has to deal with the fact that FHIR is not just an exchange technology: we have always made explicit agreements about the semantics in the content. We're not going to stop doing that. And if the openehr community continues to position that as a 'problem' - which is the message I'm hearing from some key players - then that combination is not going to work. If, on the other hand, the openehr community was to embrace that - that there is worldwide agreement about content and infrastructure around those agreements, and to work within that constraint - then the combination could work really well. But I'm not blind to the impact to openehr for doing that.
Erik Sundvall (Mar 25 2016 at 05:45):
What I have been somewhat puzzled by is what FHIR strives to be, and I guess part of my confusion comes from that the scope of FHIR probably has changed along the way (and seems to keep growing).
First I percieved FHIR as striving for a software-developer-friendly "one-level model" using a limited number of Resources based on what you can find as common denominator in already implemented systems. @Ewout Kramer in April 2014 http://www.slideshare.net/ewoutkramer/fhir-more-than-the-basics said that you had done 40 of expected 100 resources and then in November 2014 http://www.slideshare.net/ewoutkramer/e-hin2014-fhir-ek that you were at 60 of expected 120 Resources. Where are you now in completed vs expected # of Resources? Any ideas about future growth rate?
When the number of FHIR resources grows the (clever?) system designers might start wondering if a multilevel-approach with a model (like CIMI/openEHR/13606 RM) containing a more limited number generic building blocks (plus a way to configure them like the CIMI/openEHR/13606 AM) would be easier to implement inside systems than doing and maintaining a great multitude of manual mappings.
If FHIR is aiming to stabilize around a basic set of Resources (<150?) and then growing and changing fairly slowly, then systems using openEHR internally can do their best to do manual mappings just as they do now to formalisms like HL7 V2 and CDA mesages. A good thing is that such mappings can be shared between openEHR systems and don't need to be reinvented for each vendor, I Think sets of templates and transforms corresponding to sets of FHIR Resources will be done and shared.
If on the other hand FHIR is actually in the long run aiming to capture all (or most) things that are interesting in the clinical input/documentation end as FHIR-resources and wants to build a clinical modeling/reviewing community like the one openEHR has, then perhaps the wheel is getting reinvented using a methodology that suits technicians more than clinicians. Exchange models rather than documentation models.
Grahame Grieve (Mar 25 2016 at 05:55):
From the beginning, we said 100-150 resources as a guideline to the level of abstraction we were targeting. There's never been an actually number, since we rescope between resources as we go based on learned experience, and contention between communities as to who wants to exchange what.
Grahame Grieve (Mar 25 2016 at 05:57):
from the beginning, we'd also recognised that there is a tension between useability and reusaeability. If we design specific tight models, very use case focused, then there will,be hundreds or thousands of models, and different but closely related use cases will have incompatible content models. We learnt from v3 that it doesn't matter how consistent your design framework and layering is, people can't deal with that
Grahame Grieve (Mar 25 2016 at 05:59):
so we design a set of base concrete models that are reusable across multiple use cases, and a 'conformance' layer for taking the base framework, and saying additional things about how it's used. Voila, 2-level modelling - it's been part of FHIR from day 1
Erik Sundvall (Mar 25 2016 at 06:00):
When you say you can't do anything about the hype, is that really completely true? In a "USA-influenced" context you'd might not bother fitting FHIR into an openEHR context, the main documentation modeling has perhaps already been decided to be a EHR-vendor concern.
On the other hand there are countries where there is clinical modeling going on using openEHR and where vendors are starting to use openEHR inside their systems. In such contexts/countries it might be responsible behaviour during FHIR presentations to actively moderate some of the hype. For example hype leading to things like Koray describe above (FHIR will solve Everything - lets's quit the achetyping efforts).
Grahame Grieve (Mar 25 2016 at 06:01):
From the beginning, our focus with this regard has been defining interoperable formats, so that we can build an open community, rather than just defining a closed tooling chain. But this hasn't yet been entirely successful. We'd love to have openehr decide to use it
Grahame Grieve (Mar 25 2016 at 06:01):
its community and ecosystem and tooling and knowledge to produce FHIR 2nd level models. That would be great. And perhaps what Ian is going to tell us about.
Grahame Grieve (Mar 25 2016 at 06:02):
I've never said FHIR will solve everything, and I hope none of the core team have either. Others have, and they've not listened when I ask them for moderation. Because it's political to them
Grahame Grieve (Mar 25 2016 at 06:05):
But those other countries might want to think about their standards pathway, and consider what their choices should be. It's not just people on FHIR side who need to temper their language
Erik Sundvall (Mar 25 2016 at 06:06):
So perhaps some of us in the core FHIR and openEHR teams can try to make some pedagogical slides about what the technical and political consequenses of approaches are and what gets simplified/complicated by different choices?
Erik Sundvall (Mar 25 2016 at 06:25):
Regarding standars pathways and politics I think there is a great clue in your post http://www.healthintersections.com.au/?p=820 "The business model for intraoperability rarely works out, because it’s standards writ large – a big price for a big payoff, but who’s going to be paying the price? (as usual, not the ones who benefit)"
Depending on contexts such as healthcare financial systems, vendor business models, political views and time-perspectives the big payoff might be a very logical goal to strive actively for. In some cases it is actually the same entity paying and getting the benefit from intraoperability, reuse and shared modeling workload. (I Think Sweden is such a case, at least if you mentally zoom out to see the big picture.)
In many other contexts the more usual/logical way of sharing costs and workload is through paying for (and contributing to) and thus reusing an EHR-vendor's proprietary internal clinical modeling. And then FHIR is a great way of getting some useful standardized viewports into those proprietary models.
Erik Sundvall (Mar 25 2016 at 06:41):
Politically I guess it has something to do with what balance between competition and cooperation you believe is the best (fastest? cheapest? most efficient?) way to reach (near-time? sustainable?) progress...
Grahame Grieve (Mar 25 2016 at 07:38):
Cause countries can do it by themselves in their own border? I think that the problems of countries making their own decisions will become increasingly obvious in the next few years
Erik Sundvall (Mar 25 2016 at 07:52):
Do what? Not sure what you mean.
Deciding on Health policy, like public funding etc.? YES, that can (almost) be done within borders.
Develop and maintain enough clinically relevant up-to-date data models and CDS rules? NO that can not be done nationally by a small country at least. And not by a small EHR-vendor without collaborating in a larger open modelling-community.
But why are you asking in this context? Deciding to get nationally engaged in openEHR modelling is an international approach, and so is deciding to use FHIR.
Please help me understand what you are saying or asking about.
Grahame Grieve (Mar 25 2016 at 09:27):
My impression is that countries are using openehr as a framework, but making their own clinical models, and demanding that systems in the country adopt their on local agreements. That's what I'm seeing. And even if countries are collaborating, it seems obvious to me now that openehr will not be becoming an internationally recognised standard.
Grahame Grieve (Mar 25 2016 at 09:30):
So it's not an international approach in the same sense
René Spronk (Mar 25 2016 at 09:42):
Intraoperability is a lofty goal to achieve, but if achievable at all it will be either small-scale, or require some "top down enforcement" by government. Intraoperability at the international level sounds as achievable as world peace, I'm afraid. But we do (also) need solid clinical requirements models for interoperability, hence the use of CKM by projects desiring to capture such interoperability requirements. By nature OpenEHR is focused on intraoperability, whereas most projects may be looking into it from an interoperability perspective. CIMI may be able to bridge some of this.
Erik Sundvall (Mar 25 2016 at 09:44):
Ok, now I understand your views a bit better Grahame. Thanks! I agree with somo of the things, not others. Countries like Australia did things the (bad) national way, Norway does it the (good) international way.
Grahame Grieve (Mar 25 2016 at 09:48):
Well, like Rene says, there's no magic bullet, and FHIR is not one either. But countries and people have to be realistic that whatever approach they take is a less than perfect compromise. Some,ahh, aren't doing that
Grahame Grieve (Mar 25 2016 at 09:49):
but I do think that in spite of the fact we don't have any other alternative, the extremely nationalistic policy everyone is pursuing (higher levels than FHIR) will turn out to be increasingly problematic
Erik Sundvall (Mar 25 2016 at 10:24):
Actually what I have observed is that when there are big (or many) enough vendors that together with customers (healthcare regions etc) see business value in intraoperability and see value in international cooperation and workload sharing/splitting then the openEHR/intraoperability approach actually works and clinicians have reason to get (and stay) engaged.
That is why it works in Norway where the dominant EHR vendor DIPS and three of the four hospital regions have been clever enough to see that the modelling coordination is better done by a vendor-neutral party. The Norwegian government has not really gotten into archetyping etc. (yet), but seem to accept it’s existence.
Ian McNicoll (Mar 25 2016 at 10:33):
One of the interesting things to emerge is that where vendors are given readily usable ways to build reusable/sharable artefacts, (as we now have with openEHR and FHIR), they will do so, and it is in fact the 'standards bodies', particularly at national level, who largely still attempt to do their own thing. To some extent that is wholly understandable- standards policies are set in stone, there is some risk aversion to change, existing and well-embedded standards will force legacy approaches etc etc.
So I see this as a phase, where the business drivers for vendors/implementers to adopt common components are stronger than those at national level.
Erik Sundvall (Mar 25 2016 at 10:34):
In countries where a governmentally controlled body have adopted openEHR for some kind of top-down approach you often see some flavor of nationalistic/protectionistic archetype modeling effort without understanding the need for international collaboration/sharing. (I wonder if bigger budget and more resources available implies lower understanding for the point of sharing.) I think both GB and AU have seen things like that.
EDIT - See Ian's comment at 12:18 below. My guess within the double parenthesis here was wrong: ((If the company selling the national CKMs makes money per instance of CKM and has national governmental organizations as main customers they might not see the point in putting great efforts into convincing narrow-minded national projects to be more international. Especially at times when there was no international funding for doing editorial archetyping work.)) National projects can obviously miss seeing the point of an internationally shared workload even when it is repeatedly pointed out both by their toolproviders and others - END OF EDIT
I discussed this and related issues in sections 4.3 and 4.4 of my PhD thesis, see http://liu.diva-portal.org/smash/get/diva2:599752/FULLTEXT03.pdf (Scalability and Semantic Sustainability in Electronic Health Record Systems). Not sharing archetyping internationally creates technical debt and other bad things (Perhaps incompatible national V3 profiling did the same?)
Grahame Grieve (Mar 25 2016 at 10:39):
Yes, that was on of the fails of v3. But as we see from this discussion, this particular fail is easy to reproduce
Erik Sundvall (Mar 25 2016 at 10:42):
In Sweden some years ago, we also saw a top-down project where openEHR was abused for disseminating a new untested Swedish healthcare management/process model through home-made archetypes (incompatible with international ones) rather than focusing on detailed real clinical needs. That was a failure (no surprise) that gave archetypes and openEHR a bad name here.
Also there was a national Project that kind of used 13606 for transfer of a fairly fixed scope and limited number of different data Points. But that project mostly the RM without using the power of archetypes/templates - using a home-made XML-schema for the limited number of different datapoints would probably have been easier than half-way using a multilevel model there.
Now the Swedish situation is different when several regions (and at least one big EHR vendor) want to share the workload of clinical modeling that is used for data entry forms in (currently mostly proprietary) EHR templating/configuration mechanisms. But we are years behind Norway. We’d also like to share queries and decision rules in the long run. This is the situation where I want to avoid an unrealistic FHIR-hype killing the efforts of joining the Norwegian vendor-neutral way for modelling EHR input.
Grahame Grieve (Mar 25 2016 at 10:48):
Well, in a general sense, this is the Gartner hype curve at work. There will be hype, there will be a trough of despair. Our job is to make the trough as shallow as possible
Ian McNicoll (Mar 25 2016 at 10:50):
@Grahame Grieve I don't see this as a #fail actually, either in the past or now. I think it is just a phase we have to recognise as being inevitable and probably necessary. Possibly the #fail is to raise the level of expectation too high that we can avoid 'national' wheel re-inventing, at least for some time. Accept it as inevitable, put in place the methodologies and technologies to make it easy for people to do theright thing, (including 'fail fast') and wait for the market to gradually enforce a more global perspective.
Ian McNicoll (Mar 25 2016 at 11:00):
@René Spronk ". Intraoperability at the international level sounds as achievable as world peace, I'm afraid. " I agree, but that does not mean that we can't derive huge, potential benefit from building a set of resources that at least one section of the vendor community are able to develop and use in common, and therefore build additional value on top of that e.g common integrations, SMART-on-FHIR layer. Global intraoperability is neither possible nor desirable but if I am a startup SME, I can potentially compete much faster if I build my killer app on top of of a set of pre-existing services and components, without vendor lock-in. Interoperability is almost a side-effect and not, IMO, the key factor here. As an implementer I will always have to juggle the competing demands of shaping my data to fit local, national and international requirements. The more global I go, the less work I have to do and the bigger market I can potentially meet, but, of course I ultimately have to meet my direct customer needs by building /using a very local archetype e.g for allergies, then so be it.
Ian McNicoll (Mar 25 2016 at 11:18):
@Erik Sundvall "(If the company selling the national CKMs makes money per instance of CKM and has national governmental organizations as main customers they might not see the point in putting great efforts into convincing narrow-minded national projects to be more international."
Hi Erik . Having been involved in that work (but no longer) , I must strongly reject that assertion. The CKM tooling and the licensing model actively promotes the use of international content (the latter not being counted in licensing terms). There are many drivers which prevent national bodies interacting on a more global basis, but the interests of the tooling provider is not one of them (in fact quite the contrary in my experience, both as an insider and outsider). Please reconsider your statement which, in my view, and direct experience, is wholly without substance, deeply unfair and unhelpful.
Thomas Beale (Mar 25 2016 at 13:47):
I realise I am currently unclear on what FHIR's scope actually is. So far it seemed as if it was to create a REST-based service interface to EMR and similar data. If it is more than that, does anyone have an architectural vision / scope statement to point to? I think it would be helpful to clarify.
Lloyd McKenzie (Mar 25 2016 at 15:29):
@Thomas Beale There are two aspects to scope. One is "what parts of healthcare does it cover", the second is "what level of granularity does it cover it at". The first answer is "everything" - human/veterinary, clinical/administrative/financial/research, inpatient/outpatient/community/public health, traditional medicine/"western" medicine, psychology/social services/physiotherapy/homeopathy/accupuncture/you name it, across every country in the world. (That doesn't mean that all of these are appropriately covered yet, but it does mean that when needs are identified from those communities, FHIR won't say "no, that's out of scope". And we're relatively confident we can cover those spaces with the 100-150 resources we've estimated. In terms of "level of granularity", core FHIR scope is pretty large-grained - as it must be in order to cover that scope with that limited number of models. The granularity is also heavily influenced by what differentiation systems typically make. That doesn't mean that HL7 won't develop implementation guides that are more targeted and have finer granularity, but that will be developed using the conformance mechanism - the second level of modeling, not as part of the core spec. And HL7-developed implementation guides are only a small part of the ecosystem that will exist.
Lloyd McKenzie (Mar 25 2016 at 15:31):
Note that FHIR is not REST-specific. FHIR also supports documents, messaging and services interoperability paradigms. Much of the initial focus is on REST, both because REST imposes constraints the other models don't (meaning the resource designs need to focus on being REST-friendly) and also because REST is new/cool, at least to the healthcare community. It certainly is intended to extend well beyond EMRs, though that's where much of the energy/funding is right now.
Thomas Beale (Mar 25 2016 at 16:02):
@Lloyd McKenzie a) content scope - that's fine, but to work it is likely to require an information modelling approach that takes into account the semantics of all these domains, i.e. what we would think of as 'reference model'. I'm not sure the 150 resources could do this unless they are made so general as to be open?
b) Are we still talking essentially about data retrieval? Because if we are not, the whole equation changes - then a model of data commit is needed that reflects many needs: source context, version control, auditing, some knowledge of business event (episode, encounter etc) - i.e. a comprehensive base model for EHR/CDR persistence. Is FHIR trying to do this as well?
c) there seems heavy reliance on profiling to achieve what we know to be probably 300x the number of actual content models in healthcare (i.e. O(50k). I am still somewhat surprised FHIR doesn't use the archetype formalism to achieve this, because without it, it has to invent a complete equivalent. Grahame tells me that it has, and that it is stronger in a number of ways than archetyping, which would be interesting to learn about, but I am having trouble locating a formal specification to review (I have seen the descriptions of course).
d) w.r.t. documents etc - are they passed as opaque content?
Lloyd McKenzie (Mar 25 2016 at 16:48):
@Thomas Beale Well, they are fairly generic. For example, Observation covers lab values, vital signs, psychological scores and a few other things. Encounter covers home visits, long-term institutional care, patient phone consultations, etc. The resources define the core elements broadly supported across scope with the ability to extend for narrow circumstances.
Lloyd McKenzie (Mar 25 2016 at 16:50):
We're talking about data exchange - which may be push, pull or a variety of other mechanisms. FHIR supports tracking provenance and audit information and expects that that will occur in most situations. FHIR also provides for "technical" version management - every time a resource changes, it gets a new version id that is addressable by a unique URL
Lloyd McKenzie (Mar 25 2016 at 16:51):
To see the formal description, look at the following: http://www.hl7.org/fhir/profiling.html, http://www.hl7.org/fhir/structuredefinition.html and perhaps http://www.hl7.org/fhir/valueset.html
Lloyd McKenzie (Mar 25 2016 at 16:54):
FHIR documents and FHIR messages are passed using a "collector" resource called Bundle that in turn contains other resources. For documents, there's an initial resource called Composition that sort of acts like the CDA header and defines the table of contents. Then you send other resources to convey the content associated with the different sections of the document. There are formal rules for how the documents are expected to be rendered when authenticating or displaying to a consumer. Blood pressure would look the same inside a document as it does inside a message or when passed as part of a service or accessed using REST.
Lloyd McKenzie (Mar 25 2016 at 16:54):
You can see more about documents here: http://www.hl7.org/fhir/documents.html
Lloyd McKenzie (Mar 25 2016 at 16:58):
Agree that there will be tens or hundreds of thousands of detailed models/profiles that get built on top of FHIR - for a wide variety of purposes - to document what specific systems actually do or what procurers want a system to do; to describe regional or specialty profiles - e.g. "How do we do allergies in Canada - vocabulary bindings, minimum expectations, etc.", as well as detailed-clinical-model use-cases (and the variations on those from jurisdiction to jurisdiction or discipline to discipline where universal agreement on terminologies and other requirements can't be reached).
Thomas Beale (Mar 25 2016 at 17:22):
@Lloyd McKenzie I have some reading to do, but just on 'data exchange - push, pull, ....' - 'push' sounds like B2B comms, i.e. some sort of automatic update within a pub/sub framework. Is that correct?
Lloyd McKenzie (Mar 25 2016 at 17:24):
There's a variety of B2B architectures supported. It could be a messaging approach like v2 or v3-messaging. It could be publish-subscribe. It could just be posting data to a server endpoint.
Grahame Grieve (Mar 25 2016 at 18:22):
"And we're relatively confident we can cover those spaces with the 100-150 resources we've estimated" - I'm not. Every domain we've worked into Implemetation has created more resources than we estimated.
Lloyd McKenzie (Mar 25 2016 at 19:04):
Perhaps. But we had allowed for some of that. And in terms of the domains we know we still need to bring in - clinical trials & public health, they won't add that many. We're currently in the 90 range and have covered pretty much everything in the clinical domain. And as we experiment, resources are as likely to disappear as they are to get added. Certainly it won't be significantly higher than 150. We're not looking at 500 or even 300 resources. And most typical clinical systems will be able to get by with <100 regardless of how many we end up with.
Erik Sundvall (Mar 25 2016 at 21:37):
Tom you might want to read some posts
Erik Sundvall (Mar 25 2016 at 21:39):
...in the clinFHIR thread regarding that proposal.
Erik Sundvall (Mar 27 2016 at 12:29):
Many of the issues with converting from models based on generic RMs (like openEHR) to FHIR are also applicable to CIMI. How many of you in the core FHIR team "believe" in the CIMI approach? Is there any tension between the FHIR and CIMI approaches? Are there any clear well specified ways of going from CIMI archetypes to FHIR resources or is that just a dream so far?
Erik Sundvall (Mar 29 2016 at 20:52):
Regarding the FHIR hype (and decisionmakers missing important things), I think that presenting the intERoperability and intRAoperability approaches is very important when talking about FHIR and the Healthcare context. Both from FHIR and openEHR sides I think we could become better at recognizing that the other part is actally doing good work seen from the FHIR-intERoperability goal perspective and the openEHR-intRAoperability goal perspective. What is 1:st or 2:nd class models depends on perspective, I Think both sides can accept that.
Erik Sundvall (Mar 29 2016 at 21:15):
One of the things I and several of my colleagues in Swedish healthcare providers/regions want is to reduce the amount of mappings and remodelings needed every time clinicians have decided what they want to change or add models (because every extra manual intervention takes time, like convincing vendors to adjust models or to get competent mappers to do mappings). Mapping-exercises and other manual intervensions slow down the clinical improvment cycle. Thus I prefer to aim at as much intRAoperability as possible with the organizations we communicate with. And since we don't want to (continue to) enforce usage of the same vendor EHR product on the parties we are communicating most with, then open intRAoperability standards, especially with strong clinical involvment possibilities, like openEHR are very interesting.
Also, the clinical community and practice often move faster than vendors so it is not obvious to me that filtering reqirements through the vendors (to reach some 80% implementation level) is the most efficient way of improving care, if there are alternatives where clinicians are more in control.
FHIR solves many of today's problems better/easier than some previous HL7-approaches (and probably at least as good as some Swedish homegrown ones) so I welcome FHIR to the Swedish context, but please, please, please don't make it sound like FHIR is solving current and tomorrows intRAoperability needs in an efficient way. Let's find a good way for talking about FHIR and openEHR coexistence and complementary strengths.
Erik Sundvall (Mar 29 2016 at 21:20):
Some national projects/actors are mostly interested in getting some fast agreement on the particular data they need exchanged in that scope and thus naturally mostly care about intERoperability. The mapping costs are externalized to us, the healthcare providers. National projects can say that they have "finished their work" and now the (slow) regions just "need to do their homework"... Sometimes the "homework" is just time consuming and sometimes it is not algorithmically solvable without changing clinical input models in the EHR. So why not work with aligning/modeling the clinical input end to begin with?
If you are a mapping consultant (as many HL7 core people are) then mappings are not a problem, they are rather a source of revenue. Also working from the exchange-end might feel more natural and important than working from the clinical input end.
If on the other hand you are in my situation, you start worrying about the future scalabilty of working with many FHIR extensions/profiling and associated mappings when clinicians, national projects and others want to exchange more and more (or new versions of) different datasets or decison support rules.
Lloyd McKenzie (Mar 29 2016 at 22:47):
@Erik Sundvall The FHIR core spec's objective isn't (directly) to improve care. It's to enable the sharing of data as easily and cheaply as possible. That indirectly improves care. It also makes it relatively straightforward to add additional layers that can define best practices. But best practices are of no value unless the implementer community decides to roll them out. (HL7 has produced a lot of specifications that (our) clinicians thought were great but that the implementer community ignored - because they were too complicated, or (their) clinicians didn't agree or various other reasons. Implementers need to have buy-in before any interoperability occurs - and endorsement by a clinical body is only a part of of that buy-in process.
FHIR is a set of tools. We're trying to design it to be able to solve both today's and tomorrow's problems - the extensibility makes it easy for implementers to move forward independently. However, how well it will work for a particular problem space will vary. We continue to make adjustments, but there will almost certainly be places where other approaches may work better because FHIR is targeted at a broad scope. Narrow targeted solutions for narrow spaces may work better. And, of course, sometimes we'll get it wrong.
Believe me, none of the FHIR core team has an interest in driving a business as mapping consultants. Mapping is painful, but it's also largely unavoidable. We can't drive the internal behavior of systems. And even if we could, it would get locked in to specific behavior at a given time while the interoperability space would continue to evolve. Mapping is unavoidable whenever you want interoperability across a diverse community of implementations - which is what we're trying to do with FHIR.
Ewout Kramer (Mar 31 2016 at 12:14):
Hi all, sorry, had lots of catching up to do after my easter holidays. I do fully agree with Ian's previous statement (which confirms Rene's statement). From this discussion I'd like to summarize three points that find accord with me:
- Ian's previous point: there's no thing like intraoperability at the international level - and it is not necessary either. You'll get standardization across verticals/groups/communities, but inter-community exchange will remain firmly in the domain of *inter*operability
- "We learnt from v3 that it doesn't matter how consistent your design framework and layering is, people can't deal with that". The reason for this being: "The business model for intraoperability rarely works out, because it’s standards writ large – a big price for a big payoff, but who’s going to be paying the price? (as usual, not the ones who benefit)"
- Finally, I think most top-down approaches will fail, since this will lead to a few (nationalized) pilot projects, a tendency to be too little too late for all the developers that have interoperability needs, but whos needs are outside the current focus of the national standardization body. No matter how agile a national body would be - it would not be wise to spend effort and money on everything - hence "bottom-up" standardization is something that will happen - regardless of technology. Well, v3 made bottum-up so hard no one did it, but that's hardly exemplary.
Ewout Kramer (Mar 31 2016 at 12:15):
I don't mind at all spending a few slides on these comments during my presentation - in fact I already planned doing some of this. It's got nothing to do with technology - it's a reality I wish people understand, and also understand FHIR won't be fixing this.
Erik Sundvall (Mar 31 2016 at 13:03):
Great to see you online Ewout! Your first bullet point above might use some rephrasing, intraoperability can be very international if the community is. Some communities are international (e.g. the non-siloed internationally synced part of the openEHR comunity). But getting inter-community exchange and international at the same time, I agree will be less likely. (This applies also to non-open approaches - as an example the "community" of EPIC customers likely could have some degre of international intraoperability if they want to.)
Ewout Kramer (Mar 31 2016 at 13:07):
So, Erik will you be doing presentations during Vitalis too?
Erik Sundvall (Mar 31 2016 at 13:38):
@Ewout Kramer I'll present at the co-located http://www.shi2016.org/program.html but plan to be in the audience for most of the FHIR-related Vitalis sessions. If you would need any assistance e.g. during parts of Q&A or discussions I am available.
Thomas Beale (Apr 02 2016 at 15:49):
One question here: why the focus on 'top-down'? It's orthogonal to the standards themselves. FHIR can be mandated by some country's MOH, that's top-down, but not because HL7 said so. In some other country, FHIR might be adopted in a grass roots fashion by small vendors. SAme is true of openEHR or most other standards. One thing openEHR does is allow the customer side to determine the content, it's not by and large an openEHR activity.
Last updated: Apr 12 2022 at 19:14 UTC
