...
| Method | URL | Parameters | Description | Notes | ||
|---|---|---|---|---|---|---|
| POST | /ehrs |
| Create a new EHR | 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: At the moment only:
HF: What is the purpose of meta and action? Shouldn't we use HTTP headers for these? HF: Why have we change the URL to /ehrs? The resource is an EHR. BL: Plurals are favoured in REST. To be consistent with /compositions, etc, | ||
| PUT | /ehrs/{ehrId} | As above | Create a new EHR with specified ehr_id | HF: Required when creating an EHR with same ehr_id as in another system | ||
| GET | /ehrs/{ehrId} | Get EHR | HF: Useful to get profile of an EHR. E.g. time created, how many compositions, is there a directory, what was the last contribution etc. | |||
| DELETE | /ehrs/{ehrId} | Delete an EHR | 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. | |||
| GET | /ehrs/{ehrId}/ehr_status | Retrieve EHR_STATUS | ||||
| POST | /ehrs/{ehrId}/ehr_status/{versionUid} |
| Update EHR_STATUS | HF: Can we create using this also? BL: 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: If that is our suggested approach then fine, but this needs to be specified. HF: We need audit details for the contribution HF: We should provide precedingVersionUid or something to support optimistic locking BL: Added versionUid. HF: Is version uid the new version UID or preceding version uid? The proposed URL would suggest we are posting to this version, not replacing it. HF: I think preceding version uid should be represented as a HTTP If-Match header rather than in the URL. This keeps urls simple and clean. HF: What is returned in the response? BL: What would you have in response? HF: I would suggest we just need HTTP status and headers Content-Location (version specific URL, although we don't have one) and ETag (new version uid) HF: FHIR uses the HTTP Prefer header to allow the client to specify return minimal or representation. The latter would return the new version of the resource. The server can decide how it responds if it is not specified. | ||
| PUT | /ehrs/{ehrId}/ehr_status/... | Update an attribute in ehr_status | 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 | |||
| GET | /ehrs/{ehrId}/ehr_access | Retrieve EHR_ACCESS | ||||
| POST | /ehrs/{ehrId}/ehr_access/{versionUid} |
| Update EHR_ACCESS | 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? | ||
| PUT | /ehrs/{ehrId}/ehr_acess/... | Update an attribute in ehr_access | 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 |
...