openEHR REST API compressed formats in current CDRs

Implementation Platform
,
1

The openEHR REST APIS now allow sufficient header information to be passed to a compliant CDR to work with the FLAT and STRUCTURED json formats but it looks as if neither Ehrbase or Better CDR support these via the formal REST API.

e.g this call returns a format not supported error in both.

curl --location --request POST 'http://165.227.231.224:8080/ehrbase/rest/openehr/v1/ehr/700d884e-324a-4060-9783-28a805a65c5a/composition' \

--header 'Content-Type: application/openehr.wt.structured+json' \

--header 'openEHR-TEMPLATE_ID: MH-REACT - Therapeutic observations.v0' \

--header 'openEHR-AUDIT_DETAILS.committer: name="Dr Franke' \

Not the end of the world as it is easy enough to direct implementers to use the Ehrscape endpoints that Better and EhrBase support to handle these, but it does make training a lot easier if that switch does not need to be explained. It also raises some (unwarranted) anxiety that these are proprietary formats.

@birger.haarbrandt @matijap - do we know if this is on your roadmaps?

Are any other CDR providers planning to support these formats?

1 Like
2

I’m just guessing here, but it could be that they still implement the earlier (initial) release 1.0.0, where as these headers were perhaps added later to specs.

3

We are planning, actually testing, using compressed formats in atomik.app for the REST API but also for protobuf over gRPC, plain TCP or something like MLLP (HL7v2.x transport protocol). We are not only looking at reducing payload size but also to increase throughput, which is difficult via HTTP 1.1 (protobuf w/gRPC, WebSockets or even HTTP3 look promising on that area). The main idea is to provide real time, bidirectional communications of openEHR data and to support event-driven architectures.

We don’t use what you mention as FLAT or STRUCTURED, since those are not formal openEHR formats yet, I you know I don’t like the names in the paths :slight_smile:

Anyway, when this research is finished, I’ll share the findings and provide an implementation.

1 Like
4

Hi @ian.mcnicoll,

not formally on our roadmap, but might be relatively easy and quick to add (famous last words…). As we are moving to only support the official openEHR REST API (+Admin stuff), this would need to be done eventually.

I will check with the team.

5

That would be great . The Ehrscape end point support in Ehrbase works well but it is a bit confusing to explain to newbies why you need to switch there to make us of the compressed formats.

Not everyone is a fan, but we have had great success in their use with 3rd party dev teams.

1 Like
6

I really like the “new” formats and I agree that it will improve developer experience when these are becoming available through the official REST API. Again, as the services are already available, it should be rather trivial to add these to the endpoints.

2 Likes