Versions Compared

Old Version 28

changes.mady.by.user Former user

Saved on

compared with

New Version 29

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

MethodURLParametersDescriptionAPI levelNotes
POST

/compositions

/ehrs/{ehrId}/compositions

  • ehrId
  • committer
  • audit change type
  • version lifecycle state
  • commit audit description

Create a new composition

 

HF: If we use the second URL we don't need to specify ehrId as parameter

HF: should use the RM term of commit audit description rather than commit comment

HF: audit parameters should be group under commit audit parameter

HF: What is returned in the response?

BL: response is very simple:

Code Block
{
  "meta": {
    "href": "http://example.domain.com:8082/rest/v1/composition/bddcedc8-46cc-4df6-8b1a-b05534235f17::example.domain.com::1"
  },
  "action": "CREATE",
  "compositionUid": "bddcedc8-46cc-4df6-8b1a-b05534235f17::example.domain.com::1"
}
PUT/ehrs/{ehrId}/compositions/{objectId} Create a new composition with specified objectId HF: Useful when you want to control the object ID
GET

/compositions/{compositionId}
/ehrs/{ehrId}/compositions/{compositionId}

 Retrieve a compositionR1

Do we return a VERSION or a COMPOSITION here?

HF: I would prefer VERSION

BL: I would prefer a different resource returning versions

HF: is compositionId the version UID or object ID?

BL: we could have both - one returns exact version specified, the other latest one?

HF: Should be able to request version by uid, point in time or at specified contribution?

BL: Good idea - can you suggest parameters?

GET

/compositions/{compositionId}/version
/ehrs/{ehrId}/compositions/{compositionId}/version 

 

 Retrieve a VERSION 

BL

HF: I would prefer the reverse approach to align with RM
E.g. /compositions/{compositionId}/data

HF: is compositionId the version UID or object ID?

POST

/compositions/{compositionId}

/ehrehrs/{ehrId}/compositions/{compositionId}

  • committer
  • audit change type
  • version lifecycle state
  • commit comment
Update a composition 

HF: is compositionId the version UID or object ID? If version UID then it should be PUT. Having said that, FHIR uses PUT for update using an object ID.

BL: I think it should be version uid as it then also gives us optimistic locking

HF: We should provide precedingVersionUid or something to support optimistic locking, this could be done using the HTTP If-Match header

HF: What is returned in the response?

DELETE

/compositions/{compositionId}

/ehrehrs/{ehrId}/compositions/{compositionId}

  • committer
  • audit change type
  • commit comment
Delete a composition 

HF: is compositionId the version UID or object ID?

BL: I think it should be version uid as it then also gives us optimistic locking


HF: We should provide precedingVersionUid or something to support optimistic locking

...

MethodURLParametersDescriptionModelNotes
POST

/contributioncontributions

 Atomically commits a set of changes (composition creates, updates or deletes).
Code Block
languagejs
[
    {
        "action": "CREATE",
        "ehrId": "054ea32b-9ffa-4b00-ba58-a7e92be68087",
        "composition": {
			...
        }
    },
    {
        "action": "UPDATE",
        "compositionUid": "5ab5d99c-ee84-4571-9470-e5fb5002016b::default::1",
        "composition": {
			...
        }
    },
    {
        "action": "DELETE",
        "compositionUid": "1cb4e6bc-860e-4075-9fab-f3c9c113d30d::default::1"
    }
]

This call might also be under /composition resource.

HF: Although the RM doesn't explicitly state this, I think contributions should be related to an EHR. E.g. /ehr/{ehrId}/contributions

HF: Where multi-ehr contributions are required, we may consider a transaction mechansim

HF: The contribution resource should align more with the RM such as using a cut down representation of the ORIGINAL_VERSION including attributes such as lifecycle_state, preceding_version_id, change_type, data.

BL: Even in the current call - where multiple EHRs are concerned contributions should be created for each EHR separately - but the whole operation should still be transactional - so all or nothing. I do agree it would also be nice to have a call with /ehr/{ehrId}/ prefix. Perhaps the name contribution is not right although I hardly imagine somebody would want to POST contributions.

      

...