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.
I think we should start with simply having these as JSON on the filesystem or Derby as BLOBs as the first pass. Have you looked at the Spring data Reactive Repository and what I mentioned about it a few posts back? I think we should go for this, if others in the community think its a good direction. Going back to a relational database after getting such nice document-like representation of FHIR doesn’t make sense to me.
Small microservices with reactive data access should be the way to go. I think its time to go Reactive, since we will move to a new data model.
Any opinions @judywawira @ivange94 and others?
1 Like
@sunbiz I will look at the spring data reactive and update.
Saving JSON representation straightaway to the database would be fine in the first phase. In the long run, there will be resources that is getting referred within other resources. Also search capabilities needs to be added which might require to separate the data.
Note that “encounter” is the term used in our EHR as well as most other recently developed systems. It might be worth shifting the toolkit terms for this basic concepts. Encounter/D.O.S./MRN vs. Appointment. Visit is a bit too ambiguous. We only recently converted to that paradigm ourselves. It is actually a very helpful distinction in training and development.
1 Like
@sunbiz I had look at the spring reactive. MongoDB and Cassandra are most popular No-SQL databases which supported. However spring data reactive is at early stages.
Also with this project are we going to create separate web component from scratch or are we going to integrate the capability inside the current code base?
We should probably start from scratch, but use as much as we can from the present toolkit. I am not very sure of the answer yet.
@prashadi , how do you feel about working on an analytics engine of the JSON documents? Something that might use Apache Spark on Cassandra? So the FHIR JSON will be used to run over Spark?
1 Like