Create native JSON composition format from OPT

Implementation Platform
41

Hello @birger.haarbrandt . Did you have any success in cleaning and submitting the composition I had problem with?
Does anybody have a working pair template-composition from which I can start understanding what was wrong with my tests?

42

You might want to keep[an eye here as we will be working between Ehrscape and ehrBase when building sample compositions. Sorry -a but busy with this to answer directly but some of the test material might help

43

Hi @surfer,

please the followin PR containing the analysis: https://github.com/ehrbase/ehrbase/pull/186

We had some issues regarding null flavours. This should also help you regarding the other aspects of the composition.

44

thank you. Iā€™m definitely gonna take a look at it as soon as my internet connection resurrects

45

Hi again,
Your link @birger.haarbrandt was precious to understand the errors in my xml composition. Now Iā€™d like to be able to submit a json composition which, if I understood well, is the only one that allows to make AQL queries.
Does somebody have a couple template/json composition even very simple that is accepted by Ehrbase?
@ian.mcnicoll I looked at the files you linked (and not). I can see templates but no composition. I grabbed the NES-ACP_COVID.v0.0.opt and the openEHR-Suspected Covid-19 assessment.v0.opt I then got the json structured composition examples for those templates from Better API ( GET /template/{templateId}/example ) but they havenā€™t been accepted in Ehrbase.

46

Here the trick!!

Use the Better Ehrscape API to create FLAT examples and then submit them to EBetter CDR via ehrscape /composition /POST - note the composiitonID

THen ā€¦ us the Better openEHR API to retrive the composition via the compositonID as RAW JSON. Bingo you have an example RAW JSON which will commit to EhrBase.

Have a look in the GH repo above for Postman examples and in the dev branch openEHR folder some examples.

49

@ian.mcnicoll I just followed your instructions. It lead me to the same result that is :
400
{ā€œerrorā€:ā€œjava.lang.IllegalArgumentException: Composition missing mandatory attribute: nameā€,ā€œstatusā€:ā€œBad Requestā€}

to summarize the steps I took:
-I created a FLAT JSON composition from template example REST call in BETTER
-I submitted to BETTER the same composition as FLAT JSON
-I retrieved the composition from BETTER as RAW JSON
-i tried to insert it in Ehrbase as RAW JSON

50

Sorry too busy to try to replicate.

-I retrieved the composition from BETTER as RAW JSON

The critical step here is that you retreive the RAW JSON via the Better openEHR API not via Ehrscape.

Ehrscape generates ā€˜BETTER RAWā€™

openEHR API generates 'OPENEHR Canonical/RAW)

They are actually very close.

51

You might also try to recommit the CANONICAL RAW back to Better via the openEHR API - it sould work, then try it against EhrBase.

52

I know @ian.mcnicoll Iā€™m bothering you a lot but I canā€™t make it work :frowning:
Which is which when you talk about EHRscape API and BETTER API ?
Better has two API. One is called OpenEhr REST API whereas the latter , much larger , for the part we are referring to is called Electronic Health Record API.
The first time you suggest me your trick I used only the second one. So i retrieved with API GET /composition/{uid}
Last time I retrieved the composition with the first one (API GET /rest/openehr/v1/ehr/{ehr_id}/composition/{versioned_object_uid} )
The error with the second approach when posting the retrieved composition to Ehrbase is:
400
{ā€œerrorā€:ā€œjava.lang.IllegalArgumentException: Composition missing mandatory attribute: archetype_node_idā€,ā€œstatusā€:ā€œBad Requestā€}

53

Are you still using the same samples from the Gist you posted?

54

I retrieved the composition from BETTER as RAW JSON

Yes but this has to be via the Better openEHR API not the Better Ehrscape API (Electronic Health Record API)

curl --location --request GET ā€˜https://cdr.code4health.org/rest/openehr/v1/ehr/3e674739-950c-4b8a-976b-5aef21c618c5/composition/89631516-6359-4b08-9500-b0a32b1e5d4f::a81f47c6-a757-4e34-b644-3ccc62b4a01c::1ā€™
ā€“header ā€˜Accept: application/jsonā€™
ā€“header ā€˜Content-Type: application/jsonā€™
ā€“header ā€˜Authorization: Basic YTgxZjQ3YzYtYTc1Ny00ZTM0LWI2NDQtM2NjYzYyYjRhMDFjOiQyYSQxMCQ2MTlraQ==ā€™

I will send over a postman collection that shows this working

55

Thatā€™s exactly what I did last time. Same parameters.
looking forward to see your postman commands to see where I went wrong

1 Like
56

So I can make this work here

  1. Uploaded the template .opt to Better Ehrscape and EhrBase openEHR

  2. Committed the XML composition via Better Ehrscape API

curl --location --request POST 'https://cdr.code4health.org/rest/v1/composition?templateId=hospitalization_ocean&ehrId=3e674739-950c-4b8a-976b-5aef21c618c5&format=RAW' \
--header 'Content-Type: application/xml' \
--header 'Ehr-Session-disabled: {{Ehr-Session}}' \
--data-raw '<?xml version="1.0" encoding="US-ASCII"?>
<v1:composition xmlns:v1="http://schemas.openehr.org/v1" xmln ...
  1. Read it back as Canonical JSON via the Better openEHR API /rest/openehr/v1 
curl --location --request GET 'https://cdr.code4health.org/rest/openehr/v1/ehr/3e674739-950c-4b8a-976b-5aef21c618c5/composition/89631516-6359-4b08-9500-b0a32b1e5d4f::a81f47c6-a757-4e34-b644-3ccc62b4a01c::1' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic ....
  1. POST /composition to EhrBase via openEHR API
curl --location --request POST 'http://localhost:8080/ehrbase/rest/openehr/v1/ehr/e86234ed-d4a4-4f14-9c23-c2a913a48789/composition' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'PREFER: representation=minimal' \
--header 'Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=' \
--header 'Content-Type: text/plain' \
--data-raw '{
    "_type": "COMPOSITION",
    "name": {
        "_type": "DV_TEXT",
        "value": "Hospitalisation" ...

I canā€™t commit to Ehrbase because of 4 issues which have been already noted.

  1. ā€˜Eletivaā€™ in Patoient_admission needs to be ā€˜Electiveā€™ - this is correct because the language on the parent ADMIN_ENTRY is set to ā€˜enā€™ and it was validating against the local code rubric - Better do not validate the values only the code_string.

2 x2 The Docker version of EhrBase that I have cannot handle null_flavours but I think this is fixed https://github.com/ehrbase/ehrbase/pull/132 @birger.haarbrandt ?

  1. Some issues with DATE_TIME formatting that I have not figured out yet.

  2. Tee text for context/setting was wrong - should be ā€˜secondary medical careā€™

A working version of the Raw openEHR JSON is at the end of this Gist

57

The DATE_TIME issue is that EhrBase expects a Timezone suffix on COMPOSITION/context/start_time/value - weirdly it does not care otherwise!

 "start_time": {
            "_type": "DV_DATE_TIME",
            "value": "2018-12-11T11:20:07,227"
        },

{
    "error": "Internal Server Error: java.time.temporal.UnsupportedTemporalTypeException: Unsupported field: InstantSeconds",
    "status": "Internal Server Error"
}
58

thank you very much Ian!

59

@birger.haarbrandt In Ehrbase when I do a REST GET of a composition (posted succesfully in json or xml) I obtain always an XML in spite of Content-Type set in headers
Am I doing something wrong?
From https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#composition-composition-get you have to set only the content type (Content-Type : application/json) and complete the url with the right ehrId and compositionId

60

You need ro set the Accept Header

curl --location --request GET 'https://cdr.code4health.org/rest/openehr/v1/ehr/3e674739-950c-4b8a-976b-5aef21c618c5/composition/89631516-6359-4b08-9500-b0a32b1e5d4f::a81f47c6-a757-4e34-b644-3ccc62b4a01c::1' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
1 Like
61

Looks like the spec needs adjusted to add Accept

62

just tested, works all for me

accept: application/json

Edit: ah, now I see. Iā€™m not an expert on this HTTP headers but I guess @ian.mcnicoll is right that this should be accept instead of content-type in the spec. Maybe @sebastian.iancu or @erik.sundvall can comment :slight_smile: