Proper way of discerning between siblings that are instances of the same archetype in COMPOSITION

Implementation Apps
1

Hi everyone, we’re currently running a scenario here in Brazil in which modelers create the COMPOSITION in Ocean’s Template Designer, export the OPT and TDS and deploy them to be distributed to external/public implementers. Since most of them have zero to little knowledge about openEHR, they use the TDS to create TDDs, and internally we have some transformation logic to turn them into canonical XML instances and commit (we’re refactoring from EtherCIS to EHRbase).
A major issue we’re dealing with is how to address siblings that are instances of the same archetype (e.g. happen at the same lavel with the same archetype_node_id). Currently we’re facing errors such as:

<Map>
    <error>Internal Server Error: org.ehrbase.validation.constraints.wrappers.ValidationException: :Validation error at /content[openEHR-EHR-SECTION.problem_list.v1]/items[openEHR-EHR-ACTION.procedure-HAOC.v1]/description[at0001]/items[at0060], Mandatory element missing, expected:[1..1]
Validation error at /content[openEHR-EHR-SECTION.problem_list.v1]/items[openEHR-EHR-ACTION.procedure-HAOC.v1]/description[at0001]/items[at0.74], Mandatory element missing, expected:[1..1]
Validation error at /content[openEHR-EHR-SECTION.problem_list.v1]/items[openEHR-EHR-ACTION.procedure-HAOC.v1]/description[at0001]/items[at0.70], Mandatory element missing, expected:[1..1]
Validation error at /content[openEHR-EHR-SECTION.problem_list.v1]/items[openEHR-EHR-ACTION.procedure-HAOC.v1]/description[at0001]/items[at0002.1], Mandatory element missing, expected:[1..1]
Validation error at /content[openEHR-EHR-SECTION.problem_list.v1]/items[openEHR-EHR-EVALUATION.problem_diagnosis-ms_br.v1]/data[at0001]/items[at0002.1], Mandatory element missing, expected:[1..1]
</error>
    <status>Internal Server Error</status>
</Map>

By inspecting the composition, we can see the data points are there, but I believe the server might be validating against the wrong definition because there are multiple /content[openEHR-EHR-SECTION.problem_list.v1] siblings with different restrictions created from a more generic archetype. What is the proper way to reference them (not only for server validation, but also for app controls, such as AQL)? Since they are optional, we cannot rely on index. It could also happen on a deeper level in the COMPOSITION. I think I’ve seen some EtherCIS code using the name attribute to reference them, but this could lead to unexpected behaviors due to relying on localized text such as mishandled languages/translations. What about archetyped text codes/definitions?
I’ve uploaded the OPT, TDS, TDD and composition files at https://gist.github.com/ricardofago/7446ea8f8611add03faa14afe35603d1.

2

Hi Ricardo,

Christian will take a look at this. See: https://github.com/ehrbase/ehrbase/issues/24

Best,

Birger

3

Hi Birger,

Thanks, I noticed the updates on the issue. I asked here as well (as suggested by @thomas.beale) because I’m not sure if my understanding of path traversal and predicate coding is correct with regards to the specification itself.

4

As I understand it, at least Ocean, Better and Ethercis (perhaps others, generally add a suffix to the name/value attribute e.g.

"resultSet": [
    {
      "uid": "79baa53b-fc38-4a0b-85c1-bbb710a6a11a::local.ethercis.com::1",
      "siteValue": null,
      "siteName": "Body site",
      "siteValue2": "Body site 0"
    },
    {
      "uid": "79baa53b-fc38-4a0b-85c1-bbb710a6a11a::local.ethercis.com::1",
      "siteValue": null,
      "siteName": "Body site #2",
      "siteValue2": "Body site 1"
    }
  ]
}

or the full composition in canonical json ( this is from Ethercis)

...{

            "items": [
              {
                "@class": "EVALUATION",
                "name": {
                  "@class": "DV_TEXT",
                  "value": "Diagnosis"
                },
                "archetype_node_id": "openEHR-EHR-EVALUATION.problem_diagnosis.v1",
                "archetype_details": {
                  "@class": "ARCHETYPED",
                  "archetype_id": {
                    "@class": "ARCHETYPE_ID",
                    "value": "openEHR-EHR-EVALUATION.problem_diagnosis.v1"
                  },
                  "rm_version": "1.0.1"
                },
              
                "data": {
                  "items": [
                    {
                      "@class": "ELEMENT",
                      "name": {
                        "@class": "DV_TEXT",
                        "value": "Diagnosis name"
                      },
                      "archetype_node_id": "at0002",
                      "value": {
                        "@class": "DV_TEXT",
                        "value": "Eczema"
                      }
                    },
                    {
                      "@class": "ELEMENT",
                      "name": {
                        "@class": "DV_TEXT",
                        "value": "Body site"
                      },
                      "archetype_node_id": "at0012",
                      "value": {
                        "@class": "DV_TEXT",
                        "value": "Elbow"
                      }
                    },
        
                    {
                      "@class": "ELEMENT",
                      "name": {
                        "@class": "DV_TEXT",
                        "value": "Body site #2"
                      },
                      "archetype_node_id": "at0012",
                      "value": {
                        "@class": "DV_TEXT",
                        "value": "Knee"
                      }
                    }
                  ],
                  "archetypeNodeId": "at0001",
                  "name": {
                    "@class": "DV_TEXT",
                    "value": "structure"
                  }
                }
              }
            ]
          }
        ]
      }
5

Yeah, that’s how Template Designer handles cloning an element as well, considering it uses name/value as predicate when needed. But wouldn’t it lead to issues (i.e. AQL would only work with the same language used to commit the composition instance, archetypes with translations to different languages, etc.)?

I think we also had some situations in the past with EtherCIS when using local archetypes created in Portuguese (for some English wasn’t the primary language, others didn’t even have English translations).

6

Is the OPT correctly exported? Has the correspondent constraints for each SECTION?

Also, I think if the sections are different, because contain different constraints, those should have different node_ids, which are used to differentiate between siblings of the same type. I’m not sure if the TD handles that correctly.

Can you share the OPT and a complete instance XML to double check if that looks OK?

7

I referenced the OPT and composition files through Gist (https://gist.github.com/ricardofago/7446ea8f8611add03faa14afe35603d1). The OPT was exported from Template Designer and the composition was transformed from a handwritten TDD that matches a TDS also exported from Template Designer. The section archetype is generic, intended to be renamed and group content at template-level through slot inclusion, and since its instances happen at the same (root) level they have the same archetype_node_id and path (we could use different name predicates, but how to handle languages and translations?), and the inner contents have different restrictions.

8

Do you have the OET?