Page Comparison

• subjectId (optional): id of the subject in the external system
• subjectNamespace (optional): namespace of the subject id in the external system
• committer
• audit change type
• commit audit description
  
  

HF: How do subjectId and subjectNamespace manifest themselves in the EHR model/resource?

HF: We should allow EHR_STATUS and EHR_ACCESS objects so it is not necessary to make additional requests resulting in multiple contributions

BL: Good idea.

HF: We need audit details for the contribution

HF: What is returned in the response?

BL: I suggest we

: At the moment only:

{
  "meta": {
    "href": "http://localhost:8082/rest/v1/ehr/f77f9b4a-cfda-414d-aa6c-4f78bcac7601"
  },
  "action": "CREATE",
  "ehrId": "f77f9b4a-cfda-414d-aa6c-4f78bcac7601"
}

TB: this isn't possible (well not by an external REST access - it would be an internal admin operation); all you can do is mark an EHR as inactive, which would be a POST (I think) to /ehr/{ehr_id}/ehr_status/other_details/is_active or similar. But even this operation, if it succeeds, is serious - it makes it look like an EHR is deleted, so it's probably not appropriate via any externally visible REST interface.

SI: In some countries the patient/client is owner of the data and it has the right (by the law) to ask for a complete (total) removal of all his data, which is more than just an inactive flag.

TB: that's true, but doing the delete would require some documentation and/or special permission. I still doubt very much that this could ever be done through a visible REST interface, unless all the proof parameters were provided, and I think these would be too variable to standardise.

DB: I agree with SI, this can be a requirement. The authentication/permission is a completely different issue. You could argue that the same kind documentation or special permission would be needed for creating a new composition.

BL: I would leave this out of the REST API for the moment. If this is a requirement somewhere it can be performed by other means (special admin interface to the system or similar).

DB: I won't leave this out, delete has a clear use case (i.e. opt-out from clinical research)

ES: Seems like delete EHR is needed in some cases, so it should be system configurable, we just need to agree on what HTTP status codes/messages to return for different cases.

• committer
• audit change type
• commit audit description

HF: Can we create using this also?HF

BL: We need Do we need to - would it not be better to create a default status and access when creating EHR (or use the provided ones in the EHR create call body).

HF: We need audit details for the contribution

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

BL: Added versionUid.

HF: What is returned in the response?

BL: What would you have in response?

TB

HF: Do we really want to provide this level of updates, it may result in many contributions when multiple attributes need to be updated

• committer
• audit change type
• commit audit description

HF: Can we create using this also?

HF: We need audit details for the contribution

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

HF: What is returned in the response?

TB

HF: Do we really want to provide this level of updates, it may result in many contributions when multiple attributes need to be updated

HF: We need audit details for contribution

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

HF: What is returned in the response?

SI

/compositions

/ehrehrs/{ehrId}/compositions

• ehrId
• committer
• audit change type
• version lifecycle state
• commit commentaudit 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?

HF: audit parameters should be group under commit audit parameter

HF: What is returned in the response?

BL: response is very simple:

{
  "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"
}

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

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 IDcompositionId 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?

/compositions/{compositionId}/version
/ehrehrs/{ehrId}/compositions/{compositionId}/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?

/compositions/{compositionId}

/ehr/{ehrId}/compositions/{compositionId}

• committer
• audit change type
• version lifecycle state
• commit comment

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?

/compositions/{compositionId}

/ehr/{ehrId}/compositions/{compositionId}

• committer
• audit change type
• commit comment

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