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
2 Likes
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
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.
2 Likes
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
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.
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.
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
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
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
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?
4 Likes
There goes the Ocean acronym for our Analytics Data Repository 
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
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 
1 Like
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
Let’s call it Yeet Acronym Mapping Language (YAML), just to give it a running start 
4 Likes
Please don’t provoke another discussion about the validity of reference models (may I as a newcomer even ask such a thing 
).
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
I have some bad news for you…
1 Like