Hi Tiago, I don’t think multiple selections in a dvcodedtext is possible because a dvcodedtext can contain only one code in data. So I think you need multiple elements with each a dvboolean, you can group them using a cluster.
I understand that you can use a cluster with multiple Boolean. But I would like that the values came from a terminology.
Maybe a better example would be the following:
Select the laboratory tests that should I request:
Blood Glucose
Blood Culture
Albumin
< 100 other tests …>
Amylase
Can’t I use the values of a terminology such as list of options using openEHR? Do I must write all the laboratory tests in the archetype like booleans?
I have trouble understanding how openEHR handles lists of values. I think I have to use the field “occurrences 0.*” but I’m not sure if that is the correct way.
Maybe I’m not thinking right about how to use OpenEHR.
Hi Pablo, good solution, I think it is a better solution then mine, the only problem is that it allows more times the same selection, isn’t it? Because you can let occur a DvCodedText more then once in an Element, but you cannot define it more then once. Maybe more elements with all one DvCodedText and with all have only one (but different) code to select, and have an occurrence of optional 0..1..
I think OpenEhr should solve this by creating a new datatype. What do you think?
This is an issue that was raised many years ago by the Code24 guys, which they called the ‘pizza problem’ i.e what toppings would you like on your pizza?
The standard approach is to model this, as has already been suggested, as multiple occurences of a coded_text element.
This leaves the problem of how to exclude non-unique elements as Bert suggested. We have talked in the past about adding a ‘unique’ keyword to occurences to signfify that repeated identical elements are invalid, however I am struggling to think of any valid clinical use-case where it would be valid to have repeated, non-unique coded_text or text items.
I think you can assume that at least for coded_text element with multiple occurence, unique should apply (although it is also difficult to see what harm would befall if mutliple identical codes were recorded in data.
It would be probably be easy to add ‘unique’ keyword to occurences if necessary, as the key word already exists against containers but I am really not sure it is necessary.
The solution is using multiples DV_CODED_TEXT and uniqueness is implemented by software.
In this case I think that the data persistence is made of many leaf paths (one value by leaf). I don’t see the problem in saving the entire composition in a contribution, but if I send only changed data I have to find a way of delete a leaf when “checkbox” is deselected. I know how to update key/path data but I didn’t find deletion in the openEHR specification (Probably I failed when I was searching for this).
I think that is just a implementation problem and I wont’t find that in specification. Am I correct?
Hi Ian, I think you know Murphy's law. If a bug can happen, it will happen. Last years, for developers, the rule is to write code in a way that a bug can not occur.
Archetypes are everywhere, as building blocks in templates, they can be the base of reports, messages (incoming outgoing), displays.
I think a new datatype, like DVCodedList would be a good idea (a list with codephrases, a list which can have attributes like sort (true/false), single-select (true/false)) but also a list with no items predefined which retrieves its items from code, a list with max-display (for if it gets to long), etc. It would be good for integrating SCT, to have such a list datatype.
I’m with Ian, a coded_text with multiple occurrences. Probably the existing “unique” option in the “items” attribute of the container CLUSTER already solves the problem of repetitions of the same ELEMENT. It will mean that you are defining a logical set of ELEMENTs. What I have never had clear (and I think it is not clear in the specifications either) is if the unique property means identity or equality, i.e. we cannot have exactly the same ELEMENT, or we cannot have ELEMENTs with the same value.
Bert, what you propose is probably mixing things from the data structure definition and from the UI, which is not a good idea for future maintenance. If we want to render the different options as checkboxes, as a selection list or whatever other representation lies on the UI side.
This should only be an issue if you have to perform an update. My best understanding is that known of the well-known implementations try to perform a ‘diff’ in event of an update they simply create a full new version of the composition based on the new data.
Whilst this is a bit inefficient, the realities for performing diffs safely across the full range of potential scenarios is quite daunting and raises many potential clinical safety issues.
My suggestion would just to recreate the composition each time.
