# Simplified Formats (FLAT) completing partial DV\_CODED\_TEXT input

**URL:** <https://discourse.openehr.org/t/simplified-formats-flat-completing-partial-dv-coded-text-input/17446>\
**Category:** RM\
**Tags:** ehrbase, better, flat, ferroehr\
**Created:** [30 October 2026 12:09 UTC](https://discourse.openehr.org/t/simplified-formats-flat-completing-partial-dv-coded-text-input/17446 "2026-10-30T12:09:37Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Post date:** [30 October 2026 12:09 UTC](https://discourse.openehr.org/t/simplified-formats-flat-completing-partial-dv-coded-text-input/17446/1 "2026-10-30T12:09:37Z")

</div>

Hi!

The fun thing when trying to implement software (like [Ehrtslib](https://github.com/ErikSundvall/ehrtslib/blob/main/docs/README.md)) from specifications is that you discover possible ambiguities in them; that is yet another reason to love new implementations!

The fairly recently added [Simplified Formats §5.27](https://specifications.openehr.org/releases/ITS-REST/latest/simplified_formats.html#DV_CODED_TEXT) specification makes `|value` and `|terminology` optional for local/openehr codes, but does not say how a receiver should complete them. It marks `|code` as required, but does not say whether value-only input must be rejected, and is silent on a bare key with no suffix, input that matches nothing, and a `|code`/`|value` conflict. Actual implementations differ:

| Input | [EHRbase 2.36.0](https://github.com/ehrbase/openEHR_SDK/blob/3d5ca54c6a488030cbd5ef33fd26a605f6435089/serialisation/src/main/java/org/ehrbase/openehr/sdk/serialisation/flatencoding/std/umarshal/rmunmarshaller/DvCodedTextRMUnmarshaller.java#L72-L126) | [FerroEHR 5.5.0](https://github.com/FerroHEALTH/FerroEHR/blob/d25c95a974142ec13fe7b107fa098555ef1631c3/crates/openehr-sdt/src/flat/map/data_values.rs#L585-L609) | [Better web-template 5.0.1](https://github.com/better-care/web-template/blob/05320691dbda9b1ac94379d5591b17595c20a5b8/src/main/kotlin/care/better/platform/web/template/converter/raw/factory/leaf/DvCodedTextFactory.kt#L107-L162) (source) |
| --- | --- | --- | --- |
| `|code` only | template default-language rubric | template default-language rubric | composition-language rubric ([test](https://github.com/ErikSundvall/ehrtslib/blob/main/docs/research/flat-coded-text-language-test-2026-10.md#better-web-template)) |
| `|value` only | exact label match | 422 | stored without `defining_code` |
| bare key | code, then label | 422 | treated as code; also accepts `terminology::code::value` |
| value-only/bare key, no match | 422 | 422 | bare key: exception; `|value`: stored without `defining_code` |
| `|value` = another code’s term | value replaced by rubric | sent value kept | sent value kept |

### Language test:

With a template whose original language is Swedish, with English as an included translation ([Region Stockholm chemotherapy symptom form](https://github.com/regionstockholm/CKM-mirror-via-modellbibliotek/releases/tag/ChemoForm-MBA%28oral_administration%29.1.0.1)), sending only `|code` with `ctx/language` set to `en` made EHRbase 2.36.0 and FerroEHR 5.5.0 store the Swedish rubric “Ja” instead of the English “Yes”, while the Better web-template library (3.2.9 and 5.0.1) stored “Yes”.

Sending an English `|value` “Yes” without `|code` in an English composition was rejected with 422 by EHRbase, which matches the text against the Swedish rubrics only (Swedish “Ja” was accepted in the same composition), and by FerroEHR, which requires `|code` for every coded value; the Better library accepted it but produced a DV\_CODED\_TEXT without `defining_code`. _(Better was tested as a library only, not as a CDR, so the missing `defining_code` might be caught by validation in Better’s server. [Test details](https://github.com/ErikSundvall/ehrtslib/blob/main/docs/research/flat-coded-text-language-test-2026-10.md#results))_

### Display text for DV\_CODED\_TEXT:

Can I assume `defining_code.code_string` and [`preferred_term`](https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_code_phrase_class) must correspond, while `value` may differ to record what the user saw in the user interface (e.g. a synonym or form label), as intended by [SPECPR-165](https://openehr.atlassian.net/browse/SPECPR-165) and the RM [integration scenarios](https://specifications.openehr.org/releases/RM/latest/data_types.html#_integration_scenarios)?

The RM [data types design text](https://specifications.openehr.org/releases/RM/latest/data_types.html#_design_2) instead requires the “exact term text”, else a `DV_TEXT`. EHRbase overwrites such a `|value` in FLAT and [rejects it](https://github.com/ehrbase/openEHR_SDK/blob/3d5ca54c6a488030cbd5ef33fd26a605f6435089/validation/src/main/java/org/ehrbase/openehr/sdk/validation/webtemplate/DvCodedTextValidator.java#L109-L135) in canonical; FerroEHR [keeps it](https://github.com/FerroHEALTH/FerroEHR/blob/d25c95a974142ec13fe7b107fa098555ef1631c3/crates/openehr-sdt/src/flat/map/data_values.rs#L585-L609), having reverted value = rubric enforcement as spec overreach ([#254](https://github.com/FerroHEALTH/FerroEHR/issues/254), [#262](https://github.com/FerroHEALTH/FerroEHR/issues/262), [#1507](https://github.com/FerroHEALTH/FerroEHR/issues/1507)). @ian.mcnicoll has proposed the same reading ([11606](https://discourse.openehr.org/t/snomed-coding-of-values-in-compositions/11606/3), [5063](https://discourse.openehr.org/t/how-to-make-mappings-easier-to-query-and-to-document-in-openehr/5063/26), [1998](https://discourse.openehr.org/t/coding-element-and-event-names/1998/14)). To @sebastian.iancu’s question regarding [how to validate](https://discourse.openehr.org/t/how-to-make-mappings-easier-to-query-and-to-document-in-openehr/5063/31): validation applies to `code_string` and `preferred_term`; `value` is display text, and a `value` equal to another code’s term is a conflict and an error (Q4).

What ehrtslib currently does ([PR #236](https://github.com/ErikSundvall/ehrtslib/pull/236)):

- `|code` only: rubric in the composition language.
- `codedTextMismatch`: `"reject"` (default), `"keep"` or `"correct"`, for case-only mismatches, no match, `|value` = another code’s term, and another language’s rubric.
- Valid `|code` + unlisted `|value` is display text, per `codedTextDisplayValue`: `"keep"` (default, like [Better](https://github.com/better-care/web-template/blob/05320691dbda9b1ac94379d5591b17595c20a5b8/src/main/kotlin/care/better/platform/web/template/converter/raw/factory/leaf/DvCodedTextFactory.kt#L317-L336) and [FerroEHR](https://github.com/FerroHEALTH/FerroEHR/blob/d25c95a974142ec13fe7b107fa098555ef1631c3/crates/openehr-sdt/src/flat/map/data_values.rs#L585-L609)), `"keep-and-set-preferred-term"` (rubric into [`|preferred_term`](https://specifications.openehr.org/releases/ITS-REST/Release-1.1.0/simplified_formats.html#DV_CODED_TEXT)), or `"replace-with-rubric"` (EHRbase compatibility, not recommended).
- These are options because ehrtslib can be used as a front end for, and converter between, platforms that behave differently. A CDR likely wants fewer or no options.

### Questions:

1. Should code-only completion be normative, using the composition language with the template default as fallback? ([SPECPR-171](https://openehr.atlassian.net/browse/SPECPR-171) leaves the language to the implementation.)
2. Is value-only or bare-key input conformant, or a receiver-side extension that producers must not rely on? If it is allowed, should matching be exact by default, with case-insensitive matching as an opt-in?
3. Should value-only or bare-key input that matches nothing be rejected, or kept with a warning?
4. When `|value` equals the term of a different code than `|code`, I suggest rejecting with an error by default. Agreed?
5. Better parses bare keys as `terminology::code::value`, while its [2020 SDT description](https://discourse.openehr.org/t/simplified-data-template-sdt-data-types/546/4) was `terminology::code|value|`. Neither is documented. Should one be documented, or both deprecated?
6. Should the RM text be refined accordingly, so a valid `|code` with an unlisted `|value` is kept as display text?Se related alternatives in _“Points for the SEC to decide”_ in [Veredictum #718](https://github.com/Vernum-Projecten/Veredictum/issues/718) issue by @rubentalstra.

After we have some feedback on the questions we can turn the outcome into a SPECITS problem report.