View source for 201705 PATCH Connectathon Track Proposal

[http://wiki.hl7.org/index.php?title=Category:201705_FHIR_Connectathon_Track_Proposals Return to September 2017 Proposals]
[[Category:201705_FHIR_Connectathon_Track_Proposals|March 2017 Proposals]]

[http://wiki.hl7.org/index.php?title=Category:201705_FHIR_Connectathon_Track_Proposals Return to May 2017 Proposals]
[[Category:201609_FHIR_Connectathon_Track_Proposals|September 2016 Proposals]]
__NOTOC__
=PATCH Connectathon=
Zulip: https://chat.fhir.org (implementer > Patch): https://chat.fhir.org/#narrow/stream/implementers/topic/Patch

Connectathon Tracking spreadsheet: https://docs.google.com/spreadsheets/d/1rrz8yqkG5gHhSEzUvZxP-6_CCFr_6F0FUElFRGmObyw/edit#gid=0

==Submitting WG/Project/Implementer Group==
Cerner - Jenni Syed

Also some documentation from FHIR core and Grahame: http://hl7.org/fhir/2016Sep/http.html#update 

http://www.healthintersections.com.au/?p=2441

==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. With the way FHIR currently defines an update, 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.


==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: https://speakerdeck.com/daliboz/sep-2016-hl7-connectathon-patch-track

==Roles==
===EHR===
Exposes the FHIR MedicationStatement resource with GET (search) and PATCH methods available.
Exposes the FHIR Patient resource with GET (search) and PATCH methods available.

===FHIR Client===
Has the ability to GET and PATCH MedicationStatement.
Has the ability to GET and PATCH Patient

==Scenarios==
We will focus on getting more participation/feedback on [http://jsonpatch.com/  JSON Patch] and add [http://tools.ietf.org/html/rfc5261 XML Patch] for XML formatted resources.
TODO: Consider using fluenthpath?


===1 Search MedicationStatement (JSON) ===
:Action: FHIR Client sends GET to EHR /MedicationStatement resource with patient parameter
:Precondition: EHR should expose GET resource with the JSON format
:Success Criteria: Response from server includes a bundle of MedicationStatement resources (with at least 1 resource populated)
:Bonus point: MedicationStatement must expose the meta.versionId and meta.lastUpdated fields and support search by patient.

===2 Patch MedicationStatement (JSON) ===
:Action: FHIR Client sends PATCH to EHR /MedicationStatement resource using [http://jsonpatch.com/ JSON Patch] format to update any fields in MedicationStatement.
:Precondition: EHR should expose PATCH resource honoring the [http://jsonpatch.com/ JSON Patch] format.
:Success Criteria: Response from server either shows full MedicationStatement resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.
:Bonus point: Rejecting the update if there is a [http://hl7.org/fhir/2016Jan/http.html#concurrency version conflict]. 

===3 Search MedicationStatement (XML) ===
:Action: FHIR Client sends GET to EHR /MedicationStatement resource with patient parameter
:Precondition: EHR should expose GET resource with the XML format
:Success Criteria: Response from server includes a bundle of MedicationStatement resources (with at least 1 resource populated)
:Bonus point: MedicationStatement must expose the meta.versionId and meta.lastUpdated fields and support search by patient.

===4 Patch MedicationStatement (XML) ===
:Action: FHIR Client sends PATCH to EHR /MedicationStatement resource using [http://tools.ietf.org/html/rfc5261 XML Patch] format to update any field on MedicationStatement.
:Precondition: EHR should expose PATCH resource honoring the [http://tools.ietf.org/html/rfc5261 XML Patch] format.
:Success Criteria: Response from server either shows full MedicationStatement resource with the requested modifies applied, OR the read of the updated resource by id includes the modifications requested.
:Bonus point: Rejecting the update if there is a [http://hl7.org/fhir/2016Jan/http.html#concurrency version conflict]. 

===5 Search Patient (JSON) ===
:Action: FHIR Client sends GET to EHR /Patient resource with name (or other) parameter
:Precondition: EHR 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)
:Bonus point: Patient must expose the meta.versionId and meta.lastUpdated fields and support search by name.

===6 Patch Patient (JSON) ===
:Action: FHIR Client sends PATCH to EHR /Patient resource using [http://jsonpatch.com/ JSON Patch] format to update any field on Patient.
:Precondition: EHR should expose PATCH resource honoring the [http://jsonpatch.com/ 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.
:Bonus point: Rejecting the update if there is a [http://hl7.org/fhir/2016Jan/http.html#concurrency version conflict]. 

===7 Search Patient (XML) ===
:Action: FHIR Client sends GET to EHR /Patient resource with name parameter
:Precondition: EHR 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)
:Bonus point: Patient must expose the meta.versionId and meta.lastUpdated fields and support search by name.

===8 Patch Patient (XML) ===
:Action: FHIR Client sends PATCH to EHR /Patient resource using [http://tools.ietf.org/html/rfc5261 XML Patch] format to update any field on Patient.
:Precondition: EHR should expose PATCH resource honoring the [http://tools.ietf.org/html/rfc5261 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.
:Bonus point: Rejecting the update if there is a [http://hl7.org/fhir/2016Jan/http.html#concurrency version conflict]. 

==TestScript(s)==
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested.  
These should be committed to SVN under trunk/connectathons/[connectathon]
-->
TestScripts and corresponding fixtures have been committed to the FHIR SVN repository at:
http://gforge.hl7.org/svn/fhir/trunk/connectathons/BaltimoreSep2016/Connectathon13/PATCH