Greetings all, coming to the end of the first week of the 2023 Google Summer of Code Coding period which officially began on 29th, May 2023. Here's my project OpenMRS talk post https://talk.openmrs.org/t/gsoc-2023-fhir-add-support-for-fhir-patch-operations-project-updates/39555?u=mherman22.
Having held a couple of meetings with my mentors and being guided on how to go about the whole period, i was advised to first of all choose five(5) resource providers and implement JSON_MERGE_PATCH patch operations, after that is done i can then implement XML_PATCH for those same resource providers. I would then go on to the other formats like FHIR_PATCH_JSON and FHIR_PATCH_XML.
I set out to implement JSON_MERGE_PATCH operations on on R4 Resource providers that included the following Patient Resource, Condition Resource, Location Resource, Person Resource and Allergy Intolerance Resource. To ensure that the implementation i am adding to the OpenMRS-Module-Fhir2, i have to include integration tests.
Everything went on as planned as i was implementing the JSON MERGE PATCH operations for resources like condition, location but things got a little complicated when i had to make patches for resources like patient, person. This was because these resources had some complicated JSON documents that included Arrays, Lists hence not being able to do operations like replace on them hence a JSON MERGE PATCH not being feasible. This is something that i initially missed when i was reading through the JSON MERGE PATCH RFC documentation.
The quote below is from the RFC
Also, it is not possible to patch part of a target that is not an object,such as to replace just some of the values in an array
On consultation with my mentor, he pointed me to the hapi/fhir interceptor that was added to the openmrs fhir module that simply intercepted the patch operations and converted the JSON_MERGE_PATCH operations into JSON_PATCH operations. This was done because of the fact that the PatchTypeEnum enum class from hapi fhir does not really provide an implementation for JSON_MERGE_PATCH operation. So all that this means is Json merge patch and Json patch were both coming across as the same type since we needed to use one of the values in PatchTypeEnum (which doesn’t support Merge Patch), so we hack around this by temporarily making it appear that a merge patch request is actually a JSON patch request. Here's the implementation of this https://github.com/openmrs/openmrs-module-fhir2/blob/master/omod/src/main/java/org/openmrs/module/fhir2/web/util/SupportMergePatchInterceptor.java.
The task at hand to find a way of separating the two operations(JSON PATCH vs JSON MERGE PATCH). I created the ticket https://issues.openmrs.org/browse/FM2-579 to track these changes. I did the following, i created an if-else statement under JSON_PATCH
because both merge patches and normal patches will come in under that.
What i did is to get the RequestDetails object (add it as a parameter to
the patch method on the provider and then pass it to the service method
call and check the Content-Type. If it’s application/merge-patch+json, then it’s a merge patch, otherwise, treat it as a JSON patch. Checkout the pull request at https://github.com/openmrs/openmrs-module-fhir2/pull/483.
With the pull request above, we can now implement both JSON PATCH and JSON MERGE PATCH operations on the OpenMRS-Module-Fhir2. With the second coding week imminent, i hope to finalize with json patches and json merge patch operations on the remaining resources.
I am loving the journey and the lessons
Below are the pull requests from week 01:-
No comments:
Post a Comment