The original question from Matija Polajnar was: do we need an endpoint for committing persistent compositions, to ensure for example that one one instance is allowed of a particular Composition e.g. medications list.
Issues:
this kind of rule (e.g. can only have one Medications List persistent Compostion) will not be globally applicable - it will therefore apply to specific deployments;
Where are the rule(s) encoded?
Heath Frankel (Unlicensed) What about when the Composition is part of a multi-Composition Contribution?
problem of race condition of N clients trying to create a singleton Composition e.g. Meds list;
This example can be generalised to a) any kind of content and b) any multiplicity, e.g. this system allows <=10 Problem Lists.
FHIR ‘conditional create’. Seref Arikan (Personal) consider using the REST approach established by FHIR (i.e. Seref Arikan (Personal) : set the singleton template id list via a dedicated REST endpoint. Matija Polajnar : treat this as a back-end validity question. Ian McNicoll : template ids + Composition names? Diego Bosca : modify existing OPT upload REST endpoint header params? Bjørn Næss : rules need to be context specific, e.g. in certain episode, folder etc. Ian McNicoll : maybe start with true persistent singletons? Bjørn Næss : how to handle branching? Partial commits (multi-Composition) fail if one Composition breaks the rule. Thomas Beale : consider these as ‘content policies’ for EHR system deployments. DO we want a ‘singleton’ Composition category? Ian McNicoll create a new attribute to replace existing Erik Sundvall : ‘blacklist’ - can have a template id; plus a test AQL that must return 0 results? Seref Arikan (Personal) allow criteria (could be AQL, JS etc) to items in the blacklist. |
Erik Sundvall I agree that too many (all) of the current archetypes constrain the "category" if we are going to use "category" as a switch.
A template-id-based blacklist in config is more flexible,
singleton_per_ehr vs singleton_per_folder vs singleton_per_????
Bjørn Næss Since templates historically is not versioned you need a way to Group template_ids to a singel "persistent Group"
ProblemList : ["templateX", "templateY"]
Joost Holslag
I like this perspective Erik. singleton_per_folder is problematic though. because folders are post hoc lists. So what happens if two singleton per folder versions are linked to the same folder? Or via a ‘subfolder’. What you would like to achieve i believe, is singleton per episode. And we don’t have an episode concept in openEHR other than folder. But I think we should solve that over doing singleton_per_folder.
Bjørn Næss
And to follow that into a contextual persistence:
ProblemList: {
"scope": "EpisodeOfCare",
"templates": ["Templatex", "TemplateY"]
Erik Sundvall endpoint ‘black list’ - special template ids? Should be a customer question