Admin delete composition

Implementation Platform
1

Hi,
I was trying to delete a composition in EHRBase in version 0.32.0. I received a 401 error with no explaining text.

The configuration I’m using allows me to successfully delete ehr and templates(both a specific one and all).

I followed the instructions in:
https://ehrbase.readthedocs.io/en/preview/03_development/07_admin/02_ehr_composition/index.html#delete-admin-ehr-id-composition-composition-id

example of a delete call:
http://localhost:8080/ehrbase/rest/admin/76a6e0ef-5c96-4516-a84f-0e47713cd49f/composition/65bd4228-4111-4be7-b0dd-271abe4cc8d5::local.ehrbase.org::1

with:
ehr_id=76a6e0ef-5c96-4516-a84f-0e47713cd49f
compositionversionuid=65bd4228-4111-4be7-b0dd-271abe4cc8d5::local.ehrbase.org::1

Is there any other configuration parameter to add? Any idea of what am I doing wrong?

2

Silly question … but are you using the admin User name and password? This is an Admin API ‘Hard delete’ call which needs admin level authorisation - might explain the 401?

2 Likes
3

@surfer also make sure the admin-api.enabled is set to ture. In newer versions, spring security returns 401 in case a secured path doesn’t exist, so that might be another reason why you get a 401.

2 Likes
4

@vidi42
I have these lines in my environment loaded into EHRBase:
ADMINAPI_ACTIVE=true
ADMIN_API_ACTIVE=true
ADMINAPI_ALLOWDELETEALL=true

The third one should be intended only for the deletion of all the templates. The other two should be for simple deletion.

@ian.mcnicoll
imho Nothing is so silly to be unlikely in human interaction with computers. That could have been it but it is not. I have checked and double checked before posting it. In fact with the same configuration I can delete single/multiple templates and single ehr.

Just for sake of example this is the call I’m doing in Python but recreated (and tested) with curl:
curl -o - -I -X DELETE http://localhost:8080/ehrbase/rest/admin/76a6e0ef-5c96-4516-a84f-0e47713cd49f/composition/807b4c69-4b16-4e02-a66d-dd6b73b8775d::local.ehrbase.org::1 -H ‘Authorization:Basic ZWhyYmFzZS1hZG1pbjpFdmVuTW9yZVNlY3JldFBhc3N3b3Jk’

the basic authorization is the base64 encoding of admin user and admin password. The result of this REST call:
HTTP/1.1 401
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
WWW-Authenticate: Basic realm=“Realm”
Content-Length: 0
Date: Mon, 19 Feb 2024 15:19:47 GMT

The final empty line is the response.

@birger.haarbrandt any thought on this?

5

@surfer can you try with this url

http://localhost:8080/ehrbase/rest/admin/ehr/76a6e0ef-5c96-4516-a84f-0e47713cd49f/composition/807b4c69-4b16-4e02-a66d-dd6b73b8775d

has the /ehr path after /admin and removes the system_id and version from the composition_id

6

It worked!!! thank you @vidi42
That means that probably you can’t specify which UID version of the composition you are deleting in EHRBase

7

With the admin api you can only delete the whole composition object, with all it’s history.
I belive you can use the openEHR Delete Composition endpoint to delete the latest version of a composition.

8

I checked the endpoint you cited. It seems to work. I’ll investigate it further

1 Like
9

Now I made some tests and share the results I obtained.

The “normal user” delete method behaves much like the admin one. I mean that though in the REST call I have specified the version (not possible in admin) the final result is the same. All the versions of that compositions are deleted. I cannot access any version of that composition neither with the simple composition id (i.e.,without version) nor with a specific composition version id. If I do a query looking for all the compositions with the EHRid , that I assigned the compositions to, the composition deleted through the “normal user” delete method do not appear in the results list.

10

It might appear the same but it should be different.

The normal delete is just a logical delete - it creates a new revision of the composition with it’s lifecycle set to 523 deleted.

All of the original versions should still be there but normal querying will not find them.

If you run the Get Versioned History API call, you should be able to see them
(Better and , I think Ocean) support a CONTAINS VERSION v[all_versions] in AQL that also helps

openEHR REST API Get Versioned History

https://{baseUrl}/v1/ehr/{ehr_id}/versioned_composition/{versioned_object_uid}/version

{
    "_type": "ORIGINAL_VERSION",
    "contribution": {
        "_type": "OBJECT_REF",
        "id": {
            "_type": "OBJECT_VERSION_ID",
            "value": "6dad76a4-bd4c-4669-b5d1-ae609a91c3cc"
        },
        "namespace": "11ed4f4e-6a7f-4849-a03c-2c41333a15ec",
        "type": "CONTRIBUTION"
    },
    "commit_audit": {
        "_type": "AUDIT_DETAILS",
        "system_id": "11ed4f4e-6a7f-4849-a03c-2c41333a15ec",
        "committer": {
            "_type": "PARTY_IDENTIFIED",
            "name": "11ed4f4e-6a7f-4849-a03c-2c41333a15ec"
        },
        "time_committed": {
            "_type": "DV_DATE_TIME",
            "value": "2024-02-20T00:37:11.592Z"
        },
        "change_type": {
            "_type": "DV_CODED_TEXT",
            "value": "deleted",
            "defining_code": {
                "_type": "CODE_PHRASE",
                "terminology_id": {
                    "_type": "TERMINOLOGY_ID",
                    "value": "openehr"
                },
                "code_string": "523"
            }
        }
    },
    "uid": {
        "_type": "OBJECT_VERSION_ID",
        "value": "18c0556a-7902-4206-b1d2-024d83700b5c::11ed4f4e-6a7f-4849-a03c-2c41333a15ec::2"
    },
    "preceding_version_uid": {
        "_type": "OBJECT_VERSION_ID",
        "value": "18c0556a-7902-4206-b1d2-024d83700b5c::11ed4f4e-6a7f-4849-a03c-2c41333a15ec::1"
    },
    "lifecycle_state": {
        "_type": "DV_CODED_TEXT",
        "value": "deleted",
        "defining_code": {
            "_type": "CODE_PHRASE",
            "terminology_id": {
                "_type": "TERMINOLOGY_ID",
                "value": "openehr"
            },
            "code_string": "523"
        }
    }
}

OTOH if you have used the Admin DELETE, the entire version history should have been deleted, and you will get nothing back.

1 Like
11

Yes .

After I ran an Admin delete on the example above and tried the REST API Get Versions call , I get

404 and {
“message”: “The required composition does not exist and has never existed. Check your domain and version.”
}

12

thanks @ian.mcnicoll
I tried to replicate your steps with EHRBase.

“soft” (user) composition delete

  • get composition responds with code 404.
  • get versioned composition at time does not work with any time
    400 for latest (no time) 500 for any other time
  • get versioned composition works
  • get versioned composition revision history works
  • get versioned composition by version works
    the last three works as if there was no delete. I can retrieve also the composition whose version I deleted.
    I have no lifecycle info

“hard” (admin) composition delete

  • get composition respond with code 404
  • get versioned composition at time 404
  • get versioned composition 404
  • get versioned composition revision history 404
  • get versioned composition by version 404
    so it is like the composition never existed

In summary, If I haven’t made any mistakes, the hard delete removes any trace of the compositions whereas the soft delete just causes the get composition method to fail.
I would have expected something like Ian pointed out, that is a logical delete that leaves trace in the revision history or in the info from get versioned composition. Possibly EHRBase does it this way but, not being shown the lifecycle state. I can’t tell.

1 Like