For a very long time we have wanted a way of constraining links of various kinds in the RM (or anywhere) such that the constraint can say what kind of thing the link target points to - both at RM level (e.g. must be an EVALUATION) and semantic level (e.g. must be problem-diagnosis). On the clinical side, @ian.mcnicoll, @siljelb and @joostholslag might want to have a think about this proposal, likewise tool builders @pieterbos , @borut.fabjan , @NeoEHR , @yampeku , @damoca , @sebastian.garde … did I miss anyone?
The kinds of links/references we currently have in the RM are:
-
OBJECT_REFs, includingPARTY_REF, etc - here, classes likePARTY_REFare actually trying to do the job we want, but in a hardwired way. -
LINKs, which are mostly intended to connectENTRYsto create chains e.g. ofOBS -> EVAL -> INSTRUCTION, and have an internalDV_EHR_URI - any use of
DV_URIorDV_EHR_URIas a data item -DV_EHR_URIis also a kind of hard-wired approach to trying to constraint the target, in this case, to EHR-only content; - the proposed CITATION class, which is a special kind of ENTRY that can point to any other kind of ENTRY; it’s internal reference is currently a LOCATABLE_REF.
Other kinds of RM have various kinds of ‘reference’, including things like FHIR Reference(x).
Let’s assume a new meta-type in AOM to support archetyping of links called C_REFERENCE, that can constrain any kind of link/reference class. The contents of this constraint is really a C_ARCHETYPE_ID, i.e. a constrainer on ARCHETYPE_IDs, which allows to constrain on RM type and semantic type.
Such a constraint could look something like this in ADL (requires some new syntax - here I have used an arrow to mean ‘points to’):
target ∈ {
DV_EHR_URI[id25] → {openEHR-EHR-EVALUATION.problem.*}
}
However, we might want to be able to allow multiple possibilities, and also do it by inclusion or exclusion, like for slots. E.g.
target ∈ {
DV_EHR_URI[id25] → ENTRY ∈ {
include
archetype_node_id ∈ {/openEHR-EHR-EVALUATION\.problem\..* | openEHR-EHR-OBSERVATION\..*.\.*/}
exclude
archetype_node_id ∈ {/.*/}
}
}
Another possible example - a CITATION under a SECTION in a care plan, that should point to a medication_order within the medication list (Citations are just a proposal at this stage - model here):
items ∈ {
CITATION[id25] ∈ {
source_parent_ref ∈ {
LOCATABLE_REF[id27] → COMPOSITION ∈ {
include
archetype_node_id ∈ {/openEHR-EHR-COMPOSITION\.medication_list\..*/}
exclude
archetype_node_id ∈ {/.*/}
}
}
source_ref ∈ {
LOCATABLE_REF[id28] → INSTRUCTION ∈ {
include
archetype_node_id ∈ {/openEHR-EHR-INSTRUCTION\.medication_order\..*/}
exclude
archetype_node_id ∈ {/.*/}
}
}
}
}
Of course, in tools it should look more efficient, e.g. a bit like:
CITATION[id25]:
source_parent_ref[id27] → openEHR-EHR-COMPOSITION.medication_list.*
source_ref[id28] → openEHR-EHR-INSTRUCTION.medication_order.*
Note that the following construct could be used to replace the PARTY_REF type:
attr1 ∈ {
LOCATABLE_REF[id2] → PARTY ∈ { ... }
}
It will be noted that if we allow the following general form:
attr1 ∈ {
RM_REFERENCE_TYPE[idN] → RM_TYPE ∈ { ... }
}
Then the part on the right could be more than just an archetype id constraint; it might constrain content as well. E.g. something like:
attr1 ∈ {
LOCATABLE_REF[id4] → INSTRUCTION[openEHR-EHR-INSTRUCTION.medication_order] ∈ {
activities ∈ {
ACTIVITY ∈ {
description ∈ { ...}
}
}
}
}
This seems overkill to me, but it’s interesting to think about.
