Constraining DV_EHR_URI

I have a usecase where I want one (careplan) composition template to index multiple other compositions of sub care plans. using DV_EHR_URI this should work. Accept that it’s not possible to constrain the element to only link to compositions from a specific type (template).
I’m looking for potential strategies for solving this. Easy fix is custom logic, in client app, but I’m looking for something that’s specified in the RM.
Has this requirement come up before?
Thoughts on how to edit the RM for supporting this?

2 Likes

As the only thing available to constraint is a String, your only hope would be some regex that only accepts the references you wants, although they would be hardcoded in the template. Not sure it would work in your use case.

1 Like

Yes hardcoding regexes constraints on the value string is what I was thinking about. Similar to how we use regexes in use_archetype in adl.
Why wouldn’t it work?

When it depends if (when) the validation is enforced, I would assume validating regexes over DV_EHR_URI is not a common use case

@thomas.beale curious for your thoughts.
Would one say it’s related to the managed list discussion?

The correct way to solve constraints on links is that we have to add something to ADL, which I have been threatening to do for years :wink:

A new AOM type is needed that constrains links such that you can state in the constraint the RM type of the thing the link points to. This new AOM type is needed, because normally there is no way to constrain just a link element to state what kind of thing it points to, unless you make assumptions about the pointer, e.g. that the URI contains the RM type buried inside it. But this is not generally reliable, and is not a safe long term approach.

I must get back to looking at the details of this change. Of course, even if we get it done at the specifications level, it will be some time before tool developers implement the change…

1 Like