Stream: implementers
Topic: DefaultValue
Radha Rajendran (Apr 10 2021 at 05:22):
@Lloyd McKenzie Okay . How and where to use defaultValue ?
Lloyd McKenzie (Apr 10 2021 at 05:29):
As it says in the comments in ElementDefinition, defaultValue is only allowed to be used in logical models. It'll never be used in resource or data type definitions and it's prohibited for use in profiles on either of those.
Radha Rajendran (Apr 10 2021 at 05:34):
okay thank you
Radha Rajendran (Apr 10 2021 at 05:37):
@Lloyd McKenzie One more question , How to define elements in structure definition for complex data types such as CodeableConcept, BackboneElement ?
Lloyd McKenzie (Apr 10 2021 at 05:51):
First, read the section on validation in the core spec? http://build.fhir.org/validation.html
Radha Rajendran (Apr 10 2021 at 06:43):
:+1:
Matt Rouhana (Oct 28 2021 at 16:52):
@Lloyd McKenzie - what's the rationale behind prohibiting default values in profiles? I have a use case where it would be helpful for the sending system to not have to provide identifier.system for every resource. In my mind, a profile that defaults that element to a previously agreed upon value (but would still allow it to be overwritten) would be a helpful implementation tool.
Lloyd McKenzie (Oct 28 2021 at 17:00):
Instances need to be safe for systems to parse wherever they come from - so we can't allow different systems to assert different defaults (because that would mean we'd need to interpret instances differently based on where they came from). Also, default values add complexity to processing because you need to treat an element with one value (null) as if it actually had a distinct value.
We do allow defaults for logical models - because those aren't about exchange. However, for FHIR resources and data types, the only thing allowed is "meaning if missing" which is globally declared across all FHIR implementations. E.g. "If deceases[x] is absent, you should presume the patient is alive". That's obviously not a guarantee, but is a safe reasonable inference. For anything else, you must explicitly populate the value.
Matt Rouhana (Oct 28 2021 at 17:44):
@Lloyd McKenzie - thanks for the context. I suppose I was thinking of "default values" as they're implemented in many relational databases, where if you insert a record and leave a field null, but that field has a default value defined, the field will actually be populated with the default on insert. Is there any standard/recommended approach for achieving this in a FHIR server implementation?
Lloyd McKenzie (Oct 28 2021 at 17:51):
Can you give a specific example you're wanting to set? If it's setting a boolean to false, and the meaningIfMissing is "if not specified, assume false", then that's relatively safe. However, for most other defaults, it's not safe and shouldn't be done when consuming FHIR data. I.e. you can't say "if you don't send this element, we'll presume you mean X - because that saves bandwidth". FHIR requires that X always be transmitted.
Matt Rouhana (Oct 28 2021 at 18:12):
I'm thinking primarily of the namespace/code system context. Take the following example:
resourceType: Encounter
meta:
source: http://example.org/source-1
identifier:
- value: 12345
status: finished
class:
code: AMB
type:
coding:
- code: 1
subject:
identifier:
value: 67890
It would be helpful to say: "Because you've provided a meta.source value, I can look that up somewhere and contextualize the identifiers and codes that you've sent." Upon POSTing to the server, the resource would look like:
resourceType: Encounter
meta:
source: http://example.org/source-1
identifier:
- value: 12345
system: http://example.org/namingsystem/source-1-encounter-id
status: finished
class:
code: AMB
system: http://terminology.hl7.org/CodeSystem/v3-ActCode
type:
coding:
- code: 1
system: http://example.org/codesystem/source-1-encounter-type
subject:
identifier:
value: 67890
system: http://example.org/namingsystem/source-1-patient-id
I realize that I could simply do some preprocessing upstream of the server to the same effect, but it's beneficial to (1) centralize that configuration and (2) have a canonical standard for documenting it.
Vassil Peytchev (Oct 28 2021 at 18:45):
Nothing prevents your server from getting the input described above, and storing it as the output shown. The configuration would be only on the server.
Matt Rouhana (Oct 28 2021 at 19:12):
@Vassil Peytchev understood, I'm just wondering if there's a best practice for doing the above. It would be useful to expose that configuration as a FHIR Resource - perhaps a custom one?
Lloyd McKenzie (Oct 28 2021 at 19:16):
As a rule, it's not a good idea to encourage the sender to transmit the data that way - as it requires the receiver to have special information to convert the record into "useable" form. If it's a situation where you've got a device with limited bandwidth that always talks to a 'controller' system that inserts the additional data, then that's probably safe.
Last updated: Apr 12 2022 at 19:14 UTC
