GSoC 2020 - Improve FHIR Search - Final Presentation

Community GSoC
,
1

Primary Mentor: @ibacher

Backup Mentor: @reagan

Student: Varun Gupta

Project Link: https://wiki.openmrs.org/display/projects/GSoC+2020+%3A+Improve+FHIR+Search

Project Overview:

The Improve FHIR Search project was aimed at improving the search capability provided by the FHIR v2 module. This included implementation of an exhaustive search for the supported resources, sorting of the search results by one or more parameters, addition of paging functionality to restrict the number of search results per page and addition of new features like _id, _lastUpdated, _include, _revinclude and a lot more.

Objectives:

  • Implementation of an exhaustive search (Completed):

The main aim here was to implement as much search as possible for the supported resources so as to not restrict search by a single parameter. This also included adding support for chained queries when searching a resource using the reference to another resource.

Along with search, it was also essential to provide a sorting functionality for the returned search results, both in an ascending and descending order of the specified sorting criteria.

Another key issue was to make sure that search returned distinct search results, because there were instances of the same resource being returned multiple times as a result of the joins between the Hibernate tables.

  • Addition of paging functionality (Completed):

Paging of search results refers to restricting the number of search results on a single page.

Initially, all the search results were returned at once on a single page. The paging functionality was added to all resources to return only the specified number of search results in one go (configured using the page size property). The link to the next resource would allow the user to traverse through the pages until the last page was reached, which had no additional links.

  • Implementation of common search parameters (Completed):

The objective was to implement the search parameters _id and _lastUpdated, which are available for use with all the FHIR resources.

_id search parameter is used to retrieve a particular resource using the UUID of the resource.

It makes less sense of adding support for this feature because if we have the UUID, then we have the resource as well. But it is more significant when used in combination with other search parameters to retrieve detailed information about a specific resource.

_lastUpdated search parameter is used to retrieve resources based on the last time they were modified.

In case of immutable resources i.e. those which do not have a date modified property, the date of creation is considered for the purpose of the search query.

  • Implementation of advanced search parameters (Completed):

Apart from returning the resources matching a particular search criteria, FHIR also allows us to return resources related to these. This is done using the _include and _revinclude advanced search parameters and the support for these was added for resources where meaningful.

_include search parameter is used to return resources of a particular type associated with the results matching the search criteria.

For instance, a search using /Encounter?_include=Encounter:patient allows us to return the matching Encounters as well as the Patient resources associated with those Encounters.

_revinclude search parameter is used to also return resources of a particular specified type that refer to the results matching the search criteria.

Since, _revinclude functions exactly opposite to _include, it is also called as the reverse include. For instance, search using /Patient?_revinclude=Encounter:patient returns all the Patient resources as well as the Encounters that refer to those Patient resources.

JIRA Tickets and Pull Requests

Through the twelve weeks of the GSoC’20 program, I worked on a lot of issues in different domains of the FHIR v2 Module. Apart from working on my project objectives, I worked on tickets regarding the implementation of CRUD methods for certain resources, code refactoring, bug fixes as well as adding the integration tests. The tickets that I worked on can be found here.

My commits and pull requests are as follows:

  • Commits and PRs that have been merged into master:

Commits · openmrs/openmrs-module-fhir2 · GitHub

  • Unmerged commits:

The commits for _include and _revinclude are still not merged because any new features are not being added onto master until the module’s initial release. Hence, these commits are on a separate include branch:

Commits · openmrs/openmrs-module-fhir2 · GitHub

Weekly Reports and Presentation

The weekly reports regarding the project status and the work documentation along with any blockers throughout the twelve weeks of the coding period are listed below:

With these weekly blog posts in place, I think it is clear enough regarding the project status and the work done on a regular basis. But often documentation is not the best way to demonstrate the work product and give an insight into its functioning when ready! Therefore, keeping the reader’s curiosity in mind, I made a short video explaining the project objectives along with a small demo of the same. Hope that makes it more clear…

Future Work on the Project

Even though the project ends as being a part of GSoC 2020, there is still a lot more work that can be done to improve the module. Some of the things that are planned for later are:

  1. Adding support for List Resource along with some other FHIR resources.
  2. Implementing support for Lucene for the versions of OpenMRS where the Lucene index is available for a given resource.
  3. Implementing the ability to search using the _filter special syntax.
  4. Implementing the ability to search via GraphQL.
  5. Integrating FHIR search with ElasticSearch.

Thoughts on GSoC

Contributing to Open Source as a part of Google Summer of Code has been a great learning experience for me. I was not familiar with most of the things involved in the project when I started to look into it during the application period and it was also my first time working on Open Source.

I learnt about REST services, application servers, working of Hibernate along with the all-important Criteria API which formed a crucial part of this project. Leaving tech aside, what I really learnt were best coding practices by reviewing a lot of pull requests and engaging in discussions on my code. I still remember being a novice with respect to the FHIR module and taking ages initially to get to a point where the code started making sense. But as time flew by, I gradually started noticing places of improvements, bugs and related fixes.

I’ll use this opportunity to thank my mentor, Ian Bacher, for all the support and guidance. Even though he was involved in a lot of things simultaneously, he made sure to reply to my concerns and blockers as soon as possible in the most comprehensive way. This allowed me to make good progress on my work and objectives. We also had numerous conversations wherein we used to discuss any bugs that I found out, plan for the next set of tasks and talk in general about the working of the module, which I think benefitted both of us at times.

Lastly, I would like to thank the OpenMRS community for being supportive and selecting me to work on this project. The community has some amazing and dedicated people who help each other in the quickest and best possible way. And I think this is the beauty of contributing to Open Source!

Looking forward to keep the motto going… “Write Code, Save Lives.”

3 Likes