There is a discussion on SEC JIRA about the format of INSTRUCTION.activity.action_archetype_id which is currently a regex but was suggested to be a proper archetypeId. Against all that, I suggested that tyhis was not an RM attribute that I was aware of ever using in real-world settings. The idea is to constrain an INSTRUCTION to wrok which specific ACTION archetypes. I’m pretty sure that most ? any CDR’s do not validate against this attribute, not does it appeat in templating, where it might just have some value.
The current regexes would also break in ADL2.
My suggestion is that we deprecate use of this attribute, and simply document expected matching ACTION archetypes in USE, as happens now. One less part of openEHR to explain!!
Claude via the Cadasto MCP, reports…
There are only two INSTRUCTION archetypes in CKM that constrain ACTIVITY.action_archetype_id to anything other than the default /.*/ noted in SPECPR-180. Both are draft “request” archetypes, and both point at ACTION archetypes that don’t exist in CKM at the version given.
| INSTRUCTION archetype | ACTIVITY | action_archetype_id constraint |
Target in CKM |
|---|---|---|---|
openEHR-EHR-INSTRUCTION.care_plan_request.v0 (DRAFT) |
at0001 “Activity” | /openEHR-EHR-ACTION\.care_plan\.v1/ |
Only ACTION.care_plan.v0 exists; there is no v1 |
openEHR-EHR-INSTRUCTION.informed_consent_request.v0 (DRAFT) |
at0002 “Current Activity” | /openEHR-EHR-ACTION\.informed_consent\.v1/ |
Only ACTION.informed_consent.v0 exists; there is no v1 |
Both archetypes were confirmed through the openEHR MCP against live CKM.
The other INSTRUCTIONs leave action_archetype_id unconstrained, so they fall back to /.*/. These include service_request.v1, medication_order.v3, therapeutic_item_order.v1, care_pathway_order.v1, transfusion_order.v0, supplemental_oxygen_order.v0, notification.v0, health_education_request.v0 and the project-only request-report.v1
These two examples support your comment on the ticket. Where the attribute has been used at all, it’s a single hard-coded ID rather than a pattern. In both cases that ID is already stale, because it names a v1 ACTION that was never published. That’s a reasonable argument for deprecating it in RM 2.
===========================
Views please, to feedback to SEC.