Add Composition Version ID to the debug log

[SevKohler]

Background

We need this version id for the mapping, currently we have to pour it out of the ehr (which could have several compositions), which is super inconvienient and takes way too much time. See the old fhir-bridge there the version id of the composition is returned. Im currently wasting a lot of time doing that and so will others. I tried to add a VersionId to the Composition before its pushed, but didnt work. Tried to retrieve it after submission to ehrBase and got a null pointer.

[SevKohler]

@subigre @ppazos this is very important for testing and fixing wrong mappings, because i cant distinct my submitted compositions and need restart the database or i end up losing the track.

[subigre]

@SevKohler 👍👍👍

I fully agree that the Composition Version ID should be return back to the client and I have the issue #79 in my todo list.

Regarding the implementation, I have two proposals to based on the current solution:

• Either we implement all the methods T fromComposition(C composition) and we returned this result instead of the one persisted in the database. => This solution was my idea since the beginning and explains why the AqlComponent and CompositionConverter are implemented like that.

• Either we update the AqlComponent and the CompositionConverter to convert only from FHIR to EHR and return back the submitted FHIR resource + the Composition Version ID.

There is even a last one (but sounds like a workarround of the second proposal)... we return a FHIR resource from the CompositionConverter that contains only an identifier with the Composition Version ID as value and then, we merge the submitted resource with this almost empty resource before returning the response.

[SevKohler]

I dont think we need to see the resource again, we already have it in the body. There is not value in doing so. I prefer the first solution, of returning the mapped composition.

[ppazos]

@SevKohler from the openEHR perspective, the version ID on the composition.uid should be assigned by the server, because it's used for internal version management. It can't be assigned by a client, like FHIR bridge is for ehrbase. The only way is retrieving the composition as the result of the create operation, and grabing the compo.uid as I was doing in the old repo.

I didn't check how this work in the new implementation, we can review it together if you want.

[SevKohler]

Yeah i know, but isnt that what @subigre suggests with the first solution ? If not thats what we need.

[ppazos]

@SevKohler I'm not sure if we are talking about the same thing because I don't know what T fromComposition(C composition) is.

The point of my message is clarifying the way openEHR and the API works, not about a specific solution implementation. To return the composition created from the POST to the openEHR API, it just needs the header Prefer: return=representation

[subigre]

@ppazos , @SevKohler I think that this issue might be close now that the versionUid is returned in the FHIR Bridge response.

{
    "resourceType": "Condition",
    "id": "1",
    "meta": {
        "versionId": "1",
        "lastUpdated": "2021-02-04T08:24:16.179+01:00"
    },
    "identifier": [
        {
            "system": "local.ehrbase.org",
            "value": "06eae9dd-90c1-4d6b-bd16-0a3dcbf8af5f"
        }
    ],
    ...
}

[SevKohler]

can we close this then ?

[subigre]

I would say yes if the current solution is fine for you