Project: Implement spring data to the LibreHealth toolkit

Abstract

The Librehealth toolkit is dependent on Hibernate for database mapping to MYSQL. To scale various uses for the toolkit, there is a critical need to integrate a standard database management framework. This project aims to implement Spring Data into LibreHealth toolkit

Mentors @namratanehete @sunbiz @judywawira

Users Subprojects that depend on LH toolkit

Objectives

  • Implement the LH-toolkit data model using spring data
  • Document examples that show how spring data can generate a non relational and relational database

Resources

  1. http://projects.spring.io/spring-data/

Technical Requirements Mysql , java , Spring

4 Likes

I want contribute to this project, please give me a start on this, on how to start contributing.

@judywawira @sunbiz @namratanehete I would like to take up this project if that is ok with you. I have been busy with the prerequisite tasks, but I am ready to commit myself to this, while doing the final touches on those tasks. I am familiar with the technical requirements involved(MySQL and Java especially). I was introduced to Spring while working on one of the prerequisite tasks, but I would not say I am up to a level that is satisfactory for this task, but I intend to, and pretty quickly too. I will begin looking deeper into the project in order to prepare my proposal and I believe with your help I will be able to see it through

2 Likes

@tenas97, do you have a proposal for us to review? on how you will get this task done?

@shoaib, please complete the pre-req tasks - https://gitlab.com/librehealth/lh-toolkit/issues/34 to show your skills and then write an application on how you will complete this project.

@judywawira @sunbiz I’m going through this idea. Currently when I’m looking at the code, hibernate is used to be the persistence layer. So main goal of this project to completely replace the hibernate layer with spring data?

I believe entire code base is heavily depends on the hibernate layer and the functions provided by the hibernate such as search APIs. So is it required to completely rewrite the hibernate layer? Or is this project looking for doing it for some components and try out the functionality?

1 Like

We are looking to replace hibernate throughout the project and move to Spring data. So, not doing some components but changing all the hibernate classes. The existing Entity POJOs will also need to be replaced by the FHIR HAPI structures.

1 Like

When you say that existing POJOs will need to be replaced by FHIR HAPI structures, do you mean we’re supposed to use POJOs from HAPI FHIR structures library or we need to implement new POJOs based on those structures and add any validations or mapping annotations needed?

If we going to replace the POJO with hibernate classes, there will be a issue. According to my analysis, FHIR and Librehelath POJO attributes doesn’t match 100%. Also in order to support FHIR structures we will need to alter the database design as well right @sunbiz ?

Just use the HAPI structures from the library and not write new POJOs.

Yes, the database will be very different from what is present in the toolkit. It will be closer or similar to the FHIR ones, but the old tables for user, global_properties etc, will be the same. An example that you could emulate is this - http://hapifhir.io/doc_jpa.html . It does it over a Derby database, but with Spring data, we can chose what database module we want to use.

Thank you for the clarification @sunbiz. Since FHIR resources doesn’t support all the attributes of the Librehealth POJO classes, we will require complete restructuring of the web application UIs as well?. Also while I’m doing the background research, I found that every resource in librehealth can’t be represented in FHIR. For example, EncounterType in librehealth can’t be represented by FHIR resource. I will work on the proposal and add a draft.

We will have to keep those POJOs that are related to authentication, global properties, modules etc. Those that are in FHIR, will be replaced to connect to those. You do not have to do any UI restructuring as part of this project. Just the REST resources should be exposed like the JPA server example that I provided in my last post.

Encounter has type property, which takes value from a valueset - Valueset-encounter-type - FHIR v5.0.0 . This is the replacement for the EncounterType from present lh-toolkit.

The UI part will be done using the web components project - Project: Create web components for FHIR Resources

1 Like

Thanks a lot for the informatio @sunbiz.

The REST Resources are exposed via the web services module which depends on the librehealth core. This means we have to restructure the rest web services module as well?

@sunbiz also will it be good to use HAPI FHII library to expose the resources as REST?

Also in FHIR there isn’t resource call Visit. Then how should we map those resources in Librehelath?

I also checked https://talk.openmrs.org/t/gsoc-2017-fhir-module-enhancements/10613/8 which mention about supported FHIR resources in openmrs platform. This was a GSoC project and student did feasibility study for FHIR Resource mappings in https://talk.openmrs.org/uploads/default/original/2X/1/1de1432ffc0d3b79d892f2375d66dff5e02097ab.pdf

I don’t believe that the Visit term is not clinically correct. The FHIR resource is called Episode of Care, which has more appropriate properties in my opinion than the OpenMRS/LibreHealth Visit.

We are not taking the approach of mapping the two data/information models. Instead, we are moving to the FHIR model completely. The HAPI FHIR library is a very fine approach to take. Using spring data, we can move to JPA or another database. I like the way Spring 5 defines the two ways to build Spring applications now. The Reactive WebFlux is really very interesting and deploys on Netty, instead of blocking IO approach of Tomcat etc…

1 Like

I recommend looking for “encounter” or a term that means “date of service”. Visit is typically a scheduling term, where an encounter is a patient contact. These can be phone calls and the like, so “visit” wouldn’t apply.

The mapped resource should be

@sunbiz Ok I was thinking about mappings in the existing system. That was the reason for the confusion. If we going to have completely move to FHIR. Then most of my concerns are going away. Thanks a lot for the information.

I pasted a link above, and something on the forum removed it. https://www.hl7.org/fhir/encounter.html Trying it again, though it may not be as relevant as I think, just to see if it goes poof again. www.hl7.org/fhir/encounter.html <without the https

@aethelwulffe , indeed Encounter is the single interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient. We were talking about grouping of Encounter, which can be done using CarePlan or Episode of Care. I think FHIR has got it right, even if both of those are still for trial use and not very mature resources.

1 Like

Since the underline data structures going to support FHIR, we will require a full database redesign. I checked the HAPI JPA server, it seems that responses are getting store in BLOBs. So proper redesign is required.