OHDSI Home | Forums | Wiki | Github

Adding manufacturer and model information to the device_exposure table

CDM Builders
#1

Hi all,

I am working on a Hearing Health project, for which we aim to use the OMOP CDM. Data will mostly include audiograms, appointments, and hearing devices.

When looking at converting the device data to OMOP, we are wondering what is the best way to add details about the manufacturer and model of the device, and ideally have a unique ID for each manufacturer/model combination. I have noticed a unique_device_ID field, but this says it is for FDA-approved device IDs only. This is clearly not suitable for our UK NHS data, as these hearing devices will not be FDA-approved

If anybody has any advice on how we could describe device manufacturers/models for UK NHS Hearing aids, that would be much appreciated. Should we add our own extra fields locally? Or perhaps request new fields be added to the device_exposure table?

An example of such a device would be:

Device Type: Hearing Aid
Manufacturer: UNIVERSAL
Model: Spirit Zest Power

Thanks in advance for any advice

#2

The unique_device_ID field is not limited to US FDA. It is intended for the UDI (Unique Device Identification). Many regulatory regions have UDI systems, the biggest of which are the US and the EU. The EU system is part of the Medical Device Regulation, MDR. In the EU, the EUDAMED database carries the UDI information.

The manufacturer assigns the UDI-DI following the rules of a company recognized for this purpose. In the US there are three companies and in the EU there are four. The most commonly used company is GS1.

The UDI encodes the manufacturer’s identity and the model of the device. It would be a rare case in which the UDI-DI for a given manufacturer and model changes by regulatory region.

The UK, post Brexit, is in a transition period, but will not create a new UDI system, but may create a new database to store the information.

There are rules, by regulatory region, to create a new UDI-DI for device changes.

The best approach is to capture the UDI-DI on the device, because it will be the same for all regulatory regions. Using it as a key to obtain device attributes depends on the database available. If there is one available in the UK use it. If not, use EUDAMED in the EU. If it is not there, use Access GUDID in the US.

One issue is that the databases require different information for the same UDI-DI. As an example, Access GUDID requires either the GMDN code or the FDA PT code. EUDAMED requires the EMDN code.

#3

Add needed fields locally. I will create a git issue about the ‘unique_device_id’ being limited to FDA approved devices since the CDM Workgroup wants to make the CDM non-country specific.

#4

I recommend you do not take this approach. The unique_device_id should contain the UDI-DI, which is an attribute of the device, not the regulatory region. If the same device were sold in the US, EU, UK, Canada, etc. it would have the same UDI-DI in these locations.

If the documentation says the field is US only, then that is the error to fix.

The full UDI includes both the devices identifier, DI, and applicable production identifiers such as serial number, model number, expiration date, etc.

A few years ago there was an issue about the field size. Apparently, it is too short to contain the longest possible full UDI – UDI-DI and all the production identifiers. I don’t know if that is fixed. In addition, I think the issue was raised before the EU added a fourth company to issue UDIs, so it should be rechecked.

#5

I change my response to agree with @doleary. He knows a lot more about device identifiers than I do. I will update the issue I created to reference this discussion.

In v5.4 the unique_device_id is varchar(255), it was varchar(50) in CDM v5.3.

#6

If you need somewhere to save the details of the device, but don’t need it to be recognized in OHDSI tools, you can put it in the device_exposure.device_source_value. I often - particularly when developing the ETL code use this field to contain a formatted representation of the source and its value. For example in capturing Emergency Medical Service (EMS) defibrillator data the device_source_value is expanded to VARCHAR(1024) and the following is saved as a dot-format ID: ...<s/n>.<procedure/transaction GUID>

ex “Zoll Medical.M Series ™ Defibrillator.80,07.11223344.20090724120202_00030004”

Its a work around but I found it helpful when debugging ETLs and grouping measurements/observations to the GUID or looking at what manufacturers were involved, which models, etc in a large national trial of many EMS agencies and devices involved.

How to record non-regulated device details in CDM 6.0?
#7

Many thanks for your response. Although the ideal scenario would be separate variables for concepts ike ‘model’ and ‘manufacturer’, this looks like a good workaround that would still allow this information to be retrievable by end-users of the data (researchers).

#8

To encode the device manufacturer and model, you should use the Unique Device Identification, UDI… One component is the Device Identifier, UDI-DI, which encodes the device manufacturer and model. It is the key to large amount of device information publicly available in the ACCESS GUDID database.

The FDA requires that the device manufacturer have the UDI-DI on every device, label, or package in both machine readable and human readable form.

#9

@mkwong & @georgetilston
Have you come across any examples where a separate table had been used to represent a set of attribute-values for each device attribute? Or is adding a string of “formatted representation of attribute and value in device_exposure.device_source_value” the current utilized approach?

I am designing a data model for a clinical trial where we need to save extra details about non-regulated user devices (mobile phones and personal cameras). I am looking for some examples how such data had been modeled by others.

t