This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201601 PATCH Connectathon Track Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Initial creation)
 
(Add details for PATCH track)
Line 2: Line 2:
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 
__NOTOC__
 
__NOTOC__
−
=Track Name=
+
=FHIR PATCH for MedicationStatement=
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
−
<!-- Who is asking for this track? -->
+
This is something FHIR Core requested feedback on DSTU 2: http://hl7.org/fhir/dstu2/http.html#update
  
 
==Justification==
 
==Justification==
−
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
+
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?
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
−
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
+
Jenni Syed
 +
  Email: jenni dot syed at cerner dot com
 +
  Skype: jenni.syed
  
 
==Expected participants==
 
==Expected participants==
−
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
+
Cerner (Jenni Syed)
  
 
==Roles==
 
==Roles==
−
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
+
 
−
===Role 1 Name===
+
===EHR===
−
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
Exposes the FHIR MedicationStatement resource with GET (search) and PATCH methods available.
 +
 
 +
===FHIR Client===
 +
Has the ability to GET and PATCH MedicationStatement.
 +
 
  
 
==Scenarios==
 
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
−
===Scenario Step 1 Name===
+
===Search MedicationStatement===
−
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
:Action: FHIR Client sends GET to EHR /MedicationStatement resource with patient parameter
−
:Precondition: <!-- What setup is required prior to executing this step? -->
+
:Precondition: EHR should expose GET resource with the JSON format
−
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
:Success Criteria:
−
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
:Bonus point: MedicationStatement must expose the [http://hl7.org/fhir/dstu2/medicationstatement.html#search meta.versionId and meta.lastUpdated] fields and support search by patient.
 +
 
 +
===Patch MedicationStatement===
 +
:Action: FHIR Client sends PATCH to EHR /MedicationStatement resource using [http://jsonpatch.com/ JSON Patch] format to update the [http://hl7.org/fhir/dstu2/medicationstatement-definitions.html#MedicationStatement.status MedicationStatement.status]
 +
:Precondition: EHR should expose PATCH resource honoring the [http://jsonpatch.com/ JSON Patch] format.
 +
:Success Criteria:  
 +
:Bonus point: Rejecting the update if there is a [http://hl7.org/fhir/dstu2/http.html#2.1.0.10.1 version conflict]. Support for updating other fields (eg: [http://hl7.org/fhir/dstu2/medicationstatement-definitions.html#MedicationStatement.note note]).
  
−
<!-- Provide a description of each task -->
 
  
 
==TestScript(s)==
 
==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]
 
−
-->
 

Revision as of 19:00, 18 November 2015


FHIR PATCH for MedicationStatement

Submitting WG/Project/Implementer Group

This is something FHIR Core requested feedback on DSTU 2: http://hl7.org/fhir/dstu2/http.html#update

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?

Proposed Track Lead

Jenni Syed 

  Email: jenni dot syed at cerner dot com
  Skype: jenni.syed

Expected participants

Cerner (Jenni Syed)

Roles

EHR

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

FHIR Client

Has the ability to GET and PATCH MedicationStatement.


Scenarios

Search MedicationStatement

Action: FHIR Client sends GET to EHR /MedicationStatement resource with patient parameter
Precondition: EHR should expose GET resource with the JSON format
Success Criteria:
Bonus point: MedicationStatement must expose the meta.versionId and meta.lastUpdated fields and support search by patient.

Patch MedicationStatement

Action: FHIR Client sends PATCH to EHR /MedicationStatement resource using JSON Patch format to update the MedicationStatement.status
Precondition: EHR should expose PATCH resource honoring the JSON Patch format.
Success Criteria:
Bonus point: Rejecting the update if there is a version conflict. Support for updating other fields (eg: note).


TestScript(s)

Retrieved from "https://wiki.hl7.org/w/index.php?title=201601_PATCH_Connectathon_Track_Proposal&oldid=107769"