In the PIH EMR, we currently don’t use drug the drug_ingredient table, but for different formularies of the same drug just rely on the free-text name in the drug table.
For example:
mysql> select count(*) from drug_ingredient;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)
mysql> select name from concept_name where concept_id=6223 limit 1;
+------+
| name |
+------+
| DRV |
+------+
1 row in set (0.00 sec)
mysql> select name from drug where concept_id=6223;
+-------------------------------+
| name |
+-------------------------------+
| Darunavir (DRV), 600mg tablet |
| Darunavir (DRV), 75mg tablet |
+-------------------------------+
2 rows in set (0.00 sec)
Of course, there would be value in switching to a coded model that uses drug ingredients, and we may do this, but, if we didn’t, would there be any way using our current module to translate an OpenMRS Drug into a FHIR Medication, including the formulary. It seems like the FHIR module doesn’t support any free-text option for a formulary, but relies on Drug Ingredient.
FHIR 2 module code that converts from a Drug to a Medication:
This is relevant to us as we determine if we can/should use a “FHIR first” approach to the Medication Dispense functionality we are building… ie, if we are going to communicate entirely via the FHIR REST API, it would need to support free-text formularies or we’d need to populate our drug ingredient table.
@mogoodrich and I just discussed this and I think we are good. What we need to start doing at PIH is actually using the “dosage_form” and “strength” columns of the drug table properly (which we are also not yet doing). That should be sufficient I think. We can also start using drug ingredient (and I think we should), but this should not be required for us to convert between Drug and Medication in FHIR as far as I can tell.
“strength” in the OpenMRS Drug table, is a string and non-coded, so I assume it would expect something like “200 mg”. In FHIR, it looks like it expects strength to be coded (ie with a quantity and units component).
It looks like you’ve already added support to FHIR2 to send the OpenMRS free-text strength as part of Medication using a custom-defined extension? (So the current “dose_form” and “strength” as supported in OpenMRS should work out of the box, with this custom extension).
That’s right. I’ve tried to minimize the number of custom extensions required, but here and in a couple of other places (addresses spring to mind) where there’s no straight-forward way to get the OMRS model to match FHIR, we’ve used custom extensions to at least ensure the data is available.
So I get that you guys have decided to change how you’re using the drug table. However, I think it’s worth pointing out a couple of principles around how we can approach similar issues:
First, it’s entirely possible that FHIR2 maps some things incorrectly. We’ve done our best, but I’ve ended up suggesting what a lot of the mappings should be and… I don’t have access to an OpenMRS system with actual patient data. In those cases, we can easily change the FHIR2 module to make whatever corrections we need.
Second, there are clearly some cases where implementations will just make different decisions about how to map things. @burke always stressed that we should have some kind of strategy pattern to determine how mappings are done. The original FHIR module did this in quite a literal manner: every resource had one or more strategies that were fetched from the settings at runtime. With FHIR2 I decided to adopt a simpler to implement approach: Spring is our strategy pattern.
Basically, this means that any module should be able to override our mappings by implementing one or more classes, depending on how complex the mapping changes are (this is also why FHIR2 has an annoying number of interfaces). Concretely, what this looks like can be seen here. The classes in that directory override our normal ServiceRequest mappings to use a “custom” mapping–in this case, iSantePlus represents lab orders as observations rather than TestOrder classes.
Thanks @ibacher ! And thanks overall for all your hard work on the FHIR2 module… I haven’t had much of a chance to interact with it, but that will likely be changing in the coming months!
And thanks for the concrete example of the iSantePlus override…
Perhaps someone can summarize what was decided and whether the CIEL drug tables are also appropriate. We had originally set up the concept and drug tables to leverage RxNORM so that we should be able to pull ingredients out.
So, trying to think through how to answer Andy’s question above, maybe we should think about revising how the Medication resource works because we’re basically ignoring the drug table name field. Perhaps for Medication we should just be returning the name in the code field instead? (In FHIR coded fields can be real coded answers, but they also could just be a string display). That seems to reflect how the CIEL drug table and the PIH drug table work. We could then attach the actual concept as an (OpenMRS-specific) extension. (Since the drug name and concept describe two slightly different things and there’s only one code allowed, it would seem inappropriate to lump them both into the same coding as that would imply the concept === the drug).
