Lifecycle_state in EHRbase

Hi all

We are using EHRbase for our CDR which is going ok albeit we have only a tiny number of EHRs on it (<10), and only for an anticipatory care plan application supporting ReSPECT.

This is pretty much testing the ground for us as we need to scale up to manage 6 million citizens health and care records, so we need very much to make it work and be solid, safe and meet our requirements!

One recurring requirement is to handle ‘drafts’, that is compositions that are being worked on by users but not yet complete. In practical terms this is because they want to start a thing, be distracted by lunch or some clinical emergency, and come back to it later or tomorrow.

ReSPECT is using this template:

Which makes use of this composition:

I understand (I think!) that the proper way to manage that is by using lifecycle_state, which can be ‘complete’, ‘incomplete’ or ‘deleted’.

Does EHRBase support this particular attribute?

If so, I guess we could use it to manage this in our interface and application.

Alternatively, the composition we are using has an element ‘Status’ in Context which we could perhaps use to do a similar workflow, exposing that element in the UI and designing a process to allow the user to mark the composition as ‘in draft’ or ‘complete’.

This achieves the same aim, but not in quite so elegant a fashion.

Does all that seem sensible, and can @birger.haarbrandt give me any help re EHRbase supporting lifecycle_state?

Thanks, if that makes any sense!


Dr Paul Miller
Clinical Lead
NES Digital Service

1 Like

Hi Paul,

Like everything it is a bit complicated.

There are 2 possible kinds of ‘draft’ which the current ReSPECT form template was trying to support

  1. The ‘technical lifecycle’ which you point to - which is really about controlling the queryability / discovery of the composition - if it is incomplete or deleted, it is not normally ‘visible’ to normal querying, It can be found, but you have to explicitly ask for ‘incomplete’ compositions.

So you would set that if a composition was not intended for wider consumption i.e. ‘not clinically safe’.

When we had the original conversations around the ReSPECT process, the discussion, at that that time, was that even a very minimally completed form was safe and valuable, and therefore should be available i.e ‘complete’ but needed to be flagged for its ‘clinical status’ - which is where the other context-based ‘report Status’ came in.

I’m not saying this is necessarily correct or necessary but it had ‘some’ logic at the time, and I suspect does reflect two ideas of ‘draft’ which many need to be handled, at least in some cases.

AFAIK lifecycle is supported in Ehrbase but it would be worth checking the rules around ‘incomplete’ availability in querying as this was a very recent specification change and might not be supported yet.


You should be able to state that a composition’s lifecycle is incomplete but there is no functionality based on this info at the moment. For now we concentrate to polish EHRbase and remove bugs for the 1.0 release candidate and we would have to put this into the backlog. Maybe we should have a conversation in the near future how we can help you with such topics on short notice.


Thanks @birger.haarbrandt that’s really helpful. I am chatting to the developers tomorrow about our options as our users have a dependency on some sort of drafting function before they will allow it to scale out across a wider estate.

When you say ‘no functionality’ does that simply mean we cannot query it?

Possibly we could manage the Lifecycle_state attribute value anyway but use the template element Status to provide a solution in the interim.

Also, yes - be good to finally chat with you. Maybe we could sort a meeting out with you and some of our team. We are dong some internal openEHR training on the morning of the 16th June (@ian.mcnicoll is helping!) and we will allow for lots of Q&A so if you were available… :slight_smile:


Dr Paul Miller
Clinical Lead
NES Digital Service

1 Like


Right now Ehrbase does not support AQL for the VERSION object, which is wrapper around a stored composition that has the lifecycle_status on it.

However you can use the REST API to get the VERSION container for any composition.

which would let you see the lifecyle_state and ‘hide’ that composition if appropriate.

To set the lifecycle_state on a composition you would have to use the POST /contribution call which allows you to manually tweak the Version information before you commit the composition (which goes inside the data attribute). The usual POST /composition does actually do a POST /contribution this behind the scenes, with sensible defaults. So it is a little more cumbersome but can be boilerplated fairly easily.

the Better CDR dos support VERSION querying e.g.

WHERE c/name/value = 'ReSPECT-3'
and v/lifecycle_state/value  = 'completed'   //You could normally use the defining_code

which would only return ‘completed’ compositions, You don’t need the VERSIONED_OBJECT stuff - that is just for info


This is an interesting topic: Drafts

I will make a controversial statement on this:

Drafts does not belong to the EHR. They are application specific and has its own rules and workflows. Developers building applications with an openEHR CDR must solve the way drafts (among other things) should be handled.

Look forward to feedback on this statement.

1 Like

I agree conceptually. Technically the CDR might be conveniently used to store drafts, because if that is not the case, there is a need for some kind of extra storage and management of drafts elsewhere, duplicating some of the functions the CDR already provides.

Thinking about implementation, I can see some app-specific functions, for instance: list all the draft documents for a specific composer (the doctor wants to finish the documentation of a case), and that functionality might rely in openEHR APIs.


I dunno, I think it is hard to have a blanket rule here.

The CDR needs to support the people doing the work, not just be a place for final versions - medicine is fluid and imprecise, so having incomplete assessments is pretty much an everyday occurrence.

In that sense it makes sense for users to be able to commit incomplete compositions to the CDR - they are still valid in a clinical workflow sense and can be helpful medico-legally perhaps also, but they are of course not the final committed document.

Sometimes it might be easier for developers to build the ‘draft’ composition outside of the CDR functionality, then only send it to the CDR when completed.

It depends, I think, on the use case and workflow.

In our case it probably makes more sense for now to build drafting into the CDR, partly because we are where we are in the technical development so pulling that off into a separate persisted DB would a be big change, but also because as people create the ReSPECT agreement components of it become immediately useful even if the clinician has not yet filled all sections or had their senior sign it off.


I agree with Paul here. I can see a place in different circumstances for managing some sort of composition cache outside the CDR, but also the value of the incomplete (invisible to routine access/querying) state and indeed the idea of visible and useful, but not necessarily signed off as a piece of ‘clinical business’ - as per the ReSPECT example.

1 Like

Following many years of previous discussions, my understanding is that at least some of us agree that there are 2 kinds of ‘draft’:

  • A: literally unfinished input situation at the clinical workstation, due to clinician dashing off to emergency; s/he comes back later and completes and commits to the main EHR
  • B: substantial notes (e.g. ‘postnatal notes’ - 15 pages in local NHS trust) that are progressively filled out by midwives, docs, etc over some days (e.g. follow-up home visits, maternity ward obs). All stages of filling are committed by the relevant person doing it, and any clinician in the team can see what has been filled out so far.

I think @bna is really talking about the first kind; but we also have the second. Can we agree on this?

If so, A is implemented with some sort of encrypted client- (or maybe server-) side caching of draft form-fills; B is implemented with normal commits of content that has a lifecycle status indicator that is set to ‘draft’ for some time until that form really is finished.

1 Like

IMO that is a problem of modeling.

Even though that could be considered one document, it is a report or summary, composed of many data points from many documents. In that sense, we would need a different kind of COMPOSITION to represent that accurately. What I mean is: the complete/incomplete lifecycle_status we are talking about is about an individual clinical document.

In fact ‘postnatal notes’ could be considered some kind of complete EHR for pregnancy. Which again I don’t think it qualifies as a single clinical document.


I would probably model THom;s obstetric example as multiple compositions but there are certainly other examples of multi-author documents that are much smaller and would not lend themselves to that approach plus we much remember that clinicians are very frequently interrupted and the ability to save a document which is noyl partially complete (from a clinal medic0legal perspective, is important.

I still think there are 3 flavours of draft.

  1. The technical ‘cache’ for timeouts/connectivity fail - has to a local solution as wholly dependent on the tech involved.

  2. the ‘incomplete’ state for documents which are still work in-progress and are not in a fit state to be part of the patient’s normally visible record. i.e lifecycle.incomplete as currently implemented and documented in the specs

  3. Documents that are fit to be made public, but for which additional criteria need to be fulfilled before the document is signed-off - this is where we used the report status element on the archetype to fulfil that need in the ReSPECT form.

So I think we are all good here :slight_smile: next …


well as you know, we don’t do ‘documents’ in openEHR - everything is a data-set :wink:

I do agree that such a 15-page form is really a set of related / linked Compositions, but at the form level, there is a concept of what is in that form, and what is not, and when it is ‘complete’. We now have this concept in Task Planning but not really in openEHR main models. We probably need to do something about this. Maybe @ian.mcnicoll or someone else has a way of representing this form-to-Compositions relationship.

just to be clear - is this the category for when the doc races off midway through data entry to some emergency and comes back later?

Yes, but I use the word document frequently (mostly on training sessions) because it’s easy to understand for most people not familiar with openEHR, or people familiar with paper documents.

I have worked on a model to represent forms based on one template. I shared that model some years ago, as the UITemplate. Since then I’ve been working on and off on that spec, refining details, I can share what I have. Basically as three elements: layouts, views (forms), and bindings (UI elements to template nodes). The main goal is to have a set of metadata for automatic UI generation, for different target technologies (desktop, web, mobile, etc). I just couldn’t progress much on that because of work.

1 Like

Yep this will be good. We should get a group together to look at this, plus any models/meta-models already created, of which there are a few on the wiki, and the implied meta-models in Better FormBuilder + Web template format (ping @borut.fabjan ).

1 Like

I would say that 1 and 2 are more or less equal in this manner.

3 is another beast with lots of different problems to be solved.

1 Like

relatively off-topic and yet not:
On next the AQL spec release, there is a ticket related to the lifecycle state default behavior [SPECQUERY-24] AQL query processor should ignore data with lifecycle_state = incomplete. - openEHR JIRA


I have a document and an UML diagram, just need to polish stuff a little bit before sharing. I’ll try to send a draft to the SEC next week.

1 Like