Stream: ihe
Topic: Reflecting FHIR FMM in IHE Profiles
John Moehrke (Apr 27 2017 at 17:05):
I provide a proposal for how IHE Profiles can be transparent about the FHIR FMM levels of the Resources the Profile is based on. See https://healthcaresecprivacy.blogspot.com/2017/04/reflecting-fhir-fmm-in-ihe-profiles.html
Jens Villadsen (Apr 28 2017 at 09:14):
Sounds sane ... but what value does it actually provide? I see it like this (and am practicing it like this): When developing an IHE integration for one's system, the design of that component will isolate that specific component to support that specific IHE transaction and only that. The component supports only what is stated in the profile, regardless of whether its a draft standard or its crystalized - it does not matter - my funky whatever-system is going to use whatever version of whatever standard internally as I see fit. It shouldn't be the case that concepts or standards used in integrations have great implications on the interior of the systems - it should only be minimal. What I'm trying to say is that whatever the FMM level the resources have in the stated IHE profile, it really should not matter much.
John Moehrke (Apr 28 2017 at 11:18):
@Jens Villadsen we have experienced a year or two with IHE Profiles on FHIR; and there is a need for this transparency. Your perspective is common among those that understand the FHIR FMM; the audience this new proposal is speaking to is those with no understanding of STU vs Normative. It is them that we want to help understand a very mature IHE Profile like PDQm, as mature because of the fact it is all based on FMM 5 resources. Contrast that with MHD, which is a very XDS focused Profile, where the reader might think that it is very mature, but recognize that it has a broad range of Resources contained including the List Resource (used for Folders) which is FMM 1.
John Moehrke (Apr 28 2017 at 11:20):
So the IHE "Trial Implementation" status doesn't reflect how close to "Final Text" the profile is. Those that are close, should be given a bit more credibility. Those that are based on very immature underlying standards should be used only for experimentation, pilots, and pivots.
Jens Villadsen (Apr 28 2017 at 11:40):
I've attended 4 IHE connectathons (2 as monitor, 2 as vendor) having used or audited FHIR profiles 3 times. My view is this: IHE creates 'solution profiles' on top of existing standards (be that draft standards or not). If IHE were to e.g. finalize a PDQm profile using FHIR DSTU2 with resources FMM Level 0, then so be it, regardless of whatever FHIR/whatever-standard release is the most recent. The point is that whatever profiles IHE makes, the profile freezes all transitive referenced standards in time to a certain moment. That moment will not forever stay current (actually, that moment is outdated the very next second). That's what happens when it says "Final Text". Now here's a suggestion: Stop calling it final text, but call it version-x. That at least opens it up so that you have an opportunity to come back to a standard and perhaps update some of the transitive dependent standards.
John Moehrke (Apr 28 2017 at 12:36):
IHE has governance and is an recognized standard; as such the governance requires that the underlying standards upon which they profile must be normative before the IHE profile can go normative. Many profiles have been kept in Trial Implementation simply because of this fact.
John Moehrke (Apr 28 2017 at 12:52):
what you say about freezing the underlying standard is indeed true, and sometimes it must freeze in a broken version that it fixes with IHE constraints. But that is not the original intent, it is a fact of reality... FHIR STU is a known and managed period. We know FHIR is STU, we know that means immaturity. But the FMM also exposes just how immature, or how close to maturity. It seems useful to expose that to the reader.
Jens Villadsen (Apr 28 2017 at 13:45):
Sure ... Go with FMM statement on the cover. I just can't see it adds any value to the reader (it might do so to others). The resources and the way they are used is stated inside the profile - hence it has no impact whether they are considered mature or not.
Grahame Grieve (May 01 2017 at 00:34):
don't the IHE profiles themselves have a maturity level?
Jens Villadsen (May 01 2017 at 07:33):
Trial and Final (would be my response)?
Grahame Grieve (May 01 2017 at 07:37):
I think you'll find that there's more than that - that there's things that are trial that are really really trial, and things that are only just trial now
Jens Villadsen (May 01 2017 at 08:29):
That reminds of a former boss who defined the term "done-done"
Jens Villadsen (May 01 2017 at 08:29):
which no one liked
Jens Villadsen (May 01 2017 at 08:29):
but it illustrated the problem of people stating that stuff was done ... well almost done
Jens Villadsen (May 01 2017 at 08:30):
so there is no trial trial ... there might be draft, trial, and final
Jens Villadsen (May 01 2017 at 08:30):
and if that is not sufficient, then add more states
Grahame Grieve (May 01 2017 at 08:49):
I think IHE may have less maturity levels than HL7, but I still think that being semi-formal about the maturity level will be useful
Jens Villadsen (May 01 2017 at 08:53):
It might to some ... but being conformant to an IHE profile means that you support whatever is beneath - meaning that underlying standards in principle can be done or not-so-done.
John Moehrke (May 01 2017 at 11:58):
IHE has the same gross levels as HL7. There is the stuff only being worked on by the committee, there is the version sent out for "Public Comment", there is the version that has resolved public comment sufficiently to be "Trial Implementation", and finally when that meets a set of maturity criteria "Final Text". (HL7 draft, ballot, DSTU/STU, Normative). Adding the FMM to FHIR is a good idea, I just reflected that into the IHE Profile as a subtext to the "Trial Implementation" statement. Might be more clear to see pictures on my blog article https://healthcaresecprivacy.blogspot.com/2017/04/reflecting-fhir-fmm-in-ihe-profiles.html
Last updated: Apr 12 2022 at 19:14 UTC
