GSoC 2023 at OpenMRS | Coding Period Week 06

 

Welcome to the sixth week of my Google Summer of Code (GSoC) journey! It's hard to believe how quickly time has flown by as I continue to dive deeper into my project and explore new territories. This week has been full of exciting challenges and rewarding accomplishments, pushing me further towards my goals.

Throughout the program, I have had the opportunity to work closely with dedicated mentors and a vibrant community of like-minded developers at OpenMRS. Their guidance and support have been invaluable in shaping my understanding the FHIR Api and how OpenMRS leverages its functionality. As I reflect on the progress made so far, I am filled with a sense of gratitude and enthusiasm for the road ahead.

In this blog post, I will delve into the highlights and key learnings from the sixth week of my GSoC project. I will share the hurdles I encountered, the strategies I employed to overcome them, and the valuable insights gained along the way. Additionally, I will provide updates on the project's overall direction and discuss the exciting features and improvements implemented during this period.

Join me as I recount the fascinating moments, breakthroughs, and challenges encountered in the sixth week of my GSoC journey. I hope that my experiences and insights can inspire and resonate with fellow developers, and perhaps even offer valuable takeaways for those embarking on similar endeavors.

Without further ado, let's dive into the adventures of the past week and explore the strides taken towards making a meaningful contribution to the open-source community through my GSoC project.

Goal of the week

• Ensure that XML PATCHing works as it should on all the Fhir Resources that support patching in the OpenMRS Fhir2 Module. They should be able to take in an xml document like the one shown below:

<?xml version="1.0" encoding="UTF-8" ?>
<!--
    This Source Code Form is subject to the terms of the Mozilla Public License,
    v. 2.0. If a copy of the MPL was not distributed with this file, You can
    obtain one at http://mozilla.org/MPL/2.0/. OpenMRS is also distributed under
    the terms of the Healthcare Disclaimer located at http://openmrs.org/license.
    Copyright (C) OpenMRS Inc. OpenMRS is a registered trademark and the OpenMRS
    graphic logo is a trademark of OpenMRS Inc.
-->
<diff xmlns:fhir="http://hl7.org/fhir">
	<replace sel="/fhir:MedicationDispense/fhir:status/@value">
		completed
	</replace>
</diff>

Let us break down the xml document for better understanding of what is going on there:-

1. The root element is named diff and it belongs to the XML namespace "http://hl7.org/fhir". Namespaces allow for the differentiation of elements with the same name but belonging to different contexts or specifications. 
2. Within the diff element, there is a child element named replace. It specifies the XPath expression sel attribute which selects a specific attribute value in the XML document. In this case, it selects the value attribute of the status element under the MedicationDispense element in the FHIR namespace. The text content within the replace element is completed, indicating the new value that will replace the selected attribute's current value.Therefore, the above XML patch document  modifies an existing XML document in the OpenMRS Fhir2 Module.

Highlights / Pull Requests

• Clean up parameter passing in Practitioner Service class method: Service classes that support searching will often accept a long list of optional search parameters, where most of these parameters are not used (and thus passed in as null). This can lead to noisy and hard to maintain code. I pulled all search parameters for the Practitioner Service class into a separate searchParams class.
• Add Support for XML PATCHing operations - MedicationDispense
• Add Support for XML PATCHing operations - Task Resource.
• Add Support for XML PATCHing operations - Medication Resource.
• Add Support for XML PATCHing operations - DiagnosticReport
• Add Support for XML PATCHing operations - MedicationRequest
• Add Support for XML PATCHing operations - Condition
• Add Support for XML PATCHing operations - Person
• Add Support for XML PATCHing operations - AllergyIntolerance
• Add Support for XML PATCHing operations - Practitioner
• Add Support for XML PATCHing operations - Patient
• Clean up parameter passing in Medication Service class method

Thanks for taking time to go through the blog! 

Nice week ahead, cheers!

GSoC 2023 at OpenMRS | Coding Period Week 05

 

 Welcome to this week's blog that gives an account of what happened last week as I continue in this journey. Last week was an eventful week in terms of getting most of my pull requests merged into the openmrs-module-fhir2. Most of these pull requests were catering for JSON PATCHing and XML PATCHing operations.

The merged pull requests include the following:-

• https://github.com/openmrs/openmrs-module-fhir2/pull/493
• https://github.com/openmrs/openmrs-module-fhir2/pull/492
• https://github.com/openmrs/openmrs-module-fhir2/pull/491
• https://github.com/openmrs/openmrs-module-fhir2/pull/490
• https://github.com/openmrs/openmrs-module-fhir2/pull/488
• https://github.com/openmrs/openmrs-module-fhir2/pull/487
• https://github.com/openmrs/openmrs-module-fhir2/pull/484
• https://github.com/openmrs/openmrs-module-fhir2/pull/479 

For the past week i have looked into https://issues.openmrs.org/browse/FM2-591 which ensures to fully translate the ServiceRequest Fhir Resource into the OpenMRS datamodel's object called TestOrder. I created a talk post at https://talk.openmrs.org/t/toopenmrstype-translator-for-servicerequest-should-be-implemented/39980/1 where i needed help in translating some elements of the ServiceRequest resource like intent, status and performer. 

During our weekly meetings, my mentors took me through how i should overcome the issue. For the intent element, there is no need to translate it to openmrsType since it is hardcoded as ServiceRequest.ServiceRequestIntent.ORDER.

For performer. i would have to reverse engineer the current implement in the toFhirResource method.  Here is the method to reverse engineer. and after doing so i will go through all the other elements that need to be translated and hopefully have this implemented this week.

	private Reference determineServiceRequestPerformer(String orderUuid) {
		IBundleProvider results = taskService.searchForTasks(new TaskSearchParams(
		    new ReferenceAndListParam()
		            .addAnd(new ReferenceOrListParam().add(new ReferenceParam("ServiceRequest", null, orderUuid))),
		    null, null, null, null, null, null));
		
		Collection<Task> serviceRequestTasks = results.getResources(START_INDEX, END_INDEX).stream().map(p -> (Task) p)
		        .collect(Collectors.toList());
		
		if (serviceRequestTasks.size() != 1) {
			return null;
		}
		
		return serviceRequestTasks.iterator().next().getOwner();
	}

With the merging of the above pull requests that catered for JSON PATCHing, JSON MERGE PATCHing and the XMLPATCHUtils class that introduces XML PATCHing, i can now(this week) move onto writing integration tests for the other resources to ensure and confirm they implement XML Patching operations.

Thanks for taking time and reading through.

GSoC 2023 at OpenMRS | Coding Period Week 04

You are welcome to this week's blog. This marks week number 4 of this year's GSoC coding period. I am excited to share what i have been able to achieve throughout this entire week. 

This week i have laboured to look into XML PATCHing and how to implement that in the OpenMRS Fhir2 Module. I started off by creating a utils class in the Util directory within the api directory. I will break down the contents of the class below, please follow along;-

First of all, it contains a static method applyXmlPatch that handles XML patch operations for resources in the context of the FHIR (Fast Healthcare Interoperability Resources) standard.

public static <T extends IBaseResource> T applyXmlPatch(FhirContext theCtx, T theResourceToUpdate, String thePatchBody) {

The applyXmlPatch method is declared as public static, which means it can be accessed without creating an instance of the XmlPatchUtils class. It takes three parameters: 

• theCtx: An instance of FhirContext representing the FHIR context. 
• theResourceToUpdate: An object of type T that extends IBaseResource, which represents the resource to be updated.
• thePatchBody: A String containing the XML patch to be applied to the resource.

@SuppressWarnings("unchecked")
Class<T> clazz = (Class<T>) theResourceToUpdate.getClass();

The above line retrieves the class of the theResourceToUpdate object and casts it to Class<T>. It is used later for parsing the patched resource.

String inputResource = theCtx.newXmlParser().encodeResourceToString(theResourceToUpdate);

This line encodes the theResourceToUpdate object into an XML string using the newXmlParser() method of the theCtx object.

ByteArrayOutputStream result = new ByteArrayOutputStream();
try {
    Patcher.patch(new ByteArrayInputStream(inputResource.getBytes(Constants.CHARSET_UTF8)),
        new ByteArrayInputStream(thePatchBody.getBytes(Constants.CHARSET_UTF8)), result);
}
catch (IOException e) {
    throw new InvalidRequestException(e);
}

 The above block of code performs the XML patching operation using the Patcher.patch method. It takes the encoded input resource as a ByteArrayInputStream, the patch body as another ByteArrayInputStream, and writes the patched result to the result ByteArrayOutputStream.

return theCtx.newXmlParser().parseResource(clazz, toUtf8String(result.toByteArray()));

Finally, this line parses the patched resource from the result byte array using the newXmlParser() method of the theCtx object. It specifies the resource class (clazz) and uses the toUtf8String method to convert the byte array to a UTF-8 encoded string.

Overall, this code provides a utility method for applying XML patches to FHIR resources using the FHIR context and XML parsing capabilities provided by the FhirContext class.

To achieve the patching, we have utilized a library developed by dnaut and can be found at https://github.com/dnault/xml-patch.

I added the dependency to the root pom.xml file in the OpenMRS Module Fhir2 as shown below:-

            <dependency>
                <groupId>com.github.dnault</groupId>
                <artifactId>xml-patch</artifactId>
                <version>0.3.1</version>
            </dependency>

This and more can be accessed from the pull request at https://github.com/openmrs/openmrs-module-fhir2/pull/493.

Thanks for taking time to read through.

GSoC 2023 at OpenMRS | Coding Period Week 03

 

Week three(03) of my GSoC journey was a move into the right direction since it involved assessment of my work so far on my part so as to forge a way forward to meeting all the project objectives. Welcome to the past week's blog post and i hope you enjoy the read or better yet pick something useful from it.

Like the forecast was from last week, this week was more into code reviews and finishing up on some of the resources. I began the week by adding Encounter resource to the resources that need to support json merge patch and json patch operations. 

However the patching was not happening for the Encounter resource and the error below was being returned. Actually this blocker consumed a big chunk of my time this week.

Expected: response with HTTP status indicating request was handled successfully
     but: response with status code <500> with message "Failed to call access method: org.hibernate.HibernateException: A collection with cascade=\"all-delete-orphan\" was no longer referenced by the owning entity instance: org.openmrs.Encounter.encounterProviders"

The issue here was that somehow we deleted an encounter but not the encounterproviders attached to the encounter. This was brought about by how the translation of the Fhir Encounter resource to the OpenMRS Encounter data model was done. On further investigation and consultation with my mentor, we came with a fix for that as can be seen at https://github.com/openmrs/openmrs-module-fhir2/pull/489.

The rest of the week i embarked on making changes as was advised by my mentor especially on the integrations. I  had to migrate them the Integration tests 2.2 directory to the integration tests directory. The former is based of openmrs v2.2 whereas the latter is based off openmrs v2.0.5 so since most resources were supported by openmrs v2.0.5, it was fine to have all our integration tests in that folder save for a few which are not supported upto until version 2.2.

During our weekly meetings with my mentor, part of agenda was the discussion on the need to discuss the projected length of the project for administrative purpose. I wont dive into the reasons here, i am just highlighting it among the developments from last week.

Part of my projections last week was to be able to start on XML Patching but most of the week was taken up in fixing the Encounter resource and making changes as advised on our weekly call.

Appreciation to my mentor Ian for the time he offers to have me unblocked or learn something new. 

Thanks for the taking your time to read through.

Onto next week enthusiastically 😎

GSoC 2023 at OpenMRS | Coding Period Week 02

Comes another opportunity for me to update my blog with the experience i have had in the past week as i was working on my GSoC project. Here's the Coding Period Week 01 blog in case you missed it. I will breakdown my writing today into the various tickets/issues i encountered throughout this week. I was lucky to have some of work merged this week and it felt awesome 😍.

toOpenmrsType translators should set uuid to id part of id, not full: This ticket was created to fix the bug that was on a couple of the resources. This would cause an error where the uuid provided would exceed the maximum length which is 38. For example when i tried doing a patch operation on the patient resource, the error i got was failed to validate with reason: uuid: This value exceeds the maximum length of 38 permitted for this field. This was fixed and merged into master to cater for all other resources it could be affecting.

Add support for Json Patch operations - Patient Resource: This was meant to introduce the json patches to work along with the json merge patches as i explained in the previous blog. This work was also merged into master and it was able to unblock all the other tickets that would wish to implement any of the two patch formats. The rest of  the implementation can be at this commit.

Add Support for Json Merge Patch - Service Request Resource: This was meant to introduce json merge patch operations to the Service Request resource. However, this resource was not fully translated into the OpenMRS data model. Hence after spending hours on it, my mentor advised that i created a ticket for it but that could be out of scope for this project. So for future work on the module i ticketed the required changes at https://issues.openmrs.org/browse/FM2-591. This therefore means that the Service Request resource could also be out of scope for this project unless towards the end i get sometime at hand to dive into fully translating the resource.

Add support for Json Merge Patch operations - Medication: This was meant to introduce json merge patch operations to the Medication Resource. The pull request has been sent in and it is await review and hopefully merging into master. While working on this, i realized that the OpenMRS fhirIG index page didn't cater for the Medication resource so that it is easier to locate on the IG so i pushed a followup commit to ensure it does that and it is awaiting review and merging.

This was pretty much it from this past week and i am hoping this week will be more of review of the many pull requests i have created and having them merged. I also intend to work on the integration tests to test out the json patch functionality on the resources.

Thanks for taking your time to through, cheers 🍸🍷

GSoC 2023 at OpenMRS | Coding Period Week 01

 

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:-

• https://github.com/openmrs/openmrs-module-fhir2/pull/483

• https://github.com/openmrs/openmrs-module-fhir2/pull/481

• https://github.com/openmrs/openmrs-module-fhir2/pull/480

• https://github.com/openmrs/openmrs-module-fhir2/pull/479

• https://github.com/openmrs/openmrs-module-fhir2/pull/478

• https://github.com/openmrs/openmrs-module-fhir2/pull/477

GSoC 2023 at OpenMRS | Community Bonding Period

This Blog post is meant to give an update about my experience with OpenMRS as we start this year's Google Summer of Code. The community bonding period is about three weeks long and it is  meant to give the student the opportunity to interact with the opensource community and above all get to know his/her mentors, get themselves involved in the project they are supposed to work on when the coding period begins by reading documentation, code and any other related material.

Abstract

OpenMRS is an open source software project that offers an EMR that ensures patient care is a seamless process. As an open source community, the warmth is felt the moment you introduce yourself since there are so many people willing to spare a moment or two in order to show you around. That's the same culture Incase one has an issue to raise or a blocker. 

The email from GSoC team lead congratulating me upon being selected for this year's GSoC brought me chills allover since this was my second time applying for GSoC with OpenMRS but i had failed on the previous attempt. I hope to make the most of it and kickstart my career in open source software development.

About the Project: 

Name: 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.

Mentors: Ian Bacher and Abert Namanya

Community Period

OpenMRS community is very open and welcoming. Community members have lots of experience and knowledge. They always ready to help you, especially when you are a beginner. They provide you the resources and guide you as well.

I have been in touch with my project mentors and we have created a recurring weekly meeting to meet and digest the project even more. During this period, i have gone through the available resources on patch operations and how various FHIR implementations have implemented them. I have also had the chance to read the entire OpenMRS Fhir2 Module documentation and codebase so that i can get to understand what is taking place in the implementation of HL7/FHIR Standards by OpenMRS.

I have created an Epic in JIRA to track all the tickets that i will be working on throughout  this whole coding period. The Epic can be found at https://issues.openmrs.org/browse/FM2-573  

 Cheers and Happy coding!

Resources

• https://talk.openmrs.org/t/add-support-for-fhir-patch-operations/39042 
• https://wiki.openmrs.org/display/RES/Summer+of+Code+2023#:~:text=FHIR%3A%20Add%20support%20for%20FHIR%20PATCH%20operations%20%C2%A0 
• https://github.com/openmrs/openmrs-module-fhir2
• https://hapifhir.io/hapi-fhir/docs/server_plain/rest_operations.html#instance-level-patch
• https://docs.google.com/document/d/14g2EddqKIpon3xXI71BMKXfu5zISIy6Psy9NgCp4t6Q/edit?usp=sharing