I have searched but can only find 9 posts with ‘drug infusion’ and none seem to answer my question. Apologies however if I have missed something, and thanks in advance for any help.
We have an existing data model that we share via https://github.com/ropensci/cleanEHR/wiki which is based on an EAV table structure. We are trying to move our existing data to the OMOP CDM for inpatient records of patients in critical care, acute care and perioperative care.
We cannot find a suitable way to record drug infusions. For example, a patient might prescribed an infusion of 4mg/ml adrenaline (epinephrine) in 50mls normal saline. We would normally record the infusion rate as mcg/kg/min in the clinical record. This could change on a minute by minute basis.
I note that the PEDSnet CDM has made some modifications that would approach an answer: specifically the idea of an effective_drug_dose.
Is this the best solution? We would then need to calculate the effective drug dose for each time period and record a start/stop timestamp with each update?
Or is recording of such granular detail (hour by hour or even minute by minute measurements) not within scope of the drug exposure table?
@docsteveharris current drug_exposure is supposed to store the overall dosage of the drug that was given, because usually this is the only thing that matters. Indeed, there are rare cases where infusion rate matters (dopamine is the only one that I can recall), but this is rather exception to the rule.
In your example, you’d put RxNorm Epinephrine 4 MG/ML Injectable Solution in the drug_exposure, omitting saline as in this case it basically serves as a solvent and doesn’t have any pharmacological effect. If saline used in volume depletion states, you can also add another raw with Sodium Chloride 9 MG/ML Injectable Solution.
Hope it hepls. If you have cases where infusion rate matters, I’d love to take a look.
@docsteveharris Continuous infusions have been tricky for us as well, especially when they’re frequently titrated. I do think drug_exposure is the right place to put the data . We already have a separate row for each dose of intermittent drugs in the inpatient setting, so we can get a handle on prn usage, and changes in CMIs are similar in concept. And I agree that effective_drug_dose is the best way to capture the instantaneous dose.
To steal one of @Christian_Reich’s favorite mantras, it’s also fair to say that use case could be a major factor here. If all you anticipate needing is a qualitative “pressors or not”, it might be enough to integrate a day into one exposure in ETL. If you’re interested in level of exposure, you might be able to, say, represent an X hour window with the max dose in that interval. But if you have a critical care study looking at effects of different doses, I think you’re stuck with lots of rows (drawn from either a MAR or a flowsheet, depending on local practice).
Thanks Anna. We work in a critical care and periop environment where these measures are important for a wide range of medications (sedation, anaesthesia, vasopressors, inotropes). I’ll comment more in the response to @bailey below.
Thanks Charles.
If we end up using this approach (and I think we will need to because these doses and the ensuing physiological response) are so important to our subject area, then this spawns two further questions. Please let me know if I should post separately.
Will we hit performance issues if we start recording data at this high resolution? Our current database records hourly and we estimate around 6000 drug doses and physiological measurements per patient.
What is the best practice, or are their guidelines, to using a variant of the OMOP CDM such as that in the PEDSnet CDM? We would like to keep as ‘true’ to the CDM as possible. Do people tend to run 2 versions of the database (a faithful one, and a dev one)? Should we aim to add new tables for these specific entries rather than modify existing tables?
Sorry to do this to you, @bailey, but this field is going to go away. Here is what you should do:
If you inject the entire vial, put the correct Quantified Clinical Drug into drug_concept_id.
If you are dosing it more precisely use the (non-quantified) Clinical Drug, which gives you the concentration, and put the mL amount into the quantity field.
@Christian_Reich
Will the approach you suggested support of dose-response analyses when the amount of infused vs ordered drugs is known? I assume we want to support that when its possible to decrease the significant bias from unused meds in dose response analyses in oncology for example.
@Andrew You still know the amount of drug infused, right?
Then what do you think of playing with drug_type_concept_ids, using variations of administered/prescribed types? In this way, you’ll be able to distinguish between infused and ordered dosages.
Hi Christian. Thanks very much for your comments. The problem is that the infusion rate is captured instantaneously (e.g. 20mcg/minute at 2200hours on 2018-07-18) with perhaps another data point reporting the infusion rate 1 minute or 1 hour later.
If I find the correct concentration (adrenaline 4mg in 50mls), then I have to assume that the infusion rate was constant over that time period and then calculate the volume (e.g. 20mcg/minute for 1 minute is 0.25 mls of 4mg/50ml adrenaline). It is very likely that the rate is changing and as the sampling frequency goes down, then my assumption becomes less reliable.
I’d really like a way of recording an infusion rate but am struggling because (I believe) there is no facility to record a unit, and in particular a unit of mass or volume per unit time. Such units are standard concepts (e.g. mcg/kg/min http://athena.ohdsi.org/search-terms/terms/9688)
Sorry if this is really specific but this is a really common scenario in the world of anaesthesia and critical care.
@andrew: Not sure I understand your use case. Usually, in oncology, you calculate the dose and administer it fully. Unless the patient has side effects or the central line goes bad. Is that what you are after?
Not sure what to do here, @docsteveharris. If we only have a snapshot of the rate, and not the entire infusion time, we don’t know the total dose. But total dose is the thing we are interested in, are we not?
But if you are saying you want the infusion rate: Please explain the analytical use case. And then we can figure out how to reflect it.
Thanks for the update. That approach doesn’t work so well for us, because we don’t live in a world where we can assume all patients are identical for dosing purposes. So it becomes important to express doses in many cases as mg/kg or mg/m2. We could get there using the method you propose, but that looks to me like:
Look up drug_concept_id in concept.
Parse concept_name to extract what looks most like the concentration. Extra points for mixtures.
Consult measurement to find the nearest weight or BSA (or derive same).
Extract quantity from drug_exposure.
Compute effective_drug_dose
Seems like a lot of work when it was there in the source data. I think we may just be seeing differences on two fronts: pediatrics vs adults, and claims provenance vs EHR provenance. It certainly makes sense to me that if your data source is Truven or Optum or ResDAC, and you can’t rely on dosing info other than package used, and you can rely on a unit dose for most any patient, then effective_drug_dose is work you don’t need. This is potentially an easier case to address for us, since keeping it will be downwardly compatible with the canonical CDM spec.
At some point, they’ll crop up, depending on what your dbms setup is, and how much you can use things like partitioning and indexing to help you out. (For instance, if you have lots of records for the same drug that document dose changes, it may be slower to retrieve specific doses of that drug than if you had an equal number of total doses spread across more drugs.) But I’d expect that to happen in the >100M row territory on decent hardware.
This is a great question, and there’ve been discussions on and off about “flavors” of the CDM that address needs that don’t make sense for everyone, but we’re not at any kind of standard practice. In PEDSnet, what we try to do is make additions that leave us compatible with the canonical CDM (sounds like effective_drug_dose may become one of these ) so as not to interfere with logic that expects the regular CDM. Early on, we shied away from even adding columns to canonical tables, but as time has passed, we’ve become more comfortable with that; there aren’t a lot of OHDSI practices that depend on extra stuff not being there. We can sometimes add content in a similar way. For instance, drug_era records at the ingredient level aren’t adequate for some of our core use cases (where in/on the patient did that prednisone go?), but it doesn’t interfere with CDM logic to add era records based on Clinical Drug Forms (and if Clinical Dose Form Groups ever show up in the vocabulary, they’ll be even better ), because canonical logic looking for ingredient-level drug_concept_ids just won’t see them.
The harder problems, of course, are when you make choices that’re incompatible with the canonical CDM spec. To pick one we’ve been discussing recently in PEDSnet, we’ve just decided to not follow some OHDSI domain “routing” for diagnoses, because we were seeing diagnoses codes like “Elevated blood glucose” routed to measurement, and, well, they’re diagnoses not measurements, and putting them in measurement because they were a judgment about some other measurement created a bunch of problems for us. Another case is where we deploy a data element in PEDSnet and OHDSI later picks up that or a similar element (such as birth_datetime; for some historical reasons PEDSnet had first deployed that as time_of_birth). We’ll migrate over to the canonical definition over time, but it requires retooling ETL pipelines incrementally, and in the interim we’ll be non-compatible.
In these latter cases, I see best practice as being driven by the analyses you plan to do. If your goal is to be able to use tools like Achilles and Atlas, but you’re not participating in a bunch of OHDSI community studies, then your compatibility requirements are narrower. If you want to participate in studies with other folks who have OHDSI CDMs, you can agree on common extensions (this is effectively what PEDSnet does across sites), or materialize the canonical and custom versions as you note, or sometimes split the difference using tricks like views to make available the flavor with the less granular definition. This kind of analytic balance also impacts where you put new stuff: on a pragmatic level, the question may become whether it’s less pain on balance to add stuff in new columns/table and take a join when you want to get to it vs. putting it into the existing structures but not having canonical logic from elsewhere be able to deal with it.
Thanks @bailey for this detailed description, and I agree with almost everything you say. But I do want to make a plea to this comment:
" To pick one we’ve been discussing recently in PEDSnet, we’ve just decided to not follow some OHDSI domain “routing” for diagnoses, because we were seeing diagnoses codes like “Elevated blood glucose” routed to measurement, and, well, they’re diagnoses not measurements, and putting them in measurement because they were a judgment about some other measurement created a bunch of problems for us. "
If concepts don’t have a singular, unambiguous definition of what domain they belong in, then every researcher has to guess at every place that a ETLer might have chosen to put the data. I think one of the most important conventions we developed as a community in getting into OMOP CDM v5 was getting to a solution that would allow for reconciling this problem by having the vocabulary domain orientation.
Now, while I would make a passionate plea that we all try our hardest to follow one common vocabulary domain convention, I am extremely open to and would strongly encourage everyone to collaboratively participate in the discussion to determine which concepts go to which domains. And if there’s a concept that currently has a domain designation that you think is inappropriate, or could be argued against (either on clinical merits or because it interferes with your analytical use case), then please post those issues to the Vocabulary GitHub repo, so they can be properly evaluated as a collective. I think we should do this thoughtfully on a concept-by-concept basis, and should fight strongly against the notion that ICD9 codes all need to be in the condition domain just because they are put into diagnosis fields on claims records (when so many of them are very obviously not conditions).
Personally, I don’t have a strong opinion about a concept like ‘elevated blood glucose’, if you are saying that can be diagnosed clinically without a formal measurement, or if the increase in a value has a clinical meaning as a diagnosis, then I would support it being a condition occurrence. If, however, you only are observed to have ‘elevated blood glucose’ when your blood glucose is actually measured and seen to be above some nominal value, then I can understand why it would be considered a measurement. To think about an analogous situation, a clinical diagnosis of ‘Type 2 diabetes’ seems unambiguously a condition, and a HbA1c value is unambiguously a measurement…but if somehow there was an observation of ‘HbA1c > 9%’, then I can see how that may result in either a condition (for the formal diagnosis that the value represents), measurement (the for the value itself), or both.
An important postscript to my note. I made the mistake that I always yell at my team about: providing an opinion without first looking at the data!
In the version of the vocabulary that I have locally as well as the latest via ATHENA, the ICD10CM code R73 ‘Elevated blood glucose level’ maps into SNOMED as ‘Hyperglycemia’, which is in the CONDITION domain.
So, at least for that one example, I’d say that @bailey desires are currently being met by the current vocabulary. But if there are other examples that aren’t meeting others needs, please voice the concerns!
Thanks for expanding on this @Patrick_Ryan. To be clear, I agree 100% with the concept; just was feeling the length of my original post. (I also get to hear the counterargument a lot, from investigators who believe ICD-9|10 === diagnosis, but I’m willing to argue that one. ) And in fairness to the researcher, it helps less in the diagnosis domain than it might elsewere. For instance, it’s more straightforward to say that the domain routing means you’ll unambiguously be able to find that rituximab exposure in drug_exposure, whether it was ETLd in from an order, a MAR record, or a bill. It’s inherently harder to say that routing will put everyone with an MI in condition_occurrence, but if I sent a troponin, and it was elevated, that patient had an MI, whether or not I said so. So I have to code for multiple case definitions anyhow. (I understand that’s a different thing from what you’re saying; just noting the practical limitations.)
The devil, as always, is in the details. And many of the existing mappings are really valuable, unwinding as they do the tendency of ICD-10-CM and CPT to become a dumping ground for drug administration, procedures, public health, and so forth because that makes it easier to bill for things.
Yep, there’s a continuum here. It seems most natural for me to approach this from the perspective of clinical process. So for me the clinician asserting (code) ‘HbA1c >9%’ is a different phenomenon than a hypothetical lab whose analyzer hit the end pin at 9, because it’s not (necessarily) connected to a specific specimen or value or point in time. Where that assertion is coterminous with a disease, it’s easy to call it a diagnosis. If you can say ‘HbS >80%’, you may as well just say ‘Hemoglobin SS disease’. Other times I agree it’s more an observation - one elevated A1c without context does not T2DM make - but if it’s an observation about potential pathology, I’m ok leaving it in with diagnoses; I’ll just keep that condition_concept_id out of my concept set if I want to require the clinicial to have said ‘DM’. I also like the tendency over the past several revisions to shift more of this stuf into observation rather than measurement. So the bulk of what’s mapped over from ICD-9|10 to measurement are procedure codes for “we did a test”. I’m an outlier, so I still think that’s a procedure or an observation, and doesn’t become a measurement until it has a specimen and value, but that’s me. When I go to the measurement table, I’m usually asking what the result was. I’m undoubtedly biased by being a hematologist here, since in the huge majority of cases “we did a test” is spelled “we did a panel”, so that step will land in procedure_occurrence rather than measurement anyhow.
Seems like a lot of work indeed. Drug_strength helps to avoid the first 2 steps though, as it contains concentrations.
Another way to simplify it is to use Clinical Drug Form in drug_concept_id and put the total dosage in quantity. In this case, we only need to divide it by the patient’s weight in order to calculate the effective dose.
It doesn’t seem like what you want but may serve as a shortcut. I’m also thinking of putting this effective dose into quantity and ‘mg/kg/h’ into dose_unit_source_value if you don’t care much about the total dosage.
Actually, everybody I know (myself included) thinks the same As Patrick said, just share all the questionable mappings. At the end of the day, this is the natural process of refining them.
As for me, using diagnosis is a little bit more reliable. If we choose to go procedure/measurement path, the whole phenotyping needs to be done. In this example, we need to exclude trauma, myocarditis, DIC and other things that may cause troponin elevation, at which point we still need to use condition_occurrence for exclusion criteria. In my humble opinion, it’s used mainly due to the lack of patients in the original ‘condition-based’ cohort.
Condition domain doesn’t necessarily imply a diagnosis: it also can be a symptom, syndrome or any other clinical finding. From this point of view, hyperglycemia perfectly sits in conditions, as it represents a pathological symptom and is a sign of an underlying condition. It also can be an observation; observation table is sometimes considered as a trash bin though and is often neglected. Taking this into account, I’d preserve all clinically significant symptoms in condition table.
So we’re hoping to use the CDM across the hospital, but my team work in critical care and anaesthesia) hence why we hit this particular case really early on, but it is very common in our world. We will typically have patients on multiple drug infusions (sedatives and vasoactives). We are never interested in the total dose administered. The drugs all have super short half lives which is why they are administered as continuous infusions. The bedside nurse will titrate the infusion rate to response (increase the adrenaline if the mean arterial pressure (MAP) falls). Hence all our analytical use cases would expect time series data containing paired physiological measurements (MAP) and adrenaline doses as mass per unit time (usually weight standardised so mcg/kg/min).
We’d ideally sample these minute by minute but for now the measures of drug infusion rates are hand entered into the EHR every 30-60 mins.
So I can see a hacky work around where I’d record the likely average mass (dose) delivered in those 30-60 min timeblocks but I’d be assuming there were no minute by minute bedside adjustments during that interval. It would be more faithful to the situation to record the rate at whatever sampling frequency was available.
That’s also a viable idea - we discussed it in PEDSnet and landed on the convention that effective_drug_dose is the dose basis (mg/kg/dose) and quantity is the absolute dose (mg) wherever we can get to both. But that is probably more work than is needed outside the peds context.
And using drug_strength to compute concentrations is definitely a better option than parsing concept_name.
That pretty much hits the nail on the head. If use of diagnosis codes is reliable, that’s great. If it’s not, you need to try something more complex. In my experience, investigators often throw in some non-diagnosis criteria to “confirm” the diagnosis. And we all know the value of requiring repeated use of diagnosis codes.
But all this notwithstanding, I guess what I’m trying to say is just that diagnoses are inherently more complex concepts that, say giving a drug or doing a test. They may require integration of several facts, and usually involve some level of judgment call. And those judgments may later get flattened out by what’s good for billing and what’s not. So the coding for “a patient with X” in my experience, gets complex more quickly than “a patient who got X”, though there are of course many counterexamples.
Ultimately, I think we’re all agreeing in different words.
Hi Charles. Were you concerned that using quantity to record the total dose would make your version of the CDM further from the original where it has a different meaning? Was there a view point that it would be better to leave this empty in this context and use both the dose_unit_concept_id and an additional “dose_quantity” field? This feels to us like the way to proceed but not sure if we’d lose out in some other way. Thanks.
I think we may just be seeing differences on two fronts: pediatrics vs adults, and claims provenance vs EHR provenance. It certainly makes sense to me that if your data source is Truven or Optum or ResDAC, and you can’t rely on dosing info other than package used, and you can rely on a unit dose for most any patient, then effective_drug_dose is work you don’t need. This is potentially an easier case to address for us, since keeping it will be downwardly compatible with the canonical CDM spec.
+1 here.
In this discussion, we have the similar claim vs EHR balance.
) so as not to interfere with logic that expects the regular CDM. Early on, we shied away from even adding columns to canonical tables, but as time has passed, we’ve become more comfortable with that; there aren’t a lot of OHDSI practices that depend on extra stuff not being there. We can sometimes add content in a similar way. For instance, 
), because canonical logic looking for ingredient-level 
As Patrick said, just share all the questionable mappings. At the end of the day, this is the natural process of refining them.