I have a requirement from one of our project teams to record the Class of a medical device as a value.
Classes (in UK and EU) are: I, IIa, IIb, III.
Over in the ‘Medical Device’ Cluster:
We do not have a specific element for ‘Class’ in respect of UK/EU MDR or FDA (for example).
‘Product Description’ element has this description: “Identification of the medical device, preferably by a common name, a formal fully descriptive name or, if required, by class or category of device.”
but that does not really work as far as I can tell as it combines the ‘Class’ with the ‘Common Name’, so not quite right, unless there is some clever way of doing that of which I am unaware.
Another element ‘Type’ is described as 'The category or kind of device." which I was going to use for ‘Class’ but then paused and thought even that is not quite right. It may do for now though. but what if in the future they want to overlay an additional categorisation like ‘is of type joint replacement’ or ‘is of type pacemaker’ etc?
I am going to query with the project whether they really need to persist the ‘Class’ value as it is presumably coming from some reference data that could be otherwise interrogated, and I am not sure it is immutable anyway so perhaps they would then need to handle changes to ‘class’ of device in their data in the future, adding complexity.
Regardless, I wanted to ask the community for advice. Should we have a separate element for ‘Class’ of medical device or should I use an existing one, or something else?
Thanks @ian.mcnicoll, though it is also a compromise. Ideally it should be a constrained value set with the options as above, so whilst I can use ‘ID’ it is a data type of Identifier, which Class is not.
Is there a way to constrain the ID values to the Class options I, IIa, IIb, III in the template?
I seem to recall that we had many discussions about how many of the myriad, and ever changing identifiers and categorisations to model explicitly, and decided that it was never going to work neatly, which was why we left that Other Identifiers as a catch-all.
I agree about constraining the valueset, in theory yes, but it is not supported in the tools, and thinking further, this is not really an Identifier, it is really a coded Text.
Two potential non-breaking changes
Make Type multiple occurrence, recognising that there are potentially multiple types of categorisation at different levels e.g the UK example. This could be cloned in templates and given an explicit valueset.
It would solve your immediate problem.
Add Text to the Identifier as a dataype.
I prefer (1).
We could of course review the state of play across FDA, EU, Uk and others to see if there is any more clarity in the various categories - see that FHIR 5 has a few interesting ideas.
Agree I think ‘Type’ is the right concept, and right now it is 0…1 in the archetype.
Also right now all they are asking for is ‘Class’ so I can use that as is without changing the archetype’s occurrence.
Pushing future problems down the road, if they then come back asking for another ‘type’ like the categories list above then we would need to change to occurrence in the archetype. That might not be too awful though, and we can cross that bridge if and when we come to it.
If I remember rightly, at the time of the archetype review and publication it was assumed that something like ‘Class’ would be considered more administrative and a part of an external knowledgebase (ie assigned by a manufacturer).
So, given we aim for inclusiveness of all requirements, if you have a need for it, it is likely others will as well so a change request/revision may be more appropriate than ‘fudging it’. I suggest you propose an updated version of the archetype as a change request by adding the new data element for 'Class with a description and constraints and uploading it here - Medical device CRs
It would be helpful for Editorial decision-making to understand your specific use case and, most specifically, why it should be recorded within a health record. If accepted, the addition of a new data element becomes a non-breaking change.
The other thing you may like to consider is whether this might be better recorded within scope of the ‘Medical device details’ CLUSTER - CLUSTER.device_details
I will get back to the project team now I have more clarity on the modelling as, like you refer to, I wonder if they really need this data element in the clinical EHR.
They may…but we will see.
If so I will raise the CR as suggested. It does feel more like a ‘Details’ attribute than in the Medical Device cluster itself.
@heather.leslie - it is a fair point about whether class/category etc really needs to be in the record or is better handled as reference data in a ‘device ontology’. The problem there is , at least in the UK, that it just does not exist.
We did have similar issues around medication details, where in some places the drug dictionary/ontology was good enough that there was non need to record e.g. detailed substances as part of the record but this was not always the case.
So perhaps a wee optional extension cluster to record classifications might bridge the gap where necessary?
My feeling is that Class does not need to be in the EHR. It is not about the patient. But hey ho, pragmatically our project may still want this to maybe make reporting easier or something?
We will be persisting Device Name, ID, Serial and Lot number in the EHR as part of a procedure record. These things are good because clinicians and patients will be able to identify precisely which device has been implanted. We do not need ‘class’ to achieve that, and indeed class is quite abstract and definitions may change over time, and will not apply in different localities. So it becomes ‘Device class according to UK MDR as at 2023’.
Again we can do this in the data model, with changes as above perhaps, but I am not super keen on it.
As Ian says there may not be accessible reference data that does this, and maybe it will be important to the patient / clinician to understand for the future what the ‘UK MDR 2023 Class’ was at the time of the procedure in which case, sure, we should store it.
I am being led here by our medical device clinical expert from the project group (hello if you are here!) so ultimately I think we need to do what they feel is needed, but first they need to shoot down all my objections!
