201709 PATCH Connectathon Track Proposal

Return to September 2017 Proposals

NOTE: AS of right now, PATCH will NOT be part of the September Connectathon. There are not enough participants. If you plan to participate, please comment here: https://chat.fhir.org/#narrow/stream/implementers/subject/Interest.20in.20Patch.20Connectathon.20Track

PATCH Connectathon

Zulip: https://chat.fhir.org (implementer > Patch): https://chat.fhir.org/#narrow/stream/implementers/topic/Patch

Connectathon Tracking spreadsheet: TBD

Submitting WG/Project/Implementer Group

Cerner - Jenni Syed

FHIR Core - Grahame Grieve

Justification

There are real world use cases for some form of PATCH, for example, to update only the status of a specific resource, to update or add a comment, and many other single or limited field updates. If a traditional FHIR update is used, the client should send in the full resource exactly as received, with the single field changed. This is sometimes challenging, both for the FHIR server and the Client. For example, if a client application does not support storing a specific field the server exposes, how will it send it back? If the FHIR server receives an update request where a field is missing, how does it know the intention was to blank/null that field out? More Specifically:

• Sensitive Elements - a client may not have available to them all elements of a resource, or the some elements may be redacted or de-identified in some way. PATCH would allow the client to send updates to authorized elements without sending the unauthorized or de-identified.

• Targeted updates - explicit delineation of which elements a client is updating. In systems with complex dependency management (element A is dependent on elements B and C), this simplifies the triggering of dependency checks (prevents change detection on fields not patched). Also applies for security (don't have to authorize field updates that aren't patched).

• Bandwidth Constrained - a mobile or other bandwidth constrained client that creates many small updates in real time to a resource. For instance, a UI for updating (sharing) a care plan in real time.

Because of this, Patch was added to STU3. We would like to continue trialling the specification as defined.

http://hl7.org/fhir/stu3/http.html#patch

Proposed Track Lead

Jenni Syed

  Email: jenni dot syed at cerner dot com
  Skype: jenni.syed
  Zulip: Jenni Syed

See Connectathon_Track_Lead_Responsibilities

Expected participants

Please sign up on our tracking spreadsheet]

• Cerner (Jenni Syed)

Summary

Summary slides here: TODO

Roles

FHIR Server

Exposes the FHIR Patient resource with GET (search) and PATCH methods available.

FHIR Client

Has the ability to GET and PATCH Patient

Required Scenarios

1 Search Patient (JSON)

Action: FHIR Client sends GET to FHIR Server /Patient resource with name (or other) parameter

Precondition: FHIR Server should expose GET resource with the JSON format

Success Criteria: Response from server includes a bundle of Patient resources (with at least 1 resource populated)

2 Patch Patient (JSON)

Action: FHIR Client sends PATCH to FHIR Server /Patient resource using JSON Patch format to update any field on Patient.

Precondition: FHIR Server should expose PATCH resource honoring the JSON Patch format.

Success Criteria: Response from server either shows full Patient resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.

3 Search Patient (XML)

Action: FHIR Client sends GET to FHIR Server /Patient resource with name parameter

Precondition: FHIR Server should expose GET resource with the XML format

Success Criteria: Response from server includes a bundle of Patient resources (with at least 1 resource populated)

4 Patch Patient (XML)

Action: FHIR Client sends PATCH to FHIR Server /Patient resource using XML Patch format to update any field on Patient.

Precondition: FHIR Server should expose PATCH resource honoring the XML Patch format.

Success Criteria: Response from server either shows full Patient resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.

Optional Scenarios

5 Patch Patient (FHIRPath)

Action: FHIR Client sends PATCH to FHIR Server /Patient resource using the FHIRPath format to update any field on Patient.

Success Criteria: Response from server either shows full Patient resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.

6 Conditional Patch

Action: FHIR Client sends PATCH to FHIR Server using a format the server and client supports, including an If-Match header as described http://hl7.org/fhir/stu3/http.html#versionaware

Precondition: FHIR Server must expose ETag and meta.versionId fields

Success Criteria: Response from the server shows a 409 Conflict response when version mismatch occurs, otherwise returns the resource with the modified applied, OR the read of the updated resource by id includes the modifications requested.

5 Batch Patch (FHIRPath)

Action: FHIR Client sends a batch operation to FHIR Server (at least multiple patient resources) using the FHIRPath format to update any field on Patient.

Success Criteria: Response from server either shows full Patient resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.

5 Transaction Patient (FHIRPath)

Action: FHIR Client sends transaction operation to FHIR Server (at least multiple patient resources) using the FHIRPath format to update any field on Patient.

Success Criteria: Response from server either shows full Patient resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.

TestScript(s)

TODO (Test scripts below are from previous tracks)

TestScripts and corresponding fixtures have been committed to the FHIR SVN repository at: http://gforge.hl7.org/svn/fhir/trunk/connectathons/BaltimoreSep2016/Connectathon13/PATCH