# Really good openEHR technical documentation (from FHIR)

**URL:** <https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622>\
**Category:** Specifications\
**Created:** [1 December 2025 06:16 UTC](https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622 "2025-12-01T06:16:15Z")\
**Posts on this page:** 5\
**Page:** 1

<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:** [1 December 2025 06:16 UTC](https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622/1 "2025-12-01T06:16:16Z")

</div>

Just check this page [Artifacts Summary - OpenEHR Base package v0.1.0](https://build.fhir.org/ig/FHIR/openehr-base-ig/artifacts.html)

---

<div class="post-metadata">

**Author:** ![siljelb](https://discourse.openehr.org/user_avatar/discourse.openehr.org/siljelb/32/12_2.png) [@siljelb](https://discourse.openehr.org/u/siljelb)\
**Post date:** [1 December 2025 08:58 UTC](https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622/2 "2025-12-01T08:58:37Z")

</div>

Interesting read! But I suspect they’ve put the description of DV\_INTERVAL with both DV\_INTERVAL and DV\_ORDINAL.

Edit: Also DV\_COUNT’s description both with DV\_COUNT and with DV\_PROPORTION.

---

<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:** [1 December 2025 19:26 UTC](https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622/3 "2025-12-01T19:26:44Z")

</div>

I don’t know what’s the quality status of that spec, and that site might be WIP. Anyway it’s interesting and it’s in a very user friendly format.

---

<div class="post-metadata">

**Author:** ![joostholslag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/joostholslag/32/1981_2.png) [@joostholslag](https://discourse.openehr.org/u/joostholslag)\
**Post date:** [2 December 2025 14:28 UTC](https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622/4 "2025-12-02T14:28:07Z")

</div>

@grahamegrieve made it by hand during meetings XD

---

<div class="post-metadata">

**Author:** ![Seref](https://discourse.openehr.org/user_avatar/discourse.openehr.org/seref/32/13_2.png) [@Seref](https://discourse.openehr.org/u/Seref)\
**Post date:** [3 December 2025 14:50 UTC](https://discourse.openehr.org/t/really-good-openehr-technical-documentation-from-fhir/11622/5 "2025-12-03T14:50:46Z")

</div>

I’ve been meaning to check out what happens when generics get involved in openEHR ←→ FHIR mappings at the data type level. It looks like this is not yet addressed at the logical model based approach. To avoid invoking the impression of an entitled snob with that previous sentence, let me say that I did not mean to express an expectation; this is not a trivial semantic bridge, and it will probably require the same kind of materialisation trick we resort to in XML schemas. Things would get even more fun with reference ranges etc. because there’s some data level recursion there which cannot be constrained at the type level.

I think @grahamegrieve had a note somewhere (in the github repo?) suggesting that this was supposed to be a representation for machines to process, and not for us carbon based life forms 🙂 but the nice formatting helps it serve a dual purpose I think. Nicely done.