Stream: europe
Topic: EUDAMED
Julien Germa (Oct 07 2020 at 13:33):
Good afternoon guys,
Does anyone know if the FHIR Device Definition enables to feed the EUDAMED db?
I am looking for a canonical format for Medical device master data and the FHIR format is interesting. Problem is that we have this big deadline coming next year with EUDAMED.
Before I do the exercise to analyze both formats to see how it matches, I wouldn't mind anyone to tell me what the official line.
BR
Julien
Giorgio Cangioli (Oct 08 2020 at 10:45):
Who can help Julien :-) ? @Hugh Glover @François Macary @Rik Smithies @Jose Costa Teixeira any suggestion ?
Jose Costa Teixeira (Oct 08 2020 at 10:59):
Hi @Julien Germa. DeviceDefinition should be expected to hold that information, because that is its purpose.
Jose Costa Teixeira (Oct 08 2020 at 10:59):
if you have the data needs from EUDAMED at hand, i'd be glad to help with matching and finding gaps
Jose Costa Teixeira (Oct 08 2020 at 11:01):
note that Device may not be the only resource you need. For EUDAMED you may need to exchange other master data such as Organization, etc. and you may need something else if you want to have a bundled "catalog" of devices
François Macary (Oct 08 2020 at 11:40):
Also, you might want to represent indications and contraindications for some DMs (e.g. implants). My understanding is that DeviceDefinition will evolve to be able to reference these as instances of ClinicalUseIssue (in R5 or R4B?). Just as it was done for medications leveraging MedicationKnowledge resource.
Rik Smithies (Oct 08 2020 at 12:13):
ClinicalUseIssue can already point at DeviceDefinition, which is the intended direction for that relationship.
François Macary (Oct 09 2020 at 08:56):
To me, it looks like the other way round is needed. If you want to express this model of device is manufactured for this purpose, these indications, and is contraindicated in these situations. How would you do that?
Jose Costa Teixeira (Oct 09 2020 at 09:05):
François Macary said:
To me, it looks like the other way round is needed. If you want to express this model of device is manufactured for this purpose, these indications, and is contraindicated in these situations. How would you do that?
with a lot of resources, it seems...
I think I agree: If the ClinicaUseIssue is supposed to represent the "abstract" condition, the relation would be the other way around.
Rik Smithies (Oct 09 2020 at 09:05):
hi François, the direction of the model is not the direction of the meaning. So it does do what you are asking already.
It is physically modelled that way around because the indications can be added to the device, as time goes by. You don't want to update the fundamental device definition when an indication is added. It is like the way patients and their conditions work. Conditions come and go, and you don't want to have them all referenced in the patient.
Jose Costa Teixeira (Oct 09 2020 at 09:06):
because the ClinicalUseIssue seems to require that you create a ClinicalUseIssue for each combination of device/condition.
Jose Costa Teixeira (Oct 09 2020 at 09:06):
(hence a lot of resources)
Jose Costa Teixeira (Oct 09 2020 at 09:08):
I understand Rik's reasoning though. I miss our CatalogEntry :sob: but perhaps clinicaluseissue has the same purpose
François Macary (Oct 09 2020 at 09:33):
Thank you @Rik Smithies . I understand that one can search on ClinicalUseIssue on subject criterion with a particular DeviceDefinition.
However I don't see yet how we could include indications and contraindications into a catalog of devices. My expectation so far, is that all the resources providing further details on the device model should be referenced by the DeviceDefinition representing this model. We'll have to give it more thoughts in the catalog project group.
Rik Smithies (Oct 09 2020 at 11:01):
Logically the device "has" indications, but in physical FHIR terms there is no special need for the reference to work in either direction. We just do it in a way that is most practical for granularity, ease of update, ownership etc (e.g. the person asserting the contra/indication - their local indication perhaps - may not have control of the device resource).
The device has indications, whether or not it points to them or is pointed at by them (or "knows" about them).
In a catalogue you just have a bunch of resources e.g.
<DeviceDefinition>
<id value="12435"/>
<deviceName>
<name value="WonderComb"/>
<type value="manufacturer-name"/>
</deviceName>
<type>
<text value="This is a hair device"/>
</type>
</DeviceDefinition>
and also
<ClinicalUseIssue>
<type value="indication"/>
<subject>
<reference value="DeviceDefinition/12345"/>
</subject>
<indication>
<diseaseSymptomProcedure>
<text value="In the UK we use recommend this for relief from painful hair"/>
</diseaseSymptomProcedure>
</indication>
</ClinicalUseIssue>
(I realise this may be what you already understand, but just don't agree with :-)
Jose Costa Teixeira (Oct 09 2020 at 12:49):
Yes, that seems the same issue. The device does not have indications. The device, in a given context, has indications. We had a resource for that but was too fuzzy and was abandoned
Julien Germa (Oct 12 2020 at 06:38):
Jose Costa Teixeira said:
Hi Julien Germa. DeviceDefinition should be expected to hold that information, because that is its purpose.
Thanks for the hints. I've briefly looked at the EUDAMED requirements and the device definition seems to cover only the UDI-Device identifier (catalog view of the product, the model) required by Eudamed. The Device is completing what is missing that is the Basic UDI-DI (labelling ecompassing UDI, Carrier, batch...)and the UDI-Product (production data) Identifier . I need to build a mapping to see how it matches and I will surely be back to have a better understanding of the meaning of the FHIR data sets. First I need to work on my data providers, I am new in my company and it looks a bit messy. I'll feed with upd when I progress
Jose Costa Teixeira (Oct 12 2020 at 09:09):
devicedefinition does include UDI (Device data)
Jose Costa Teixeira (Oct 12 2020 at 09:10):
DeviceDefinition cannot include Production identifiers because those are on instance - therefore on Device resource
Jose Costa Teixeira (Oct 12 2020 at 09:10):
Production identifiers : batch, serial...
François Macary (Oct 16 2020 at 15:16):
Coming a bit later on this subject of DeviceDefinition referencing or being referenced by ClinicalUseIssue. @Rik Smithies and @Jose Costa Teixeira
We all agree that in a catalog, devices, like drugs should be able to declare what their indications and contraindications are. In a drug formulary for instance, each drug described as an instance of MedicationKnowledge references its indications and contraindications through the administrationGuideline element. I think it should work the same way with DeviceDefinition. So I'm expecting a usageGuideline backbone element in DeviceDefinition conveying patient characteristics and indications and contraindications as CodeableReference(ClinicalUseIssue).
Rik Smithies (Oct 16 2020 at 15:29):
Hi François. You can point from DeviceDefinition to ClinicalUseIssue if you want. That method will not allow anyone to assert an indication etc about a device that already exists, or that they don't own the record of. So it's a less flexible solution, but if you want that you can ask O&O to add that, or you can add an extension.
François Macary (Oct 16 2020 at 15:31):
Thanks. I will request that change, and see how it goes.
Jose Costa Teixeira (Oct 16 2020 at 16:32):
Rik Smithies said:
That method will not allow anyone to assert an indication etc about a device that already exists, or that they don't own the record of.
This issue does not apply, because those are different resource instances
Jose Costa Teixeira (Oct 16 2020 at 16:33):
A device D1 that indication I1 , suddenly gets an indication I2 as well.
Either a new version of the Device D1 is created, or a Device D1v2 is created.
Jose Costa Teixeira (Oct 16 2020 at 16:33):
This is the way it has to work since we removed the CatalogInstance resource.
Rik Smithies (Oct 16 2020 at 16:59):
The other way it can work:
DeviceDefinition D1 has indication ClinicalUseIssue I1, which points at D1.
Later another indication comes along and you create ClinicalUseIssue I2 and point that at D1.
No need to update D1 or create D1v2.
Jose Costa Teixeira (Oct 16 2020 at 18:33):
Agree there are different ways it can work. But what we settled on (regardless of my preference) was that the current way is the intended way of working - the intent is to update the device
Jose Costa Teixeira (Oct 16 2020 at 18:34):
This is not a robust thing imo but we need others' feedback
Rik Smithies (Oct 16 2020 at 21:13):
That sounds like something an implementation guide would do, rather than core.
Why would one resource rule out a legitimate use of a different resource?
DeviceDefinition would be saying "don't use ClinicalUseIssue to point to this resource", even though that is one of the uses of ClinicalUseIssue.
Jose Costa Teixeira (Oct 16 2020 at 22:40):
I'm pointing to the core behaviour as was decided before.
ClinicalUseIssue can surely point at the device, but what we had discussed is that for catalogs, the focal resouce would be the one that contains the relationships. I didn't agree then, but that is how we rolled.
Jose Costa Teixeira (Oct 16 2020 at 22:41):
Besides, ClinicalUseIssue is fresh painted and was developed with a specific scope in mind.
We've been through that - I don't reject its use, but we should proceed with caution and openness
Rik Smithies (Oct 19 2020 at 10:31):
~"fresh painted"?
Do you mean to say that ClinicalUseIssue is new and so can be ignored? (it actually existed before DeviceDefinition :-)
~was developed with a specific scope in mind
Yes, indications for various things including devices. Why is scope an issue here? Is it not appropriate?
~I'm pointing to the core behaviour as was decided before.
What was decided and in what context?
Jose Costa Teixeira (Oct 19 2020 at 10:53):
What was decided was, to my understanding, that the catalog would contain the definitional resources - for devices, a collection of DeviceDefinition, each of these pointing to some indications/contraindications. If you change a contraindication, you change the device.
Jose Costa Teixeira (Oct 19 2020 at 10:55):
Another misunderstanding: no, I did not say it could be ignored. I am just not so sure that the way you propose the relations is the only way that it can ever work.
Jose Costa Teixeira (Oct 19 2020 at 10:55):
the decision I mentioned above was in the scope of catalogs.
Rik Smithies (Oct 19 2020 at 12:22):
But that is about catalogues.
A collection of resources is not a "catalogue", in a FHIR sense, with some meaning that changes the behaviour of the rest of FHIR (e.g. mandating a certain update pattern).
My intention was to not to propose only one way ever - although in fact there is only one documented way at the moment, as far as I know - but to push back on the idea that the current situation could not be used here, based on a ruling that I cannot see at the moment.
Jose Costa Teixeira (Oct 19 2020 at 12:37):
For drugs, I believe the current direction is as François says: we can add the indication to the MedicationKnowledge.administrationGuideline.
For Device it would be the same. Or we can change for both, but if we do, the ClinicalUseIssue becomes an authoritative resource and must be a part of the catalog (and not a contained resource, I think?)
We can discuss this in a Catalog call.
Last updated: Apr 12 2022 at 19:14 UTC
