Difference between revisions of "201605 PATCH Connectathon Track Proposal"
Jenni syed (talk | contribs) |
Jenni syed (talk | contribs) |
||
| Line 8: | Line 8: | ||
==Submitting WG/Project/Implementer Group== | ==Submitting WG/Project/Implementer Group== | ||
| − | + | Cerner - Jenni Syed | |
| + | |||
| + | Also some documentation from FHIR core and Grahame: http://hl7.org/fhir/dstu2/http.html#update | ||
| + | |||
| + | http://www.healthintersections.com.au/?p=2441 | ||
==Justification== | ==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. | ||
| + | |||
| + | *Targetted 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 Contrained - 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== | ==Proposed Track Lead== | ||
| Line 29: | Line 40: | ||
==Scenarios== | ==Scenarios== | ||
| − | + | Try FHIRPath implementation of original track: http://wiki.hl7.org/index.php?title=201601_PATCH_Connectathon_Track_Proposal | |
| + | |||
| + | Try to modify lists: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=8364 | ||
===Scenario Step 1 Name=== | ===Scenario Step 1 Name=== | ||
Revision as of 16:40, 5 February 2016
PATCH Connectathon
Skype: https://join.skype.com/xUx16MpXljhv
Connectathon 11 Tracking spreadsheet: TODO
Submitting WG/Project/Implementer Group
Cerner - Jenni Syed
Also some documentation from FHIR core and Grahame: http://hl7.org/fhir/dstu2/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.
- Targetted 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 Contrained - 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
See Connectathon_Track_Lead_Responsibilities
Expected participants
Roles
Role 1 Name
Scenarios
Try FHIRPath implementation of original track: http://wiki.hl7.org/index.php?title=201601_PATCH_Connectathon_Track_Proposal
Try to modify lists: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=8364
Scenario Step 1 Name
- Action:
- Precondition:
- Success Criteria:
- Bonus point:
