core__medicationrequest only contains "inline" codes that are RXNORM. (But adds some niceties like dosage instruction text)
core__medication is built from MedicationRequest tables but includes "inline", "contained", and "external" codes. Does not filter by system.
I believe we build our core__count_medicationrequest table off core__medicationrequest and are thus missing a lot of data.
My Proposal
Nuke core__medicationrequest
Rename core__medication to be core__medicationrequest
Add in any now-missing features (like dosageInstruction.text) to the new tables.
I imagine the core__medication tables were named that because they sometimes inspect Medication resources (contained or external). But the rows do not represent Medication resources at all. They are summaries of MedicationRequests that happened to (behind the scenes) grab the correct codes from Medication resources.
Consumers of the tables don't care about all that abstraction work - let's actually provide the abstraction.
In this proposal, we don't need a core__medication table, since those aren't patient/encounter linked resources (maybe we could still provide one in the future, if someone wants the ability to look up detailed med info -- but not our concern right now).
Some other idea
Or some better idea - but regardless of where we land, I think there's currently some unnecessary duplication between those two tables, and we could stand to develop an actual vision for them.
Current State
core__medicationrequestonly contains "inline" codes that are RXNORM. (But adds some niceties like dosage instruction text)core__medicationis built from MedicationRequest tables but includes "inline", "contained", and "external" codes. Does not filter by system.core__count_medicationrequesttable offcore__medicationrequestand are thus missing a lot of data.My Proposal
core__medicationrequestcore__medicationto becore__medicationrequestdosageInstruction.text) to the new tables.I imagine the
core__medicationtables were named that because they sometimes inspect Medication resources (contained or external). But the rows do not represent Medication resources at all. They are summaries of MedicationRequests that happened to (behind the scenes) grab the correct codes from Medication resources.Consumers of the tables don't care about all that abstraction work - let's actually provide the abstraction.
In this proposal, we don't need a
core__medicationtable, since those aren't patient/encounter linked resources (maybe we could still provide one in the future, if someone wants the ability to look up detailed med info -- but not our concern right now).Some other idea Or some better idea - but regardless of where we land, I think there's currently some unnecessary duplication between those two tables, and we could stand to develop an actual vision for them.