Stream: IG creation
Topic: Applying FMM levels to IG content
Elliot Silver (May 14 2021 at 18:22):
Does anyone have experience using FMM levels for IG resources; for example labelling one profile as FMM0 while another profile is FMM2? Can organizations other than HL7 use FMM levels (since the definition of the levels speak about WGs, etc.)?
Lloyd McKenzie (May 14 2021 at 18:34):
That's on the near-term list of things to add to the templates. (Also standards status.) I've been struggling about whether to support it in the 'base' template or only the HL7 template. FMM refers to specific expectations around 'ballot', which wouldn't be relevant to non-HL7 artifacts. However, perhaps FMG could soften that to 'formal review', noting that in HL7, that formal review is expected to be balloting. You could submit a request to the FMG to suggest that.
Elliot Silver (May 14 2021 at 20:00):
I think any solution would have to allow organizations to define their own maturity levels, which could involve balloting, formal review, or just publication. What I'd like to see in the base template is standard content that appears if a maturity level is defined for a resource. "This profile/valueset/etc. is at MyOrg maturity level: PG-13. To know more about MyOrg maturity levels, please see link"
Lloyd McKenzie (May 14 2021 at 20:08):
Perhaps a base property that says "maturity definitions". If the IG has such a property, we'll expose. Though I'm concerned that the extension we drive off of has a fixed value set, which might make it harder to find other types of maturities
Elliot Silver (May 14 2021 at 20:10):
Why have a fixed value set? Why not just use an example value set (which corresponds to the FMM levels), but allows users to define any maturity levels they want?
Lloyd McKenzie (May 14 2021 at 20:27):
Because the extension was defined for HL7 without other uses in mind. At minimum, I think we'd have a preferred binding. Trick if we loosen it how do we enforce that HL7 artifacts only have the HL7 maturities and don't allow any others
Elliot Silver (May 14 2021 at 20:32):
Make it one of the FMM maturity criteria? :laughing:
Sorry I misunderstood, I thought your were proposing a new extension, not using an existing one. And I'm not convinced that the HL7 FMM levels _are_ preferred in other contexts.
Grahame Grieve (May 14 2021 at 21:08):
I don't think that HL7 should redefine it's own maturity level criteria to generalize them.
Grahame Grieve (May 14 2021 at 21:08):
but I think it makes total sense for organizations to define their own levels and criteria.
Grahame Grieve (May 14 2021 at 21:09):
perhaps we could define an alternative link for the FMM definitions to be used in an IG?
John Moehrke (May 14 2021 at 21:49):
I am very much wanting to expose in the IG I author the underlying FMM of the resources I profile. We do this manually in IHE today, would be great if it could be automated. Today it shows up as a IG wide table of Resource | FMM
Lloyd McKenzie (May 14 2021 at 22:00):
What I'm thinking of now is that there'd be two parameters in the IG - one would be the URL where maturity levels are defined and the second would be the canonical URL of the extension that conveys maturity on artifacts. The publisher would 'propagate' that extension from high-level resources down into resources that don't have declared maturities and would expose those maturities in the resource summary table with a hyperlink to the place that defines them. If an IG doesn't define either property, no maturities shown. If it defines one but not the other, that's an error. (I'm also thinking we'll put an extension on the maturity extension that conveys where an inferred maturity came from and could show a flag indicating that a maturity had been inferred and a fly-over showing from where (would probably only show the first 5 artifacts or so whose maturity drove that level declaration). I think we'd require that maturities have a numeric scale - because otherwise there'd be no way to know how to propagate the 'highest' maturity.
Elliot Silver (May 14 2021 at 22:19):
Sorry, I'm having a hard time understanding this. I get a "URL where maturity levels are defined" (although, I am kinda drawn to using a codesystem for this, which makes it easy to validate), but I get lost after that. You're proposing an extension that identifies another extension?
Are you also picturing something that enforces a profile on an FMM 2 resource can't have a profile maturity of more than 2? I can't see that working unless we align the definitions. What happens if my IG uses a 3-level maturity model, or a 12-level model? How do those map to FMM2? Maybe one org's levels match 1:1 for FMM levels 0-4, but have 3 more levels before the FMM level 5; another org may have 3 levels between 0 and 1, but 2-5 match the FMM. Even if definitions are aligned, why shouldn't an org say this is a finalized (balloted, published, normative, etc.) IG (and thus the profiles in it are highest maturity) based on FHIR STU3 (which has no normative content).
Lloyd McKenzie (May 15 2021 at 03:34):
I'm proposing two IG properties (not extensions):
- fmm-definition-page: the URL of the web page that defines the maturity levels and their associated rules. For HL7 artifacts, this would be http://hl7.org/fhir/versions.html#maturity
- fmm-extension: the canonical URL of the extension that appears on a resource and defines its maturity level. For HL7 artifacts, this would be http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm
John Moehrke (May 15 2021 at 15:28):
The validation of the IG specific codeSystem would not need to be enforced by this navigation URL mechanism... but, It might be a solution some IG might choose to have the URL be to the html rendering of their codeSystem.
Lloyd McKenzie (May 15 2021 at 15:53):
The maturity levels would need to be integers
John Moehrke (May 15 2021 at 16:13):
why not codes?
Lloyd McKenzie (May 15 2021 at 18:44):
Because the logic has to be able to compare maturities to tell what's higher or lower than another maturity in order to auto-propagate the highest maturity of a 'using' resource to value sets, code systems, etc. that don't declare maturities
Lloyd McKenzie (May 15 2021 at 18:45):
In theory, we could do codes with an ordinalValue extension, but I don't see much reason to support that level of complexity...
John Moehrke (May 16 2021 at 12:36):
that would only work if we can come up with a universal meaning to the FMM integers. Even Normative means slightly different things in different standards organizations. I think it is best to just show the code at various levels of depth of profiling.
Lloyd McKenzie (May 16 2021 at 19:33):
The integers don't have have universal meaning. All that matters is that 3 is more mature than 2 and 7 is more mature than 6.
Lloyd McKenzie (May 16 2021 at 19:34):
Maturities must exist on a linear scale. I'm not saying people can't do other things too, but if they do, that would fall outside the notion of a maturity scale.
John Moehrke (May 17 2021 at 11:46):
so, how do we assure that there is enough space between FHIR core integers for the various organizations that are going to derive off of FHIR core? As it stands today, there is no room for other organizations to add more fine grain maturity because there are no spare integers between the FHIR core FMM integers.
Lloyd McKenzie (May 17 2021 at 17:18):
They can define their own scales. If they want to have a maturity range between 1 and 25, they can. The meaning of their numbers can be completely different from HL7s. If they want to map some of their numbers to FHIR's levels they can.
John Moehrke (May 17 2021 at 17:19):
okay, that is what I was looking for
John Moehrke (May 17 2021 at 17:20):
the other problem with numbers is ... what happens for things that have matured enough to be retired?
John Moehrke (May 17 2021 at 17:20):
or deprecated
Lloyd McKenzie (May 17 2021 at 17:32):
That's a different element - reflecting 'standards status'. Something can be deprecated independent of maturity level.
Elliot Silver (May 17 2021 at 18:06):
OK, this is where I get confused. You want maturities on a linear scale, so you can inherit base resource maturities and cap current resource maturity based on base resource maturity? If my profile's base has a FMM of 2, does that mean my resource (which I would put as a 17--predraft status--on my maturity scale) gets capped at 2?
Elliot Silver (May 17 2021 at 18:11):
My other issue is why the need for fmm-extension? Why have an element that lets you select an extension, instead of everyone agreeing on one extension, but leaving the valueset open?
If you do need it, unless it is specifically for conveying FMM, leave FMM out of the name. Use maturity-extension.
Lloyd McKenzie (May 17 2021 at 18:21):
I don't want to inherit base resource maturities. The driver for numbers is so that if you have a value set with no maturity and it's used by an extension with maturity 6 and a profile with maturity 8, we can infer a maturity of 8 for the value set.
Lloyd McKenzie (May 17 2021 at 18:22):
The extension for fmm already exists and has a type of 'code'. It's tied into a whole bunch of logic in the publisher already, so I don't want to mess with it.
Lloyd McKenzie (May 17 2021 at 18:23):
Maturity of a resource would never be inherited to determine the maturity of a profile. (Though in HL7, there would be a warning if a profile declares that it's more mature than the underlying resource.)
Elliot Silver (May 17 2021 at 18:28):
Ah, within the same IG. I'm not sure that things should project that way in all cases though.
OK, the fmm extension exists and is used. Is that sufficient reason to make things more difficult for all the non-HL7 guides? Is it any more difficult to add code to the publisher to recognize two fixed extensions vs one dynamic extension?
Lloyd McKenzie (May 17 2021 at 18:40):
Not sure how we're making things more difficult. You can define the extension you want to use with the semantics and scale you want it to have and it should just work. If everyone uses the same extension, then we'd have to make it a Coding rather than a code or integer, which bulks things up a bit. Not understanding how a generic extension with Coding makes things easier?
Elliot Silver (Sep 17 2021 at 23:43):
@Lloyd McKenzie , where did you land on this? What's the current mechanism to indicate resource and IG maturity?
Lloyd McKenzie (Sep 18 2021 at 02:55):
The extensions for capturing standards status and resource maturity will be the same ones as are used in the core spec. They will propagate, so for example, if the IG is set to "STU" and "FMM 3", then everything else in the IG will be too. If two resources would be propagated to by the same source - e.g. a value set is used by two profiles, one STU and one draft, the higher one will be inherited. Examples are always 'informative' and have no FMM.
Lloyd McKenzie (Sep 18 2021 at 02:56):
The changes are mostly made, but Grahame wanted me to refactor a few things and I've needed to turn my attention to getting SDC changes finalized. I hope to return to FMM shortly after the WGM. If you want to be proactive and start putting your maturity levels into your resources, feel free.
Elliot Silver (Sep 18 2021 at 05:36):
OK, I'll play around with that a bit. The propagation isn't present yet, correct?
Somewhat related, if I'm profiling a resource that has an element with an example valueset, and I provide that element with another valueset (maybe with a stricter binding), is there a way to show that binding is draft/trial-use/experimental? The rest of the profiling is solid, and the valueset we've chosen is solid too, but we want feedback on whether that was the right valueset to choose. As far as I can tell, I can't apply the standards-status extension to the element, since it isn't (e.g.) TU in the base resource, and I can't indicate that the binding is trial, so I"m left with setting the whole profile as trial. Now, setting the profile as trial makes sense because that reflects that not all of the profile is ready to go normative, but the flip side is that there is no way to point attention to the elements that are less mature in the profiling, except use of a note/ballot note in the intro. Is that all accurate?
Lloyd McKenzie (Sep 18 2021 at 16:33):
You can show an element overall as being STU or draft, but you can't show a specific constraint as being STU or draft. We haven't talked about what it means for a profile element to be STU when the base resource is normative, but given that the entire profile can be STU, it seems that a single element should be able to be - and similarly, you could have a draft element in an STU profile based on an STU resource.
Mark Kramer (Dec 10 2021 at 14:58):
I'm looking at adding maturity levels to mCODE IG. Reading the above discussion about using the HL7 FMM and alternative maturity models, my vote would be to change the FMM extension to a CodeableConcept. That allows the user to specify the system that defines the code. The codes then could be ordinal. I think that is the proper approach.
Mark Kramer (Dec 10 2021 at 15:13):
One more thing about this: I see the fmm extension being used on StructureDefinition, but the context of the fmm extension is "Element". Are you supposed to use this as a top-level extension to express a profile's maturity, or are you supposed to add it to element[0]?
Lloyd McKenzie (Dec 10 2021 at 15:39):
Typically you add it at the profile level, but there are times when the maturity of certain elements differs from the overall maturity of the profile.
Lloyd McKenzie (Dec 10 2021 at 15:40):
For HL7, everyone should be using the same maturity scale.
Mark Kramer (Dec 10 2021 at 15:44):
For HL7, fully agree. Can you add the FMM extension to a value set, or only an element bound to a value set.
Lloyd McKenzie (Dec 10 2021 at 15:48):
You can add maturity to any conformance resource that isn't an example. (You can add to examples too, but it'll be ignored.) Once the process for IGs turns on, maturity will cascade from IG to profiles to valuesets, code systems and extensions. So you really only need to declare it where you want to override what'd be inherited.
Last updated: Apr 12 2022 at 19:14 UTC
