# Lifecycle_state in EHRbase **Category:** [Platform](https://discourse.openehr.org/c/platform-implem/7) **Created:** 2021-05-19 15:35 UTC **Views:** 2269 **Replies:** 32 **URL:** https://discourse.openehr.org/t/lifecycle-state-in-ehrbase/1567 --- ## Post #1 by @Paulmiller 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](https://www.resus.org.uk/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: https://ckm.apperta.org/ckm/templates/1051.57.279 Which makes use of this composition: https://ckm.apperta.org/ckm/archetypes/1051.32.166 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! Paul -- Dr Paul Miller Clinical Lead NES Digital Service [https://nds.nes.digital/](https://nds.nes.digital/) --- ## Post #2 by @ian.mcnicoll 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. --- ## Post #3 by @birger.haarbrandt 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. --- ## Post #4 by @Paulmiller 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: Paul – Dr Paul Miller Clinical Lead NES Digital Service https://nds.nes.digital/ --- ## Post #5 by @ian.mcnicoll @Paulmiller 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. https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#composition-versioned_composition-get-2 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. ```sql SELECT vo/uid/value, vo/owner_id/id/value, vo/time_created, v/uid/value, v/preceding_version_uid/value, v/commit_audit/committer, v/commit_audit/time_committed FROM EHR e CONTAINS VERSIONED_OBJECT vo CONTAINS VERSION v` CONTAINS COMPOSITION c 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 --- ## Post #6 by @bna 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. --- ## Post #7 by @pablo [quote="bna, post:6, topic:1567"] Drafts does not belong to the EHR. They are application specific and has its own rules and workflows. [/quote] 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. --- ## Post #8 by @Paulmiller 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. --- ## Post #9 by @ian.mcnicoll 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. --- ## Post #10 by @thomas.beale [quote="bna, post:6, topic:1567"] 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. [/quote] 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. --- ## Post #11 by @pablo [quote="thomas.beale, post:10, topic:1567"] B: substantial notes (e.g. ‘postnatal notes’ - 15 pages in local NHS trust) that are progressively filled out [/quote] 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. --- ## Post #12 by @ian.mcnicoll 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 COMPOSITION.report archetype to fulfil that need in the ReSPECT form. So I think we are all good here :slight_smile: next .... --- ## Post #13 by @thomas.beale [quote="pablo, post:11, topic:1567"] 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. [/quote] well as you know, we don't do 'documents' in openEHR - everything is a data-set ;) 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. --- ## Post #14 by @thomas.beale [quote="ian.mcnicoll, post:12, topic:1567"] 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 [/quote] 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? --- ## Post #15 by @pablo [quote="thomas.beale, post:13, topic:1567"] we don’t do ‘documents’ in openEHR [/quote] 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. [quote="thomas.beale, post:13, topic:1567"] someone else has a way of representing this form-to-Compositions relationship. [/quote] 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. --- ## Post #16 by @thomas.beale [quote="pablo, post:15, topic:1567"] 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. [/quote] 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 ). --- ## Post #17 by @bna 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. --- ## Post #18 by @sebastian.iancu relatively off-topic and yet not: On next the AQL spec release, there is a ticket related to the lifecycle state default behavior https://openehr.atlassian.net/browse/SPECQUERY-24 --- ## Post #19 by @pablo [quote="thomas.beale, post:16, topic:1567"] Yep this will be good. [/quote] 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. --- ## Post #20 by @borut.jures > [bna](https://discourse.openehr.org/u/bna)[Bjørn Næss](https://discourse.openehr.org/u/bna) > > [20 May](https://discourse.openehr.org/t/lifecycle-state-in-ehrbase/1567/6) > > 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. Why not use a separate instance of an openEHR CDR for drafts? This would allow developers to use the same approach as for non-draft compositions. It also doesn't require any extra status elements that are not in the standard. If a process requires different kinds of "drafts" then a separate instance could be used for each kind. --- ## Post #21 by @birger.haarbrandt Hi Borut, for this case we would have to relax the rule validation inside the CDRs. Could be a way, but does not work according to the spec and out of the box at the moment. Birger --- ## Post #22 by @borut.jures Hi Birger, Thank you for the answer. After thinking some more I guess rule validations would fail due to missing required data in the "draft" compositions? Some kind of "N/A" or "undefined/null" data values would be needed to satisfy the validation rules. In my understanding (as a newbie to openEHR), the separate "draft" instance of e.g. EHRBase would treat its data as if it is "finalized". Only the app would treat both instances differently - one to list/save draft data and the other to use as regular CDR. --- ## Post #23 by @thomas.beale [quote="borut.jures, post:22, topic:1567"] In my understanding (as a newbie to openEHR), the separate “draft” instance of e.g. EHRBase would treat its data as if it is “finalized”. [/quote] This would be technically possible, but raises other problems: * draft content is usually required to be visible in the EHR of the patient, just marked as 'incomplete' or 'not signed off' or similar * draft content would normally be considered part of the patient's EHR - it is real information that may be in use. If you put it in a separate CDR, then the logical EHR of any patient for whom there is draft info will now stretch across 2 CDR instances, which creates difficulties for privacy management, access control, and various admin-level operations such as move / delete / merge etc. I would advise against it. Note: here I am not talking about some kind of client-side partial form-save capability - that would need to be implemented completely separately e.g. via some encrypting cache approach. --- ## Post #24 by @borut.jures [quote="thomas.beale, post:23, topic:1567"] Note: here I am not talking about some kind of client-side partial form-save capability - that would need to be implemented completely separately e.g. via some encrypting cache approach. [/quote] I was thinking using separate "type A draft" instance for partial form-save capability as mentioned by @Paulmiller and you: > 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 Not on the client but on the server with standard security as in the case of the "primary" CDR instance. The primary goal was to reuse a CDR instead of building something similar just for "drafts of type A". However a simple sawing of draft composition as a JSON on the server (or client) might also solve this requirement in some cases. Thank you for pointing out the non-technical aspects. This is the knowledge I still need to acquire. --- ## Post #25 by @Seref I advocated for this approach (second CDR) in the past, but I was not the decision maker and my suggestion did not make it to chosen implementation. Depending on the circumstances, I have no problem advocating this again. Put a second CDR instance up, disable validation, and use it to deal with the chaotic reality of a ward. Tom beat me to emphasising the difference between different kinds of drafts. The requirement for users to keep on working on a clinical form intermittently, i.e. maybe stop working and come back to it later pops up very frequently. Come to think about it, it's probably one of the biggest user experience downsides of computer vs paper. As a nurse, you don't think twice before leaving a paper form on a desk, to attend to something else, then come back to it, or ask another nurse to complete it (patient safety related scenarios excluded). Expecting the same convenience from computers leads to half a dozen architects in a discussion forum on a Friday afternoon, as this thread shows... It's not about what we can make the computer do compared to paper, but what we can make it not to do. Here comes the part of my response which may be of help: **go back to your requirements for the actual clinical application**. Go through the user stories which requires a type-1 draft, then consider if any actual downsides to having a second CDR with relaxed validation settings exist, **in the context of that application, in and around those scenarios**. Outside of the context of whatever application you're developing, the comments saying a second CDR is OK, and those saying otherwise, are all speculative. What matters is do they apply to your specific application and use cases. EhrBase having the capability to turn off validation and function across the whole spectrum of its features is an entirely different matter of course. I just wanted to present an argument from a software engineering perspective, which sometimes gets overshadowed by openEHR vision. --- ## Post #26 by @ian.mcnicoll I thought the latest RM had formalised that a query should not normally retrieve compositions whose lifecycle_status is marked as 'incomplete'. https://openehr.atlassian.net/browse/SPECQUERY-24 I'd have thought it could be left to implementations to decide whether using a separate CDR is the best approach? There is a further subtle variation where the users want a document to be 'complete' in the sense of being visible in the CDR, but not 'signed-off' . We just used a local templated valueset in composition context for this. Ian --- ## Post #27 by @bna I am asking myself the question : What is a CDR and what's the purpose for it? I use the term CDR as the clinical data storage. I see the CDR as an abstraction or API to the (electronical) health record. There will be lots of other APIs in a health care provider. The ADR is an interesting service. I invented it now as an acronym for Application Data Repository. This is a layer to support applications and developer of applications to enable end-user functionality. Working with #openehr many applications and as such developer of applications will face the same needs and challenges. Should we as the #openehr community create specifications and/or patterns for these user-stories? I have been most interested in the clinical data related topics. They seems to be challenging enough for many. In our system we have implemented a solution for type 1 draft. This kind of drafts will never hit the CDR. We classify these kind of data as unfinished and with potential errors. It makes no sense to share them with others like a clinical decision support. I think it might be a good idea for #openehr community to look more into the ADR (application data repository/services) to provide a unified developer experience. We have, IMHO, so far not investigated this domain. A few topics to look into would then be * Drafts * Authorization (what a beast 🤔) * Structured and reusable AQL * No/low code solutions like Forms * UI building blocks * Reporting solutions * Folder "documents" To name a few. Are we ready to open these topics as a community? --- ## Post #28 by @Seref [quote="bna, post:27, topic:1567"] The ADR is an interesting service. I invented it now as an acronym for Application Data Repository. This is a layer to support applications and developer of applications to enable end-user functionality. [/quote] There goes the Ocean acronym for our Analytics Data Repository :) [quote="bna, post:27, topic:1567"] To name a few. Are we ready to open these topics as a community? [/quote] Big question. Depends on what you mean by opening. I'm concerned about the thin line between providing guidance to software developers on various things they'll all have to deal with and letting vendor choices leak into specs, therefore (partially) defining openEHR in terms of choices of individual vendors. Some of the topics you listed carry that risk (in my opinion). Discussion is good, it helps us share experiences and learn about how others view requirements, or about requirements we have not encountered yet. I'd just like to understand what those discussions aim to deliver from an openEHR specs perspective. --- ## Post #29 by @bna I am not sure myself Seref if we should go this direction. Its more like an restorative question, and I think its important to be specific about which topics are SW development guidance and tooling, and which are core CDR features. Sorry for taking an used acronym 😂 --- ## Post #30 by @Seref [quote="bna, post:29, topic:1567"] Sorry for taking an used acronym :joy: [/quote] don't worry. In the sprit of openEHR, we'll first invent an acronym mapping language, then develop an information model and add both to the specs. Problem solved. --- ## Post #31 by @siljelb [quote="Seref, post:30, topic:1567"] we’ll first invent an acronym mapping language [/quote] Let's call it Yeet Acronym Mapping Language (YAML), just to give it a running start :grin: --- ## Post #32 by @borut.jures [quote="Seref, post:30, topic:1567"] don’t worry. In the sprit of openEHR, we’ll first invent an acronym mapping language, then develop an information model and add both to the specs. Problem solved. [/quote] Please don't provoke another discussion about the validity of reference models (may I as a newcomer even ask such a thing :flushed:). An important step forward happened over the past few days regarding them. Check [this thread](https://discourse.openehr.org/t/where-to-find-aom2-bmm-for-the-latest-stable-release-2-3-0/2006/28) to see what @thomas.beale and @pieterbos achieved: [quote="thomas.beale, post:28, topic:2006"] Teamwork rules :wink: [/quote] --- ## Post #33 by @Seref [quote="borut.jures, post:32, topic:1567"] Please don’t provoke another discussion about the validity of reference models [/quote] I have some bad news for you... --- **Canonical:** https://discourse.openehr.org/t/lifecycle-state-in-ehrbase/1567 **Original content:** https://discourse.openehr.org/t/lifecycle-state-in-ehrbase/1567