Stream: shorthand
Topic: References to custom resources
Martin Höcker (Jun 04 2021 at 13:49):
How strict should SUSHI be with References to custom resources? The following FSH works on the master branch (not released on npm yet!):
Resource: TestResource
* isValid 1..1 boolean "this is something"
Instance: MyTestResource
InstanceOf: TestResource
* isValid = true
Instance: MyPatient
InstanceOf: Patient
* name.given = "Bob"
* extension.url = "http://example.com/test"
* extension.valueReference = Reference(MyTestResource)
It produces the following MyPatient in json-form:
{
"resourceType": "Patient",
"id": "MyPatient",
"name": [
{
"given": [
"Bob"
]
}
],
"extension": [
{
"url": "http://example.com/test",
"valueReference": {
"reference": "TestResource/MyTestResource"
}
}
]
}
I realize that the usage of custom-resources is strongly discouraged. But if for some reason I have to use them, I would like to do it in the minimally breaking way possible. I like the idea by @Grahame Grieve for handling references to custom resources: Use the datatype uri instead of Reference.
Would it make sense that SUSHI emits a warning when the user defines a standard resource that references a custom resource? This would inform the user that even the instance of the standard resource is no longer FHIR compliant, and could help establish best-practices for working with custom resources.
Chris Moesel (Jun 04 2021 at 14:42):
@Martin Höcker - that's a great question, and kudos to you for finding and using an advanced feature only merged to master yesterday! I think what you propose (issuing a warning when an instance of a standard resource references a custom resource) makes sense. I imagine it would be the same for a profile of a standard resource that references a custom resource. What about an extension definition that constrains valueReference to a custom resource type? Is the definition of that extension warnable? or only if you use that extension in a profile or instance of a standard resource?
Elliot Silver (Jun 04 2021 at 16:15):
I would think that if you are going to support custom resources, and if you are going to warn about them, then you need to warn on any use. An extension could be defined in an IG and, other than that, never used within the IG. That should trigger a warning because it's an issue that any user of the extension is going to need to be aware of.
Martin Höcker (Jun 06 2021 at 10:48):
@Chris Moesel The extension-definition that constraints valueReference to a custom resource is an interesting point. I understand @Elliot Silver's argument that if we warn about standard resources referencing custom resources, we should also warn when the standard resource is a StructureDefinition.
But I think it would be OK to omit the warning in this special case, maybe on the condition that StructureDefinition.context constaints usage to one or more custom resources.
Martin Höcker (Jun 06 2021 at 10:49):
Side question: Would it be possible to "transpile" definitions of custom resources to profiles of the Basic resource?
Lloyd McKenzie (Jun 06 2021 at 13:05):
The publisher will error/warn on non-resolved content. Why should FSH take that on? (And why is FSH supporting custom resources at all??)
Mark Kramer (Jun 06 2021 at 23:40):
Lloyd, we believe some work groups will migrate along a path where they eventually design, create, and maintain their base resources in FSH.
Lloyd McKenzie (Jun 07 2021 at 04:35):
Creating resources is non-conformant unless you're HL7. I'm not understanding why FSH would support non-conformant behavior?
Chris Moesel (Jun 07 2021 at 04:54):
We want to support the HL7 use case. But in addition, FSH users have specifically requested support for defining custom FHIR resources. The most common reason is if they want to exhange proprietary data in-house using the FHIR exchange API. If you need to design a custom API for in house use anyway, why not piggyback on the FHIR spec rather than creating something from scratch? We specifically warn in the docs that you must not use custom resources for inter-organizational data exchange.
Grahame Grieve (Jun 07 2021 at 05:43):
I'm interested in report backs from such organizations - what challenges do they have with an approach like that?
Lloyd McKenzie (Jun 07 2021 at 13:18):
Do you also warn that they can't use standard XML or JSON schemas, can't use public test servers or registries and can't use standard validation or publication tooling?
Lloyd McKenzie (Jun 07 2021 at 13:18):
And that any such systems are explicitly non-conformant?
Chris Moesel (Jun 07 2021 at 13:23):
We note that they do not work w/ the FHIR IG Publisher. It seems kind of obvious to me that custom resources wouldn't work with the standard FHIR schemas, public test servers, validators, or registries. Do you really think we need to point that out?
David Pyke (Jun 07 2021 at 13:26):
It should probably have a large warning with all that content and a special flag in sushi-config.yaml to shut it up
David Pyke (Jun 07 2021 at 13:27):
something like: Non-conformant FHIR creation warning: false
Lloyd McKenzie (Jun 07 2021 at 14:21):
The more red flags and warning bells we can raise when implementers pursue non-conformant solutions, the better.
Lloyd McKenzie (Jun 07 2021 at 14:21):
Might also be useful to nudge them towards Basic as an alternative.
Chris Moesel (Jun 07 2021 at 15:11):
Yeah, it might be interesting to support something like @Martin Höcker suggested above -- an automated solution to make Basic variants of the resources. But I don't think you can define new extensions inline in a profile, right? So that will result in a new extension for every element in the Resource, right?
Grahame Grieve (Jun 07 2021 at 15:13):
Do you really think we need to point that out?
Sadly the answer is: I don't believe that you have to, and I still can't believe that you have to, in spite of years of evidence that, yes, you do have to
Grahame Grieve (Jun 07 2021 at 15:14):
So that will result in a new extension for every element in the Resource, right?
Yes. At least technically. I'm not sure all the tools support it but they can be contained resources but that would change the extension ids.
Grahame Grieve (Jun 07 2021 at 15:15):
But.... you don't necessarily have to publish them? (I mean, there's no way not to right now but that doesn't have to be final?)
Last updated: Apr 12 2022 at 19:14 UTC
