Archetyping links and references

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, including PARTY_REF, etc - here, classes like PARTY_REF are actually trying to do the job we want, but in a hardwired way.
  • LINKs, which are mostly intended to connect ENTRYs to create chains e.g. of OBS -> EVAL -> INSTRUCTION, and have an internal DV_EHR_URI
  • any use of DV_URI or DV_EHR_URI as a data item - DV_EHR_URI is 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 can do something of the general form:

    attr1 ∈ {
        RM_REFERENCE_TYPE[idN] → RM_TYPE ∈ { ... }
    }

The the part of 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.

3 Likes

Could these be expressed as rules instead? would probably solve the last use case as the constraints in other archetype could be expressed there, even mandating how the returned entity should look.
Something like “this points to an entry X such as its path_to_value = $whatever”
This could be an extension over the rules syntax and don’t break ADL parsers too much :wink:

1 Like

Thanks for bringing this @thomas.beale

That would open a world of possibilities. And probably, if anytime this is introduced, it should be also adopted by the SLOT constraint.

That is an interesting idea to minimize the impact in current implementations, but probably only as a patch solution. Otherwise, it would blur the lines between cADL constraints and the rules section. Why just this kind of constraint is expressed as a rule and not any other constraints?

I that sense, for better consistency, I would support one of the proposals made by Thomas. What we need is a kind of SLOT (PROXY_SLOT I think is a name that was commented in the past) which defines the type of the target of data values that are object references.

Interesting idea. The Slot constraint is mostly a design-time thing, although slots could be filled just-in-time at runtime (= templating on the fly). Normally, the constraints you want in the included structure in a slot are defined in the archetype (or overlay) that the slot points to. So I’m not sure how useful this would be - unless you want to use it to actually define the structure of the filler inline, but that seems to defeat the whole purpose of a slot? You might have something else in mind though…

The C_REFERENCE concept is a runtime thing, so it’s saying: the target of this reference at runtime needs to be EVAL.problem_diagnosis or whatever; if we go that further step and allow content constraints inline, I think the potential utility is not to define content, but to build in a small GraphQL-like query - i.e. now you are saying, don’t just get me EVAL.problem_diagnosis, but make sure it’s got the ‘index problem’ field set to ‘diabetes’ or whatever.

I’ll leave this alone for now - I’d like to see what others think about all this.

1 Like

That’s already happening if the rule is based on any archetype path :thinking:

This proposal makes a lot of sense to me.

I think it’s inevitable that we’ll want constraints on content as well. First example comes to mind is, referencing a problem that’s part of a compostion.problem_list only. I’d be fine with kicking it down the road, but if it’s easy to pickup now we should do it.

ah well we did think of that one, and I agree with it. It’s the reason that the CITATION class (which BTW is just my proposal, this has not been agreed by SEC) has both a ‘source_parent_ref’ and a ‘source-ref’. So that parent pointer can point to any parent of the citation source (not just the immediate parent).

NOTE: some people might think source_ref and source_parent_ref should be called target_xxx. I originally made the design thinking of the target of the reference as the ‘source’ of the citation, i.e. in the literary sense. But if ‘source_xxx’ causes less brain trauma, happy to change it. I think we all know what it means.

Can this kind of constrait be used for Instruction State Machine definitions?