I have been selected for Google Summer of Code 2023 to work on the project FHIR: Add support for FHIR PATCH operations. I will be using this thread for the discussions and updates of the project.
Project Details
Name: FHIR: Add support for FHIR PATCH operations.
Description: OpenMRS is using the FHIR API more and more in place of the REST API. However, the FHIR API is, by default, quite verbose. Supporting PATCH operations would allow us to support partial updates to FHIR resources without needing to send the whole resource from the client to the server.
Held my first of many meetings with my mentors(@ibacher and @abertnamanya ) on Friday evening(EAT) and Ian took me through the scope of the project and explained further the openmrs-module-fhir2 architecture.
Among the core objectives i picked from the meeting include the following;-
The PatchTypeEnums to be covered are JSON_PATCH(“application/json-patch+json”), XML_PATCH(“application/xml-patch+xml”), FHIR_PATCH_JSON(“application/fhir+json”), FHIR_PATCH_XML(“application/fhir+xml”).
For json patching, there is a preference for JSON_MERGE_PATCH(application/merge-patch+json) since they’re not as complicated for a user as the JSON_PATCH when making an http request.
The patches will only be implemented for resource providers that already allow updating of the resource with only a few exceptions for those that don’t.
For the start we will cover the R4 version of the FHIR module and then R3 will be considered since its a little more complicated and requires some more contemplation.
The Hapi/FHIR implementation will come in handy with only a few tweaks here and there to suit our use case.
For now the objective list is there above with expectation for it to grow as we continue to delibarate and work towards our goal which is Adding Support for FHIR Patch operations. Otherwise thanks to my mentors for sparing the time.
I had my second meeting with my mentors last Friday which is scheduled for every week 2023-05-26T17:00:00Z and the meeting link is Launch Meeting - Zoom and we discussed majorly on how we are going to manage the project using JIRA. I have opted for creating an epic master ticket that will have child tickets as can be seen in the Epic → [FM2-573] - OpenMRS Issues.
As quoted from @ibacher on one of the tickets. So in the light of that comment, i have created 5 tickets for five resources to cater for JSON_MERGE_PATCH operations and these resources are Patient, Location, Condition, Person, Observation. Then i will create 5 other tickets for the same resources so that i can cater for XML_PATCH operations. And the same for other remaining formats.
herman muhereza To consider: do we want one ticket for “PATCH Operations” or one ticket per type of PATCH operation? we can likely close a ticket that’s only working with, e.g., JSON Merge Patch much quicker. Up to you on how this work gets staged, but it might make sense to do:
Pass-through support for JSON Merge Patch to a few resources
Implement XML-PATCH and add support for those resources
Implement JSON Patch and add support for those resources
As i was working on applying JSON_MERGE_PATCH for the patient resource, i have figured out that actually json merge patches do not support changes in Arrays, Lists so changing things like family_name, given_name or patching addresses in a location resources is not possible as the patch will simply add( if the intention is to replace) the element as a new element in the Array, List, etc…
For example in the json document below, its possible to change the gender to a different one but impossible to change the given name or family name.
So in the meeting today, @ibacher advised to also make sure that we implement the JSON_PATCH where ts possible to have the modifictions in Arrays, Lists, etc…