Lifecycle_state in EHRbase

Implementation Platform
21

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

22

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.

23

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.

24

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.

1 Like
25

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.

4 Likes
26

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

1 Like
27

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 :thinking:)
  • 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?

4 Likes
28

There goes the Ocean acronym for our Analytics Data Repository :slight_smile:

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.

3 Likes
29

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 :joy:

1 Like
30

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.

4 Likes
31

Let’s call it Yeet Acronym Mapping Language (YAML), just to give it a running start :grin:

4 Likes
32

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 to see what @thomas.beale and @pieterbos achieved:

1 Like
33

I have some bad news for you…

1 Like