Stream: conformance
Topic: Documenting input/output differences in data
Morten Ernebjerg (Aug 20 2020 at 13:23):
I have been looking at cases where the a server can make stronger claims about the data it makes available than on the data it is willing to accept. Specifically, I am thinking of cases where there are resource elements that (a) the submitting client cannot always fill, but (b) the receiving server can always fill based on internal knowledge or context, if required. The server could thus guarantee that this element will always be present when the resource is retrieved.
This is of course nicely in line with Postel's law (lenient with input, strict with output). However, I imagine there would be cases where it would be useful to communicate these differences to the clients, rather than just giving the "lowest common denominator" (element not required) as one would do in a profile. For instance, researchers consuming data from a system might rely on the presence of codes from a specific code system that the server adds upon resource creation, if missing (and which submitting clients cannot always supply).
Are there approaches within FHIR to communicating such input/output differences, other than through written documentation? (e.g. systems that have distinct "incoming an "outgoing" profiles for a given resource type)
Grahame Grieve (Aug 20 2020 at 20:41):
US core has done this for content types on documents - systems will accept more formats than they'll return. @Eric Haas how was that represented again?
Eric Haas (Aug 20 2020 at 22:10):
I think you are referring to this https://build.fhir.org/ig/HL7/US-Core/clinical-notes-guidance.html#using-expand
Grahame Grieve (Aug 20 2020 at 22:13):
yes, thanks. So it's not quite the same, but a similar concept
Morten Ernebjerg (Aug 21 2020 at 09:28):
Thanks, I'll have a look at that
Last updated: Apr 12 2022 at 19:14 UTC
