OHDSI Home | Forums | Wiki | Github

New working group: Medical Device Working group

General
#21

Hi all,

We will not have a call this Monday due to conflicts.
In addition, this group is still in the stage of forming and organizing. Welcome to join!

Thanks,
Asiyah

#22

Hello, great talking with you at MDEpiNet Asiyah. Iā€™m also interested in joining.

#23

We had a great first call. Asiyah is in the process of scheduling future calls.

In the meantime, we need to continue defining informatics objectives and the motivating use cases that will the group will focus on.
The following broad informatics objectives were suggested on the first call.

  • Develop vocabulary and conventions for representing devices and device IDs
    SNOMED, GMDN, GUDID, etc.
  • Develop device ID data capture best practices
    Begin with a few focused device areas
  • Develop device-generated data ETL conventions
    ETL conventions to OMOP from device-generated data in MIMIC III ā€œnumericsā€ format explained here
  • Enable data-holding OHDSI member sites to meet informatics requirements for full participation in NESTcc
    To be specified as these requirements become clear

Please reply with your thoughts on the list of broad informatics objectives above.

#24

We also need to define the specific research use cases that will motivate the work on the broad informatics objectives.

Until the GitHub or Wiki for the work group is set up we should contribute our use case ideas on this thread.

Please reply with your use cases here using this format.

Goal:

Reason the goal is important:

Required device data:

#25

Hi Andrew,
Thanks for posting!
Below are the deliverables for the group after I reflected the call:

  1. Propose and conduct an OHDSI community study (means cross few hospitals) on medical devices.

  2. Produce 3 or 4 posters or talk of medical device effectiveness or safety analysis using EHR as RWE on next yearā€™s OHDSI symposium.

  3. Write a white paper or a peer-reviewed paper on the medical device data needs in various EHR systems.

The specific study, posters and white paper topic will be determined by the use cases you suggest. Please reply with your use cases.

#26

I have two particular interests, reportable events and UDI, for which I hope we can generate information.

Health care intuitions, with some minor exceptions, must report certain events under 21 CFR Part 803. Report deaths to the FDA and the manufacturer. Report serious injuries to the manufacturer. In both cases the manufacturer reports to the FDA.

It would be good if we could determine whether there were reportable events and, if so, which type. We probably canā€™t determine whether the health care institution reported the event.

For UDI, I hope we can determine the UDI-DI for each device used. A summary of UDI-DI occurrence would be fine. If we can determine a UDI-DI, then it would also be valuable to determine the associated UDI-PIs.

It would be nice if we could determine the UDI-DI for each reportable event.

A few years ago, CMS made a decision to not require the UDI. I donā€™t know the current status of the decision. It would be interesting to know if that is still the case.

#27

Hi Dan,
Can you specify from what data source youā€™d like to determine the UDI-DI for each device? I see the OMOP use SNOMED. SNOMED imports GMDN, and GUDID is mapped to GMDN. From there, you can find UDI-DI for each device. Please specify your data source and identify a specific device area to start.

I heard that CMS including UDI is on the way, perhaps in 2024?

Thanks,
Asiyah

#28

I donā€™t have a good sense for the source. Many hospitals (or at least their buying groups) were anxious for UDI. Now that it is available for most devices, I infer that hospitals now implement it at the patient level, but I donā€™t have any specific information.

There is a problem with GMDN codes because there is a one-to-many relationship to a UDI-DI. For example, a manufacturer could have multiple versions or models on the market at the same time. Each would have different UDI-DI but the same GMDN code.

Also, multiple manufacturers could have multiple versions or models with distinct UDI-DI that share a GMDN.

In addition, GUDID does not always have GMDN codes. Companies my use an FDA PT code instead of a GMDN code.

Since the initial proposal was for date from 3 or 4 hospitals, Iā€™m in hopes that they have accessible patient records with UDI-DI and UDI-PI data.

I donā€™t have a specific device area in mind. I suspect that the UDI and reportability process are independent of device area. Others in the group probably have a more specific device area in mind; any of them be of interest to me.

#29

Friends:

When talking about Devices, everybody always thinks of implantable, life-supporting or life-saving devices. These are heavily regulated, Class III and the stakes are high.

However, when collecting use cases, donā€™t forget there is a large amount of things that are also medical devices, which live much more humble lives, like glucose sticks, syringes, medical stockings, catheters.

#30

I believe the use cases should focus on more common devices rather than the more esoteric ones. The commonly used devices would generate more data, which would help the analysis.

The devices should be Class II or Class III, since all of them should have a UDI-DI. There is a question however, about how often the hospitals record the UDI-DI and UDI-PI in patient cases. It would be best if the hospitals in the study commonly use the UDI information.

Also, the device should be a ā€œproblem deviceā€. By this I mean one that generates a significant number of user facility reportable events as identified in 803.30. The frequency of reporting is different issue for which it might be hard to acquire the data.

One method to generate candidate devices would analyze the frequency of occurrence of reports by product code in the MAUDE database. This analysis would give only the denominator of the frequency of occurrence calculation. The top 10 to 25 product codes could give a good candidate list. Also, know the product code allows the analysis to determine the class and, therefore where the UDI data should be in GUDID.

#31

I analyzed (part of) the MAUDE database for 2018 to identify the most frequently occurring Product Codes and the most frequently occurring regulations.

I have the information in a Word document, but I donā€™t see how to upload it to this thread. I would appreciate some help.

#32

When you click on reply - there is an ā€œuploadā€ icon - up arrow.

#33

Found the upload arrow. Thank youMAUDE Analysis.docx (24.0 KB)

#34

Hi Asiyah, I am interested in joining this working group. Is there a specific way to sign up or does this post add me to your group?
Many thanks for your help and look forward to participating,
Kathy

1 Like
#35

@asiyahfda I am interested in joining as well.

Best,
Stephen

#36

hi @AsiyahFDA ,
Iā€™d be delighted to contribute. please let me know if youā€™ve already set up a wiki or similar
bw

#37

Iā€™d be very interested in contributing to this too. I have experience with implants for joint replacement surgery and a wider interest in novel implantable medical devices.

Thanks,
Chris

#38

I am the former FDA CDRH Associate Director of Informatics as well as former Senior Advisor for UDI Adoption in electronic health information and now work in the private sector. I would be happy to participate.
Terrie

#39

Hi @AsiyahFDA I am interested in joining this working group as well. I have experience mapping and analyzing UDI-DI data and am familiar with adoption rates and barriers at hospitals.

#40

see https://www.ohdsi.org/web/wiki/doku.php?id=projects:workgroups:devices

to track emails of interested folks, add it to the workgroup meeting notes (see link above)

t