openEHR REST APIs Release 1.1.0 published

openEHR news Releases
, ,
1

The openEHR Specifications Editorial Committee (SEC) has published ITS-REST Release
1.1.0.

This is the first minor release since 1.0.3 (2022) and a substantial one. It introduces several new APIs, a major overhaul of the Simplified Formats specification, improved REST/HTTP conformance, and
a broad alignment of the OpenAPI schemas with the openEHR Reference Model.

New APIs and resources

  • SPECITS-69: “SMART on openEHR” — App Launch & Service Discovery framework (new specification)
  • SPECITS-70: new Demographic REST API
  • SPECITS-80: new Admin API, including support to delete an EHR
  • SPECITS-77: support for ITEM_TAGs
  • SPECITS-58: /example sub-resource under the template-definition endpoint
  • SPECITS-84: FLAT/SDT support on CONTRIBUTION calls — the format applies to versions[].data; the CONTRIBUTION envelope stays canonical JSON

Simplified Formats

  • SPECITS-61: cleanup and consolidation of the Simplified Formats spec (and deprecation of the separate Simplified Data Template document); Accept /
    Content-Type headers wired into the relevant endpoints
  • SPECITS-94: review feedback — new |other and |preferred_term suffixes on DV_CODED_TEXT, corrected EVENT_CONTEXT / PARTICIPATION / DV_*
    mappings, and many table fixes

REST / HTTP conformance

  • SPECITS-50: return minimal responses to avoid 204 No Content codes
  • SPECITS-60: consistent status codes when creating resources
  • SPECITS-74: deprecate some uses of the Location response header
  • SPECITS-75: fix inconsistent and invalid header names
  • SPECITS-82: add the weak-ETag W/ indicator

Templates & ADL

  • SPECITS-86: treat template_id as a reference; add template_id / version filters to listTemplates
  • SPECITS-87: deprecate ADL2 “Get template at version” and the version query parameter on template upload

Query

  • SPECITS-46: fix endpoint resolution when a stored query is named aql

Reference Model alignment & tooling

  • SPECITS-92: sync the OpenAPI resource/type schemas with the RM type specifications (mostly RM 1.1.0 related)
  • SPECITS-95: type UPDATE_AUDIT.change_type as DV_CODED_TEXT (and UPDATE_VERSION.lifecycle_state likewise); add optional system_id
  • SPECPR-472: document the openEHR-AUDIT_DETAILS.system_id request header
  • SPECITS-73: restructured and improved the YAML sources

The new Demographic, Admin and SMART on openEHR specifications are published at DEVELOPMENT maturity — we especially welcome implementer feedback on those. The OpenAPI 3.0 source files
remain available under computable/OAS.

We hope this proves useful for the community, and would like to thank all the implementers for the feedback that led to this release, as well as the SEC members and others who helped create it.

Discussions and feedback may be provided on the Implementation Technology Specifications forum. Issues may be raised on the specifications
Problem Report tracker.

2

Thanks Sebastianfir all your work.

Which vendors support this release allready?

Igor

3

@IgorSchoonbrood I use v1.1.0 for my CDR project. I added the REST API last week, so I used the latest version. Good timing for me :blush:

4

Hi Igor,

As most of specifications are based on industry practice and functionality already existing, these specifications are in big lines already implemented by CDR vendors. There might slight deviations, or perhaps partial implementation, as they might not caught up yet in development with all agreed specifications, but I think soon it will be compatible. There are also a few new specifications and feature marked as “development” inside the Release-1.1.0 which implies vendors working on implementing and experimenting with them, until the specification becomes “stable”.

As for Cadasto CDR, we implemented most of the changes and plan to achieve 100% in upcoming period.

5

Hi Igor,

Better will fully support this version in the next major release planned for September.

6

Thanks to everyone involved in this release!

I have a question regarding EHRbase.

What is the current status of ITS-REST 1.1.0 support in EHRbase (https://www.ehrbase.org)?

7

I have the same question regarding HIP-CDR (the commercial version of EHRbase).

But before we start asking about each piece of software individually, I think it would be great if the developers would take the initiative to publish their roadmap here.

8

Dear all,

EHRbase and HIP will also implement version 1.1.0 this year, already providing REST APIs and underlying services for Tagging, Examples and the Admin REST APIs today. Please note that demographics is out of scope for us (as we rely on FHIR for demographics) and SMART on openEHR will be HIP only.