OPT annotations inconsistencies

Implementation Tools
1

Hi all,

I was checking some OPT samples I have, that were generated using different modeling tools.

Here you can see items contains a text node, while in the second example items contains a value element that contains a text node:

Example 1:

<annotations path="[openEHR-EHR-OBSERVATION.promis.v0]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.promis_bank_v20_physical_function.v0]/items[at0009]">
    <items id="item_code">PFA53</items>
  </annotations>

Example 2:

 <annotations path="[openEHR-EHR-COMPOSITION.referral.v1]/content[openEHR-EHR-SECTION.problem_list.v1]/items[at0001][openEHR-EHR-EVALUATION.clinical_synopsis.v1]">
    <items id="default">
      <value>For use ONLY if structured data is not available</value>
    </items>
  </annotations>

I’m not sure if we agreed on a “valid” OPT1.4 XML Schema, and I’m trying to adapt the XSD that I have to comply with this, so which one of those is the valid one? :slight_smile:

2

I vote (1) - I suspect (2) was generated by a version of Template Designer that inadvertantly introduced a breaking change.

3

I think so, but its difficult to know which one is correct having samples coming from different places and form different tools :slight_smile:

It makes it more complex to keep everyone happy :stuck_out_tongue:

As you know, I did some changes trying to comply with some modifications done by tolling to the original OPT schema, here is my current XSD https://github.com/ppazos/cabolabs-ehrserver/blob/master/src/main/webapp/xsd/OperationalTemplateExtra.xsd (that contains the value node inside items). I believe that was added from one sample you provided hehe.

4

Oops. Just t oupset you more, here is what happens when you pull through annotations in archetypes (in CKM).

<annotations path="[openEHR-EHR-COMPOSITION.encounter.v1]/content[openEHR-EHR-SECTION.adhoc.v1]/items[openEHR-EHR-SECTION.adhoc.v1, 'E - Exposure']/items[openEHR-EHR-OBSERVATION.laboratory_test_result.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]/items[at0024]">
   <items id="hl7v2_mapping">OBX.3</items>
   <items id="fhir_mapping">Observation.code</items>
 </annotations>

In AD this is

<annotations path="[openEHR-EHR-COMPOSITION.adverse_reaction_list.v1]">
        <items id="test">me</items> <!-- Added in template -->
    </annotations>
    <annotations path="[openEHR-EHR-COMPOSITION.adverse_reaction_list.v1]/content[openEHR-EHR-SECTION.allergies_adverse_reactions_rcp.v1]/items[openEHR-EHR-EVALUATION.adverse_reaction_risk.v1]">
        <items id="source">openEHR,FHIR</items>
    </annotations>

and Template Designer 2.8 is

<annotations path="[openEHR-EHR-COMPOSITION.summary.v1]">
    <items id="GUI Directives.Group">testing</items>
  </annotations>

So I think we have consensus!! Forget the value node.

5

Thanks Ian. FYI, I got this eReferral OPT which has the value in the annotation, not sure which editor was used to generate it:

e5f533a2_7480_4b53_91f6_9b83433f36ab.en.v1.opt (687.2 KB)

6

This is really old template which should probably be deprecated.

1 Like
7

Gotcha, thinking about all the source we could have for authoring OPTs, and knowing there are differences that are currently unmanaged and unmanageable, I would like to suggest to add some kind of metadata to the OPTs that is mandatory and states which tolling and version was used to generate it. I know the TD adds come comment on the top, but I think should be in a header node of the OPT that can be read by apps.