Call me stupid. I spent the last 12 hours working on a performance challenge before I realized what the real solution was. The issue was that I was using a FHIR _include parameter on an existing query to get included resources that needed to be displayed. The performance was absolutely miserable.
To explain a bit, MedicationStatement and MedicationOrder reflect two different sides of an intention that a patient be given or taking certain medications. The MedicationStatement resource is (quoting DSTU2):
A record of a medication that is being consumed by a patient. A MedicationStatement may indicate that the patient may be taking the medication now, or has taken the medication in the past or will be taking the medication in the future. The source of this information can be the patient, significant other (such as a family member or spouse), or a clinician.
Whereas MedicationOrder is:
An order for both supply of the medication and the instructions for administration of the medication to a patient.
And while neither MedicationOrder nor MedicationStatement reference each other, the MedicationStatement does provide for "supportingInformation" as a Reference to any resource. I wanted to link the two to show the physician intention with the actual prescriptions and refills given.
But then when querying for MedicationStatement for a time period, I also wanted MedicationOrder, so I just grabbed the included references. Needless to say, this was a MISTAKE, because a patient may have been taking a medication for years and had literally hundreds of refills (I'm not kidding here 3 years of monthly refills on three meds is > 100, and hell, that could even be me).
The first sign of this was some icky performance. But see, the MedicationOrder stuff is there not because I have an immediate use for it, but rather because I'm following the CCD/CCDA pattern long established, and I KNOW it will be used in something I have to work with downstream, so I included it. So, it is kinda hidden and took a while to track down. AND then I spent about 8 hours trying to improve the performance of the MedicationOrder retrieval instead of asking about the quantity of data.
It might have been advantageous to go after MedicationOrder in the _include because of my data model and processing flow, but FHIR syntax for queries don't cross into _included resource in DSTU2 (I get to play with STU3 soon, maybe they've solved the problem there). I cannot in DSTU2 say: Give me these MedicationStatement resources, with ONLY the _included MedicationOrder resources that look like that. Yeah, I'm sure I could use the extended query syntax to get to this, but I'm looking for a bit more elegance here (that's what engineers call complexity that looks cool).
So, here's my thought on syntax:
_include=MedicationStatement:supportingInformation:MedicationOrder(setName)&_restrict:setName.searchParam=value
This would name the set of included fields, AND allow me to set an inclusion restriction on them.
If we only had that, AND if I implemented it, my problem would be solved. A simple matter of programming, what? Yeah.
Nah. FHIR Query syntax is complicated enough. But here is a use case for something we haven't thought of and the nice thing about it is that it seems simple enough to understand (even if I don't yet really know how to implement it). Is it in the 80%? Maybe. I have ONE use case for this. I could probably find others. I'm not going to spend much more time on this, I still have to fix that performance problem now that I've found it.
Keith
To explain a bit, MedicationStatement and MedicationOrder reflect two different sides of an intention that a patient be given or taking certain medications. The MedicationStatement resource is (quoting DSTU2):
A record of a medication that is being consumed by a patient. A MedicationStatement may indicate that the patient may be taking the medication now, or has taken the medication in the past or will be taking the medication in the future. The source of this information can be the patient, significant other (such as a family member or spouse), or a clinician.
Whereas MedicationOrder is:
An order for both supply of the medication and the instructions for administration of the medication to a patient.
And while neither MedicationOrder nor MedicationStatement reference each other, the MedicationStatement does provide for "supportingInformation" as a Reference to any resource. I wanted to link the two to show the physician intention with the actual prescriptions and refills given.
But then when querying for MedicationStatement for a time period, I also wanted MedicationOrder, so I just grabbed the included references. Needless to say, this was a MISTAKE, because a patient may have been taking a medication for years and had literally hundreds of refills (I'm not kidding here 3 years of monthly refills on three meds is > 100, and hell, that could even be me).
The first sign of this was some icky performance. But see, the MedicationOrder stuff is there not because I have an immediate use for it, but rather because I'm following the CCD/CCDA pattern long established, and I KNOW it will be used in something I have to work with downstream, so I included it. So, it is kinda hidden and took a while to track down. AND then I spent about 8 hours trying to improve the performance of the MedicationOrder retrieval instead of asking about the quantity of data.
It might have been advantageous to go after MedicationOrder in the _include because of my data model and processing flow, but FHIR syntax for queries don't cross into _included resource in DSTU2 (I get to play with STU3 soon, maybe they've solved the problem there). I cannot in DSTU2 say: Give me these MedicationStatement resources, with ONLY the _included MedicationOrder resources that look like that. Yeah, I'm sure I could use the extended query syntax to get to this, but I'm looking for a bit more elegance here (that's what engineers call complexity that looks cool).
So, here's my thought on syntax:
_include=MedicationStatement:supportingInformation:MedicationOrder(setName)&_restrict:setName.searchParam=value
This would name the set of included fields, AND allow me to set an inclusion restriction on them.
If we only had that, AND if I implemented it, my problem would be solved. A simple matter of programming, what? Yeah.
Nah. FHIR Query syntax is complicated enough. But here is a use case for something we haven't thought of and the nice thing about it is that it seems simple enough to understand (even if I don't yet really know how to implement it). Is it in the 80%? Maybe. I have ONE use case for this. I could probably find others. I'm not going to spend much more time on this, I still have to fix that performance problem now that I've found it.
Keith
No comments:
Post a Comment