| OHDSI Home | Forums | Wiki | Github |
Sorry to do this to you, @bailey, but this field is going to go away. Here is what you should do:
Make sense?
@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:
drug_concept_id in concept.concept_name to extract what looks most like the concentration. Extra points for mixtures.measurement to find the nearest weight or BSA (or derive same).quantity from drug_exposure.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.
Hi Christian.
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.
Friends: So, after all that conversation I think we can crystallize the points this debate frazzled into:
So: Please keep bringing it on, and we will make the CDM better.
In the short term, we thought it better to put it into the canonical fields, since it’s not generally possible to study dose otherwise. Still discussing possible long-term solutions as @Christian_Reich mentioned; we’ll get there.
@Christian_Reich : Others should correct me if this is off base, but I think that it is quite common for infusions to result in unused portions of vials. The amounts are calculated by body weight and the vial units are large enough that the discarded proportion in the last vial is significant. The routine discard of unused portions of vials is common enough to have led to studies and calls for policy changes that will prevent waste: https://www.bmj.com/content/352/bmj.i788
So error in a dose response analysis would come from an attribution based on the assumption of complete infusion.
Well, that’s an old discussion and it has been quiet for three years, but I want to stir it up a little bit now.
As a critical care doctor myself I understand @docsteveharris 's pain with continuous infusion of inotropes and pressors and its representation in OMOP CDM. From the clinical point of view, it doesn’t really matter for me if my patient is on 0,11 mcg/kg/hr epinephrine infusion or 0,13 mcg/kg/hr, as long as I know that the rate is not more than, let’s say, 0,15 mcg/kg/hr epinephrine. The same is for other inotropes, pressors, and prostaglandins with a specific dose range for each drug. And, genuinely speaking, there aren’t many drugs that require the calculation of infusion rates.
I want to propose a simple solution for @docsteveharris 's case: introduction the concepts of low-dose, medium-dose, and high-dose inotropic and vasopressor support, defined somehow like:
We can make the gradation more specific if needed (each 0,05 mcg/kg/min eg.)
According to this solution, during the ETL process, all you need is to calculate how much support your patient got on that day and write the corresponding concept_id into the Observation table. I think this solution pretty much fits into the current CDM and allows to solve the problem (at least temporarily) with help of standardized vocabularies.
Sorry again for touching old wounds Please correct me if I am missing something.
Hello,
has there been any progress on this? Dr. Harris, how did you end up doing it? Asking the question now as the CHoRUS consortium is trying to line up their approach to the representing of drug infusions, a major domain of critical care delivery.