Generated Narrative: CodeSystem obligationProposed Language: en Properties This code system defines the following properties for its concepts Name Code URI Type Description Parent parent http://hl7.org/fhir/concept-properties#parent code Who is the parent element of this concept? Multiple parents are possible. negation negation boolean Negating the underlying combination of concepts. Not Selectable 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 testable code Is this a testable requirement? Comment comment http://hl7.org/fhir/concept-properties#comment string Comment from Conformance WG converse converse code What is the opposite item constrainTo 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 applyOn code Apply on which element level: root, node, leaf, all, notRoot, notLeaf actor 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 print 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 HL7 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 HL7 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 HL7 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 X 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
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.
Who is the parent element of this concept? Multiple parents are possible.
Negating the underlying combination of concepts.
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)
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.
Apply on which element level: root, node, leaf, all, notRoot, notLeaf
Negate the meaning of the concepts that inherit 'negation'. (Negation is not negated again.)
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.
Conformance verbs are to be used to define the requirement level that is the foundation to indicate what has to be tested.
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.
it is to the developers choice whether an element is supported or not
MAY primarily provides additional general information, but is still for the discretion of the implementer/developer.
It is a recommendation to take care of this element
This verb denotes a testable requirement.
It is to the developers choice whether an element is probably not supported.
MAYNOT is no reasonable option. It is mentioned though to complete the hierarchy.
it is a recommendation NOT to take care of this element (for some reasons)
It may happen for some elements, eg. due to security reasons, not to handle (provided/store/etc.) this element.
function that operates on the internal data management
functional requirement on direct returns
functional requirement to prepare responses
requirement is testable by a human (inspection)
requirement is testable by using a checklist
An actor can operate in two ways: with the content itself, or as a manager of the instance.
handle the transport of data once the instance is available/accessible
not sure whether this (and everything related) has to be taken out of this spec?
Actor, i.e. indirect direction of communication
both: sender+receiver resp. creator+consumer
an actor can only do one thing at a certain point in time. Therefore, both is not allowed and only listed for documentation.
Sender does not necessarily need to create the instance.
Creator does not necessarily need to send the instance.
router of data: shall be receiver and sender!
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.
screen/display capable of showing radiologic results
Sometimes it is important to use a matrix printer, esp. for creating carbon copies.
different media to be used with specialised devices
On which level to apply this obligation: root, node, or leaf
apply on any node that is not root or leaf
Functional Obligation describing processsing functionalities
convey instance with values to somewhere
prohibited elements can be expressed by 'SHALL NOT send'.
Take the data from UI, so that the user has the ability to enter it.
Take data from storage/persistence layer.
This data can be generated from other data.
As a router, take data from input stream.
added as constant to the data, no special treatment done internally
added to the narrative, no special treatment done internally
handle data from instances as needed for general message consumption, store permitted.
elements that are to be ignored can be expressed by 'SHALL NOT process'.
persist/store the archive which ensures longlasting access
too explicit/dedicated, concerns application details
consider the data in order to interpret other correctly
to UPDATE existing data by merging other data with the existing data in a controlled manner
as a router forward to the next recipient
Other obligations beyond what has been described above.
provide an explanation in a capability statement how this element is handled
document the use of this element in a separate document
The following codes may apply to creator and consumer. For example 'do not modify from UI'.
This applies to recipients and denotes that the data should be present according to the specification, i.e. is specified.
That may also be used to take data from UI without any modifications.
not sure whether 'unaltered' is sufficient so that we can drop that!?
Covers all types of modifications to data.
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.
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.
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.
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.
cut off remaining characters from the data thereby shortening the data
extends the expected data with more/own information, e.g. appartment if street is specified
This is in principle not a modification...
provides the data with more granular details, e.g. house number for an address line
In FHIR this is the permission/indication for a data-absent-reason or something similar. In V3 it is null-flavor.
this value has no valid representation or meaning in the sending application, it is just added because it is required to be there
how to manage unexpected data (as sender or receiver)
replaces the expected data by something else
take vare of values that are coming but not described/specified. Allows for warnings
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.
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.
Conformant applications MAY take and provide data.
MAY populate data element with why orig data is missing
Conformant applications MAY populate the element why the original data is missing.
Conformant applications MAY take data from a UI and provide it.
Conformant applications SHOULD take and provide data.
Conformant applications MAY populate element into narrative text as well.
discuss whether other representation forms are better
Conformant applications SHOULD populate element into narrative text as well.
Conformant applications SHALL populate element into narrative text as well.
Conformant applications SHOULD NOT populate element into narrative text.
Conformant applications SHALL NOT populate element into narrative text.
Conformant applications SHOULD take data from a UI and provide it.
Conformant applications SHALL take data from a UI and provide it.
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.
Conformant applications SHOULD send the instance.
Conformant applications SHALL send the instance.
Conformant applications MAY store the data.
Conformant applications SHOULD store the data.
Conformant applications SHALL store the data in some way.
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.
Conformant applications are asked to store the data in a database.
SHALL NOT populate more data than is specified
Conformant applications SHALL NOT populatae more data than is specified. The specification is closed.
SHALL NOT populate info about missing data, ie. data absent reasons
Conformant applications SHALL NOT populate a reason for missing information.
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.
Conformant applications SHALL NOT cut off data.
Conformant applications MAY, i.e. are allowed to modify the data.
Conformant applications MAY print the data.
Conformant applications SHOULD print the data.
Conformant applications SHALL print the data.
Conformant applications SHALL NOT add this data to the narrative.
Conformant applications MAY process the data somehow.
There is no further specification in which way the data can be processed.
Conformant applications SHOULD process the data in some meaningful way.
Conformant applications SHALL process the data in some meaningful way.
Conformant applications SHOULD NOT process the data in some meaningful way.
Conformant applications SHALL NOT process the data in some meaningful way.
Conformant applications SHOULD document the way the data is used in some (meaningful) way.
Conformant applications SHALL document the way the data is used in some (meaningful) way.
Conformant applications SHOULD display the data in some meaningful way.
Conformant applications SHALL display the data in some meaningful way.
Conformant applications SHOULD NOT modiify the data in any way.
Conformant applications SHALL NOT modiify the data in any way.
Conformant applications MAY NOT process data, aka of ignoring.
Conformant applications SHOULD reject invalid data.
Conformant applications SHALL reject invalid data.
Conformant applications SHOULD accept invalid data.
Conformant applications SHALL accept invalid data.
Conformant applications SHOULD be able to receive the data.
Conformant applications SHALL be able to receive the data.
SHOULD NOT return an error to the sender of the data
Conformant applications SHOULD NOT reurn an erorr to the sender of the data.
SHALL NOT return an error to the sender of the data
Conformant applications SHALL NOT reurn an erorr to the sender of the data.
Other standards use specific terms for optionality/usage that should be conceptualized here.
A value must be present and null-flavors are not allowed; to be combined with minCard = 1
A value must be present but it can be a null-flavors
This is interpreted as the receiver has to support it, but when becoming the sender it is not really necessary to return it again
The German xDT standard family has a very specific set of codes and is just presented here for completeness and demonstration purposes
all concept codes are to processed by the receiver; different requirements for sender