Stream: openehr
Topic: Building some shared slides
Erik Sundvall (Mar 30 2016 at 20:55):
Ok @René Spronk, @Ewout Kramer and all. See attached presentation. I reduced text-density on first slide(s) and followed René's idea to add one slide discussing when to use what. I also split the slide set into two parts...
First part: for buzzword-level "lay audience" (useful e.g. for Vitalis morning intro)
Second part: for people familiar with interoperability issues (useful e.g. for Vitalis afternoon workshop)
It would be wonderful if at least the core FHIR team (and other interested) could review this slide set (it's only 5 "real" slides). I'll then ask the rest of the openEHR specification editorial comittee to review it too.
fhir-openehr-v03.pptx
Erik Sundvall (Mar 30 2016 at 21:02):
The possibly most controversial slide in the file in my last post (because it's an unrewiewed first attempt and includes suggestions on when to use what) is #4. I also attach it as separate image here for those that don't want to fire up a pptx-compatible viewer...
Comment that one if you don't have time for all.
slide5-draft-when-to-use.png
Erik Sundvall (Mar 30 2016 at 21:06):
Spotted a typo already: varation -> variation ...
Lloyd McKenzie (Mar 30 2016 at 22:57):
It might not get a review until tomorrow or Friday. We've been in the build up to a release for the upcoming WGM and connectathon, so a few people (including Grahame) need a chance to catch up with this thread.
Grahame Grieve (Mar 31 2016 at 05:55):
well, here I am. I just read the entire thread since I fell off due to flat battery (easter in Australian bush) and getting the frozen version published. And next week I'll be in Samoa surfing, and not on line much
Grahame Grieve (Mar 31 2016 at 06:24):
Erik, looking at your slides, I'll comment on the first: I think CIMI is not on the interoperbility/intraoperability continuum in any categorizable way. and I think 13606 is hard to categorise since it didn't define archetypes itself. And I want to mention again, that interoperability vs intraoperability is not a bianry disjunction -it's a continuum, and as pointed out elsewhere
, both FHIR and openEHR are variable in this regard
Erik Sundvall (Mar 31 2016 at 07:09):
Good points about the slides @Grahame Grieve, I'll try to incorporate the feedback. CIMI and 13606 are a bit all over the continuum. (There is actually some archetyping done using both 13606 and CIMI, but it is not very visible globally.)
Ewout Kramer (Mar 31 2016 at 13:05):
@Erik Sundvall, I think one of the points Grahame made about interoperability and intraoperability is that it moves the costs: "but who’s going to be paying the price? (as usual, not the ones who benefit)" And this is an important part: depending on how important intraoperability is for a given usecase or community, more or less money will be put into intraoperability. And this mostly means government-led projects will focus on intraoperability (and receive pushback from vendors), while most decentralized - smaller community projects will "just do what works for them". As a result, any succesful standard - used across this whole spectrum - will cause heaps of isolated, non-interoperable islands of data.
Erik Sundvall (Mar 31 2016 at 13:13):
Here is an updated slide-content suggestion draft wher I tried to incorporate feedback from @Grahame Grieve
fhir-openehr-v04.pptx
@Ewout Kramer Great that you'll be covering this in your talk(s) that will make FHIR land in a better context in Sweden. Uneducated hype will only cause unneccesary dissapointments.
I hope you can use the slide suggestions in some form. If you want feedback on your edits, reformatting, reformulations etc then, feel free to post something here. In this way you can claim to say things that even openEHR-nerds don't object to...
Erik Sundvall (Mar 31 2016 at 13:24):
Regarding paying the price, we don't mind sending our clinicains also into the international openEHR discussion and archetyping effort to wrestle with their opinions and thoughts against peers online internationally (and nationally when we get that set up in Sweden).
The alternative is (today's) regional mind-wrestling with opinions from colleagues at nearby hospitals. The international openEHR discussions are often more medical-informatics-educated and clinically wide-minded than the local discussions. Then at a local template level we can cater for the local process/documentation adjustments without creating semantic caos in the stored data.
Erik Sundvall (Mar 31 2016 at 13:30):
I know representatives from the leading Norwegian EHR provider (DIPS) have said something like that it is very nice to have a constructive place (the Norwegian archetyping effort) to point concerned/complaining clinicians to. (Instead of piling up and trying to align angry (often mutually incompatible) little modification requests from clinicians. )
Being able to do this of course requires the archetyping effort to be open and focused on serving the needs of clinicians (which is not always the case for some governmental top-down approaches focused on their own needs and priorities).
Grahame Grieve (Mar 31 2016 at 19:50):
@Erik Sundvall - the slides again. it's not true that interoperability is constrained to the lowest common denominator; it's more true to say that it naturally gravitates to that
Grahame Grieve (Mar 31 2016 at 19:51):
and, btw, the ecis definition of intraoperability is not unrelated to my definition
Grahame Grieve (Mar 31 2016 at 19:53):
and I think, after a few years of experience since i wrote that blog post, that I would specifically call out the role of legacy data in forcing your hand when choosing between the two.
Grahame Grieve (Mar 31 2016 at 19:53):
if I wrote the blog post again
Erik Sundvall (Apr 03 2016 at 17:20):
The "role of legacy data in forcing your hand" that @Grahame Grieve mentions is a very interesting angle to discuss when looking at the different approaches. One extreme on a possible scale is to let that legacy force - be your main guiding light. There are several problems associated with this extreme (including slowing down clinical agility/progress). Thankfully FHIR is not at the 100% legacy extreme end of the scale, the systems with slowest change won’t dictate the speed of FHIR content change. The 80%/20%-FHIR-inclusion window (plus some filtering of which systems are considered worth looking at) likely speeds up change.
Another extreme on the scale is to let the ever changing clinical needs (and the process you have for capturing them) be the thing “forcing your hand”. That kind of force would be very demanding for system providers if done in a, for them, uncontrolled way. Thankfully openEHR considers both kinds of forces and has many mechanisms for making life (maintenance etc) easier for system providers when facing constant change.
Erik Sundvall (Apr 03 2016 at 17:26):
It could also be helpful to discuss things from a "breaking change"-perspective.
Every breaking change introduces pain for somebody with implemented systems and existing data, but if a clinical system wants to keep up with the constantly changing clinical reality, there will always be some breaking changes (even it they wouldn't communicate with other systems). Non-breaking changes can be handled reasonably fast by most system implementations, but the breaking ones forcing changes deep down in semantics or database schemas etc are usually a pain (and something that at least take some of our “classical” system providers long time to do).
What I find very interesting with openEHR is that it provides many mechanisms for making both non-breaking and breaking changes easier to handle for system providers (and for the customers, the healthcare providers). There are also mechanisms for handling legacy data import, storage (and human readability). Do you want some examples or are you all familiar with those mechanisms?
Erik Sundvall (Apr 03 2016 at 18:09):
I am not saying that the FHIR or the openEHR (or inter- vs intra-operability) approach is better than the other for everything, but that there is room for both and it would be good to align things that are of shared interest. It would be good if each community understood the strength of the other approach.
Last updated: Apr 12 2022 at 19:14 UTC
