ORIGINAL_VERSIONs of COMPOSITIONS are committed as part of a CONTRIBUTION. Each ORIGINAL_VERSION has a lifecycle_state attribute that indicates the state of the added, modified or deleted ORIGINAL_VERSION.
So an ORIGINAL_VERSION can be created, modified, deleted, etc. but that has a specific order, for instance a modification can't come before a creation. Also I asked on the lists if a modification can come after a delete, if I recall correctly the answer was "no".
This CR is to add a diagram to the specs, with the valid state machine (states and transitions) which an ORIGINAL_VERSION should comply with.
Add a lifecycle state machine to the UML; add with description to EHR IM spec.
I am stumbling a bit over the ability to REVERT from COMPLETE to INCOMPLETE:
You describe that the incomplete content can e.g. be held in a separate holding bay.
What happens with this when the incomplete content is completed and later reverted? Is this kept in the "holding bay" forever?
(And if so, isn't the term 'holding bay' a bit misleading then?)
Also, is this transition from COMPLETE to INCOMPLETE necessarily a REVERT operation or can it just be a normal UPDATE that just has not been completed yet? Or, even more, is the revert operation really something you can and should support (forever)? What are the consequences of such a REVERT for the EHR? In any case, a few words about the rationale of this REVERT transition would be helpful.
Also, would it make sense to add an "update" (and maybe even a "revert") step from "incomplete" -> "incomplete" as well as "complete" -> complete" (but not from delete to delete)?
Unfinished Compositions cannot be saved locally on the client machine, since this represents a security risk (a small client-side database would be much easier to hack into than a secure server).
-> The statement itself is true I believe, but to me, the reason given here is a bit feeble or just one of several. In context of the above REVERT to incomplete transition, would client-side saving even work? And how would this work in modern environments, where the user may want to complete it from a different client, etc.
I agree with @sebastian.garde that we should add "update" arrows from "incomplete" -> "incomplete" as well as "complete" -> complete".
I also understand the argument that the semantics of the "revert" going from "complete" -> "incomplete" is unclear and probably risky. Can it be removed again in 1.0.4. (and possibly added in a later release if really needed).
Rechecking this section, I can't think of a use case that reverts a COMPLETED version to an UNCOMPLETE version. This gives me the idea that someone wants to remove information that was part of a COMPLETED document. I guess I agree with @sebastian and @erik concerns here.
About the COMPLETE->COMPLETE and INCOMPLETE->INCOMPLETE transitions, the idea of this state machine was to add certain constraints to VERSION lifecycle flows, I don't think it is mandatory for each commit to make a transition here when the VERSION lifecycle doesn't change. But if others think this is needed or clarifies the spec in any way, go ahead.
Good example: surgery plan initially incomplete then made complete when ready for use.
Regarding the surgery planning:
We have a persitent composition where the surgeon does his planning. The composition is persistent within the scope of a folder (the surgery). The surgeon will update the content several times until he makes it final. This is an example where you use the IN_COMPLETE and then COMPLETE state.