Uploaded image for project: 'Specification'
  1. SPEC-91

Correct anomalies in use of CODE_PHRASE and DV_CODED_TEXT

    Details

    • Change Description:
      Hide
      Make TERM_MAPPING.purpose optional. Convert all starred
      attributes in the list above to CODE_PHRASE, the rest to
      DV_CODED_TEXT. Define an openEHR Terminology and an access method
      in the Support IM specification which enables value set groups
      (used for the non-starred attributes above) and code sets (used
      for the starred attributes above) to be accessed in invariants.
      Remove the current method of referring to Terminology identifiers.

      The openEHR vocabularies for these attributes should list direct
      mappings to e.g. CEN, HL7 and other terms for the same concepts.
      This is a better approach than directly relying on the standards
      bodies for up to date vocabularies.
      Show
      Make TERM_MAPPING.purpose optional. Convert all starred attributes in the list above to CODE_PHRASE, the rest to DV_CODED_TEXT. Define an openEHR Terminology and an access method in the Support IM specification which enables value set groups (used for the non-starred attributes above) and code sets (used for the starred attributes above) to be accessed in invariants. Remove the current method of referring to Terminology identifiers. The openEHR vocabularies for these attributes should list direct mappings to e.g. CEN, HL7 and other terms for the same concepts. This is a better approach than directly relying on the standards bodies for up to date vocabularies.
    • Approved By:
      PG

      Description

      Within the reference model, there are several structural
      attributes which are coded from a specified vocabulary. In some
      cases, such as 'territory', 'language', and 'mime type', the
      vocabulary is really just a list of codes - there are no rubrics,
      and no idea of translation (i.e. within computer systems, 'jp', the
      country code of Japan is 'jp' in all languages, including
      japanese). These codes can be expressed in the model directly
      using CODE_PHRASEs. Any attribute which is not the name of
      something in the real world, but is either an acronym (e.g. "RSA")
      or a self-defining word (e.g. "gzip") is in this category.
        
      However, other structural (predefined) attributes should be
      expressed as proper coded texts. Examples include
      RELATED_PARY.relationship, PARTICIPATION.mode, and any other term
      which should be viewable in the user interface in the local
      language.

      Currently these guidelines are not followed properly: there are a
      number of structural coded attributes which are expressed as a
      bare CODE_PHRASE, when a DV_CODED_TEXT should be used.

      Another problem is that the location of the attributes for
      language and charset on DV_TEXT probably is not optimal. No-one
      has a use case in which language could vary at any finer level
      than Entry (since Entries are the minimum indivisible unit of
      information in openEHR); it may not even be necessary to record
      charset at all, if we assume Unicode UTF-8. If we assume unicode,
      but the byte encoding can vary from UTF-8 to UTF-16, which could
      be the case for EHRs in the US versus EHRs in China, then we still
      do need to record which encoding it is.

      The current list of 'structural' attributes is as follows. Starred
      items are code only attributes:

       *DV_TEXT.language
       *DV_TEXT.charset
       DV_QUANTITY.property
       *DV_MULTIMEDIA.media_type
       *DV_MULTIMEDIA.compression_algorithm
       *DV_MULTIMEDIA.integrity_check_algorithm
       TERM_MAPPING.purpose
       *DV_ENCAPSULATED.charset
       *DV_ENCAPSULATED.language

       ATTESTATION.status
       PARTICIPATION.mode
       RELATED_PARTY.relationship
       VERSION_AUDIT.change_type
       FEEDER_AUDIT.change_type

       *COMPOSITION.territory
       EVENT_CONTEXT.setting
       ELEMENT.null_flavour

        Attachments

          Activity

            People

            • Assignee:
              OLDthomasbeale OLDthomasbeale
              Reporter:
              OLDthomasbeale OLDthomasbeale
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: