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. 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. |
Solution ideas
Erik Sundvall endpoint ‘black list’ - special template ids? Should be a customer question