Obligation Discussion
0.4.1 - Working Draft to present the Concept Ideas and Background Details (FO)
Obligation Discussion - Local Development build (v0.4.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Official URL: http://v2.hl7.org/fhir/CodeSystem/dataExpectation | Version: 0.1.0 | |||
Active as of 2022-10-10 | Responsible: FO | 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
Code | URI | Type | Description |
parent | http://hl7.org/fhir/concept-properties#parent | code | |
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:
Lvl | Code | Display | Definition | Parent | actor |
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 |
This please remember that this codesystem may be behind the ontology, and should be updated regularly, if at all.