Add demographic component to the REST API spec
Description
PR is addressed in
Activity
Pablo Pazos April 20, 2023 at 2:49 PM
I have proposed an initial demographic API here
The DELETE is not there but would be like a PUT without providing the payload.
POST /demographic/actor
Creates any type of ACTOR (PERSON, ORGANISATION, GROUP, AGENT) from a non empty payload.
Design note: I have considered ROLE as a weak entity and should always be inside an ACTOR when you need to create an instance. So this endpoint also creates the ROLEs if any is provided. I also consider CONTACT and PARTY_IDENTITY to be weak entities, so they will always be created when the container ACTOR is created.
PUT /demographic/actor/$versioned_uid
Modifies an existing ACTOR. Needs an If-Match header with the version.uid of the current last version of the versioned object, which UID comes in the URL as $versioned_uid.
GET /demographic/actor/version_uid
Retrieves an ACTOR by version UID.
POST /demographic/relationship
Creates a PARTY_RELATIONSHIP between two existing ACTORs. The server should check both source and target references exist.
PUT /demographic/relationship/$versioned_uid
Modifies an existing PARTY_RELATIONSHIP. Needs an If-Match header with the version.uid of the current last version of the versioned object, which UID comes in the URL as $versioned_uid.
GET /demographic/relationship/version_uid
Retrieves the PARTY_RELATIONSHIP by version UID.
I didn’t implement the get xxx at time, but follows the same logical design.
Design note: you can see both ACTOR and PARTY_RELATIONSHIP are strong entities (top-level versionable), the rest just depend on ACTOR.
Pablo Pazos December 11, 2022 at 7:21 PM
For archetypes and templates the emptiness should be the same as the current ones, they don’t have any constraints in terms of the class being constrained and I think would be bad design to separate archetype/template endpoints by constrained class.
This issue is neither about the formats, that should be in a different issue. The point is to have endpoints to manage demographic resources.
AQL is also a different topic, not related to the rest API component. That should be discussed separately IMO.
Sidharth Ramesh December 11, 2022 at 3:12 PM
Will this be something where we are able to also post instances of demographic archetypes (Patient / Person) with for example name, age and gender?
If so, will this also be supporting multiple formats like normal openEHR compositions? FLAT, STRUCTURES, and CANONICAL?
There will also need to be additional modification to the AQL spec to accommodate this right?
Add demographic support with examples to create/modify/delete resources for all concrete PARTY classes and associations between them (PARTY_RELATIONSHIP). Operations will be like other create/edit/delete operations over LOCATABLE types like COMPOSITION, EHR_STATUS and FOLDER. 1. We need a formal API for demographics 2. The API is needed to test conformance I'm working on a test implementation of this, I might be able to show something working soon.