FHIR Chat · Handling meta.profile in instances

Stream: shorthand

Topic: Handling meta.profile in instances

Morten Ernebjerg (Jun 09 2021 at 08:51):

Hi :wave:. I'm having a lot of fun working with goFSH & sushi, but have encountered a problem when back-converting & re-generating existing instances with meta.profile entries :

If goFSH is run on a resource instance that declares a profile in meta.profile, the canonical URL is inserted in the InstanceOf field in the generated FSH. There is also a warning issued if the profile is not defined locally.
If multiple profiles are declared in meta.profile, the first entry is used for InstancecOf but the rest are put in explicit * meta.profile = .... entries.
If sushi is run on the goFSH output like the above (with the profile not locally defined), it throws the errors "InstanceOf [canonical URL] not found for [instance ID]"

Might it not be better for goFSH to always convert all meta.profile entries into * meta.profile = ... entries in FSH and let InstanceOf be the base type? That would ensure equal treatment of all profiles and would (I think) also remove the sushi error mentioned above (generation with * meta.profile = ... entries works fine). Also, my (limited) understanding of meta.profile is that it is just a claim that may or may not be true, so it feels like elevating it to an instance type declaration is perhaps too strong (though maybe I'm misunderstanding of that FSH element).

Chris Moesel (Jun 09 2021 at 13:14):

Hi @Morten Ernebjerg. I think you raise some interesting (and valid) points. Generally speaking, there are four advantages to using InstanceOf: SomeProfile vs InstanceOf: SomeResource:

It's a good signal of intent to people reading the code (and more obvious than a rule)
It tells SUSHI to automatically insert required fixed values from the profile (so you don't have to)
It tells SUSHI to do basic validation against the profile (e.g., cardinality checks)
It identifies the instance as an example of the profile in the IG JSON (which comes through in docs)

I understand your point that meta.profile is just a claim to conform to a profile -- but at the same time, when we're talking about IGs, it seems to me a very bad idea for an IG to have artifacts that claim to conform to a profile but do not actually conform. That's an unfortunate reality of real-world data, but IG data usually should represent best practice. So I actually think it is good to attempt to force/validate this conformance in an IG.

All that said, I don't think GoFSH takes advantage of #2 above (it writes explicit rules for all values, fixed or not) and #4 is only valid if you will later allow SUSHI to create the IG JSON. Also, when there are multiple profiles, I can see how perhaps #1 is not necessarily what the author wants.

So in conclusion (long post, sorry), here are my thoughts:

GoFSH aims to make valid FSH, so it should never declare a profile as Parent if that profile cannot be resolved in the IG or in the IG's dependencies. For that case, we should use the base resource as Parent w/ a * meta.profile = rule.
If an instance has multiple meta.profile entries, I agree that a better approach would be to declare the base resource as Parent and list all the profile using * rules. That's probably better than arbitrarily just choosing the first one.
If an instance has a single meta.profile entry, and that profile is resolvable (via IG or IG dependencies), I still think it makes sense to explicitly export it as the Parent. There is no ambiguity there and I think it is good to make the parent more clear and allow for the additional validation and IG documentation that having a profile parent provides.

What do you think about that?

Morten Ernebjerg (Jun 10 2021 at 06:49):

Thanks for the long post @Chris Moesel, it really made me understand the context much better!

Those are excellent points about how using the profile in InstanceOf allows SUSHI to leverage the profile information, I was not aware of all that underlying functionality (which sounds great). And I agree that in the context of an IG, it is fair to force authors to supply valid examples.
That being said, when I discovered these issues, I was actually working outside the context of an IG (for now). I really like FSH as a, well, short-hand, for improved compactness and better organization, even if I am just playing around with a few resources. Hence, from my perspective it would be ideal if there were no fixed choices made that are based on the assumption that we are in the context of a full IG.
I suspect (without having concrete proof) that even the context of an IG, there may be cases where you want to add more than one profile to an example. For instance in cases where you want to show that the example is also valid against an important parallel or overarching IG (say, IPS). Another scenario is where the use case forces you to make it explicit in the instance whether it is STU3 or R4 - AFAIK, the standard way to do that is to put the canonical for the base resource definition (which contains the FHIR version) in meta.profile.

So I agree with your suggestions, with one tweak. I think it would be nice if the use of profiles in InstanceOf could be configured with a flag (or a flag passed at runtime). That way, IG authors (and "non-IG-users") would still have the option of keeping the profiles out of InstanceOf (even if resolvable), if their use cases makes that preferable. The flag could theoretically even switch between the different kind of rules you discussed above: "never", "only if single profile", and "always, pick first profile". If there are other aspects of SUSHI/goFSH that are specific to the IG context, I wonder if an alternative might be to have a flag to switch off that context (affecting different aspects of the compilation logic).

Might one of those be viable ways to go?

Jean Duteau (Jun 10 2021 at 14:11):

I actually second something like this. I have a desire to create example instances that do NOT have the meta.profile set. I'd like to declare InstanceOf to get the expressibility of FSH but I don't want the actual instances to have meta.profile set.

Morten Ernebjerg (Jun 11 2021 at 14:34):

Ah yes, I suppose the question poses itself both for goFSH and SUSHI (I was primarily thinking about the former, but I see it for the latter too).

For goFSH
My proposal would be to allow configuring how meta.profile entries in FHIR instances are mapped to FSH. The options could be

Never InstanceOf: always put this information in * meta.profile = ... FSH entries, always set InstanceOf to the base type
Always InstanceOf: Always put the first meta.profile entry into InstanceOf (if present), second and further entries into * meta.profile = ... FSH entries (this is the current behavior)
InstanceOf if unique: Put the profile in InstanceOf iff there is a single meta.profile entry, otherwise in * meta.profile = ... FSH entries

For SUSHI
@Jean Duteau if I understand you right, this is what you are talking about. Is it correct that your suggestion would be to allow a configuration/flag that would control whether InstanceOf: [profile URL] entries in FSH are propagated to meta.profile entries in the output? (I'm actually not sure what the current behavior is here).