# Why is value not optional for DvCodedText

**URL:** <https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945>\
**Category:** RM\
**Created:** [18 October 2021 12:48 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945 "2021-10-18T12:48:27Z")\
**Posts on this page:** 8\
**Page:** 2

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [19 October 2021 15:24 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/21 "2021-10-19T15:24:42Z")

</div>

> [@Seref](#):
>
> if by ‘flattening’, we’re talking about squashing a new of IS\_A assertions about an ontology of things into a single type, then I’ll take your word regarding the difficulty of expressing invariants in that case

If you want an extreme example, see the HL7v3 Act and ActRelationship classes - 22 and 18 attributes respectively. They could never adequately define the rules for what values were allowed in each field, depending on what values were in other fields, or when optionality applied. The interdependencies make it impossible. It’s only possible to do it when the class represents a coherent type all of whose attributes relate to that type and not either semantic parents, or composition sub-parts.

> [@Seref](#):
>
> I do think though, adoption of openEHR as an Object Oriented model of computing health data is an opportunity that time left behind.

Industry activity suggests otherwise 😉 But I know what you mean. However, openEHR RM isn’t trying to be anything other than a coherent canonical model of data in patient records. The main thing I regret was not using more generic types, because I didn’t realise that Java etc would eventually get them kind of right (even if they do evaporate in byte code). Then we could have had things like `Measured<Quantity>`, which would have been very nice. Inheritance is already pretty minimal, and about the same as in other typical industry models.

Agree on various data projections, but to have projections, including models optimised for data retrieve, we have to have the original model to generate from. Starting with projections is very risky.

> [@Seref](#):
>
> I’d therefore suggest gradually extending the set of RM with types with new ones that use less inheritance and shifting the means of validation to second level of openEHR as a long term strategy. I won’t go as far as building an openEHR 2.0 based on this approach because I don’t think I’ll live that long.

I’m not aware of anywhere where the _amount_ of inheritance is a problem. Whether we got every inheritance relationship (the DV\_TEXT / DV\_CODED\_TEXT example) is a question. But the inheritance doesn’t seem to cause any problems generally - maybe the DV\_ORDERED part of the model could be easier. But we could achieve that by things like `Measured<>` which would move all the accuracy and related fields to the right place. Indeed, the current Quantity classes are in fact a good example of the flattening/ mixin problem, created by us (mainly me).

---

<div class="post-metadata">

**Author:** ![SevKohler](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sevkohler/32/3504_2.png) [@SevKohler](https://discourse.openehr.org/u/SevKohler)\
**Post date:** [19 October 2021 16:00 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/22 "2021-10-19T16:00:51Z")

</div>

> [@Seref](#):
>
> I’d therefore suggest gradually extending the set of RM with types with new ones that use less inheritance and shifting the means of validation to second level of openEHR as a long term strategy. I won’t go as far as building an openEHR 2.0 based on this approach because I don’t think I’ll live that long.

I think the problem is less the amount, more the way some classes are inherited at least in this case. Surely I dont know about the rest of the RM, as you guys do.

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [19 October 2021 17:03 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/23 "2021-10-19T17:03:02Z")

</div>

> [@SevKohler](#):
>
> I just think the DvCodedText shouldnt relate from Text, i like inheritence but here i think it has more downsides.

Having the current inheritance helps to choose between DV\_TEXT and DV\_CODED\_TEXT on each field declared as DV\_TEXT, which is a useful feature.

Which could be modeled as Thomas mention below, but it wasn’t:

> [@thomas.beale](#):
>
> we would model it like this:
> 
> - DV\_TEXT (abstract)
> - DV\_PLAIN\_TEXT
> - DV\_CODED\_TEXT

The possibility of having a text and code it, in runtime or by constraints, should still be there.

---

<div class="post-metadata">

**Author:** ![SevKohler](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sevkohler/32/3504_2.png) [@SevKohler](https://discourse.openehr.org/u/SevKohler)\
**Post date:** [19 October 2021 19:38 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/24 "2021-10-19T19:38:13Z")

</div>

Thanks i already read that, i just do not 100% agree with that design choice 😉  
Thats exactly why it has the “issues” described above with naming and cardinality, at least in my opinion. But there are also valid points in doing it like that as you and thomas already stated.

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [20 October 2021 07:13 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/25 "2021-10-20T07:13:35Z")

</div>

Realising that I am bit late to the party, I won’t go into a philosophical discussion, but want to quickly voice my opinion here:

- Inheritance in openEHR feels about right to me, generally speaking. (If ever redone, some streamlining may be useful).
- The generic types approach Thomas mentions would have been nice, but too cumbersome for tooling at the time
- DV\_CODED\_TEXT is a trouble maker as can be seen with this renewed discussion
- I used to agree with the idea of having the DV\_TEXT text value mandatory and believe it was the right design choice at the time. However, nowadays you can consider e.g. Snomed CT and LOINC almost as a commodity and this changes the balance somewhat.
- I can see why Thomas disagrees, but - from my (in this case) maybe rather pragmatic perspective - the FHIR guys got CodeableConcept pretty right. Leaving the difficult question of legacy data, potential migration, multiple ways of expressing the same thing, etc. aside, I think a CodeableConcept-ish datatype would be useful.
- Not sure how exactly Ian sees the CodeableConcept facade working in practice, but maybe this is something to be explored further.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [20 October 2021 09:59 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/26 "2021-10-20T09:59:18Z")

</div>

> [@sebastian.garde](#):
>
> the FHIR guys got CodeableConcept pretty right. Leaving the difficult question of legacy data, potential migration, multiple ways of expressing the same thing, etc. aside, I think a CodeableConcept-ish datatype would be useful.

This is what [CodeableConcept](https://www.hl7.org/fhir/datatypes.html#CodeableConcept) looks like:  
 ![CodeableConcept](https://discourse.openehr.org/uploads/default/original/2X/b/b8b18e59189e9d1f101d32a7cac337184192e4e5.png)

And it’s sub-part type Coding…  
 ![Coding](https://discourse.openehr.org/uploads/default/original/2X/7/70a503a6ef2ebfa0464d35acf3798953d8d0a3e4.png)

In this model, we can see a field ‘userSelected’. This demonstrates the factoring of FHIR types as being designed for clinical data retrieval - contextual attributes such as this are mixed in with definitional attributes. In a canonical model, you would never do this. The correct name for the Coding (based on its attributes) type would in fact be something like CodingUsedInData. It is easy to imagine applications that want to use this type, but could never populate this field, for the simple reason that there are numerous places in models and applications you want to represent codes that are not captured via user entry.

Indeed, FHIR-based app developers are doing this all the time, and have to skip past this field, and make sure no software reading the Coding object does anything wrong…

This is a [model in the Foundation Types](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_terminology_package) to do this job (this has been around for a few years now).  
 ![TerminologyTerm](https://discourse.openehr.org/uploads/default/original/2X/6/670497624203643ee96a23b80f7a3b6a87d785a1.png)

We could quite easily use these types outside of the EHR part of the RM, e.g. in Task Planning, GDL and so on.

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [20 October 2021 10:15 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/27 "2021-10-20T10:15:01Z")

</div>

I remain very comfortable with having value as mandatory - we do come across occasional instances of ‘technical codes’ where there is no formal text value , though the code itself may be human readable. In that case I simply advise replicating the code as text.

re CodeableConcept - I agree that the ‘display’ is badly termed - it should be (and I suspect is often taken to be) what we would call the defining\_code. Nevertheless having all of the assigned codes in a simple list, with the ‘source of truth’ failed is way easier to understand, than explicitly separating the mappings as we do.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [20 October 2021 11:09 UTC](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945/28 "2021-10-20T11:09:57Z")

</div>

> [@ian.mcnicoll](#):
>
> though the code itself may be human readable. In that case I simply advise replicating the code as text.

yes indeed, e.g. most ISO and IANA code -sets.

> [@ian.mcnicoll](#):
>
> Nevertheless having all of the assigned codes in a simple list, with the ‘source of truth’ failed is way easier to understand, than explicitly separating the mappings as we do

I don’t disagree - but we need to be clear on where we want such a representation - on commit or on pull.

Here is a [model of FHIR’s terminology service structures](https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_terminology_service), which we could consider using for various purposes in openEHR if we wanted.

 ![TerminologyService](https://discourse.openehr.org/uploads/default/original/2X/3/30a044c41954eac0464b8a1b12682c15c4b9c6eb.png)

[Previous page](https://discourse.openehr.org/t/why-is-value-not-optional-for-dvcodedtext/1945.md?page=1)