FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

4.3.2.56 CodeSystem http://hl7.org/fhir/tools/CodeSystem/obligation

FHIR Infrastructure icon Work Group Maturity Level: NNormative (from v4.0.0) Use Context: Country: Global (Whole world), Country: Global (Whole world)
Official URL: http://hl7.org/fhir/tools/CodeSystem/obligation Version: 5.0.0-cibuild
active as of 2023-01-31 Computable Name: ObligationCodes
Flags: CaseSensitive, Compositional, Complete. All codes ValueSet: Obligation Codes ValueSet OID: TBD

This Code system is used in the following value sets:


Codes that describe application obligations for handling FHIR content. There are three kinds of codes in this code system:

  • Qualifier codes: SHALL/SHOULD/MAY
  • Functional codes - these describe a functional behavior applications may implement, and have the concept property qualify = true, and must be qualified by one of SHALL, SHOULD, or MAY
  • Composite codes - these specialise AggregateConcepts, and have an concept property 'expression' that defines them in terms of a set of functional codes

Functional and Qualifier codes are combined using the syntax [modifierCode] ":" [obligationCode] e.g. SHALL:will-send

The functional codes are grouped into three different high level categories:

  • ResourceProducerObligations - functions that pertain to applications that produce resources (typically from databases or forms)
  • ExchangerObligations - functions that pertain to applications that transfer resources between other applications (including FHIR repositories)
  • ResourceConsumerObligations - functions that pertain to applications that consume the content of resources and do something with them

Note that applications typically produce and consume resources, whether client, server or something else again, and many applications transfer resources as well

Properties

This code system defines the following properties for its concepts

CodeTypeDescription
qualifybooleanCodes with this property true must have 'shall', 'should', or 'may' prepended in the grammar
combinationcodeOne of the codes that makes up a composite codes

Concepts

This code system http://hl7.org/fhir/tools/CodeSystem/obligation defines the following codes:

LvlCodeDisplayDefinitioncombinationCopy
1ModifierCodes ModifierCodesSHALL/SHOULD/MAY that can be prepended to codes that have the qualify property = truebtn btn
2  SHALL SHALLThe functional requirement is mandatory. Applications that do not implement this functional behavior are considered non-conformantbtn btn
2  SHOULD SHOULDThe functional requirement is a recommendationbtn btn
2  MAY MAYThe functional requirement is presented as an option for applications to consider. Note that this is usually used to indicate a choice is still valid for an application to makebtn btn
1ResourceProducerObligations ResourceProducerObligationsResource producers are applications that assembles resources in the first place. Resource producers may be a server, client, sender, receiver or some middleware device, and they may store the resource, or merely hand it on.btn btn
2  can-send Conformant Applications SHALL/SHOULD/MAY be able to correctly populate this elementNotes: Typically, this means that an application needs to demonstrate during some conformance testing process that there are some conditions under which it populates the element with a correct valuebtn btn
3    will-send Conformant Applications SHALL/SHOULD/MAY be capable of sending this element and, if the element has a value and is allowed to be shared, include it when sending the resourceNotes: This implementation obligation means that whenever the producer knows the correct value for an element, it populates it, subject to security, consent and privacy considerationsbtn btn
2  use-reason Conformant Applications SHALL/SHOULD/MAY provide an element with a DataAbsentReason or a NullFlavor (or equivalent) if a value is not known and the element is mandatoryNotes: When no value for an element is known, the producer populates the element with a [DataAbsentReason](extension-data-absent-reason.html) or a [NullFlavor](extension-iso21090-nullflavor.html) (or equivalent). If no particular reason is known or reportable, the DataAbsentReason 'unknown' is used. Which particular extension can be used, see belowbtn btn
2  in-narrative Conformant Applications SHALL/SHOULD/MAY ensure that this data element is represented in any human readable representation in a resourceNotes: When no value for an element is known, the producer populates the element with a [DataAbsentReason](extension-data-absent-reason.html) or a [NullFlavor](extension-iso21090-nullflavor.html) (or equivalent). If no particular reason is known or reportable, the DataAbsentReason 'unknown' is used. Which particular extension can be used, see belowbtn btn
2  in-ui Conformant Applications SHALL/SHOULD/MAY ensure that users can enter a value for this element during data inputNotes: Exactly what form the input takes is not specified, but the expectation is that this is a value that comes from the user, and not implied internally by the applicationbtn btn
2  in-store Conformant Applications SHALL/SHOULD/MAY ensure that the value for this element is stored in a persistent data storeNotes: Exactly what the data store is not specified, nor how long it is stored for, but it is understand that the same value will be available in later exchangesbtn btn
2  must-explain Documentation applicable to Conformant Applications SHALL/SHOULD/MAY explain how this element is handledNotes: this is really a rule about specifications, implying that another specification (which might be application documentation) either makes this element will-send, or explains how the use cases that involve this element do not arise, or how they are handled. An example: IPA marks Patient.active must-handle and must-explain. Client applications must process Patient.active correctly if they see it, but many (though *not all*) specifications and/or applications ensure that Patient.active will never be false, and so it will never be populated e.g. MedMij in Netherlands prohibits use of Patient.active, and explains that it is never false.btn btn
1ExchangerObligations ExchangerObligationsExchangers do not produce or consume resources; they only pass the resource on. They may store the resource in a persistent store between reception and subsequent transfer. The generic FHIR servers are exchangers, as are most middleware systems.btn btn
2  preserve Conformant Applications SHALL/SHOULD/MAY ensure that this element does not change between receiving and transferNotes: This does not mean that the element value cannot change, only that changing the element value for an element marked with this obligation moves an application from being an exchanger to a Consumer and a Producer, and those obligations applybtn btn
2  may-alter Conformant Applications MAY choose not to alter this element valueNotes: this is the converse of preserve, and is really a null-statement - it's the default rule for an application. It's defined here to allow a specification to be explicit that it isn't conveying obligations for resource producersbtn btn
1ResourceConsumerObligations ResourceConsumerObligationsResource Consumers are applications that consume resources and do something with them, either displaying them to humans, transferring them to some other format for further re-use, or using them to drive some kind of application logic process AKA decision support. Resource Consumers often store resources, but do not need to, and whether resources are stored or not between receiving them and using them doesn't make any difference to the obligationsbtn btn
2  no-error Conformant Applications SHALL/SHOULD/MAY accept resources containing any valid value for the element without errorNotes: Applications are still able to inform the user that a value cannot be processed correctly, but applications aren't able to reject the information out of hand or ignore the element value in order to process the resource correctly (which would be allowed for elements that do not have this obligation). This obligation also applies to elements that only contain a [DataAbsentReason](extension-data-absent-reason.html) or a [NullFlavor](extension-iso21090-nullflavor.html) (or equivalent), should either of these be allowed on the consumer obligationsbtn btn
2  handle Conformant Applications SHALL/SHOULD/MAY handle the meaning of this element correctlyNotes: this rule is vague in that doesn't specify any particular handling of the element. But it's important because an application that ignores this element is non-conformant. A good example would be a status code of 'entered-in-error' - how exactly a Resource Consumer handles this depends on the use case etc, but the application can never simply ignore such a status code. Note that whether the resource or information from it is stored for later use is irrelevant - when the resource or information in it is processed, the consequences of the element are considered. That may mean not retaining the information for later use, or informing the user, etc. Typically, this obligation marks that there are known patient safety issues that can arise if the element is ignored. Implementers should pay particular attention to the possible range of values for the element from a safety perspective.btn btn
3    display Conformant Applications SHALL/SHOULD/MAY display the value of this element when presenting the data from the resource to a human userNotes: exactly how it is displayed is not specified, but it means that a human looking at the content of the resource is made aware of the value of the element so that they can consider the meaning of the resourcebtn btn
3    share Conformant Applications SHALL/SHOULD/MAY retain the value of this element when the information from the resource is shared with other applicationsNotes: this rule applies whether the information is being shared in the form of a FHIR resource, or in some other format. The rule applies whether or not the resource is stored prior to sharing.btn btn
3    process Conformant Applications SHALL/SHOULD/MAY consider the value of this element when processing the resource as specified by the IGNotes: this implies that the IG that specifies this obligation provides details about what processing is to be performed, and the obligation specifially relates to the processing specified in the IG [DataAbsentReason](extension-data-absent-reason.html) or [NullFlavor](extension-iso21090-nullflavor.html) or equivalent when handling the resource or the information in it as specified by the other obligations.btn btn
3    store Conformant Applications SHALL/SHOULD/MAY store the value of this element in a persistent data storeNotes: Exactly what the data store is not specified, nor how long it is stored for, but it is understand that the same value will be available in later exchangesbtn btn
3    print Conformant Applications SHALL/SHOULD/MAY print the value of this element somewhereNotes: The form of the printing is not specified. A profile using this value SHALL explain the nature of the printing requirement somehowbtn btn
3    ignore Conformant Applications SHALL/SHOULD/MAY ignore the value of this element somewhereNotes: This is different to can-ignore, which indicates that the application may ignore it. This is an expectation that it will be ignoredbtn btn
3    preserve Conformant Applications SHALL/SHOULD/MAY keep the value of this element exactlyNotes: this is an expectation future references to the value, whether produced or consumed, will be to the exact same data. Alternative or truncated data is not allowedbtn btn
3    modify Conformant Applications SHALL/SHOULD/MAY keep the value of this element exactlyNotes: this is an expectation future references to the value, whether produced or consumed, will be to the exact same data. Alternative or truncated data is not allowedbtn btn
1AggregateConcepts AggregateConceptsPredefined common combinationsbtn btn
2  can-populate A Conformant Application MAY choose to populate this element or notNotes: this is the converse of will-send, and is really a null-statement - it's the default rule for an application. It's defined here to allow a specification to be explicit that it isn't conveying obligations for resource producersMAY:will-sendbtn btn
2  can-ignore A Conformant Application MAY ignore this elementNotes: this is the converse of must-handle, and is really a null-statement - it's the default rue for an application. It's defined here to allow a specification to be explicit that it isn't converying obligations for resource consumersbtn btn
2  v2-re V2 RERE as defined in chapter 2 of the v2 specificationbtn btn
2  ihe-r2 IHE R2R2 as defined in IHE Appendix Zbtn btn
2  std Standard ObligationsThe standard recommended set of obligations for IGs to use unless they know they want something different. Note that the standard codes don't include use-dar, use-dar-nf, use-dar-if-allowed / use-reason - that gets put on specific elements that justify this handlingbtn btn

 

See the full registry of code systems defined as part of FHIR.


Explanation of the columns that may appear on this page:

LevelA few code lists that FHIR defines are hierarchical - each code is assigned a level. See Code System for further information.
SourceThe source of the definition of the code (when the value set draws in codes defined elsewhere)
CodeThe code (used as the code in the resource instance). If the code is in italics, this indicates that the code is not selectable ('Abstract')
DisplayThe display (used in the display element of a Coding). If there is no display, implementers should not simply display the code, but map the concept into their application
DefinitionAn explanation of the meaning of the concept
CommentsAdditional notes about how to use the code