OHDSI Home | Forums | Wiki | Github

Mapping Transfusion Data

I have a question about blood products. I’m looking at our transfusion data and we can order “Packed Red Blood Cells”, “Platelets”, “Plasma”, etc. What domain would people suggest this information be placed? We have the start and end time for the transfusion, so I was thinking drug. @Christian_Reich what do you think?

@cukarthik:

They should be DEVICES. They are not drug because they are not exerting a biochemical effect on the body. But it is an entity used in treating condition. We’ll fix the other ones as well.

Hi Christian -

I am working with Karthik on the blood product mapping exercise. If we use USAGI to help MAP to the DEVICE domain, there is not an obvious choice for, say, “Packed Red Blood Cells” as Karthik mentions above. There are many concepts that classify objects that help collect blood or deliver blood, but I don’t see anything within the class of blood? Perhaps I am just missing it. Any help would be greatly appreciated.

Thanks
David

@dblatt:

Hang on, there.

  1. If you are talking about the existing HCPCS etc having the wrong domain, they will be fixed in the next vocabulary release (as soon as we have them all figured out).
  2. If you are talking about adding the ISBT codes: We will add them to the vocabulary (also in the next release).

You should do nothing, sit in the armchair and relax for now. :slight_smile:

@Christian_Reich I’m not sure blood products should be classified as Devices based on this premise they are not exerting a biochemical effect. I might argue that they exert significant biochemical effects, since you can get life-threatening transfusion reactions from blood products and many clotting factors or products like IVIG used in treatments are derived from plasma component of blood.

@bailey I heard you’re a Heme/Onc attending, any thoughts on this?

@rchen:

Philosophically, I can agree with you. And also disagree. But it’s not important. It’s very pragmatic: We can’t put them into Drugs, because RxNorm defines for us what that is. And blood components are not.

So, Devices? :slight_smile:

BTW: Those are drugs. Whole blood, packed cells, platelets, and red blood cells are Devices.

I see the problem with RxNorm. The counter-problem (apart @rchen’s observation about the pharmacodynamics of blood products) is that unlike most devices, blood products have a dose (in units not necessarily of, well, units). They also have a route, but that’s a bit peripheral, as it’s for all practical purposes intravenous in nearly all cases. So that makes them more drug-like. They don’t have some OHDSI drug-like characteristics such as refills, or eras in the same sense as many long-term meds, but they share that characteristic with a number of acute-care drugs.

All of this is to say that I don’t have a good general answer to the problem. Conceptually, I want to put them in the same group as LVPs like IV fluids, but for the RxNorm problem. Perhaps a candidate for a future proposal as an OHDIS RxNorm extension?

As I am dealing with transfusion data today, I am wondering whether a consensus was reached over the past year and a half.

The consensus is that transfusions are in the Device Domain. It’s not perfect. And the proposal to add a unit_concept_id to the Device table needs to be put through.

I would also disagree (as a transfusion medicine attending) with the reasoning of “They should be DEVICES. They are not drug because they are not exerting a biochemical effect on the body. But it is an entity used in treating condition.”, especially when comparing to blood-derived products (factors, IVIG, albumin).

While I can understand a mapping argument based on the RxNorm aspect for medications, I think taking that narrow of an approach to classification is flawed. Extending the device table to include units seems far more complex and unnecessary, and, at least in the US, medical devices should be getting UDIs (while biologics/medications do not). So from a regulatory perspective–blood products would not be devices. As there is no standardized vocabulary within OMOP with support for blood products, not sure why the above is being seen as consensus, especially with the limited discussion available in the forums.

I’m not making an argument for or against blood transfusion products living in the Drug vs Device domain. This is what we do with our data to support observational research.

Colorado uses the unit # for the Unique Device Identifier

And we have transfusion data recorded with the ISBT vocabulary.

@wschulz:

Look: You are totally right on principle. Obviously, just like a drug, a red blood cell transfusion is administered through a parenteral route and, quite similar to erythropoetin, will increase the hemoglobin. We know that.

The reason we pushed it into Device is entirely pragmatic: The transfusions don’t fit into the hierarchical logic of the Drug Domain. It assumes a very distinct set of attributes: ingredient, strength, form, brand name, packaging, manufacturer. Transfusions really only have packaging, in single units, and if you really stretch it they have form = solution for infusion. Ugly.

We are very pedantic with this logic, because it is the only thing holding the Drug Domain together across international markets. So, “drugs” that don’t have those features really don’t fit into the system.

The alternative to device would be to add a new Domain, like “Biological Product”. It would also contain artificial tissues and those kinds of things. I think that’s where it will ultimately end up, but right now nobody has the urgency to start modeling that out.

Makes sense?

@MPhilofsky This wasn’t oriented at how to potentially populate fields, but rather an argument against the logic that ontology should always drive classification/categorization. One of the above arguments is that RxNorm defines medication, blood products don’t have RxNorm, therefore they aren’t meds. This is a similar argument – while you could use the donor # to fill in the UDI field, it is not a UDI, therefore blood products are not devices. Similarly, while ISBT is the vocabulary to use (and has currently been marked as ‘device’), the typical approach of RxNorm = Med / SNOMED = everything else means that logic can’t be used to classify everything in the data model.

As for exerting biologic effect, it was @Christian_Reich who previously stated blood products are devices as they exert no biologic effect, which I also argue is not correct (although it appears that argument has now changed). Also, while transfusions only have packaging, the volumes/dose and number of ‘units’ (eg, single donor vs pooled) do vary (as does the ‘manufacturer’, based on which agency blood products are obtained from, such as ARC vs NYBC).

I agree there are several fields in the drug domain that don’t apply to transfusions (eg, refills), but this would simply mean that a minority of drug entries would have null values for those fields, as compared to placing into the device domain and extending that to support information like volume and units of measure, which would end up resulting in a majority of devices having null values for those fields.

Whether, where, and to what level of detail we would want transfusion information logged within OMOP I believe is up to discussion, but would hope for some discussion on it rather than basing it on potentially untrue assumptions or limited use cases.

@wschulz:

Be nice to us. Look. This is not straightforward, and we have spend many cycles getting to the best solution. And we need to be supportive of each other’s use cases and needs:

Currently, our definitions are as following:

A transfusion is in essence a transplantation, where the transplanted tissue is blood or a derived product. Happens to be as easy to transplant blood as applying a parenteral drug. But it is still a biological product, not a pharmaceutical. And tissues are devices by the above definition. Not all devices have an UDI. In fact, not a whole lot have.

None of the attributes apply to transfusions. There are no ingredients, no form (unless you want to call blood “solution for injection” and no strength - all fundamental defining attributes for a drug.

Do you have a use case in mind that would be thwarted by the current approach?

Just resurfacing this discussion since the topic of how to handle transfusion data has come up on a project that myself, @Wilson_Pace and @wschulz are a part of - REDS-IV project. One of the products of this project is to create a vein-to-vein database, which will have both donor and recipient blood information, so I envision some extension off of OMOP to accommodate the program’s needs.
Currently, the scientific committee is designing studies they would like to run and pediatric cases are a focus, so as a simple example there is a need for units that are not integers in the device table. I’m all for reusing tables, but it kind of feels like in both cases we are trying to fit a square block into a round hole. Again, I’m don’t have the clinical background to speak to the philosophy of where a data element belongs, but for transfusions we will need

and extending the device table seems extraneous and confusing to me from an approachability point of view.

Currently, there is an informatics working group in REDS-IV discussion some of these topics, but it might be nice to include some other OHDSI members who are doing transfusion related work so that we are all in alignment. Do I dare suggest another OHDSI working group :zipper_mouth_face:? Or maybe we can get on a call and hash out a solution that fits everyone. I’m not too familiar with the new tables proposed in the oncology tables, but I’ll look into those as well…

@cukarthik:

Sure, bring it on. Happy to find somebody or play myself. I think the unit is already ratified to accommodate this need.

Have we settled the convention for transfusion data in OMOP-CDM?

Not yet. Do you need that for Covid?

@Christian_Reich I found unmapped transfusion code in Korean EDI vocabulary, while I’m mapping unmapped EDI code in the COVID-19 dataset. Currently, I don’t have any use case related with transfusion for COVID-19 research.

t