GSoC 2023 at OpenMRS | Coding Period Week 08

 

Introduction

Greetings, readers!

Welcome to my blog documenting my incredible journey through the 8th week of Google Summer of Code (GSoC). Over the past weeks, i have had the privilege of working with the OpenMRS community, contributing to the fhir2 module. With each passing week, i have learned and grown as a developer, and the 8th week was no exception. Let's dive into the highlights of the eventful week!

Highlights

Add Support for Patch Operations on Immunization resource: 

implemented all patch operations on the Immunization resource i.e Json Merge Patch, Json Patch and Xml Patch. This one needed careful handling since it was being saved as an Obs object.

Add Support for Update and Patch on Observation resource: 

this was continuation from last week and i had not yet figured out i was losing the functionality of creating a new obsid when patching an observation like it is in updating an obs object. However, i achieved that and it was more to do with the data set i was using for the integration test.

Others include:

• Clean up parameter passing for MedicationRequest service method
• Clean up parameter passing for DiagnosticReport service method
• Clean up parameter passing for Condition service method

Conclusion

The 8th week was a whirlwind of challenges and accomplishments. The support and mentorship from Ian Bacher and Abert Namanya and the entire community has been instrumental in my growth as a developer.

As i reflect on last week's achievements, i am reminded of the power of open-source collaboration and the impact we make by working together. GSoC has been an unforgettable experience, and i am excited to continue contributing to open-source beyond this program.

Thank you for joining me on this incredible journey. Stay tuned for more updates as i embark on the final leg of GSoC, with new challenges and opportunities awaiting.

Until next time!

Cheers!

GSoC 2023 at OpenMRS | Coding Period Week 07

Introduction

Greetings, dear readers!

I am delighted to share with you an update on my exhilarating coding journey during WEEK 7 of the Google Summer of Code (GSoC) program. This incredible experience has allowed me to delve into the depths of programming, further honing my skills and embracing new challenges along the way.

Over the past 6 weeks, i have been engaged in an exciting project called Add Support for FHIR Patch operations. The program has provided me with an invaluable platform to collaborate with mentors and work on a real-world software development project. To have a recap of how the six weeks have been, please look through my weekly blogs so far.  You can aswell find the short demo video for my midterm evaluation at https://www.youtube.com/watch?v=P-0gj-8LOCE.

Week 7 Recap

In week 7 i embarked on completing the resources that i had not yet covered for XML PATCHing which included Location resource, Encounter resource. Below are the pull requests for the two resources:-

• XML PATCHing - Location Resource
• XML PATCHing - Encounter Resource

As part of week 7, i also attempted an issue to clean up parameter passing on the condition resource. I realized there is a little more work needed in making the right functionality come out. This is so because the OpenMRS FHIR implementation of the Condition Resource was twice because in the versions below OpenMRS 2.2.0, the Condition resource was not supported. So the translation of that resource in the Fhir2 module was based off of the Obs object. And in the second implementation, it was based off the Condition object which was introduced in the openmrs data model in the versions 2.2.0 and above. The integration tests for the versions below 2.2.0 were not properly written since they included the clinicalStatus which wasn't part of that particular version. Below is the pull request for that more.

• Clean up parameter passing for Condition Service Search method

The task i had in Week 7 was to ensure that the Observation Resource supports PATCHing operations. However, to introduce that i had to ensure that it can support UPDATING requests which i did in the commit below:-

Maybe a little context of what actually takes place here, the Obs object in OpenMRS is a unique object and hence usually refered to as immutable. This can further be explained that when an existing obs object is edited/updated, the existing obs object with the existing obsId is voided and a new obs object with a new obsId is created hence a new row in the database altogether.

• Add Support for UPDATE on Observation Resource.

After supporting UPDATE, next task i attempted was ensuring that it supports PATCHing. However, the challenge here that has blocked me from completing this task this week is that unlike the UPDATE which voids the existing obs object when updating it, with PATCHing the behavious is not really coming out as it should. It does not void the exisiting obs object hence returning the same object but patched. The saveObs() method seems to consider the patched object  as a saveObsNotDirty() yet it is supposed to be a saveExistingObs(). Below is the commit for patching;-

• Add Support for PATCHing on Observation Resource.

Looking Ahead

As i step into the 8th week, i remain confident that the challenges i am having on Observation Resource will be overcome and it will be able to support PATCHing as it should. I will continue to follow the project timeline diligently, seeking guidance from my mentors and the entire community and give feedback when needed to ensure the successful completion of my assigned tasks.

Stay tuned for more updates as i continue this exhilarating journey! 

Thank you for joining me on this blog post, and until next time!

cheers,

mherman22

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.