Inconsistency in REST API Create EHR implementations -needs spec clarification?

Specifications ITS
21

Right now we can query as long as the data is RM compliant, even if the archetype labels in the data are not actually registerd with the CDR (or actually don’t exist!). I’m grateful because, at least for us it solved the population query demographics issue mentioned else where but it would be better if it was backed by a template for reference purposes.

Here is the structure we embed in EHR_STATUS.other_details. It is actually based on a CKM archetype

```json
----
"otherDetails": {
  "@class": "ITEM_TREE",
  "name": {
    "@class": "DV_TEXT",
    "value": "Tree"
  },
  "archetype_node_id": "at0001",
  "items": [
    {
      "@class": "CLUSTER",
      "name": {
        "@class": "DV_TEXT",
        "value": "Anonymised person (PARENT)"
      },
      "archetype_details": {
        "@class": "ARCHETYPED",
        "archetype_id": {
          "@class": "ARCHETYPE_ID",
          "value": "openEHR-EHR-CLUSTER.person_anonymised_parent.v0"
        },
        "rm_version": "1.0.1"
      },
      "archetype_node_id": "openEHR-EHR-CLUSTER.person_anonymised_parent.v0",
      "items": [
        {
          "@class": "ELEMENT",
          "name": {
            "@class": "DV_TEXT",
            "value": "Administrative Gender"
          },
          "archetype_node_id": "at0001",
          "value": {
            "@class": "DV_CODED_TEXT",
            "value": "Not known",
            "defining_code": {
              "@class": "CODE_PHRASE",
              "terminology_id": {
                "@class": "TERMINOLOGY_ID",
                "value": "local"
              },
              "code_string": "at0012"
            }
          }
        },
        {
          "@class": "ELEMENT",
          "name": {
            "@class": "DV_TEXT",
            "value": "Birth Sex"
          },
          "archetype_node_id": "at0002",
          "value": {
            "@class": "DV_CODED_TEXT",
            "value": "Female",
            "defining_code": {
              "@class": "CODE_PHRASE",
              "terminology_id": {
                "@class": "TERMINOLOGY_ID",
                "value": "local"
              },
              "code_string": "at0010"
            }
          }
        },
        {
          "@class": "ELEMENT",
          "name": {
            "@class": "DV_TEXT",
            "value": "Vital Status"
          },
          "archetype_node_id": "at0003",
          "value": {
            "@class": "DV_CODED_TEXT",
            "value": "Alive",
            "defining_code": {
              "@class": "CODE_PHRASE",
              "terminology_id": {
                "@class": "TERMINOLOGY_ID",
                "value": "local"
              },
              "code_string": "at0004"
            }
          }
        }
      ]
    },
    {
      "@class": "CLUSTER",
      "name": {
        "@class": "DV_TEXT",
        "value": "Identifiable Person (PARENT)"
      },
      "archetype_details": {
        "@class": "ARCHETYPED",
        "archetype_id": {
          "@class": "ARCHETYPE_ID",
          "value": "openEHR-EHR-CLUSTER.person_identifiable_parent.v0"
        },
        "rm_version": "1.0.1"
      },
      "archetype_node_id": "openEHR-EHR-CLUSTER.person_identifiable_parent.v0",
      "items": [
        {
          "@class": "ELEMENT",
          "name": {
            "@class": "DV_TEXT",
            "value": "Person Identifier"
          },
          "archetype_node_id": "at0001",
          "value": {
            "@class": "DV_IDENTIFIER",
            "issuer": "GOSH",
            "assigner": "GOSH",
            "id": "4ff62524-64bb-421d-b664-eea72ef925ee",
            "type": "GOSH MRN"
          }
        },
        {
          "@class": "ELEMENT",
          "name": {
            "@class": "DV_TEXT",
            "value": "Person Identifier"
          },
          "archetype_node_id": "at0001",
          "value": {
            "@class": "DV_IDENTIFIER",
            "issuer": "GOSH",
            "assigner": "GOSH",
            "id": "MRN 12342345",
            "type": "GOSH ANNEX MRN"
          }
        },
        {
          "@class": "ELEMENT",
          "name": {
            "@class": "DV_TEXT",
            "value": "Year of Birth"
          },
          "archetype_node_id": "at0008",
          "value": {
            "@class": "DV_DATE_TIME",
            "value": "2013"
          }
        }
      ]
    }
  ]
}

AQLs -code snippet for creating the select

  if (ctx.vars.maxAge) {
            aql = aql + ' and e/ehr_status/other_details/items[openEHR-EHR-CLUSTER.person_anonymised_parent.v1]/items[at0014]/value/value <= \'' + (currentYear - ctx.vars.minAge).toString() + '\'';
22

Isn’t it a good thing to be able to query the data only using archetypes? Templates tend to be local / application specific, and they will change over time possibly faster than archetypes. so in my view, it’s desirable to be able to query data (that are created using different kind of templates).

23

Yes, it is. I did not choose my words carefully enough.

The point is that I would like EHR_STATUS, feeder_audit etc. to be constraint using templates. This would make life easier because you are getting a machine readable documentation of your data structure (e.g. you easily learn how to obtain the VIP flag of an EHR_STATUS.) Then you can easily extract the correct RM paths from the archetypes used in the template.

Sorry for the confusion this caused.

24

Then it makes sense. Thanks, Birger!

25

@ian.mcnicoll, i guess you know it, but perhaps it will not harm to mention here that the @class should have been _type, and that most of name/value nodes does not require the type declaration (unless they are coded texts).

26

Yes - sorry forgot to make it clear that this uses Better’s ‘raw json’ format that pre-dated the official canonical JSON format has a couple of differences that you highlighted.