# ITS

**URL:** https://discourse.openehr.org/c/specifications/its/41.md

[Latest](https://discourse.openehr.org/latest.md) · [Categories](https://discourse.openehr.org/categories.md) · [Tags](https://discourse.openehr.org/tags.md)

---

## [About the ITS category](https://discourse.openehr.org/t/about-the-its-category/630)

<div class="topic-metadata">

**Author:** [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Replies:** 0

</div>

Discussions on any of the Implementation Technology Specifications, i.e. derivatives from the abstract specs, including REST APIs, XSD, JSON, and HL7 FHIR interfaces.

---

## [Delete COMPOSITION mentions preceding\_version\_uid](https://discourse.openehr.org/t/delete-composition-mentions-preceding-version-uid/17203)

<div class="topic-metadata">

**Author:** [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Replies:** 2\
**Last updated:** [16 August 2026 15:31 UTC](https://discourse.openehr.org/t/delete-composition-mentions-preceding-version-uid/17203 "2026-08-16T15:31:25Z")

</div>

Delete COMPOSITION mentions preceding\_version\_uid in the description but it is not used as If-Match request header. If If-Match with preceding\_version\_uid is required, then the Header Parameters section should be added. …

---

## [Use the same parameter names for tag\_key and key in ITEM\_TAG endpoints](https://discourse.openehr.org/t/use-the-same-parameter-names-for-tag-key-and-key-in-item-tag-endpoints/17195)

<div class="topic-metadata">

**Author:** [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Replies:** 0\
**Last updated:** [11 August 2026 12:56 UTC](https://discourse.openehr.org/t/use-the-same-parameter-names-for-tag-key-and-key-in-item-tag-endpoints/17195 "2026-08-11T12:56:32Z")

</div>

In Get EHR tags, the query parameters are all prefixed with tag\_ (e.g., tag\_key). In Delete COMPOSITION tags and Delete EHR\_STATUS tags, the parameters are not prefixed (e.g., key). I propose that both key parameters a…

---

## [Posting IMPORTED\_VERSION with CONTRIBUTION](https://discourse.openehr.org/t/posting-imported-version-with-contribution/17180)

<div class="topic-metadata">

**Author:** [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Replies:** 2\
**Last updated:** [6 August 2026 12:50 UTC](https://discourse.openehr.org/t/posting-imported-version-with-contribution/17180 "2026-08-06T12:50:35Z")

</div>

In the openEHR REST API, the “Create CONTRIBUTION” is using UPDATE\_VERSION for the versions array payload. The properties for UPDATE\_VERSION represent most of the attributes of ORIGINAL\_VERSION. The question is, how do …

---

## [Should the UPDATE\_VERSION.data in the openEHR REST API be required?](https://discourse.openehr.org/t/should-the-update-version-data-in-the-openehr-rest-api-be-required/17177)

<div class="topic-metadata">

**Author:** [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Replies:** 2\
**Last updated:** [6 August 2026 12:48 UTC](https://discourse.openehr.org/t/should-the-update-version-data-in-the-openehr-rest-api-be-required/17177 "2026-08-06T12:48:53Z")

</div>

OpenAPI validation file for UPDATE\_VERSION has the data property as required. I assumed that the data property can be empty for UPDATE\_VERSION.commit\_audit.change\_type=523 (deleted). For example in the case of Delete COM…

---

## [RM Mappings - DV\_CODED\_TEXT preferred\_term missing](https://discourse.openehr.org/t/rm-mappings-dv-coded-text-preferred-term-missing/11780)

<div class="topic-metadata">

**Author:** [@jbuch](https://discourse.openehr.org/u/jbuch)\
**Replies:** 8\
**Last updated:** [28 April 2026 11:22 UTC](https://discourse.openehr.org/t/rm-mappings-dv-coded-text-preferred-term-missing/11780 "2026-04-28T11:22:19Z")

</div>

When trying to POST a FLAT Composition on EHRBase, I noticed that I wasn’t able to save a DV\_CODED\_TEXT with a preferred\_term, and neither is it retained after saving it using a RAW/JSON Composition and then loaded in FL…

---

## [Flat path «|other» missing in simplified format for DV\_CODED\_TEXT](https://discourse.openehr.org/t/flat-path-other-missing-in-simplified-format-for-dv-coded-text/11790)

<div class="topic-metadata">

**Author:** [@emmanuel.eschmann](https://discourse.openehr.org/u/emmanuel.eschmann)\
**Replies:** 1\
**Last updated:** [4 March 2026 09:29 UTC](https://discourse.openehr.org/t/flat-path-other-missing-in-simplified-format-for-dv-coded-text/11790 "2026-03-04T09:29:13Z")

</div>

The simplified format for DV\_CODED\_TEXT (see https://specifications.openehr.org/releases/ITS-REST/development/simplified\_formats.html#DV\_CODED\_TEXT) does not mention the flat path “|other”. However, some CDRs — for examp…

---

## [Terse/compact serialisation of openEHR leaf nodes, like ECISFLAT values?](https://discourse.openehr.org/t/terse-compact-serialisation-of-openehr-leaf-nodes-like-ecisflat-values/11649)

<div class="topic-metadata">

**Author:** [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Replies:** 5\
**Last updated:** [11 December 2025 07:03 UTC](https://discourse.openehr.org/t/terse-compact-serialisation-of-openehr-leaf-nodes-like-ecisflat-values/11649 "2025-12-11T07:03:39Z")

</div>

Hi! The value encoding in the wonderfully ingenious (now possibly deprecated?) ECISFLAT format (likely created by @chevalleyc) is described in ethercis/doc/flat json.md at master · ethercis/ethercis · GitHub There is a…

---

## [The good, the bad and the "Wat?" of current simplified FLAT/SimSDT openEHR exchange format](https://discourse.openehr.org/t/the-good-the-bad-and-the-wat-of-current-simplified-flat-simsdt-openehr-exchange-format/3819)

<div class="topic-metadata">

**Author:** [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Replies:** 45\
**Last updated:** [26 November 2025 18:42 UTC](https://discourse.openehr.org/t/the-good-the-bad-and-the-wat-of-current-simplified-flat-simsdt-openehr-exchange-format/3819 "2025-11-26T18:42:55Z")

</div>

Hi! At Karolinska we are a bit confused about how to format/use some things in different forms of the FLAT/SimSDT format. We are testing at least three CDR products that are supposed to support it and at least two (non-…

---

## [Natural language based FLAT format and long container/element names](https://discourse.openehr.org/t/natural-language-based-flat-format-and-long-container-element-names/6765)

<div class="topic-metadata">

**Author:** [@siljelb](https://discourse.openehr.org/u/siljelb)\
**Replies:** 22\
**Last updated:** [6 November 2025 07:53 UTC](https://discourse.openehr.org/t/natural-language-based-flat-format-and-long-container-element-names/6765 "2025-11-06T07:53:38Z")

</div>

Last year we were well on our way to create a modelling style guide for patient reported outcome measure (PROM) archetypes. PROMs are usually copyrighted tools, and we will most of the time require the approval of the co…

---

## [Missing constraints in JSON schemas](https://discourse.openehr.org/t/missing-constraints-in-json-schemas/6860)

<div class="topic-metadata">

**Author:** [@pablo](https://discourse.openehr.org/u/pablo)\
**Replies:** 0\
**Last updated:** [22 May 2025 00:43 UTC](https://discourse.openehr.org/t/missing-constraints-in-json-schemas/6860 "2025-05-22T00:43:45Z")

</div>

Hi all, I just found many missing constraints and raised a ticket in JIRA Jira Values for DV\_DATE, DV\_TIME, DV\_DATE\_TIME and DV\_DURATION should have a specific format and currently those are just strings in the schema…

---

## [JSON Schema and OpenAPI: current state, and how to progress](https://discourse.openehr.org/t/json-schema-and-openapi-current-state-and-how-to-progress/1385)

<div class="topic-metadata">

**Author:** [@pieterbos](https://discourse.openehr.org/u/pieterbos)\
**Replies:** 40\
**Last updated:** [8 April 2025 04:46 UTC](https://discourse.openehr.org/t/json-schema-and-openapi-current-state-and-how-to-progress/1385 "2025-04-08T04:46:54Z")

</div>

We recently had a discussion on the SEC call about JSON Schema. I was asked to write down the current state and to get the discussion going on how to progress. So, here it is: Several options exist to define a JSON form…

---

## [Demographics api](https://discourse.openehr.org/t/demographics-api/6552)

<div class="topic-metadata">

**Author:** [@joostholslag](https://discourse.openehr.org/u/joostholslag)\
**Replies:** 1\
**Last updated:** [14 March 2025 13:39 UTC](https://discourse.openehr.org/t/demographics-api/6552 "2025-03-14T13:39:44Z")

</div>

What’s the status of the demographics rest-api? I notice there’s an OpenAPI description in the SPEC. But it’s not listed on the ITS-REST page of overview spec. openEHR - REST API specifications (ITS-REST) Component - 1.0…

---

## [Directory folder in xml format](https://discourse.openehr.org/t/directory-folder-in-xml-format/6061)

<div class="topic-metadata">

**Author:** [@surfer](https://discourse.openehr.org/u/surfer)\
**Replies:** 15\
**Last updated:** [18 January 2025 12:18 UTC](https://discourse.openehr.org/t/directory-folder-in-xml-format/6061 "2025-01-18T12:18:58Z")

</div>

Hi, I can create a directory in json and post it with success (in EHRBase) but I cannot write one in xml that works. Does anyone have a xml directory folder to share ? I made several unsuccessful attempts at guessing …

---

## [Inconsistency in REST API Create EHR implementations -needs spec clarification?](https://discourse.openehr.org/t/inconsistency-in-rest-api-create-ehr-implementations-needs-spec-clarification/1199)

<div class="topic-metadata">

**Author:** [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Replies:** 27\
**Last updated:** [9 October 2024 07:47 UTC](https://discourse.openehr.org/t/inconsistency-in-rest-api-create-ehr-implementations-needs-spec-clarification/1199 "2024-10-09T07:47:50Z")

</div>

Hi - I am having a little trouble with the POST /ehr call across the Better and EhrBase implementations // EhrBase { "\_type": "EHR\_STATUS", "archetype\_node\_id": "openEHR-EHR-EHR\_STATUS.generic.v1", "name": "ehr…

---

## [Add a composition to a folder via openEHR REST API](https://discourse.openehr.org/t/add-a-composition-to-a-folder-via-openehr-rest-api/4388)

<div class="topic-metadata">

**Author:** [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Replies:** 8\
**Last updated:** [12 September 2024 05:59 UTC](https://discourse.openehr.org/t/add-a-composition-to-a-folder-via-openehr-rest-api/4388 "2024-09-12T05:59:26Z")

</div>

Sorry I’m being dumb but I can see a way to allocate a composition to a folder in the REST API - help?

---

## [SMART on openEHR](https://discourse.openehr.org/t/smart-on-openehr/4517)

<div class="topic-metadata">

**Author:** [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)\
**Replies:** 4\
**Last updated:** [20 August 2024 07:37 UTC](https://discourse.openehr.org/t/smart-on-openehr/4517 "2024-08-20T07:37:28Z")

</div>

In the past few months we where working on a draft for SMART on openEHR specifications. The idea was originally started by @Sidharth\_Ramesh (see this post), and lately a few other members of the openEHR REST API Working…

---

## [Adding metadata to stored queries](https://discourse.openehr.org/t/adding-metadata-to-stored-queries/5537)

<div class="topic-metadata">

**Author:** [@Dileep\_V\_S](https://discourse.openehr.org/u/Dileep_V_S)\
**Replies:** 2\
**Last updated:** [2 August 2024 07:09 UTC](https://discourse.openehr.org/t/adding-metadata-to-stored-queries/5537 "2024-08-02T07:09:26Z")

</div>

The current specification do not seem to include adding metadata to stored queries. It may be a good idea to allow addition of user provided metadata such as description, purpose etc. This will be useful as installed so…

---

## [REST API specifications for archetype/template governance systems](https://discourse.openehr.org/t/rest-api-specifications-for-archetype-template-governance-systems/5351)

<div class="topic-metadata">

**Author:** [@damoca](https://discourse.openehr.org/u/damoca)\
**Replies:** 1\
**Last updated:** [12 June 2024 14:35 UTC](https://discourse.openehr.org/t/rest-api-specifications-for-archetype-template-governance-systems/5351 "2024-06-12T14:35:34Z")

</div>

Following this message: Maybe it is time to start thinking about creating a REST API specification for archetype/template repositories. It should go beyond the CDR definition endpoint, and allow a complete governance …

---

## [Smart on openEHR OpenAPI](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857)

<div class="topic-metadata">

**Author:** [@joostholslag](https://discourse.openehr.org/u/joostholslag)\
**Replies:** 3\
**Last updated:** [4 May 2024 14:19 UTC](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857 "2024-05-04T14:19:54Z")

</div>

openapi: A URL to the OpenAPI specification of the service … With example: "openapi": "https://platform.example.com/openehr/rest/v1/openapi.json" At: Why doesn’t the OpenAPI always point to openEHR OpenAPI files…

---

## [Specifications for the FLAT paths](https://discourse.openehr.org/t/specifications-for-the-flat-paths/5139)

<div class="topic-metadata">

**Author:** [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Replies:** 1\
**Last updated:** [26 April 2024 06:47 UTC](https://discourse.openehr.org/t/specifications-for-the-flat-paths/5139 "2024-04-26T06:47:52Z")

</div>

I’m implementing GitHub - better-care/fhir-connect-mapping-spec It uses simplified FLAT paths: openEHR: Custom path, derived by simplifying the FLAT format and using the common separator (\`.\`) \* Example: \`"$openEhrArc…

---

## [Calculated fields and dependent fields](https://discourse.openehr.org/t/calculated-fields-and-dependent-fields/4804)

<div class="topic-metadata">

**Author:** [@saeedsamie46](https://discourse.openehr.org/u/saeedsamie46)\
**Replies:** 3\
**Last updated:** [3 January 2024 17:43 UTC](https://discourse.openehr.org/t/calculated-fields-and-dependent-fields/4804 "2024-01-03T17:43:44Z")

</div>

I have found two situations in openEhr archetype model that I cannot find a defined specification for them; 1- When a defined data field constraint (for example a coded text options) is dependent to other data field act…

---

## [Default for EHR commit isQueryable and isModifiable](https://discourse.openehr.org/t/default-for-ehr-commit-isqueryable-and-ismodifiable/3865)

<div class="topic-metadata">

**Author:** [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Replies:** 12\
**Last updated:** [18 April 2023 20:27 UTC](https://discourse.openehr.org/t/default-for-ehr-commit-isqueryable-and-ismodifiable/3865 "2023-04-18T20:27:26Z")

</div>

We have found a discrepancy in the way that Better CDR and EhrBase handle EHR\_STATUS .isQueryable and .isModifiable when first created, if these are not explicitly derined in EHR\_STATUS. EhrBase defaults to false, where…

---

## [REST API for creating compositions with id](https://discourse.openehr.org/t/rest-api-for-creating-compositions-with-id/2113)

<div class="topic-metadata">

**Author:** [@Dileep\_V\_S](https://discourse.openehr.org/u/Dileep_V_S)\
**Replies:** 52\
**Last updated:** [24 March 2023 15:26 UTC](https://discourse.openehr.org/t/rest-api-for-creating-compositions-with-id/2113 "2023-03-24T15:26:21Z")

</div>

The current REST specifications does not seem to support creation of compositions by passing an id (similar to creating ehr with id). Is there any plans to support this feature? This will be useful in situations when m…

---

## [Storing a query with no version - correct behavior when the query already exists?](https://discourse.openehr.org/t/storing-a-query-with-no-version-correct-behavior-when-the-query-already-exists/3634)

<div class="topic-metadata">

**Author:** [@joseph.kane](https://discourse.openehr.org/u/joseph.kane)\
**Replies:** 1\
**Last updated:** [5 March 2023 19:55 UTC](https://discourse.openehr.org/t/storing-a-query-with-no-version-correct-behavior-when-the-query-already-exists/3634 "2023-03-05T19:55:14Z")

</div>

The API spec does not define a 409 response for this operation. If a query already exists with the specified name, what is the correct behavior of the endpoint? My guess is to increment the patch number in the semver, bu…

---

## [REST API unkown RM version for non-locatable objects like CONTRIBUTION](https://discourse.openehr.org/t/rest-api-unkown-rm-version-for-non-locatable-objects-like-contribution/3285)

<div class="topic-metadata">

**Author:** [@pablo](https://discourse.openehr.org/u/pablo)\
**Replies:** 10\
**Last updated:** [2 December 2022 15:28 UTC](https://discourse.openehr.org/t/rest-api-unkown-rm-version-for-non-locatable-objects-like-contribution/3285 "2022-12-02T15:28:02Z")

</div>

CONTRIBUTIONs are not LOCATABLEs so they don’t have a field to specify the rm\_version. When parsing CONTRIBUTION on POST /ehr/$id/contribution, the server doesn’t know which RM version was used to define such payload. C…

---

## [REST API Specifications in OpenAPI format](https://discourse.openehr.org/t/rest-api-specifications-in-openapi-format/2767)

<div class="topic-metadata">

**Author:** [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)\
**Replies:** 23\
**Last updated:** [29 November 2022 14:07 UTC](https://discourse.openehr.org/t/rest-api-specifications-in-openapi-format/2767 "2022-11-29T14:07:14Z")

</div>

I am investigating a rewrite of our current REST API Specification (now in Api-Blueprint format) as OpenAPI 3.1 or 3.0 format. Has anybody already done this and is willing to share it? then it will be helpful and highly …

---

## [React help needed](https://discourse.openehr.org/t/react-help-needed/2911)

<div class="topic-metadata">

**Author:** [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)\
**Replies:** 1\
**Last updated:** [14 August 2022 19:26 UTC](https://discourse.openehr.org/t/react-help-needed/2911 "2022-08-14T19:26:23Z")

</div>

Hi, In the SEC working group we are now exploring possibilities to render and publish our openEHR REST Specifications in openAPI format. (relates to REST API Specifications in OpenAPI format). We are looking mainly to S…

---

## [openEHR: revisión de terminología en español](https://discourse.openehr.org/t/openehr-revision-de-terminologia-en-espanol/2766)

<div class="topic-metadata">

**Author:** [@pablo](https://discourse.openehr.org/u/pablo)\
**Replies:** 10\
**Last updated:** [31 July 2022 05:03 UTC](https://discourse.openehr.org/t/openehr-revision-de-terminologia-en-espanol/2766 "2022-07-31T05:03:58Z")

</div>

Estimados, tenemos una traducción propuesta para la terminología de openEHR en español, obviamente sólo hispano-parlantes pueden revisar que esté bien. Les pido para quien tenga unos momentos de revisar el archivo de tra…

---

## [Is the version\_at\_time parameter value on the REST API valid when ste in the future?](https://discourse.openehr.org/t/is-the-version-at-time-parameter-value-on-the-rest-api-valid-when-ste-in-the-future/1993)

<div class="topic-metadata">

**Author:** [@pablo](https://discourse.openehr.org/u/pablo)\
**Replies:** 3\
**Last updated:** [17 February 2022 15:46 UTC](https://discourse.openehr.org/t/is-the-version-at-time-parameter-value-on-the-rest-api-valid-when-ste-in-the-future/1993 "2022-02-17T15:46:38Z")

</div>

There are a couple of endpoints that accept version\_at\_time, like: GET composition EHR API GET directory EHR API I’m executing some test cases for EHRBASE and it seems to work when sending a datetime in the future, …

[Next page](https://discourse.openehr.org/c/specifications/its/41.md?page=1)