I have tested Better Designer and VeraTech LinkEHR and none support EHR_STATUS artifact definition.
Hello Pablo,
I was not even aware that EHR_STATUS is a LOCATABLE 
So yes, technically it should be possible to create archetypes for it. I have prepared a Quick and Dirty patch. I generated this file from the latest RM XDS. Just copy the files into your LinkEHR Studio folder, inside of [LINKEHR_FOLDER]/data/rm/openehr/EHR/archetypes/
EHR_STATUS.adl (58,9 KB)
Then it you should see that class as an option when creating a new archetype.
The main limitation is that there doesnât exist a dedicated UI for it, so you have to edit the archetype using the generic archetype tree. Otherwise you wont see any attributes.
1 Like
Out of curiosity, whatâs the use case for archetyping the EHR_STATUS class?
Formally, any LOCATABLE subclass could be archetyped, and any root class should be archetyped, since it should have archetype_node_id and archetype_details != empty.
Technically, having an archetype and template for LOCATABLE roots allows automatic data validation, automatic data generation, enables GUI generation, among other things.
All these classes should be archetyped and have templates:
COMPOSITION
FOLDER
EHR_STATUS
any concrete descendant of PARTY (demographic)
Note those are also the types that could be versioned in an openEHR data repository.
THe immediate requirement is that âofficiallyâ the EHR_STATUS class is Locatable so should carry and archetype. However early CDRs seem to have ignored that until the REST API came along and (correctly) insists that there is some sort of archetype metadata in there.
{
"_type": "EHR_STATUS",
"archetype_node_id": "openEHR-EHR-EHR_STATUS.generic.v1",
"name": {
"value": "EHR Status"
},
"subject": { ......
So for now it is really a bit of a technical requirement only. We have never used a ârealâ EHR_STATUS archetype but we have added structured content to the other_details part of the EHR_STATUS structure. In the example beow to carry minimal anonymised personal data to make population querying easier. Now that works and can be queried via AQL but there is no way of applying a template when the data is submitted to the CDR so it is essentially unvalidated.
{
"_type": "EHR_STATUS",
"name": {
"_type": "DV_TEXT",
"value": "ehr status"
},
"subject": {
"_type": "PARTY_SELF",
"external_ref": {
"_type": "PARTY_REF",
"namespace": "uk_nhs_nhs_number",
"type": "PERSON",
"id": {
"_type": "HIER_OBJECT_ID",
"value": "61246978-1742-4430-9c11-a52c3e4c6d2b"
}
}
},
"other_details": {
"_type": "ITEM_TREE",
"items": [
{
"_type": "CLUSTER",
"archetype_details": {
"_type": "ARCHETYPED",
"archetype_id": {
"_type": "ARCHETYPE_ID",
"value": "openEHR-EHR-CLUSTER.person_anonymised_parent.v1"
},
"rm_version": "1.0.1"
},
"archetype_node_id": "openEHR-EHR-CLUSTER.person_anonymised_parent.v1",
"items": [
{
"_type": "ELEMENT",
"archetype_node_id": "at0001",
"name": {
"_type": "DV_TEXT",
"value": "Administrative Gender"
},
"value": {
"_type": "DV_CODED_TEXT",
"defining_code": {
"_type": "CODE_PHRASE",
"code_string": "at0009",
"terminology_id": {
"_type": "TERMINOLOGY_ID",
"value": "local"
}
},
"value": "<gender>"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0002",
"name": {
"_type": "DV_TEXT",
"value": "Birth Sex"
},
"value": {
"_type": "DV_CODED_TEXT",
"defining_code": {
"_type": "CODE_PHRASE",
"code_string": "at0009",
"terminology_id": {
"_type": "TERMINOLOGY_ID",
"value": "local"
}
},
"value": "<gender>"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0003",
"name": {
"_type": "DV_TEXT",
"value": "Vital Status"
},
"value": {
"_type": "DV_CODED_TEXT",
"defining_code": {
"_type": "CODE_PHRASE",
"code_string": "at0004",
"terminology_id": {
"_type": "TERMINOLOGY_ID",
"value": "local"
}
},
"value": "Alive"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0014",
"name": {
"_type": "DV_TEXT",
"value": "Birth Year"
},
"value": {
"_type": "DV_DATE",
"value": "<birth_year>"
}
}
]
}
]
},
Note without the OPT for EHR_STATUS, the other_details field canât be queried internally, since you donât know which structure is there, so you can query to get the whole other_details, but can use an internal path of the other_details as a filter or projection in a query. The OPT is actually the âschemaâ in which the query is defined, and without that info all you know is the RM with a generic ITEM_STRUCTURE there.
You can actually query on the more granular data in the Better CDR, even without a template for EHR_STATUS. Of course you are completely reliant on that data having been committed correctly without template-base validation. And you have to know the structure committed with out it being documented in a template.
...
AND e/ehr_status/other_details/items[openEHR-EHR-CLUSTER.person_anonymised_parent.v1]/items[at0001]/value/value = 'Male'
And when you do, you should get a deprecation warning 
Years later nobody will remember how this data was committed and what is its structure.
2 Likes
Iâm not saying itâs technically impossible, Iâm saying you rely on external knowledge of the internal structure of the other_details, which IMO is a very insecure way of querying. When querying, the underlying schema should be known beforehand and with some formal definition (i.e. the OPT).
2 Likes
Yup - I agree with you there.
Does anyone have a practical/actual usage of an EHR_STATUS archetype other than as a container to add âother detailsâ as e.g Cluster archetypes. I cannot think of anything myself.
I guess the usage could be to add any metadata required by an implementation at the EHR level, e.g. some IDs, organization information, or even basic demographic data to allow querying.
My concern is not domain use cases right now, but to have a workflow that allows me to verify conformance with openEHR on any system, which includes archetyping EHR_STATUS, which should be doable considering the openEHR specs.
2 Likes
@ian.mcnicoll I have been keen for a long time to support Archetypes on âotherâ locatable objects in the EHR. Maybe not happening tomorrow in EHRbase, but definitely something I aim at.
1 Like