Thanks Paul - cheers to all from Geneva
Thanks for sharing the maturity model
As described - I think it is good to think about subsequent stages of rollout and the support from OHIE and others it requires. Also allows OHIE to set goals for “how far” to take profile validation, and to plan ahead - if you commit to get to FMM3-4-whatever then it’s gonna take many rounds of committed funding… so OHIE understands the impact of dropping the ball halfway.
Unfortunately I think it covers half the spectrum. And it misses a huge opportunity for value that OHIE brings. The maturity model is great for scale-out and validation of a profile, but starts with:
- FMM0 = the resource or profile (artifact) has been published on the current build
Where did that profile come from? Is it relevant? A priority? is it fit for purpose? appropriate for LMICs?
We need to bring in the origins of a profile into the limelight.
My question - What comes BEFORE FMM0 that would ensure those attributes in the draft?
Say, for example: FMM minus-one, FMM minus-two…
This is where OHIE can help bring field interop needs to stage, and become a relevant shaper of interop embodying values of representing the field needs of low income countries
FMM-4: an integration need has been repeatedly identified in the field in action
FMM-3: a need assessment canvassing suggests the integration could be benefited by broad interoperability (e.g. it is recurrent, may involve many actors, substitution, industry support)
FMM-2: an prototype profile has been developed with review of parties of at least 2 real world integration instances
FMM-1: at least two integrations have been demonstrated in the field with the prototype profile
so now we are ready for…
FMM0: the resource or profile (artifact) has been published on the current build
if we start at FMM0, it is just a matter of throwing enough funding and hoopla to get anything to FMM5. It doesn’t guarantee relevance or fit or priority of the profile. Previous steps could be embodied in OHIE processes to amplify that.
Just my 2 cents - Feel free to relay to whoever may benefit from thinking about it.
~ ej
···
On Sep 16, 2015, at 5:44 AM, Paul Biondich pbiondic@regenstrief.org wrote:
Hi all,
I had as an action item to follow up with Grahame Grieve on MHD and “readiness” to use FHIR operationally. For those of you who might not know, Grahame has been involved with MHD since the profile’s inception, and the author team of MHD is pretty closely aligned with the core FHIR team.
I asked him directly about the “stability” of MHD given that it leverages an emerging spec. The specific answer was that it’s fairly far down the pathway towards normative.
But then he helped me understand that the FHIR strategy towards publication is fundamentally changing in a very good way (IMO).
Previously, the plan was for FHIR to go through 2 DSTU rounds, and then become a 1.0 normative standard.
Now they are seeing aspects of what’s being published as DSTU as the 1.0 release.
They are moving to a new model of describing the maturity of specific resources within FHIR using a five point maturity model:
http://hl7-fhir.github.io/resource.html#maturity
Given this information, the MHD resources being used are at a stage 2 maturity. You can see very clearly what this means using the above link.
Now, what I think is awesome, is that this maturity model approach is a more concrete way of responding to some of the very concerns some have expressed around the standards development process. IE, developed by committee but not deployed in practice, ignorant to the needs of the people we serve, etc etc. The maturity model specifically describes stages that imply real world implementation testing.
I’d love to hear from Shaun as to his thoughts on this. I wonder whether we should consider this sort of designation for what we’re doing as well?
So, the implications for FHIR are: we shouldn’t expect a formal “full release” of FHIR anytime soon. However, we should expect yearly updates for a while, and many of the resources like patient (http://hl7-fhir.github.io/patient.html) are deeply tested and ready for broad deployment.
This is an important development for us all to internalize and give some thought to.
-Paul
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.