We are currently in the process of incorporating the FhirMedicationAdministration resource into the openmrs fhir module. Reference for the FHIR Medication Administration resource specifications at MedicationAdministration - FHIR v4.0.1.
As we make progress, we look for insights from the community regarding a specific scenario related to FHIR model design. Specifically, when dealing with a Reference type in the fhir model, we observe two distinct database modeling approaches:
The first approach involves directly mapping the resource id of the child reference into a corresponding column in the parent resource.
The second approach entails decoupling the references by utilizing a fhir_reference table.
For example, when storing encounter details in the fhir_diagnostic_report, the encounter is directly mapped as a property in the encounter_id column. Whereas, in the case of fhir_task, the encounter is mapped via fhir_reference table.
Our concern with the second approach is that possibly sql operations could be more expensive (as fhir_reference acts a common place for all type of references which can lead to high volume of data and also need to add additional join operations) inspite it provides the advantage of decoupled and lightweight database entities.
We would greatly appreciate your thoughts or experiences with these two database modeling approaches. Thank you in advance for your insights.
In general, my stance has been that the FHIR2 module is a translation layer between an existing OpenMRS data model and not the place that the data model gets implemented itself. DiagnosticReport and Task are the two exceptions to that. I regard them as a proof-of-concept rather than the model to follow. The better model to follow here is the integration of MedicationDispense over the last year or so. This was done by creating an appropriate domain in core that reflected just the parts of the FHIR model we most directly needed and then map that like any other domain object.
Hello @ibacher , thank you for your inputs and we’ll incorporate the feedbacks.
Also quick question around that. We’re from Bahmni implementation and presently operating with OpenMRS version 2.5.12 and FHIR2 version 1.10.x.
In the context of contributing medication administration, considering our usage of the older OpenMRS version and FHIR2, is it acceptable to incorporate the changes for both openmrs-2.5.12 and fhir2-1.x, as well as for the latest releases ? ie., we plan to submit pull requests for both old and latest releases.
Thanks
Data model changes in a point release (2.5.x) feels like a non-starter to me. That’s very bad versioning hygiene and leads to us having to do gymnastics to figure out what versions support what features. If you need something compatible with those versions, I would suggest building this out as a separate module.
Thanks @ibacher for the suggestion. We’ve decided to build a custom module that includes the Data model and FHIR translations, following the package structure of openmrs-core and FHIR2 module. Our plan is to contribute this module back to the master branches of openmrs-core and FHIR2. This way, when upgrading the openmrs version for our Bahmni implementation, we can easily switch the dependency to ensure smooth operation.
It would be appreciated if you could assist in reviewing the pull requests (PRs).
We were referring to previous models (Eg : MedicationDispense , MedicationRequest) & we observed a common pattern , where we see all informations related to dosage, substitution are flattened & stored in the same table ! Though we felt there was an opportunity for Normalizing the dosage information to a separate table , we had chose to denormalize it & maintain it in the same table.
As same is applicable for medication administration as well ,We are trying to understand , Based on your previous experiences , which option would be a better fit for our openmrs use cases !
=> Flatten and store dosage info in the same table (simple,flexible and better performance)
=> Normalize dosage information to separate table (reduce data redundancy & better scalability)
Although it may seem duplicative, I think the denormalised modelling is correct. That because while, ideally, the dosage ordered = the dosage dispensed = the dosage administered, the reason these are tracked separately is precisely because they might be different and this allows us to ensure that what happened at each stage is properly recorded, precisely so any discrepancies can be noted and adjusted.
If this weren’t the case, we could model it as a single row with three dates.
