Obligation Discussion
0.5.1 - Working Draft to present the Concept Ideas and Background Details (FO)

Obligation Discussion, published by . This guide is not an authorized publication; it is the continuous build for version 0.5.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/frankoemig/obligation/ and changes regularly. See the Directory of published versions

CodeSystem: Data Expectation Codes (Experimental)

Official URL: http://v2.hl7.org/fhir/CodeSystem/dataExpectation Version: 0.1.0
Active as of 2022-10-10 Computable Name: DataExpectation

This is the codesystem describing exptectations for Data Handling. It has to be discussed whether these codes can become more specialised activities!?

This codesystem is in principle the stand-alone excerpt from the complete ontology that combines them all. It is presented just for completeness and to support discussions but it can be assumed that it is not necessary afterwards.

This Code system is referenced in the content logical definition of the following value sets:

Properties

This code system defines the following properties for its concepts

NameCodeURITypeDescription
Parent parent http://hl7.org/fhir/concept-properties#parent code
actor actor code associated actor, i.e. to whom it may apply

Concepts

This case-sensitive code system http://v2.hl7.org/fhir/CodeSystem/dataExpectation defines the following codes in a Is-A hierarchy:

LvlCodeDisplayDefinitionParentactor
1 expected expected data fits to expectations/specification
2   unaltered preserve preserve what you get expected
3     exactly exactly exactly what is specified, nothing else unaltered
2   modify modify allow for modifications of the data expected consumer
3     assocation assocation taken by association modify
3     equivalent equivalent in an equivalent way modify
3     translate translate Data received is preserved by 1:1 mapping/translation to an internal value that is semantically equivalent, that preserves the temporal aspect of the translation. modify
4       semantically translate semantically Two concepts are semantically equivalent if they can substitute for each other in the defined use case with no loss of information used to define the concept. translate
4       clinically translate clinically Two concepts are clinically equivalent if they can substitute for each other in the defined use case with no impact on clinical interpretation by a trained clinician. This may include further refinements based on the specific domain, e.g., for Lab use case, this would require interpretation that includes the impact of differences in normal ranges. translate
3     reference reference Use referenced data based on stored pointer; stored data is displayed by linking to the corresponding stored value most often the case for data elements that are STORED EXACT by ASSOCIATION. modify
3     truncate cut off data cut off remaining characters from the data thereby shortening the data modify
3     more-details additional details/values extends the expected data with more/own information, e.g. appartment if street is specified modify creator
3     more-structure additional substructures provides the data with more granular details, e.g. house number for an address line modify creator
3     missing data is missing/not available provide a null-flavor/absent reason modify creator
3     constant added as a constant this value has no valid representation or meaning in the sending application, it is just added because it is required to be there modify
1 unexpected unexpected values how to manage unexpected data (as sender or receiver)
2   replaces new/other values replaces the expected data by something else unexpected
2   consider consider unexpected values take vare of values that are coming but not described/specified. Allows for warnings unexpected

Notes:

checking!

This please remember that this codesystem may be behind the ontology, and should be updated regularly, if at all.