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

Re-evaluate COMPOSITION.is_persistent attribute

    Details

    • Change Description:
      Hide
      The attribute is_persistent should be changed to a an
      attribute called "category" of type DV_CODED_TEXT, where the code
      must come from the openEHR vocabulary for "composition category".
      This is ensured by the following invariant in the class
      Composition:
       Category_validity: category /= Void and then
       terminology(���openehr���).codes_for_group_name(���composition
       category", ���en���).has(category.defining_code)

      To remain backward compatible and for convenience, a function
      "is_persistent: Boolean" is added to Composition. This has the
      same signature as the attribute being replaced, and should return
      True when the new category attribute contains the code for
      "persistent".

      The related invariant:
       Is_persistent_validity: is_persistent xor context /= Void
      should be modified to the weaker version:
       Is_persistent_validity: not (is_persistent and context
       /= Void)
      Another invariant should be added to guarantee that
      'is_persistent' returns True when 'category' has the code for the
      term "persistent":
       Is_persistent_value: is_persistent implies
       terminology(���openehr���).rubric_for_code(category.defining_code.
       code_string, ���en���).is_equal(���persistent���)

      A vocabulary needs to be added to the support model, which
      initially will contain only the terms for "persistent", "event"
      and "process" until a more standardised vocabulary becomes
      available.
      Show
      The attribute is_persistent should be changed to a an attribute called "category" of type DV_CODED_TEXT, where the code must come from the openEHR vocabulary for "composition category". This is ensured by the following invariant in the class Composition:  Category_validity: category /= Void and then  terminology(���openehr���).codes_for_group_name(���composition  category", ���en���).has(category.defining_code) To remain backward compatible and for convenience, a function "is_persistent: Boolean" is added to Composition. This has the same signature as the attribute being replaced, and should return True when the new category attribute contains the code for "persistent". The related invariant:  Is_persistent_validity: is_persistent xor context /= Void should be modified to the weaker version:  Is_persistent_validity: not (is_persistent and context  /= Void) Another invariant should be added to guarantee that 'is_persistent' returns True when 'category' has the code for the term "persistent":  Is_persistent_value: is_persistent implies  terminology(���openehr���).rubric_for_code(category.defining_code.  code_string, ���en���).is_equal(���persistent���) A vocabulary needs to be added to the support model, which initially will contain only the terms for "persistent", "event" and "process" until a more standardised vocabulary becomes available.
    • Approved By:
      ARB

      Description

      While there is a clear need to be able to differentiate
      between "persistent" (e.g. family history, therapeutic
      precautions) and "event" Compositions (patient contact, test
      result), there may be more types which need to be classified, e.g.
      types such as current medications and problem list whcih are
      currently seen as persistent, perhaps should be a subtype which
      means "persistent, regeneratable", meaning their content may be
      partly derived from querying. Other Compositions to do with e.g.
      pregnancy which are relatively long-lived, but do have finite
      durations and are not of interest for much time past the end,
      should perhaps be marked as "process" or similar.

      One solution would be to change COMPOSITION and
      VERSIONED_COMPOSITION.is_persistent: Boolean to e.g. type:
      DV_TEXT, and make the types a controlled vocabulary.

      DK: We are about to review the code-set for revision_status in
      EHRcom to consider these issues. Can I suggest that we adopt a
      placeholder attribute that is not Boolean, and add a code-set
      in a couple of months.
        
      The functional behaviour requirements which this attribute
      satisfies should be described in the documentation.

      DL: describe behaviour on record opening, committal, etc.

        Attachments

          Activity

            People

            • Assignee:
              OLDthomasbeale JeffJ
              Reporter:
              dipakkalra Dipak Kalra
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: