Does anybody (with an openEHR persistence system/solution) encountered the need to record other states than 'incomplete', complete', 'deleted' for a VERSION.lifecycle_state?
The use case is that in some circumstances a version need to become immutable and any change should be forbidden. Imagine a care plan that was already 'inform-consented' - it should not be allowed to be changed in any way, neither logically deleted (unless perhaps some administrative reasons). In contrast, by current version of specifications, a 'complete' version can be still changed or logically-deleted (which is valid behavior also).
I suspect that the idea of 'final' requires something more like a 'locked for modification' flag. But nothing is guaranteed to be immutable - what if the consent was given, and the committed information was considered clinically 'final' but then a simple typo error (e.g. patient name, or the date of procedure) was found?
final is final! Even though consent was given on wrong data...
I guess if needed on application level it can be overruled under some special conditions (special administrative rights, timeframe, owner, etc.).
But I was looking more for a 'flag' to signal that a specific version cannot be changed anymore (under normal conditions).
Hi Sebastian,
To your general question, yes we needed something to indicate a version was moved distinct from deleted. This ensured that we couldn't undelete the version. There was a PR for this which included a new change type also.
To your usecases, I agree these are necessary but have concern about the term final. It doesn't seem to have the level meaning necessary for you use case as it is overloaded with pathology result status where a final can be corrected. Perhaps immutable is more specific. Similarly with draft, seems too similar to incomplete. What about unapproved or similar?
As with all out terminologies, having too many similar options makes it hard to select the correct one unless the usecases are very clearly specified. I think you have very distinct usecases, we just need to get the right term to ensure it best reflects the usecase.
I can rephrase my question: "How can I indicate that a version should not be changed under any circumstances? How have other openEHR implementations handling this issue (if ever occurred)?"
The use case I have is in mental-care in NL is that care providers are setting up a care plan (which consists of many type of documents, anamnesis, goals, planned schedule for evaluations, planned interventions, actions, etc). During the initial phase of documenting and planning most of these are in draft-mode (they are complete, but perhaps need approvals, reviews or some are sometimes just considered as proposals), but at some point in time some of them they need to be fixated, any later change should be forbidden. It is like a contractual relation between care providers and/or patient, it requires some sealed papers.
Whats the best way to handle this? I'm not convinced this is a modeling/archetype/template issue, I rather think is something that is part of application layer, business logic, etc. but requires a 'flag' on the backend data; hence my question/hint about VERSION.lifecycle_state. If I would have the option to set it to 'final', I would of course only use it for those object that is applicable (when I can guaranty that no change is necessary/allowed); most of the time I would probably still rely on 'complete'. Other openEHR implementations may not need to use this 'final' feature if they allow in their versions may always be altered.
I'm ok to give (if necessary) a different name than 'final', as long it reflects the use case I described above. I'm also ok to make a compromise and use 'incomplete' where I actually need 'draft' (although I see it as two different meanings). Alternatively I could also use 'complete' instead of 'draft' as long as I have and 'final' that pairs it.
Is a new type of VERSION.lifecycle_state the best to solve the described use-case? Won’t the “correcting a typo change” or “we forgot a thing” use-cases etc still always be there even for things written as binding contracts?
Is it perhaps enough to have the “final” plan fixed/fixated by applying digital signatures on the VERSION using the ATTESTATION class, thus marking the “contractual agreement” with digital signatures so that nothing be changed without the system (and/or users) noticing it.
The application can then, for the type of change-sensitive documents described by Sebastian, perform signature checks and show warnings or refuse to update info unless the change is signed by the same persons or organisations that signed the previously signed version.
To me it seems natural that binding contracts and signatures belong together.
Heath’s use-case “something to indicate a version was moved distinct from deleted” won’t be solved by signatures though, so https://openehr.atlassian.net/browse/SPECPR-83 is still valid.
I see where are you pointing to - that 'attestations' can indeed be one solution to the problem. However I see this more as an application-level functionality/feature; it can be (or not) interpreted the same way by a 3rd openEHR system that might get that data. I feel safer having (also) the options of a 'final-like' state flag of the version.
You could control this in a shared environment by using a coded text item in Attestation/reason.
I think this might work better than a ‘standard’ gneric lifecycle state since it allows you to very specifically identify the exact policy/legislation involved.
EHR Access control setting might be the way to apply these kin do policies also, but I do understand you want something universally understood, not just local policy. I am hoping we might be able to get to something like this when we start looking at EHR access settings.
There is a “nice” thing in HL7 (yes, that is possible! :), when they define state or categorization data, associated with an HL7 terminology set (values should be chosen from a given set, can’t be defined by the implementer), they also offer a “modifier”. In the modifier the implementer can set it’s own term set / codes.
If you have more than one status matching one code on the standard code set, use modifier to establish the difference. Is a nice way of extension and allows a great deal of flexibility.
What do you think about having a “lifecyce_state_modifier” attribute for VERSION? (just thinking out loud)
Nothing is ever ‘Complete’, improvements are always possible.
‘Final’ is not a good idea. I’ve seen different 'final’ versions of documents and software more times than I would like.
How about “published {date; by whom; for what purpose; attestation}”. As with a book, you can’t change what someone is already using, it’s out in the wild.
Thank you all for your suggestions. To conclude on this topic, the main ideas were that:
- there is no sufficient reasons for an extra value for version.lifecycle_state to indicate that a version is immutable
- immutable is anyway in real life not '100% immutable', corrections should/might be allowed under certain conditions (up the the application)
- immutable state functionality can be achieved using ATTESTATION (that gives the seal and context) and perhaps EHR_ACCESS (that gives the read-only policy)
I think this is about right. I think 'immutable' in law and 'immutable' in information systems have to be understood as different things. The law is always local, so I think the best that could be done is a standard kind of attestation whose reason for change was something like 'final version approved by governing health authority' or similar.
final is final! Even though consent was given on wrong data...