Stream: implementers
Topic: How do you use metadata at runtime.
Yunwei Wang (Apr 21 2017 at 14:21):
I know metadata is useful at client app design time to understand the server profile. But do you really use it at runtime? I know the "security" section need to be retrieved for security connection (SMART for example). My question is more on the "resource" section. As a client, does it need to read the resource section every time to verify that resource profiles, extension, etc are not changed? What is the best practice here for using metadata?
John Moehrke (Apr 21 2017 at 14:59):
apps need to do only what the app needs to do. There is no requirement that an app confirm resources are tagged with any specific profile. However if that app is reliant on the fact that a resource is compliant with a specific profile, then it should look for that in the tag. BUT it must also be robust to the fact that a resource can be compliant and not be tagged with that profile that it is compliant with.... so, it is not all l that helpful to apps, unless there is a specific helpfulness designed in...
Lloyd McKenzie (Apr 21 2017 at 15:32):
In general, it's best not to presume that anything in an inbound instance agrees with what you expect it to be unless you have full control of the coding and configuration of the system that's talking to you. So anything that could affect your processing of the instance (e.g. modifier extensions) needs to be checked every single time.
Abbie Watson (Apr 21 2017 at 19:21):
We added a fhirVersion extension to meta, so we can look at Resource.meta.fhirVersion. That lets us do schema validations against specific versions of the FHIR spec, do schema migrations across collections, and translate FHIR versions. For instance, http://open.epic.com is still serving up DTSU2 resources; and we're on v3.0.0 for many of the resources now. Our JSON cache/datastore has dynamic schemas, so it can write down the DTSU2 resource as it comes in; but if it goes through the scrubbing process, it will get a meta.fhirVersion of fhir-3.0.0 added to it; so our housecleaning worker scripts will know if it's already been migrated or needs migrating.
Abbie Watson (Apr 21 2017 at 19:24):
We're also starting to find good use from the version number for operational transform; i.e. undo/redo, collaborative editing, revisions of a patient file, etc. But it took us a while to grok how to do that, because version only works to the extent that there is another identifier acting to bundle the different versions together into a history.
Michael Lawley (Apr 23 2017 at 22:44):
One of our clients uses metadata to determine whether batch it supported, security stuff (SMART), and the set of supported search parameters per Resource type. It also looks for whether create and/or update are supported. Pre-STU3 we also looked for the de-facto extension that listed supported CodeSystems. We also look for fhirVersion, publisher, name, and description to display to the end user.
Last updated: Apr 12 2022 at 19:14 UTC
