Rules for Controlling Content Creation in a CDR

Problem description

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.

Analysis

FHIR ‘conditional create’. @Seref Arikan (Personal) consider using the REST approach established by FHIR (i.e. If-None-Exist: [search parameters] extension header); still need to work out our own semantics. How do we do search params ? Could these params be abused i.e. access control. Need to be limited - maybe - ‘match params' or 'creation criteria'.

@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 category with same possible values as category? @Seref Arikan (Personal) - dangerous!

@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"]

Solution ideas

@Erik Sundvall endpoint ‘black list’ - special template ids? Should be a customer question