I have come across this situation where one of the fields i need to describe in an archetype (Residence Status) contains 8 strictly encoded values, one of which is "Other" implying that besides the encoded values, free-text would also be acceptable.
I am a bit puzzled as to how to represent this through the archetype editor and would appreciate your help with the following:
*) The type is clearly DV_TEXT ("free text or encoded")
*) DV_TEXT does not allow one to constrain the encoded part ("internal codes") through the archetype editor (i think)
*) DV_CODED_TEXT is a descendant of DV_TEXT
*) DV_CODED_TEXT has stricter semantics than DV_TEXT
1) If this was declared as DV_TEXT "free text or encoded" how can one constrain its content? (Through the archetype editor)
2) If this was declared as DV_CODED_TEXT, should "other" be part of the "internal codes" in a DV_CODED_TEXT? (I am not sure this would be right because in this case, you can't store the actual free-text "value" anywhere. The "value" of this will be "other")
3) Is this situation expected to be resolved at the template level? If yes, how is that achieved? (What i mean is, how do you decide if this is a "strictly multiple choice field" or "multiple choice with optional free text"
Looking forward to hearing from you
Athanasios Anastasiou
The way to do this in the Archetype Editor is by adding a "Choice" element.
With the Choice element, you can add multiple constraint types to the same node. In this particular case, you would add two Text constraints, one free text and the other with the internal codes.
This is such a common scenario that there is a proposal to make it easier to do this. Here is the text of the change request (which maybe someone will get around to doing one day):
Currently whenever modelling DV_coded text in an archetype, in 90+% of cases the true requirement is actually to model a choice of the DV_CodedText plus a DV_text (for the almost inevitable 'Other' options). Looks awkward and cumbersome. Additional step for nearly every one of these modelling situations.
However modelling this is cumbersome for so many text situations. After discussion with Sam, an option would be to allow the modeller to select DV_coded text and at the same time the application would automatically add the DV_text choice to the ADL underlying it by default. In the less common instance where the DV_text was not desired, then the modeller could deselct this as a checkbox from the AE Text attribute interface
So, request additional functionality:
1. Modeller adds a text data type, names it.
2. Selects a DV_CODEDTEXT ie Internal codes or Terminology -> Choice of DV_CODEDTEXT plus DV_TEXT is written to the ADL as default (likely 90+% likelihood that this combination is to be used)
3. Modeller deselects checkbox to remove the DV_TEXT component in less common situation that it is not desired.
the first thing I would check is whether that is actually true - or if ‘other’ is just another code, and there is no expectation of expressing the actual value separately. Because in the first 7 cases, the data structure is DV_CODED_TEXT = < value = <“code description for 1234567”> defining_code = < terminology_id = <“residence_status_codes”> – or whatever it is code_string = <“1234567”> > > (assuming you want the code rubric to be available), and in the 8th, if you want an actual value, it is in the 8th case, you are implying it is something like: DV_CODED_TEXT = < value = <“other”> defining_code = < terminology_id = <“residence_status_codes”> – or whatever it is code_string = <“99999”> > > which doesn’t really work. You would need two data points to do this properly in an archetype, so no tool is going to be able to do this job with a single data point (i.e. a single DV_TEXT or DV_CODED_TEXT). Now, I realise that the situation as you describe it probably is a relatively common pattern, and there is probably an argument for making the archetype editor support it in a way that allows the user to just specify it in a logical way, and the editor creates the appropriate constraints on two data points to cover the ‘other’ case. It’s not a completely obvious construct however, since for the other 7 codes, you only need one data point; the free text one is left empty. - thomas
In that case would "other" still have to be included in the DV_CODED_TEXT part of the CHOICE (?)
All the best
Athanasios
P.S. "Choice" (as an element) has escaped my attention so far as i have been focusing on what constitutes about 85% of the elements currently in use by the archetypes at the CKM. (Purely because of time constraints)
Thank you for your response. I think that i should have provided a bit more information indeed. Here are the possible responses:
1) House
2) Condo/Co-op (owned)
3) Apartment (rented)
4) Mobile Home
5) Retirement Community
6) Assisted Living
7) Skilled Nursing Facility
*) Other (specify)
So, it is a case of "other" requiring a response.
I suppose that it is one of these fields where, it is good to keep that information to refer to it back after performing some data analysis and finding some discrepancies. That information may be useful in this case. (Rather than expecting someone to query for that free-text "other")
> Now, I realise that the situation as you describe it probably is a
> relatively common pattern, and there is probably an argument for making
> ....
> only need one data point; the free text one is left empty.
It wasn't so much of a feature request
But having been reminded of the Choice element by Peter, maybe what you explained here could be added anyway and automatically resolve to a "Choice" field.
Maybe it would be nice to have some "Choice" attribute at the Template level so that particular choices (such as this one) are handled in specific ways.
The DV_TEXT in openEHR is unique in that it can meet your needs. This IS a free text field but it can be replaced with a DV_CODED_TEXT whenever needed. This is because DV_CODED_TEXT inherits from DV_TEXT and offers the same interface. The modeller can insist on coded values if appropriate.
The sort of coded value and other - or typing text and then having it coded etc are all useful user interface options. How this is done will depend on the application. So our models do not say anything about that: only if it can be free text or it must be coded. If it must be coded we do allow an internal code set.
