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/obligationProposed | Version: 0.1.0 | |||
Draft as of 2024-05-08 | Responsible: FO | Computable Name: ObligationProposedCodes | ||
Copyright/Legal: Conformance WG |
This codesystem is a proposal for obligation codes in response to Grahame’s codesystem for obligations. It represents an ontology that not only combines the other three codesystems (verb, obligation, data expectation), but also introduces some more axes/dimensions to better explain the meaning of the codes.
This Codesystem has originally been derived from 3 individual codesystems that were the basis for discussion in Conformance WG:
During the course of discussion Conformance WG members became aware that due to the overarching complex structure of obligations the maintenance as individual and independent codesystems seems inappropriate. It is also unnecessary complex to instantiate them in form of reasonable combinations when taking them from different CS. Instead, it appears much better to combine them as an ontology in form of a single codesystem and to introduce the meaning by properties and polyhierarchies. This way, complex obligations can be expressed. Consequently, those properties (where indicated) are inherited downwards.
As a result from the discussion, borrowing from the codesystem currently bound to the obligation extension led to an improved and enhanced codesystem. It has multiple axes to separate concerns. It is designed as follows:
Following a short intro into the different axes. The purely definitional ones are marked in red, supporting the foundation for precoordination in yellow. The green will contain precoordinated and defined concepts that can be instantiated and used in combination with profiles. Due to their ontological definition, their meaning should be clear:
Axis to be instantiated:
Some remarks:
Following, some interactions should help to understand where specific activities take place so that it becomes easier to align with obligations. The drawings should be taken as abstract examples and may of course vary to reality.
In the following, a component - the receiver - is taking the data, parse it, and maintains the data in a central space - the “parsed data”. The consumer actor in return is triggered, takes the data, and starts some kind of processing with it. It may result in any kind of modification which is shown as simple interactions with the storage (database). As a response to this internal processing, some data is provided for preparing a response to the originator. (It should be noted that this drawing abstracts from a transport vs. application acknowledgement.)
The other drawing examines what happens if data is routed to another party.
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 | Who is the parent element of this concept? Multiple parents are possible. |
negation | boolean | Negating the underlying combination of concepts. | |
abstract | http://hl7.org/fhir/concept-properties#notSelectable | boolean | Is this an abstract concept, ie. defined to establish the ontology, so that it cannot be used directly. (only valid for the concept where it is defined) |
testable | code | Is this a testable requirement? | |
comment | http://hl7.org/fhir/concept-properties#comment | string | Comment from Conformance WG |
converse | code | What is the opposite item | |
constrainTo | code | What is a possible constraint? This can be done with the hierarchy, or, in case of conformance verbs, explicitly following this option, although this is not recommended. | |
applyOn | code | Apply on which element level: root, node, leaf, all, notRoot, notLeaf | |
actor | code | Actor |
Concepts
This case-sensitive code system http://v2.hl7.org/fhir/CodeSystem/obligationProposed
defines the following codes in a Is-A hierarchy:
Lvl | Code | Display | Definition | Parent | negation | Not Selectable | testable | Comment | converse | constrainTo | applyOn |
1 | Negation | Negation | Negate the meaning of the concepts that inherit 'negation'. (Negation is not negated again.) | true | true | In principle, negation is to be inherited from concepts that are negated already. Therefore, a negation shall only take effect once, and not negate a negation. | |||||
1 | Verbs | conformance verbs | Conformance verbs are to be used to define the requirement level that is the foundation to indicate what has to be tested. | true | Conformance verbs are primarily interesting for testing, i.e. to indicate what has to be tested. The other concepts can be taken as hints to a developer. | ||||||
2 | MAY | MAY | it is to the developers choice whether an element is supported or not | Verbs | notTestable | MAY primarily provides additional general information, but is still for the discretion of the implementer/developer. | MAYNOT | SHOULD, SHOULDNOT | |||
3 | SHOULD | SHOULD | It is a recommendation to take care of this element | MAY | Just a hint. | SHALL, SHOULDNOT, SHALLNOT | |||||
4 | SHALL | SHALL | This verb denotes a testable requirement. | SHOULD | testable | ||||||
2 | MAYNOT | MAYNOT | It is to the developers choice whether an element is probably not supported. | Verbs, Negation | true | notTestable | MAYNOT is no reasonable option. It is mentioned though to complete the hierarchy. | MAY | |||
3 | SHOULDNOT | SHOULD NOT | it is a recommendation NOT to take care of this element (for some reasons) | MAYNOT | true | SHOULD | SHALLNOT, SHOULD, SHALL | ||||
4 | SHALLNOT | SHALL NOT | it is forbidden to handle this element | SHOULDNOT | true | testable | It may happen for some elements, eg. due to security reasons, not to handle (provided/store/etc.) this element. | SHALL | |||
1 | FunctionalType | Functional Type of Requirement | Functional Type of Requirement | true | |||||||
2 | functional | functional | functional requirement | FunctionalType | |||||||
3 | internal | internal functional | function that operates on the internal data management | functional | |||||||
3 | return | return functional | functional requirement on direct returns | functional | |||||||
3 | response | response function | functional requirement to prepare responses | functional | |||||||
3 | forward | forwarding function | functional requirement to forward data | functional | |||||||
2 | data | data | data requirement | FunctionalType | |||||||
1 | Testable | Type of Testing | Type of Testing | true | |||||||
2 | testable | testable | requirement is testable | Testable | |||||||
3 | testableByMachine | machine testable | requirement is testable by a machine | testable | |||||||
3 | testableByHuman | human testable | requirement is testable by a human (inspection) | testable | |||||||
4 | withChecklist | checklist | requirement is testable by using a checklist | testableByHuman | |||||||
2 | notTestable | testable | requirement is not testable | Testable | true | ||||||
1 | ActorType | Type of Actor | An actor can operate in two ways: with the content itself, or as a manager of the instance. | true | |||||||
2 | transport | transport | handle the transport of data once the instance is available/accessible | ActorType | not sure whether this (and everything related) has to be taken out of this spec? | ||||||
2 | content | content mngmt | manage the data itself | ActorType | |||||||
1 | Actor | Actor of Communication | Actor, i.e. indirect direction of communication | true | |||||||
2 | both | sender and/or receiver | both: sender+receiver resp. creator+consumer | Actor | true | an actor can only do one thing at a certain point in time. Therefore, both is not allowed and only listed for documentation. | |||||
2 | sender | sender | sender (transmitter) of data | Actor, transport | Sender does not necessarily need to create the instance. | ||||||
2 | receiver | receiver | receiver of data | Actor, transport | |||||||
2 | creator | creator | creator of data | Actor, content | Creator does not necessarily need to send the instance. | ||||||
2 | consumer | consumer | Consumer of data | Actor, content | |||||||
2 | router | router | router of data: shall be receiver and sender! | Actor, transport | true | A router is in principle a combination of receiver and sender, w/ possible changes on the data in between. It should be described as such. | |||||
1 | Device | Device for Activity | Device to be used for the activity | true | |||||||
2 | screen | screen | screen/display | Device | |||||||
3 | wideScreen | wide screen | wide screen/display | screen | |||||||
3 | radScreen | radiologic screen | screen/display capable of showing radiologic results | screen | |||||||
2 | printer | printer | printer | Device | |||||||
3 | laserPrinter | laser printer | laser printer | printer | |||||||
3 | matrixPrinter | matrix printer | matrix printer | printer | Sometimes it is important to use a matrix printer, esp. for creating carbon copies. | ||||||
2 | portableStorage | portable storage device | portable storage device | Device | |||||||
3 | usbStick | usb stick | USB Stick | portableStorage | |||||||
3 | tapeDrive | tape drive | tape drive | portableStorage | |||||||
1 | Media | Media | different media to be used with specialised devices | true | |||||||
2 | paper | paper | paper | Media | |||||||
2 | stick | stick | stick | Media | |||||||
2 | disc | disc | disc | Media | |||||||
2 | tape | tape | tape | Media | |||||||
1 | ElementLevel | Level of Application | On which level to apply this obligation: root, node, or leaf | true | |||||||
2 | root | on root node | apply obligation on root node only | ElementLevel | notRoot | ||||||
2 | node | on any node | apply on any node that is not root or leaf | ElementLevel | |||||||
2 | leaf | on leaf node | apply on leaf node only | ElementLevel | |||||||
2 | all | on all levels | application on all levels possible | ElementLevel | |||||||
2 | notRoot | all but root | apply on non-root nodes only | ElementLevel | root | ||||||
2 | notLeaf | all but leaf | apply on non-leaf nodes | ElementLevel | |||||||
1 | Activity | Activity | Activities, aka of general obligation | true | |||||||
2 | FunctionalObligations | Functional Obligations | Functional Obligation describing processsing functionalities | Activity | true | ||||||
3 | ProducerObligations | Resource Producer Obligations | FunctionalObligations | true | |||||||
4 | send | send | convey instance with values to somewhere | ProducerObligations, sender | root | ||||||
4 | populate | populate | populate with values from somewhere | ProducerObligations, creator | prohibited elements can be expressed by 'SHALL NOT send'. | ||||||
5 | from-ui | from UI | Take the data from UI, so that the user has the ability to enter it. | populate | |||||||
5 | from-store | from persistence layer | Take data from storage/persistence layer. | populate | |||||||
5 | generate | generate this data | This data can be generated. | populate | |||||||
6 | from-other | generate from other values | This data can be generated from other data. | generate | |||||||
6 | sequence | generate a sequence number | generate | ||||||||
5 | from-input | from input stream | As a router, take data from input stream. | populate, router | |||||||
5 | as-constant | constant | added as constant to the data, no special treatment done internally | populate | |||||||
5 | into-narrative | narrative | added to the narrative, no special treatment done internally | populate | |||||||
3 | ConsumerObligations | Resource Consumer Obligations | Obligation for Consumer | FunctionalObligations, receiver | true | ||||||
4 | receive | receive | receive data form somewhere | ConsumerObligations, receiver | root | ||||||
4 | process | process | handle data from instances as needed for general message consumption, store permitted. | ConsumerObligations, consumer | elements that are to be ignored can be expressed by 'SHALL NOT process'. | ||||||
5 | follow-up | follow-up activity | what to do internally | process | |||||||
6 | display | display/present (UI) | present the data on a display | follow-up | |||||||
6 | persist | persist | persist/store the data somewhere | router, follow-up | |||||||
7 | archive | archive | persist/store the archive which ensures longlasting access | persist | |||||||
7 | in-database | persist in a database | persist in a database | persist | too explicit/dedicated, concerns application details | ||||||
7 | in-file | store in a file | store in a file | persist | too explicit/dedicated, concerns application details | ||||||
6 | print the data (somewhere) | follow-up | |||||||||
6 | eval | evaluate | consider the data in order to interpret other correctly | follow-up | |||||||
6 | integrate | integrate into data | to UPDATE existing data by merging other data with the existing data in a controlled manner | follow-up | |||||||
5 | respond | activity as response | what to respond | process | |||||||
6 | warning | return warnings | return possible warnings | respond | |||||||
7 | error | return error | return possible errors | warning | |||||||
7 | reject-invalid | reject invalid data | reject if data is invalid | warning | |||||||
6 | accept-invalid | accept invalid data | accept if data is invalid | respond | |||||||
3 | ExchangerObligations | Resource Exchanger Obligations | needs clarification ... | FunctionalObligations, both, router | true | ||||||
4 | route | route forward | as a router forward to the next recipient | ExchangerObligations | false | ||||||
3 | OtherObligations | Resource Other Obligations | Other obligations beyond what has been described above. | FunctionalObligations | true | ||||||
4 | explain | explain | provide an explanation in a capability statement how this element is handled | OtherObligations | |||||||
4 | document | document | document the use of this element in a separate document | OtherObligations | |||||||
2 | DataObligation | Obligations on Data | Data Obligations | Activity, creator, consumer | true | The following codes may apply to creator and consumer. For example 'do not modify from UI'. | |||||
3 | expected | expected | data fits to expectations/specification | DataObligation | This applies to recipients and denotes that the data should be present according to the specification, i.e. is specified. | ||||||
4 | unaltered | preserve | preserve what you get | expected | That may also be used to take data from UI without any modifications. | ||||||
5 | exactly | exactly | exactly what is specified, nothing else | unaltered | not sure whether 'unaltered' is sufficient so that we can drop that!? | ||||||
4 | modify | modify | allow for modifications of the data | expected, consumer | Covers all types of modifications to data. | ||||||
5 | assocation | assocation | taken by association | modify | |||||||
5 | equivalent | equivalent | in an equivalent way | modify | |||||||
5 | 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 | |||||||
6 | 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 | |||||||
6 | 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 | |||||||
5 | 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 | |||||||
5 | truncate | cut off data | cut off remaining characters from the data thereby shortening the data | modify | |||||||
5 | more-details | additional details/values | extends the expected data with more/own information, e.g. appartment if street is specified | modify, creator | This is in principle not a modification... | ||||||
5 | more-structure | additional substructures | provides the data with more granular details, e.g. house number for an address line | modify, creator | This is in principle not a modification... | ||||||
5 | missing | data is missing/not available | provide a null-flavor/absent reason | modify, creator | In FHIR this is the permission/indication for a data-absent-reason or something similar. In V3 it is null-flavor. | ||||||
5 | 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 | |||||||
3 | unexpected | unexpected values | how to manage unexpected data (as sender or receiver) | DataObligation | |||||||
4 | replaces | new/other values | replaces the expected data by something else | unexpected | |||||||
4 | consider | consider unexpected values | take vare of values that are coming but not described/specified. Allows for warnings | unexpected | |||||||
1 | CombinedObligations | combined obligations | The children can be used to encode obligations for data elements. Terms in parenthesis are shown for readability. This list is not complete, and only provides some reasonable samples. | true | The following list is just a snippet and should be enhanced during the discussion..., The hierarchy has to discarded because not everything is explicitly modelled. | ||||||
1 | MAY:populate | MAY populate with data | Conformant applications MAY take and provide data. | CombinedObligations, MAY, populate | is this a useful combination? | ||||||
1 | MAY:populate:missing | MAY populate data element with why orig data is missing | Conformant applications MAY populate the element why the original data is missing. | MAY:populate, missing | |||||||
1 | MAY:(populate)from-ui | MAY populate with data taken from ui | Conformant applications MAY take data from a UI and provide it. | CombinedObligations, MAY, from-ui | |||||||
1 | SHOULD:populate | SHOULD populate with data | Conformant applications SHOULD take and provide data. | CombinedObligations, MAY:populate | |||||||
1 | MAY:(populate)into-narrative | MAY populate into-narrative | Conformant applications MAY populate element into narrative text as well. | CombinedObligations, SHOULD:populate | discuss whether other representation forms are better | ||||||
1 | SHOULD:(populate)into-narrative | SHOULD populate into-narrative | Conformant applications SHOULD populate element into narrative text as well. | CombinedObligations, MAY:(populate)into-narrative | discuss whether other representation forms are better | ||||||
1 | SHALL:(populate)into-narrative | SHALL populate into-narrative | Conformant applications SHALL populate element into narrative text as well. | CombinedObligations, SHOULD:(populate)into-narrative | discuss whether other representation forms are better | ||||||
1 | SHOULDNOT:(populate)into-narrative | SHOULD NOT populate into-narrative | Conformant applications SHOULD NOT populate element into narrative text. | CombinedObligations | SHOULD:(populate)into-narrative | ||||||
1 | SHALLNOT:(populate)into-narrative | SHALL NOT populate into-narrative | Conformant applications SHALL NOT populate element into narrative text. | CombinedObligations, SHOULDNOT:(populate)into-narrative | SHALL:(populate)into-narrative | ||||||
1 | SHALL:populate | SHALL populate with data | Conformant applications SHOULD take and provide data. | SHOULD:populate | |||||||
1 | SHOULD:(populate)from-ui | SHOULD populate with data taken from ui | Conformant applications SHOULD take data from a UI and provide it. | CombinedObligations, SHOULD, from-ui, creator | |||||||
1 | SHALL:(populate)from-ui | SHALL populate data taken from ui | Conformant applications SHALL take data from a UI and provide it. | SHOULD:(populate)from-ui, SHALL, from-ui | testableByHuman | ||||||
1 | SHALL:(populate)from-ui:more-details | SHALL populate with data taken from ui perhaps with more details | Conformant applications SHALL take data from a UI and bring it into the instance. It is allowed to provide more details then specified. | SHALL:(populate)from-ui, more-details | |||||||
1 | SHOULD:send | SHOULD send the instance | Conformant applications SHOULD send the instance. | CombinedObligations | |||||||
2 | SHALL:send | SHALL send the instance | Conformant applications SHALL send the instance. | CombinedObligations, SHALL, send, sender | testableByMachine | root | |||||
1 | MAY:persist | MAY store the data | Conformant applications MAY store the data. | CombinedObligations, MAY, persist | |||||||
1 | SHOULD:persist | SHOULD store the data | Conformant applications SHOULD store the data. | CombinedObligations | |||||||
2 | SHALL:persist | SHALL store the data somewhere | Conformant applications SHALL store the data in some way. | CombinedObligations, SHALL, persist | testableByHuman | ||||||
3 | SHALL:persist:exactly | SHALL store the data somewhere, but exactly as is sent | Conformant applications SHALL store the data in a way that the originally data from the instance can be reestablished. | CombinedObligations, SHALL, persist, exactly | testableByHuman | ||||||
2 | SHOULD:(persist)in-database | SHOULD store the data in a database | Conformant applications are asked to store the data in a database. | CombinedObligations, SHOULD, persist, in-database | |||||||
2 | SHALLNOT:populate:more-details | SHALL NOT populate more data than is specified | Conformant applications SHALL NOT populatae more data than is specified. The specification is closed. | CombinedObligations, SHALLNOT, populate, more-details, creator | true | testableByMachine | |||||
2 | SHALLNOT:populate:missing | SHALL NOT populate info about missing data, ie. data absent reasons | Conformant applications SHALL NOT populate a reason for missing information. | CombinedObligations, SHALLNOT, populate, missing, creator | true | ||||||
2 | MAY:populate:more-structure | MAY populate the data in more structured way | Conformant applications are allowed to populate the data with more structure. For example, to split an address line into streetname and house number. | CombinedObligations, MAY, populate, more-structure | |||||||
2 | SHALLNOT:follow-up:truncate | SHALL NOT truncate data | Conformant applications SHALL NOT cut off data. | CombinedObligations, SHALLNOT, follow-up, truncate, consumer | true | testableByHuman | |||||
2 | MAY:modify | MAY modify the data | Conformant applications MAY, i.e. are allowed to modify the data. | CombinedObligations, MAY, modify | nice hint | ||||||
2 | MAY:print | MAY print data | Conformant applications MAY print the data. | CombinedObligations, MAY, print | |||||||
2 | SHOULD:print | SHOULD print data | Conformant applications SHOULD print the data. | CombinedObligations, SHOULD, print | |||||||
2 | SHALL:print | SHALL print data | Conformant applications SHALL print the data. | CombinedObligations, SHALL, print, consumer | testableByHuman | ||||||
1 | SHALLNOT:(populate):in-narrative | SHALL NOT add to narrative | Conformant applications SHALL NOT add this data to the narrative. | CombinedObligations, SHALLNOT, populate, into-narrative, creator | testableByHuman | ||||||
1 | MAY:process | MAY process the data | Conformant applications MAY process the data somehow. | CombinedObligations, MAY, process | There is no further specification in which way the data can be processed. | ||||||
1 | SHOULD:process | SHOULD process the data | Conformant applications SHOULD process the data in some meaningful way. | CombinedObligations, MAY:process | |||||||
1 | SHALL:process | SHALL process the data | Conformant applications SHALL process the data in some meaningful way. | CombinedObligations, SHOULD:process | |||||||
1 | SHOULDNOT:process | SHOULD NOT process the data | Conformant applications SHOULD NOT process the data in some meaningful way. | CombinedObligations, SHOULDNOT, process | |||||||
1 | SHALLNOT:process | SHALL NOT process the data | Conformant applications SHALL NOT process the data in some meaningful way. | SHOULDNOT:process, SHALLNOT, process | |||||||
1 | SHOULD:document | SHOULD document how the data is used | Conformant applications SHOULD document the way the data is used in some (meaningful) way. | CombinedObligations, SHOULD, document | |||||||
1 | SHALL:document | SHALL document how the data is used | Conformant applications SHALL document the way the data is used in some (meaningful) way. | SHOULD:document, SHALL, document | |||||||
1 | SHOULD:display | SHOULD display the data | Conformant applications SHOULD display the data in some meaningful way. | CombinedObligations, SHOULD, display | |||||||
1 | SHALL:display | SHALL display the data | Conformant applications SHALL display the data in some meaningful way. | CombinedObligations, SHOULD:display | |||||||
1 | SHOULDNOT:modify | SHOULD NOT modify the data | Conformant applications SHOULD NOT modiify the data in any way. | CombinedObligations, SHOULDNOT, modify | |||||||
1 | SHALLNOT:modify | SHALL NOT modify the data | Conformant applications SHALL NOT modiify the data in any way. | CombinedObligations, SHALLNOT, modify | |||||||
1 | MAYNOT:process | MAY NOT process data | Conformant applications MAY NOT process data, aka of ignoring. | CombinedObligations, MAYNOT, process | this is equivalent to MAY:ignore. | ||||||
1 | SHOULD:reject-invalid | SHOULD reject invalid data | Conformant applications SHOULD reject invalid data. | CombinedObligations, SHOULD, reject-invalid | |||||||
1 | SHALL:reject-invalid | SHALL reject invalid data | Conformant applications SHALL reject invalid data. | CombinedObligations, SHALL, reject-invalid | |||||||
1 | SHOULD:accept-invalid | SHOULD accept invalid data | Conformant applications SHOULD accept invalid data. | CombinedObligations, SHOULD, accept-invalid | |||||||
1 | SHALL:accept-invalid | SHALL accept invalid data | Conformant applications SHALL accept invalid data. | CombinedObligations, SHALL, accept-invalid | |||||||
1 | SHOULD:receive | SHOULD be able to receive the data | Conformant applications SHOULD be able to receive the data. | CombinedObligations, SHOULD, receive | |||||||
1 | SHALL:receive | SHALL be able to receive the data | Conformant applications SHALL be able to receive the data. | CombinedObligations, SHALL, receive | |||||||
1 | SHOULDNOT:error | SHOULD NOT return an error to the sender of the data | Conformant applications SHOULD NOT reurn an erorr to the sender of the data. | CombinedObligations, SHOULDNOT, error | |||||||
1 | SHALLNOT:error | SHALL NOT return an error to the sender of the data | Conformant applications SHALL NOT reurn an erorr to the sender of the data. | CombinedObligations, SHALLNOT, error | |||||||
1 | ForeignStandards | concept codes from other standards | Other standards use specific terms for optionality/usage that should be conceptualized here. | CombinedObligations | true | ||||||
1 | v2 | v2 concept codes | optionality/usage codes from v2 | ForeignStandards | true | ||||||
2 | v2-r | v2: R | required in v2.x | v2, SHALL, populate | minCard = 1 | ||||||
2 | v2-re | v2: RE | required but may be empty in v2.x | v2, SHALL, populate | minCard = 0 | ||||||
2 | v2-x | v2: X | forbidden in v2 | v2, SHOULDNOT, populate, process | |||||||
2 | v2-b | v2: B | backwards use in v2 only | v2, SHOULDNOT | |||||||
2 | v2-w | v2: W | withdrawn use in v2 only | v2, SHOULDNOT, populate, process | |||||||
1 | v3 | V3 concept codes | optionality/usage codes from V3/CDA | ForeignStandards | true | ||||||
2 | v3-m | v3: M | mandatory in IHE V3 | v3, SHALL, populate, exactly, SHALLNOT:populate:missing | A value must be present and null-flavors are not allowed; to be combined with minCard = 1 | ||||||
2 | v3-r | v3: R | required in IHE V3 | v3, SHALL, populate, MAY:populate:missing | A value must be present but it can be a null-flavors | ||||||
2 | v3-x | v3: X | forbidden in IHE V3 | v3, SHALLNOT, populate | |||||||
1 | ihe | IHE concept codes | optionality/usage codes from IHE | ForeignStandards | true | ||||||
2 | ihe-r | IHE: R | required in IHE v2.x specs | ihe | |||||||
2 | ihe-r2 | IHE: R2 | R2 in IHE v2.x specs | ihe, SHALL:process, SHOULD:populate | This is interpreted as the receiver has to support it, but when becoming the sender it is not really necessary to return it again | ||||||
2 | ihe-x | IHE: X | XX in IHE v2.x specs | ihe | forbidden? | ||||||
1 | xDT | German xDT standards | The German xDT standard family has a very specific set of codes and is just presented here for completeness and demonstration purposes | ForeignStandards | true | all concept codes are to processed by the receiver; different requirements for sender | |||||
2 | xDT-M | xDT: M | MUSS in xDT (unbedingtes Mussfeld) | xDT, SHALL, SHALL:process, SHALL:populate | minCard=1 | ||||||
2 | xDT-m | xDT: m | muss in xDT (bedingtes Mussfeld) | xDT, SHALL, SHALL:process, SHALL:populate | depends on the value of another field | ||||||
2 | xDT-K | xDT: K | KANN in xDT (unbedingts KANNfeld) | xDT, SHALL, SHALL:process, SHALL:populate | |||||||
2 | xDT-k | xDT: k | kann in xDT (bedingtes Kannfeld) | xDT, SHALL, SHALL:process, SHALL:populate | depends on the value of another field |
Please consider that the hierarchy levels are only introduced for convenience when reading the codesystem. It can be used to identify the primary axes. In total it is in principle a poly-hierarchy that is established using the parent relationship, thereby introducing multiple parents from the different axes, each starting with level 1.
There are several topics open for discussion. Those are indicated in the comments.
Any other issues?
Some examples may help to understand how this codesystem is to be used. In general, only values below the “green concept” in the mindmap in the introduction can be instantiated. All others are for definitional purposes.
The following table may help to understand some examples and common use cases:
Code | Explanation |
---|---|
SHALL:populate | The system SHALL be capable of providing data for the instance and populating this element accordingly. |
SHOULD:send | In double contrast to the previous code, the system is neither required to do something in general, nor especially to create the instance. It is asked for sending the data instance. It is common or good practice, in other words there is some incidence to implement it, but a vendor can also decide not to do so. |
.:populate:. | Does not denote that the created artifact has to be sent over the wire. Instead, the creation itself is indicated. |
.:missing | The system can use information why requested details are missing. This is aka of null-flavor or data-abstent-reason. |
Another outstanding question is the combination of elements like “either A or B must …”. Can this be solved with invariants? Or are other type of constructs necessary?