Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

<DV_CODED_TEXT attribute_name="value">
<constraint<constraints attribute_name="defining_code" min_op=">=" min="1" max_op="<=" max="1" class="radio-buttons">
[
{
" <constraint code_string": ="at1003",
"terminology": ="local",
"description=": "The subject was standing.",
"value": ="Standing"></constraint>
},
{
" <constraint code_string": ="at1001",
"terminology=": "local",
"description": ="The subject was sitting (for example on bed or chair).",
"value": ="Sitting"></constraint>
}, </constraints>
...TO BE ]
CONTINUED </constraint>ANOTHER DAY...

TBD: If a recieving platform uses ECISFLAT-format then then perhaps using the compact syntax "terminology::code" for CODE_PHRASE or "terminology::code|value|" for DV_CODED_TEXT content alternatives would be an option?'

<selection class="multi-check" min="1" max="1" class="radio-buttons" path="/content[openEHR-EHR-SECTION....">
<DV_CODED_TEXT defining_code="local::at1003" description="The subject was standing.">Standing</DV_CODED_TEXT>
  <DV_CODED_TEXT defining_code="local::at1001" description="The subject was sitting (for example on bed or chair).">Sitting</DV_CODED_TEXT>
</selection>
...TO BE CONTINUED ANOTHER DAY...

References

[1]
H. van der Linden, T. Austin, J. Talmon, Generic screen representations for future-proof systems, is it possible? There is more to a GUI than meets the eye, Comput Methods Programs Biomed. 95 (2009) 213–226. doi:10.1016/j.cmpb.2009.03.003.
Model Driven Development of Clinical Information Sytems using openEHR
Koray ATALAG , Hong Yul YANG, Ewan TEMPERO, Jim WARREN 

...