Special treatment of "incomplete" VERSIONs

How do you currently decide if something is ‘draft’ or ‘incomplete’ ?

We actually don’t :thinking:
The client application (the EHR system using the #openehr CDR) has a document workflow for incomplete compositions. A user may store a draft. Those entries goes into a workflow called “documents for approval”. A user might save the draft several times before finishing and approving the content. This is the composition which gets committed to the CDR.

For this use case versioning it’s not needed.

I don’t want to open a Pandora box here… But there are use-cases with multiple authors work simultaneously on a composition. This will require a different protocol for sharing of updates and versioning. I think we can leave this out from current discussions.

I think we need to open the box!! , and have a clear idea of the full requirements in this space. Then decide what needs to be part of the spec (and part of the versioned CDR).

These are universal requirements.

1 Like

So what we do:

Draft is auto-saved - there is no user involvement other than using a form and returning to it later. It is deleted when committing the composition. Note that this could just be a feature of an app, perhaps even client-side, not necessarily part of a CDR.

The option to save an incomplete composition is presented if a user tries to save with validation errors. They are given the choice between saving an incomplete version or going back to fix the problems. It is an explicit choice of a user to present their input to other users or allow other users to complete their input.

@bna Simultaneous multi-user editing is something else indeed. If that needs to be solved, that sounds to me like a separate problem :slight_smile:

Simultaneous (Google Docs type) editing - yikes!! I agree but a more common scenario is where the document is ‘open’ for a number of contributors e.g. a multidisciplinary team document.

We may not need to be able to solve all the use-cases but it would be good to understand them and possibly flag those that are definitely out-of-scope.

For your incomplete example where someone cannot produce a validated composition, would you mean, for example, that a form demanded a ‘diagnosis’ (mandated in the template) but the user could not actually give one, and the UI did not allow an alternative?

Anything that is not complete, so I have no full list of use cases ready.
A score that is part of several events that need to be recorded separately was our first use case. Could be modelled differently, of course.

I would solve this with timestamped encrypted snapshots of form fills in the application space - I don’t think this kind of partial data could be regarded as reliable in any sense at all (except where, by luck, the user happened to have filled enough things in completely).

This seems like the right kind of solution to me.

I think the definition of the incomplete state, or to be more precise, the inconsistency of the definition is problematic.

The way I see it, an RM instance either passes validation with respect to a template (archetype) or not. It is a binary outcome. I cannot understand why the spec allows a ‘little bit inconsistent’ state based on relaxed cardinality constraints. From the point of view of the validators, that is an invalid instance, period.

Would any clinician be able to give a blanket guarantee from a clinical safety p.o.v that some missing items is safer than, say, a free text observation that was not completely typed (because someone interrupted the clinician)?

As long as implementers commit to ensuring that incomplete state is not visible to any party until it is committed (serialised transaction isolation level in relational db server terms…) what different does it make ‘how incomplete it is’ ?

Btw as long as a vendor is guaranteeing that data won’t be displayed to anybody other than the party/parties working on it, where it is kept is an implementation detail and should be up to the implementer.

Just one thing to note here: we are talking about data that is being committed, so it is ‘visible’ in the EHR, in a limited way, so it can be reviewed, edited to completion etc. This is why we are talking about the query processor ignoring it - which it wouldn’t need to do with uncommitted data.

The spec does not seem to clarify for whom this data would be visible, so I’m assuming it’d be limited to the author, which is what the common inf. model spec seems to say, or at least that’s my impression from reading it.

If it is visible to others, or if this is undefined behaviour, then it makes sense (to me) to limit the visibility of this data to its author and clearly express this in the spec.

My main point(s) are; it’d be better if the spec simply defined all data that fails validation for whatever reason as incomplete and it’d also be better if the spec clarified to whom data in this state should be visible to.

My 2 pennies.

This is a good point and I don’t remember it being discussed. @ian.mcnicoll and/or others - any opinions? I guess at least the senior clinicians to whom the author reports need to be able to see the content.

I think in principle that is correct, it is a temporary workspace for the original author(s) - and that would be the only complication - some documents do have multiple authors -ultimately the access rules would have to be quite local/application-specific.

3 Likes

I think the information should be visible to at least potential future authors, plus people who may need to interpret data so they know there is more data on its way, or to ask someone to complete something they need.
Very much application specific.
For us it is a way to record something that makes sense as a single composition, that cannot completely be recorded in one session, for any reason, but can safely be completed later.

1 Like