Stream: implementers
Topic: DeviceDefinition
Hans Buitendijk (Jun 29 2018 at 21:27):
During the recent OO-HCD discussions on Device "blended" (one resource, multiple meanings - represents an actual device, or the definition of a device) or "split (DeviceDefinition and Device), the conclusion was to pursue a split. Attached is an initial outline what such a split would look like. This would further enable use cases that focus on device definitions (e.g., catalogs) and where further details on capabilities are relevant.
Live discussions are occurring Tuesday's, 9-10 EDT using the HL7 FCC ord coordinates (see https://www.hl7.org/concalls/CallDetails.aspx?concall=40881). Any input/participation welcomed.
DeviceDefinition.xlsx
Grahame Grieve (Jun 29 2018 at 21:58):
I feel as though DeviceDefinition vs Device isn't quite the same as class vs instance. I can talk about DeviceDefinition as a definition of a class of device just as I can talk about the device definition of an instance of a device
John Silva (Jun 30 2018 at 11:25):
Just at a quick glance -- the DeviceDefinition as shown on the spreadsheet has UDI info (optional though) so that hints that it could be either a Kind of device (an SpO2 plugin) or a specific instance of a device (with a unique UDI ID for traceability). It seems like the same can be said about the Device -- it seems to have an optional UDI, which could mean that it can hold either a Kind of device (e.g. patient monitor) or an instance of a patient monitor (e.g. Philips MX50, UDI number 1234567). Without being involved in this discussion I assume this analysis is referencing the IEEE 11073 model and it's use in the IHE PCD profiles?
Stefan Karl (Jul 02 2018 at 08:26):
Separating "kind" and "instance" elements into two resources serves the needs for use cases where you have many instances of the same kind. For the simple case, e. g. reporting device data, you always need both together. Removing "kind" elements makes the Device resource always dependent on a DeviceDefinition resource. A client that creates a Device resource needs to add a DeviceDefinition or find out if it already exists on the server. An application using device data from a server has to make chained search, resolve references, and retrieve resources at one more level of indirection. All doable, but not as simple as it should be.
I'd prefer a solution that keeps everything at Device to represent an actual device or device component (with "kind" and "instance" elements) and make DeviceDefinition an additional resource. As everything is optional at Device it can still be used as an instance-only resource pointing to a DeviceDefinition.
Stefan Karl (Jul 02 2018 at 08:27):
@John Silva No, the ISO/IEEE 11073 DIM does not separate kind and instance attributes.
Jose Costa Teixeira (Jul 02 2018 at 08:29):
True. However if an implementer starts duplicating data (using a device for instance and also putting there some definition) they may be creating inconsistencies, right?
Jose Costa Teixeira (Jul 02 2018 at 08:31):
One thing is to define a device and its characteristics ; another slightly different is to indicate a few characteristics of a device that you want to order (without intending that this becomes a formal definition of the device). But to indicate that you have an instance that you may not even be able to define, that seems quite different.
Jose Costa Teixeira (Jul 02 2018 at 08:39):
I guess the choice is: even if it is slightly more work to design it (split data in two resources is not hard) but make it better in operations. Once you split, I believe interoperability becomes easier -systems will a) always know whether the entry is a physical item and as such consider inventory aspects; b) when scanning items they don't really need to know their formal definition - it can be done downstream ; c) it becomes better to say things like "I have in my ward stock the following devices of type BioGadget, brand Acmed, and the serial numbers/mfg dates are X, y, z"
Stefan Karl (Jul 02 2018 at 10:49):
Inconsistencies may also occur when multiple devices report their DeviceDefinitions independently.
The additional resource makes all sense for specific use cases that you mentioned. And DeviceDefinition is always about a kind of device, while Device is about a physical instance. The question remains whether we really want to add the burden of creating, storing, and retrieving two resources for an actual device instance when separating the elements is not needed.
Lloyd McKenzie (Jul 02 2018 at 11:03):
I don't see how the split helps. You're going to have to allow both choices everywhere, so you're really just moving the complexity around. What might be better is a single resource but with a profile that constrains out the "instance" elements that implementers can leverage if they want to enforce that references are "kind".
Jose Costa Teixeira (Jul 02 2018 at 14:06):
We need something (beyond the presence of a few attributes) that tells whether we are expressing a kind or an instance
Lloyd McKenzie (Jul 02 2018 at 14:06):
Why?
Jose Costa Teixeira (Jul 02 2018 at 14:07):
We don't need to create and maintain the instance resource
Lloyd McKenzie (Jul 02 2018 at 14:08):
I don't understand
Hans Buitendijk (Jul 02 2018 at 17:58):
The rationale for having a DeviceDefinition is to be able to support a number catalog/ordering/logistics related use cases where the actual device is not relevant.
Regarding @Stefan Karl concern around inconsistencies when DeviceDefinition is separate, there are similar concerns when data is copied across all devices of the same kind/class.
Regarding @Lloyd McKenzie question on "why", I'd like to equally understand "why not". The same rationale why it is relevant to know the difference between an Observation and ObservationDefinition, Specimen vs. SpecimenDefinition, CarePlan vs. PlanDefinition applies here. Perhaps your use cases are limited where you only care about the actual device and a very small set of the device definition's attributes, but not being able to distinguish between a resource instance representing an actual device (as fuzzy as the data about that may be) or a resource instance representing the definition or kind/class of a device and relevant attributes makes it challenging. Absence of a serial/lot/etc. number does not make a resource instance a definition of a device (e.g., implantable device that the patient indicates they have, but no idea what those identifiers are).
Lloyd McKenzie (Jul 02 2018 at 18:05):
Why not = lots of systems don't distinguish, maintain both using a single table and freely change from one to the other by adding and removing metadata. We will need to be able to reference kinds, qualified kinds (some instance from lot X) and instances at both the ordering and performance level. So splitting is adding complexity rather than removing it.
It's not clear why the catalog/ordering/logistics use cases can't be met with a single combined resource - possibly with a profile constraining out certain elements.
Jose Costa Teixeira (Jul 02 2018 at 22:13):
My experience tells me that systems which don't distinguish have issues in traceability. Especially when something was not traceable and becomes lot-traceable or serial-traceable. I can understand the idea of normalising these things but they are different concepts. It is not really the same to say "a MaxFlow stent" or "one unit of a MaxFlow stent, whether we know the lot number or not" IMO this is one of the cases where legacy is not a good driver. Industry is being pushed hard to change practices and readiness, we should not be lagging there.
Jose Costa Teixeira (Jul 02 2018 at 22:16):
" We will need to be able to reference kinds, qualified kinds (some instance from lot X) and instances at both the ordering and performance level." Is a good argument, but those things have different meanings - if you are referring to a specific lot or serial number when you order, then you are already aware of the existence of physical items (calling it inventory for now)
Jose Costa Teixeira (Jul 02 2018 at 22:20):
It was some time ago that we checked that we needed some differentiation between Kind And Instance (San Diego?) At the time the discussion was not focused on a solution, only that we should have something. I think I recall that we had this differentiation in the RIM.
Jose Costa Teixeira (Jul 02 2018 at 22:28):
(I am looking at why would this split mean complexity.). There may be another solution but we should be able to expose this option and see it working (or learn from where it doesn't).
I think we should make the example cases clear - not only the ordering (trivial but plagued with legacy) but inventory counting, differentiating consumption Vs usage...
Lloyd McKenzie (Jul 02 2018 at 23:13):
It doesn't really matter whether they're different concepts if existing systems don't differentiate. Remember that the resources aren't driven by modeling purity, they're driven by existing practice. In the end, you know that what will be supplied/used will be a physical instance. But how precisely that gets specified, will vary. Multiple resources means complexity. Switching from one resource to another when you populate an element that wasn't previously populated means more complexity. And I'm not hearing a use-case where implementers are saying the current single-resource solution is broken.
John Silva (Jul 03 2018 at 11:14):
@Lloyd McKenzie -- "And I'm not hearing a use-case where implementers are saying the current single-resource solution is broken."
I, as an implementer, was saying it was broken for Medication for the same reasons 'Kind vs instance'. It looks like the same issues arise with Devices. Also, from a practical point of view, imagine a real-world use case of having to track down all patients who used a specific piece of equipment (by UDI) that was recalled; with the mixed-bag of Kind devices (in FHIR server) and instance devices the search is also going to be much less efficient. The same thing happens for Medications -- if a drug batch/lot has a problem, trying to search for all Medications from that particular lot and then trying to trace back patients affected by it is not efficient either (though that's because the Medication resource doesn't have a patient reference and partially because many/most Medications are Kinds not instances, or you really can't tell because there isn't a patient or subject reference.)
Lloyd McKenzie (Jul 03 2018 at 12:37):
I don't understand the issue. If systems track serial number or lot, then you can do a search by those things. If they don't, you can't. Whether we use a separate resource for meds with lot numbers or devices with serial numbers has no bearing on that. FHIR is not going to change existing business practices. If you didn't track lot number before you started using FHIR, you're not going to start tracking it because you're using FHIR.
Lloyd McKenzie (Jul 03 2018 at 12:38):
The issue you were expressing John was around v2 conversion. That's not impacted by one resource vs. two resources at all that I can see...
John Silva (Jul 03 2018 at 15:48):
The problem I'm talking about is not V2 vs something else; nor is it about FHIR changing business practices. Either the source system has this info (lot/serial number - V2 or other) or it doesn't. The problem is about how to do efficient searches on a FHIR server to get back the list of affected patients? (Not all, if any, FHIR clients are able to control/influence how the FHIR servers they use implement search index optimization so these kinds of queries can be problematic. I suppose FHIR (and HL7) is not about implementations but about protocols/specs, but at some point the real world implementations come into play.)
John Silva (Jul 03 2018 at 15:59):
How about a simple property, kind (with a FHIR-spec'd value set)? During the workflow the source system (whether an ordering system, an inventory system, a dispensing system or a 'tracking system (e.g. MAR) knows if what it's specifying is a Kind or an instance; why not let this be known in the FHIR resource? (maybe this is too simplistic but just wanted to throw this out there to get some discussion about it.)
Jose Costa Teixeira (Jul 03 2018 at 16:03):
We had looked at this as an option but after several discussions we are leaning to this separation.
Lloyd McKenzie (Jul 03 2018 at 16:20):
Having a kind vs instance flag wouldn't make searching any easier. If there's a lot number on the Medication for a dispense it's pretty easy to query to find all patients who have medication dispenses that referenced that lot number
Lloyd McKenzie (Jul 03 2018 at 16:20):
No need to split into kind vs. instance resources to do that.
Hans Buitendijk (Jul 03 2018 at 16:28):
You assume presence/absence of serial number or lot number means instance vs. kind/definition/knowledge. That's just not true. An implantable device reported by a patient is an instance (it's in their body), but don't expect such record to have any identifying information. That is only likely to be present when the device instance is recorded as part of the surgery documentation. And having to go after serial number or lot number or or or, does not seem hepful as well. I'm still not clear why in other cases it is perfectly o.k. to split and avoid this problems, and in this case where similar use variations exist (although perhaps most implementers only deal with instances and need a few bits of definitional data) is such a concern. Reference(xyz) is done all over the place. Keep in mind also we are dealing with a communication model, not a prescribed data storage requirement (unless you want to persist FHIR resources and syncing copied data with original source data will start to create some confusion/ambiguity). This is not about modeling purity, but looking a bit further beyond "today".
Jose Costa Teixeira (Jul 03 2018 at 16:28):
Agree, flag does not help in search
Jose Costa Teixeira (Jul 03 2018 at 16:30):
And we should welcome use cases that challenge some of the current practices which simply have not a lot of concern for traceability.
Jose Costa Teixeira (Jul 03 2018 at 16:32):
traceability must be built in by this kind of mechanisms, otherwise we end up with programs to implement traceability on top of systems that do not exchange clearly articulated information
Lloyd McKenzie (Jul 03 2018 at 16:33):
If you don't have a serial number or other unique (non resource id) identifier in the instance, kind vs. instance won't help. If you have such an identifier, the kind vs. instance split is unnecessary.
Lloyd McKenzie (Jul 03 2018 at 16:35):
You can't have multiple resource instances with identical data that only differ by resource id because no-one will be able to tell them apart or know which resource instance represents which real-world thing. The electronic record needs to have some piece of data that corresponds to the unique physical instance in order to disambiguate. And if the resource has that, distinguishing kind vs. instance doesn't add anything.
Hans Buitendijk (Jul 03 2018 at 16:36):
Actually, one can still describe the presence of something. But I really need to ask again what your definition is of "definition", "knowledge", "kind", and "instance" and where that is documented, plus why that same logic is not applied to all the other places.
Hans Buitendijk (Jul 03 2018 at 16:36):
So far it sounds like a farily arbitrary delineation being pursued.
Lloyd McKenzie (Jul 03 2018 at 16:37):
The patterns reflect how implementers implement. Protocols are maintained separately from orders which are maintained separately from events. As well, the data elements on them are quite different. On the other hand, kind and instance are typically munged together in the same table and captured and manipulated using the same user interfaces.
Todd Cooper (Jul 03 2018 at 16:37):
On a side note ... I can't tell you how much it warms my heart to have so many people weighing in on a device informatics topic - fantastic!
Lloyd McKenzie (Jul 03 2018 at 16:39):
If it was the case that implementers managed medication kinds and instances (or device kinds and instances) in completely separate tables and used different UIs for them, then we would almost certainly have distinct patterns for each.
Jose Costa Teixeira (Jul 03 2018 at 16:53):
Not advocating at all for separate UI
Lloyd McKenzie (Jul 03 2018 at 16:56):
The point is that if implementers don't separate them, we shouldn't have separate resources
Jose Costa Teixeira (Jul 03 2018 at 17:11):
Implementers that need basic ordering workflows will not even worry about instance. Those are not the information models we should base on. Imo, this is not about perfection of the model, but avoiding to model ourselves in information models that are for a reduced scope, or have limitations.
Lloyd McKenzie (Jul 03 2018 at 18:49):
FHIR designs for existing implementations, not for some future "desired state". Also, it's not clear how the existing model will prohibit the sort of functionality that might be needed in future use-cases.
Erik Moll (Jul 04 2018 at 09:28):
FHIR designs for existing implementations, not for some future "desired state". Also, it's not clear how the existing model will prohibit the sort of functionality that might be needed in future use-cases.
I fully agree: the existing Device resource can be used for all use cases discussed in this stream.
IMHO it is only the absence or presence of a unique identifier that distinguishes a DeviceDefinition from a DeviceInstance. All other attributes could / should be present on both sides.
For example, a physician / ward supervisor may need Blood Pressure cuffs, but does not care about the brand, nor about the position it will be used on (upper-arm, wrist, ...). A nurse may further specify that to be of the upper-arm type suitable for adults and request an order. A purchaser may request information from suppliers that fill in brand and type. And when the order is made an assistant fills in brand and model number . The supplier may fill in the UDI DI part and even production lot / production dates. When the ordered batch arrives administrative staff may register each individual cuff in an inventory system.
In these steps, more and more attributes get values in the used FHIR resource.
For all these steps, the current Device resource can be used perfectly well; splitting it in two doesn't make this any easier.
Only in the last step, when the serial number, the full UDI information, and maybe other unique identifiers are added the resource needs to be a DeviceInstance and a DeviceDefinition resource cannot be used. Following this thinking, this would mean that DeviceInstance would ONLY contain identifiers that are unique for the instance and nothing else. This would probably not work well in practice in most other use cases as for all other use cases two resources would be needed.
Adding back all attributes to DeviceInstance as well to support other use case more efficiently , makes the whole split superfluous.
John Silva (Jul 04 2018 at 12:01):
If you don't have a serial number or other unique (non resource id) identifier in the instance, kind vs. instance won't help. If you have such an identifier, the kind vs. instance split is unnecessary.
Exactly the reason WHY I asked for Medication to have an identifier property (at least Device does) !! As @Hans Buitendijk mentioned, there are definitely examples of when something refers to an instance even if it doesn't have a lot or serial number.
John Silva (Jul 04 2018 at 12:05):
If it was the case that implementers managed medication kinds and instances (or device kinds and instances) in completely separate tables and used different UIs for them, then we would almost certainly have distinct patterns for each.
When my PCP (Primary Care Physician) orders some med for me in many cases its a 'Kind' order; that's on his own 'office system' (or paper) but the CVS Drug store that fills my prescription has a completely separate "formulary" of drug 'instances' that they use to fill my prescription. If I went down the street to a WalGreen they would have a completely different "formulary" and my same ordered drug (kind) could be filled by a different manufacturer's drug, therefore have a completely different NDC code (and obviously lot # and serial number if it happened to be a drug that was tracked, e.g. controlled substance).
Lloyd McKenzie (Jul 04 2018 at 13:29):
Adding Medication.identifier is only useful if systems actually have one - and they don't. It doesn't exist in v2 either. Adding an identifier to the resource only makes sense if the physical medication actually has an identifier. If it's just something that gets made up by the system, there'll be no way to correlate it against the real world.
The pharmacy will certainly give you an instance, but their formulary isn't instances. Their inventory might be inventory of instances, but typically it's an inventory of package instances, not medication instances. And those packages won't have identifiers unless they have serial numbers.
Jose Costa Teixeira (Jul 04 2018 at 14:03):
@Erik Moll 'only the absence or presence of a unique identifier that distinguishes a DeviceDefinition from a DeviceInstance' - actually no. If someone takes an item that is not serial-traceable from a shelf and gives it to a patient, that is an instance. It may not be a uniquely identifiable instance, but is still one.
Jose Costa Teixeira (Jul 04 2018 at 14:06):
'DeviceInstance' contains the information associated with an instance. For example you can have two instruments that are used in different operating rooms. They will be two instance resources, linked to a unique location but without an ID
Lloyd McKenzie (Jul 04 2018 at 14:20):
If they don't have a unique id, you can't disambiguate them when you query and thus you can't know which one to link to. It's obvious that if you are supplying or using a device, you're using an instance. But that doesn't mean that the record that describes the device represents a unique instance. In order to represent a unique instance, the record would have to contain property information that is specific to that one physical instance.
Jose Costa Teixeira (Jul 04 2018 at 15:02):
Indeed, if you want to distinguish two instances there must be some unique information.
Jose Costa Teixeira (Jul 04 2018 at 15:04):
A record can represent one single instance even if that instance is not univocally resolvable. So you don't need a unique ID to indicate an instance (that was the point I was addressing)
Lloyd McKenzie (Jul 04 2018 at 15:19):
Indicating an instance is redundant though. If you say you're dispensing and you just specify a CodeableConcept and don't even have a Medication resource, you still know you're dispensing instances. You don't need to point to a different code to say "I'm dispensing amoxocillin instances" rather than "I'm dispensing amoxocillin kind". So why would we need a flag if we're using the Medication resource (or Device resource) instead of CodeableConcept?
John Silva (Jul 04 2018 at 15:24):
Imagine that the
John Silva (Jul 04 2018 at 15:37):
Imagine that the "dispense message" (or API call) to the med dispensing machine only provides an unlock code for the nurse to open the specific draw containing a number of instances of the prescribed med; in this case the dispense is still a (qualified) kind! Imagine too that the nurse took out an instance (with a barcode that represented the serial number of the specific drug, e.g. a controlled substance), but "lost that drug" (either honestly or elsewise) -- then there could be yet another instance that was actually given to the patient that is recorded in the Med Admin (again maybe using the barcode of the new drug instance).
Another thing to think about --- the drug 'catalog' in the formulary could represent all those orerable drugs (I'm thinking inpatient) that the CMO and CPO (Chief Pharmacist?) have qualified as set of drugs from a drug database (e.g. First Data DB) and those are the set of drugs allowed to be ordered at that institution. When the physician orders a drug using the CPOE they are choosing a Kind of drug but from the perspective of the CPOE and the formulary that corresponds to an instance of that (kind) in the drug database, e.g. a unique GUID that references it in the formulary. Even if the formulary did not or does not keep track of inventory, per-se, it still knows the kinds of drugs that the institution has deemed to be useful for their care practice. Imagine now that there is a mobile PIS app written using FHIR, that now needs to reference the specific formulary "instance"; it needs that same unique identifier to point back to what the formulary has. (That formulary 'instance' could have a set of orderable formulations from different manufacturers as price and availability dictates.)
John Silva (Jul 04 2018 at 15:41):
I would also be curious to know how the medication workflow would/could work for the medication administration 5-rights scenario defined by IHI with FHIR Med resources? http://www.ihi.org/resources/Pages/ImprovementStories/FiveRightsofMedicationAdministration.aspx (This is an 'old/existing' use case that has been around at least 5+ years I believe.)
Lloyd McKenzie (Jul 04 2018 at 15:46):
Ok. So what you're asking for is an identifier to be added to Medication that represents a hospital-assigned bar-code on a specific bag containing a specific pill. That's reasonable to submit as a change request. And you could have a separate FHIR resource instance for each bag - but that only works if you've got a uniquely identified thing (via the bag). You can't usefully have separate medication instances for each pill sitting in a jar unless they're each inscribed with a separate id.
Jose Costa Teixeira (Jul 04 2018 at 15:48):
Indicating an instance is redundant though. If you say you're dispensing and you just specify a CodeableConcept and don't even have a Medication resource, you still know you're dispensing instances. You don't need to point to a different code to say "I'm dispensing amoxocillin instances" rather than "I'm dispensing amoxocillin kind". So why would we need a flag if we're using the Medication resource (or Device resource) instead of CodeableConcept?
True, when informing a code of a product, you are dispensing an instance but you are saying "there is no instance information here". Not sure that affects the decision to split resources, but in any case i would not need a flag here. Of course you could have a code for a unique instance ID (instead of amoxicilin you can have a serial number). This could be for example the case in trials.
Jose Costa Teixeira (Jul 04 2018 at 15:48):
@John Silva this is ringing many bells ~thanks for looking at making sense out of the whole thing. Here goes:
Jose Costa Teixeira (Jul 04 2018 at 15:52):
controlled, extemporaneous or expensive drugs/preparations may have indeed a unique ID. in that case, when they are prepared, they get that unique code which can be used elsewhere - as a code or as a "serial number" which can be in a medication resource. But that code is for that single preparation or product - whether the identifier is unique (serial number) or not (batch number).
Jose Costa Teixeira (Jul 04 2018 at 15:53):
ah i see Lloyd's answer. We can also consider that number to be a business identifier, yes
Jose Costa Teixeira (Jul 04 2018 at 15:56):
Another thing to think about --- the drug 'catalog' in the formulary could represent all those orerable drugs (I'm thinking inpatient) that the CMO and CPO (Chief Pharmacist?) have qualified as set of drugs from a drug database (e.g. First Data DB) and those are the set of drugs allowed to be ordered at that institution. When the physician orders a drug using the CPOE they are choosing a Kind of drug but from the perspective of the CPOE and the formulary that corresponds to an instance of that (kind) in the drug database, e.g. a unique GUID that references it in the formulary. Even if the formulary did not or does not keep track of inventory, per-se, it still knows the kinds of drugs that the institution has deemed to be useful for their care practice. Imagine now that there is a mobile PIS app written using FHIR, that now needs to reference the specific formulary "instance"; it needs that same unique identifier to point back to what the formulary has. (That formulary 'instance' could have a set of orderable formulations from different manufacturers as price and availability dictates.)
Those are different "catalogs" - "list of all drugs", "list of the drugs in this country", "list of the drugs in the commercial drug DB", "list of the drugs that we can order" "list of the drugs we have for internal dispensing" - and what we are doing in the Catalog discussions is to ensure that in aach of these catalogs/lists, the drugs can have different characteristics (e.g. price, or availability, or distribution mode...)
Jose Costa Teixeira (Jul 04 2018 at 15:58):
I would also be curious to know how the medication workflow would/could work for the medication administration 5-rights scenario defined by IHI with FHIR Med resources? http://www.ihi.org/resources/Pages/ImprovementStories/FiveRightsofMedicationAdministration.aspx (This is an 'old/existing' use case that has been around at least 5+ years I believe.)
That is still very good reference (although there is some marketing about the N rights, where N>5) - would be a good exercise to include for example in IHE or HL7 guidance.
Jose Costa Teixeira (Jul 04 2018 at 16:00):
IMO the FHIR impact on the 5 rights is that people (usually nurses who are the latest safety net) should have the information available.
Jose Costa Teixeira (Jul 04 2018 at 16:02):
so, @John Silva :
1. would you care to read and comment on IHE MMA profile to see if it matches some of the ideas you are exposing? http://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharm_Suppl_MMA_Rev1.0_PC_2017-10-19.pdf
2. should we build up a scenario focused on demonstrating the use of FHIR for the 5 rights?
Jose Costa Teixeira (Jul 04 2018 at 16:06):
now, going back to the split DeviceDefinition / Device (Instance)...
Jose Costa Teixeira (Jul 04 2018 at 16:09):
even if we would not split resource types, it seems clear that we will have different resource instances when we address physical items - my hypothesis is: if we have 100 devices in inventory, we can have anywhere between 1 and 101 resource instances. (1 is if we only care about the Kind, 101 is 1 for the kind and the other 100 if they have serial numbers and we want to persist them in the server for inventory and traceability reasons)
Jose Costa Teixeira (Jul 04 2018 at 16:10):
assuming this hypothesis is not controversial,
Lloyd McKenzie (Jul 04 2018 at 16:15):
You can have more than 100. Because you might have multiple resource representing different degrees of kind. And you might have different degrees of "instance" too. You might have an instance that contains lot but not serial number and others that contain both. And you might have an instances that use high-level codes and others with lower-level codes.
Lloyd McKenzie (Jul 04 2018 at 16:16):
In any event, regardless of how many instances we might have, that seems orthoganal to whether there's a need to split the resource.
Jose Costa Teixeira (Jul 04 2018 at 16:19):
(ok, for degrees of instance i am not seeing the need - i don't see why having a batch instance if we already have the serial instances..
also "degrees of kind" goes into "catalogs / product definition graphs, that i would leave out) but assuming extension to the hypothesis:)
Jose Costa Teixeira (Jul 04 2018 at 16:19):
cardinality of resource attributes can allow that we don't split resources. However, I see some challenges in this which can cause pain in the trenches:
1. In every instance resource we still have to say what this is an instance of, right? For this, either we add an attribute (instanceOf), or every instance would stil contain a duplicate of the data of the device kind... which sounds risky.
2. what about those cases (e.g. inventory counting) where you don't really want to know if this is a device of kind A or of kind B? (for that matter you don't even care if it is a device or a medication) You are just scanning DI (code that identifies the kind) and PIs (lot and batch numbers) and letting the system do the rest)
Jose Costa Teixeira (Jul 04 2018 at 16:20):
does this make sense so far?
Lloyd McKenzie (Jul 04 2018 at 16:22):
Why would we say "instance of"? You couldn't possibly point to all of the instances you might be an instance of. That knowledge comes from terminology, not explicit links. In terms of inventory, I'm not understanding how splitting the resource helps things.
Jose Costa Teixeira (Jul 04 2018 at 16:25):
when you scan a product's barcode, you only have a product code. so, for that instance resource, you say "this is an instance of product X that i am using on patient P" and then let the terminology do the rest, or you say "this is an instance of a product P, which is defined here..."
Lloyd McKenzie (Jul 04 2018 at 16:30):
But you still have the problem that you need to know it's a device or a medication. And often it's going to be a box that contains a bunch of bottles that in turn contain the real "instances". Can you show how splitting device in two helps your scenario?
Jose Costa Teixeira (Jul 04 2018 at 16:32):
for inventory, it is not the splitting in itself, it is the separation between "things you can know about an instance" and "things you can know about a kind". I believe the former one is not a subset of the other . there may be things you know about an instance even if you have no idea what kind of product it is.
Lloyd McKenzie (Jul 04 2018 at 16:36):
If we decide we want to support general inventory, then we'll need a resource that can manage that. But that doesn't argue for splitting the Medication or Device resources
Lloyd McKenzie (Jul 04 2018 at 16:37):
And the InventoryItem resource would probably support both kinds and instances too. Because when you're ordering inventory and counting inventory you may have varying degrees (or no) instance information available.
Jose Costa Teixeira (Jul 04 2018 at 16:41):
But you still have the problem that you need to know it's a device or a medication. And often it's going to be a box that contains a bunch of bottles that in turn contain the real "instances". Can you show how splitting device in two helps your scenario?
I'll keep digesting it, but if we want to capture information about an item, without really needing to know more of its definitional, then we only need to store the "instance" data (where it is found, lot, serial, etc). so in this case we would have a resource type - or profile - that is intended not to repeat the any definitional aspects. So it goes back to "why not split if it's different information?" having one resource representing the existence of a physical item and having one resource that represents the definitional aspect of a kind of device seems clean.
Jose Costa Teixeira (Jul 04 2018 at 16:43):
one thing I would argue (as usual) - approach for device and medication should be consistent. but device has a stronger case for traceability so i think it can handle the first impact. and OO and PCD have been aligning so it provides a good consensus base.
Jose Costa Teixeira (Jul 04 2018 at 16:44):
i don't understand why inventoryItem would be about kind.
Lloyd McKenzie (Jul 04 2018 at 17:55):
We don't split because systems don't behave that way, because it adds complexity and because it's not necessary to solve the problems identified (at least not so far). If you have an inventory management system and you order to replace inventory, the "order" isn't going to point to an instance. And, depending on the type of inventory, you might not have "instance" identification information. If you've got 20 cartons of paper towel, you're not going to be able to distinguish them unless you slap an identifier on each box. And lots of systems won't bother doing that.
Lloyd McKenzie (Jul 04 2018 at 17:55):
They'll just track "I have 20 cases of paper towel" (kind level), but they won't track the individual cases.
John Silva (Jul 05 2018 at 12:14):
so, @John Silva :
1. would you care to read and comment on IHE MMA profile to see if it matches some of the ideas you are exposing? http://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharm_Suppl_MMA_Rev1.0_PC_2017-10-19.pdf
2. should we build up a scenario focused on demonstrating the use of FHIR for the 5 rights?
I did a quick scan/read-through of this document and a couple of things jumped out at me:
1. the notion about using contained Medication resources in the MedAdm but there is discussio about using reference links to the Medication in the MedRequest; curious (and maybe problematic).
2. The use of STU3 with anticipated changes (reasonNotAdminster to StatusReason -- is that an R4 change)
3. The discussion about using serial numbers
4. The MMA talks about the 5-rights but in my cursory read-through I'm not sure of how it uses the FHIR resources to implement this. This is where a scenario with example resources (from MedRequest to MedDispense to MedAmin) might be helpful
5. The MMA seems to correspond mostly to outpatient MedAdmin's, e.g. VNAs administering home meds and chemo treatments; not sure if there are any differences in inpatient 5-rights workflow and administration. (I think there definitely is, e.g. MedDispense with drug 'lock cabinets' and lock codes and multiple nurse sign-offs required for controlled substances and I'm guessing more too.)
6. Why doesn't the MMA profile deal with the dispense part of the workflow? Is this because it's geared to outpatient use where it assumes the set of drugs have already been dispensed to a particular nurse?
7. It doesn't talk about 'bolus dose' or IV push type meds; I'm never sure if these are considered continuous or not. Not sure this matters for the MMA profile or FHIR resource mapping but maybe something to think about.
John Silva (Jul 05 2018 at 12:37):
Ok. So what you're asking for is an identifier to be added to Medication that represents a hospital-assigned bar-code on a specific bag containing a specific pill. That's reasonable to submit as a change request. And you could have a separate FHIR resource instance for each bag - but that only works if you've got a uniquely identified thing (via the bag). You can't usefully have separate medication instances for each pill sitting in a jar unless they're each inscribed with a separate id.
That is one example (barcode identifier) and is definitely a legitimate use case.
What I was thinking of though is the fact that the Kind of Medication is really an instance to a specific database row in the CPOE/Formulary. So the CPOE/Formulary knows about exactly which set of drugs can be used to fill this MedRequest, that unique identifier needs to be communicated downstream to, e.g. a mobile app that the pharmacist uses to pick from the correct set of drugs that match this specific type ('qualified kinds') in the formulary at this institution. The pharmacist then makes an expert decision based on patient's condition (e.g. allergies/reactions, insurance info, etc.) to choose from the allowed formulations used within this institution. This then could be sent to the dispensing system (as MedDispense) but not yet with a specific lot or serial number but with info so the 'drug locker' will only allow the specific tray with that drug to be opened and dispensed. (It may also be that the PIS pharmacy system doesn't know the 'local inventory' of the drug locker, only that a specific set of drugs are normally kept in inventory by the institution; or the 'local inventory' is not constantly in-sync with a master inventory available to the PIS.) It may only be at the time of MedAdmin that the actual used lot and serial number are known. However, in this scenario, there is still a need for an identifier for the Medication (because it represents a unique row in the formulary) within the MedicationRequest; it doesn't just correspond to a particular RxNorm or NDC code, (or SNOMED code -- which is not necessarily precise enough), but a grouping that is still unique within the CPOE/Formulary.
Lloyd McKenzie (Jul 05 2018 at 13:37):
The identifier for a kind in a formulary is the "code" in every system I'm familiar with. In what situtations would a formulary contain multiple entries for the same code?
John Moehrke (Jul 05 2018 at 13:54):
How does a pill-pack impact this discussion? It is a manufactured (assembled) identifiable pack of pills, which might be identified at the sheet, or individual pillows.
John Silva (Jul 05 2018 at 14:16):
The identifier for a kind in a formulary is the "code" in every system I'm familiar with. In what situtations would a formulary contain multiple entries for the same code?
Not sure about specific formulary implementations but an identifier could be to the Kind of 'acetaminophen 100 mg tablet' but in the formulary system (database) there is a unique id (GUID?) for this row in the formulary database. However, that one row in the formulary has a set of unique NDC (or RxNorm) codes (children rows in DB) that are what are allowed to be ordered (and the formulary may or may not keep track of inventory, i.e. batch and serial numbers). The pharmacist on the PIS would need to be able to refer to that same unique instance from the formulary (db) in order to then do the assignment (encoding of the order) to a specific formulation based on the patient's needs. Sure, I suppose you could 'hack' the formulary GUID into the Medicaiton.code with a coding system of 'myHostpitalFormulary' but that seems to not be quite correct.
Lloyd McKenzie (Jul 05 2018 at 14:20):
But "acetaminophen 100 mg tablet" would have a code - that would be the identifier for the row.
John Silva (Jul 05 2018 at 14:24):
Yes, but I
Lloyd McKenzie (Jul 05 2018 at 14:27):
Most systems are going to point to Medication by code, so the code acts as the identifier. Pointing to a full resource is typically only done if you have a custom compound or something that doesn't have a code. And in that case, you just reference by URL.
Lloyd McKenzie (Jul 05 2018 at 14:28):
The "primary key" in the database corresponds to the resource id.
John Silva (Jul 05 2018 at 14:33):
The "primary key" in the database corresponds to the resource id.
Except that a FHIR client can't control what the server uses for the resource.id! (as mentioned the other day, the FHIR REST bundle handling specifically warns against client-generated IDs and recommends against them) I guess I still don't understand why the Medication resource is virtually the ONLY resource I can find (in STU3) that doesn't have an identifier property? Even the Device (and DeviceComponent do even though you could make these same arguments about them (kind vs qualified kind vs instance).
One other thing for thought, in the unencoded order the drug might be free-text; how (other than using the contained resource 'trick' can this be handled without an external (business) identifier? (assuming that the encoding to a specific formulation is left to the expertise of the pharmacist)
Jose Costa Teixeira (Jul 05 2018 at 14:33):
This seems agreeable and a very useful discussion. I will address the MMA issues on the IHE stream, and the Catalog discussion should be also in a separate stream... All these are linked so this is a pandora box.. hopefully we can segment it so that people who care about DeviceDefinition can follow it here
John Silva (Jul 05 2018 at 14:35):
@Jose Costa Teixeira - there seems to be a lot of overlap between the issues related to Medication and Device -- does this mean these are really 'FHIR infrastructure' or modeling issues that need to be resolved at a 'higher level' ?
Lloyd McKenzie (Jul 05 2018 at 14:42):
In this situation, why does the FHIR client need to control the identifier? The formulary is the server. it determines the URL. Everything else just points to it. Adding an identifier to reflect a label put on a bag makes sense. But you wouldn't use it for the formulary's database key.
John Silva (Jul 05 2018 at 14:54):
Because what I'm envisioning is a FHIR server that is NOT an API on the formulary or the CPOE or the PIS; but rather a separate server that collects these FHIR message/bundles 'flying around' to expose a FHIR RESTful interface for other applications. (In the legacy world it is probably the case that these systems do NOT provide FHIR APIs and the reason for the FHIR server is to provide a FHIR-based RESTful interface for new applications that can't or do not want to use legacy interfaces to legacy systems.)
It still doesn't answer my question as to why virtually every other FHIR resource has both an identifier and a code (e.g. Observation being the classic example) but not Medication?
Lloyd McKenzie (Jul 05 2018 at 15:02):
We've had no situations where business identifiers were assigned to medications and it certainly wasn't considered to be part of the 80%
Jose Costa Teixeira (Jul 05 2018 at 15:13):
@John Silva I have proposed that we look at a Health Products similarly - eventually a pattern; so to me there is indeed a big overlap that we should care for. I think it's great that we let each resource progress on its own while keeping an eye on each other, and when there is some more maturity we can harmonise better
Jose Costa Teixeira (Jul 05 2018 at 15:15):
All the same questions that we answer for device or medication should be similar. The matter of Kind Vs Instance is more obvious on Device so we can start here
Jose Costa Teixeira (Jul 05 2018 at 15:15):
...and there is also active e work and discussion on product catalog, so we can use that.
Hans Buitendijk (Jul 05 2018 at 20:09):
You step away for July 4th burgers, and look what we missed! Great discussion, although not yet closer to resolution.
A couple of thoughts that may help perhaps:
- It seems that current Device use is actually about the instance, with greater or lesser specificity of what that device really is (i.e., lack of knowledge of the DI - device identifier, be it the UDI or some other unique identifier that is meaningful to the manufacturer to identify the definition of that device): I may know it is a bloodpressure cuff (type/specialization), but would not record the serial number or manufacturer perhaps when using a manual one as there is no value for the effort, but if the information is electronically transmitted I could/would (newer models) to improve on provenance, etc.
- Both LIVD and GUDID are real example use cases of focusing on DeviceDefinition, not instances. Not just future, but today.
With that perhaps we can agree on having both a DeviceDefinition and Device, where the Device's focus is on the instance aspect (nobody really has come forward they are using it for something different, although there are claims it could be profiled for DeviceDefinition, sure it could but does not make sense), and then agree to what attributes are necessary to describe the device sufficiently in the absence of being able to populate a Reference(DeviceDefinition) since the device identifier cannot be reliable established (e.g., patient reported devices, limited/no value to document in manual documentation flows, etc). We then can argue whether there need to be 2, 5 or more (hopefully not) fields to support describing the fuzzy notion of the kind of device, e.g., manufacturer, type, specialization. Note that we are going through that exercise with the OO-HCD discussions where those marked with orange on the attribute in the Device columns are candidates for just that.
It also would be great to hear from others who tried to implement the notion of DeviceDefinition as a profile what challenges that creates, and remain curious why in this case a reasonable, consistent definition approach cannot be followed, where in other situations proper separation is actually done (lest we want to repeat the challenges of the V3 moods.......) DeviceDefinition.xlsx . BTW, we got as far as the red cell, so the current list of candidates (orange) is not necessarily complete.
Lloyd McKenzie (Jul 05 2018 at 20:20):
I haven't yet heard a use-case why we need to split the resources. If we're going to have multiple resources, we need both a pressing reason to split and confirmation that all existing implementers will be able to easily manage the split. All I've seen so far is modeling-based arguments - and that's not a primary driver for FHIR design. What implementers are saying "we can't make our existing implementations work with the current one-resource approach"?
Jose Costa Teixeira (Jul 05 2018 at 20:24):
fair to discuss whether we need vs we should, and get arguments. I don't feel comfortable with only changing if "all existing implementers will be able to easily manage the split" - that is not a condition I would expect especially given the maturity of the resources, and the state they are in (see figure below). If we say "once a resource is out there, we will only change when all implementers are fine with the change" this to me means "we can't release until things are quite stable" which is not what I see either as a designer or as implementer.
Jose Costa Teixeira (Jul 05 2018 at 20:27):
Jose Costa Teixeira (Jul 05 2018 at 20:28):
This is my interpretation of the variance around overlapping resources - (something that is a medical device may become a medication in a diferent year or a different country).
Jose Costa Teixeira (Jul 05 2018 at 20:29):
The split that Hans proposes could also apply to the Medication / Medication Knowledge split.
Jose Costa Teixeira (Jul 05 2018 at 20:43):
We have:
a) a definition of a product (always kind, e.g. gudid)
b) A mention of some of the product characteristics in an order (mostly kind) or in a dispense/admin (Instance)
c) The notion and attributes of a physical instance of a product.
I suggest we look at a few use cases with a realistic scope - from GUDID to the EU FMD and the US safety/traceability act whose name I am forgetting now.
Lloyd McKenzie (Jul 05 2018 at 22:50):
We're pretty cautious about defining splits unless we're confident almost all implementers can handle it now.
Medication/MedicationKnowledge makes sense as a split - it separates the every-day use resource from the formal definition resource provided from organizations like FDB or used in regulatory submissions. That separation typically exists in current systems and the data elements captured are very different. But splitting instance and kind is not something typically done - and converting from one to the other just by populating an additional data element is quite common. So splitting there is something we should only do if we must do so - and in this very long thread, I haven't yet seen a reason why the split must occur.
John Silva (Jul 06 2018 at 12:38):
How does the Observation model fit with this Kind vs instance discussion since it's been around for a long time and has a lot of real-world use? For example, there is an order for a CBC blood test (Kind - ProcedureRequest ?) and then there's the result reporting ( instance - Observation)? How does this workflow deal with the Kind/Instance distinction and the need for definitional data?
Lloyd McKenzie (Jul 06 2018 at 13:11):
Acts don't have kinds. They have Definitions. And protocols/order sets/etc. are almost always maintained separately from orders and use different user interfaces, so we have distinct resources and patterns for Definition vs. Request vs. Event. But historically that same separation hasn't existed for Entities - medications, devices, substances, etc. They are managed with the same UIs and database tables whether treating them as instances or kinds. And therefore FHIR has been doing the same. So far, it's not obvious that approach is problematic. There is a recognition of a separate resource to capture all of the "knowledge base/regulatory" information that's associated with entities, as that is typically maintained separately.
John Silva (Jul 06 2018 at 14:16):
@Lloyd McKenzie - I know that you are using V3 modeling terminology, which I only have a cursory understanding of, so your explanation doesn't help me. From my perspective the CBC Order is a request and then a promise (is that moodCode in V3-speak?) not an Act, until the Performer actually completes the request/promise? I don't get why a similar workflow doesn't happen with Devices and Medications? For example, there is probably (typically) a 'standing order' or 'order set' for a Device with a certain set of parameters (or DeviceComponents) for a CBG patient; maybe a Patient Monitor (Device) with ABP, Temp, SpO2, Cardiac Output (DeviceComponents). I would expect this to be in a ProcedureRequest and assigned some unique identifier for traceability (and maybe billing in the US). Later on when the Performer actually connects up the Patient Monitor with the 4 plug-ins, they identify each of these by their unique UDI's. So, yes, the original "order set" is a Kind, but once it is ordered it is a unique instance of that Device 'order set' and needs to be traced. The difference, I suppose, is that there may not be a Act corresponding to the 'allocating equipment' (which is similar in some respects to MedDispense), and the Act of actually using the Patient Monitor (with plug-ins) are all reported via the FHIR Observations (not sure what that corresponds to in V3). So, my intention was not to get into V3 modeling but to try to understand the workflow pattern of a more well-known and in-use set of FHIR Resources (like Observations) to compare/contrast them to Device and Medication workflows.
Lloyd McKenzie (Jul 06 2018 at 14:25):
Sorry John, I thought the v3 terminology would have been helpful. In v3, the world is separated into Acts (things that can be/are being done) and Entities (physical things that exist). The two behave differently. We'll absolutely have protocols, orders (placer and filler), plans, proposals and events in the pharmacy and device spaces - that's what ActivityDefinition, MedicationRequest, MedicationDispense, MedicationAdministration, DeviceRequest and DeviceUseStatement are for. Medication and Device are different. They represent the physical "thing" or kind of physical "thing" manipulated or referenced by those other resources. There is no workflow pattern for the "things", only for the actions. The actions of aquiring, transporting, ordering, providing, using, etc. determines the life of the entity resources. And the action resources might talk about them from a kind perspective or an instance perspective. There's no consistency. And therefore we can't impose any.
Jose Costa Teixeira (Jul 06 2018 at 14:41):
@Lloyd McKenzie "a separate resource to capture all of the "knowledge base/regulatory" information that's associated with entities, as that is typically maintained separately."
just one short note to care for the scope: a definition of a product does not happen only at regulatory side. It happens in a chain of participants who contribute with data. the product characteristics can have regulatory, scientific, logistic dimensions, and they can be global, regional, local, insitutional, personal or role-based. this is more common with medication than device, though.
John Silva (Jul 06 2018 at 14:46):
I know about the five major color (model areas) of the V3 RIM, but not enough to be conversant in them (had to look this up to remember: Red: Action, Pink: Act-Relationship, Blue: Participant, Yellow: Participant-Role, Green: Entity. I was told that FHIR has a Request and Event 'meta-models' so I went to that page to try to understand more about the Request pattern, in particular ( http://build.fhir.org/request.html#statemachine ). I noticed this, and though it 'begs off' on saying that all resources support this, it does suggest a pattern that is intended to be followed. Of particular interest (to me and maybe this discussion) was:
The "requisitionId" represents the identifier of the prescription, lab requisition or other form that was shared by all items. The common information (patient/practitioner/authoredOn) can be seen by examining any of the Request instances that share that requisitionId
This hints to me that there should be an immutable 'instance identifier' that is able to communicated all the way from the Request (order) to the Dispense, to the Result (Act in V3-speak?) so that there is traceability all the way from start to end of the workflow. I'm not sure how this pertains to the discussion of if/should Kinds and Instances be separated or not though.
Jose Costa Teixeira (Jul 06 2018 at 14:48):
this is not an argument in favour or against any split point at this moment. i remember the spectacular effect of having a a database size explosion when kind and instance were put in the same tables, but that is just my experience.
Jose Costa Teixeira (Jul 06 2018 at 14:51):
I'm not sure how this pertains to the discussion of if/should Kinds and Instances be separated or not though.
i'd say not. one thing is the identifier of the procedure you are performing, or the thing you are trying to give (e.g. make sure that if you prescribe paracetamol / acetaminophen you can trace dafalgan / tylenol deliveries and administrations to that prescription.
"traceability" usually means (in my glossary, and when applied to this kind vs instance thing) - the ability to trace the path of each physical instance of a device/product and do things like recall,
John Silva (Jul 06 2018 at 14:54):
@Jose Costa Teixeira -- good point, in real world implementations (and existing ones not future) there is most likely a split between "definitional data" (Kinds like 'order sets' and 'medication sets' vs. instance data, i.e the actual recording of a medication admin or a device usage, etc. for performance reasons for sure (at least in traditional relational DBs).
Jose Costa Teixeira (Jul 06 2018 at 15:03):
the interoperability model does not have to follow that, and i understand Lloyd's arguments (or i think I do). but i am mostly worried if we follow the practices that have prevented proper traceability . ( again at this moment i'm not focused on whether splitting is the way to enable traceability)
Lloyd McKenzie (Jul 06 2018 at 15:56):
It's absolutely possible to chain together the plans, proposals and various levels of orders through the dispense and the eventual administration. That's all on the "action" side of things and has nothing to do with kind/instance.
John Silva (Jul 06 2018 at 18:39):
Huh? I thought earlier you said that an order, e.g. MedRequest, can have a Kind of Medication, then later on, maybe as late as administration, there is finally an instance, in this case of a specific Medication (with lot/serial number or not but regardless, it is still a single 'instance' that is given to the patient, not an abstract Kind of Medication.) Yes, the Med Admin is an Act, with a specific Performer (Nurse Z), with a specific set of Entities (Patient, specific Drug), etc. Are you simply saying that the Kind/instance distinction is orthogonal to the order workflow? OK, but there seems to be an intersection of sorts, though in that the order (or Request in FHIR) workflow deals with Kinds and instances of things (Entities in V3)?
John Silva (Jul 06 2018 at 18:39):
Is this discussion really rooted in the FHIR workflow patterns (http://build.fhir.org/workflow.html#relationships )? It seems like there is a definite linkage between the Request pattern (what you want to happen) and the Events pattern (the results of what was requested). Then there is the Definition pattern, which seems to be what this discussion started about -- when/if/why to split resources along definitional or event lines. Ah, and there is even a relationship (as to be expected) between Requests and Definitions -- interesting is that a Request 'instantiates' a Definition; this implies that a specific Request has an instance relationship to a Definition; I guess the question becomes, where does this definitional data live, in a specialized resource or the same resource used for reporting the Event?
[on that FHIR webpage I do not see any of the Definitional resources that have been mentioned in this stream though, e.g. ObservationDefinition, MedicationDefinition, DeviceDefinition, etc.]
Lloyd McKenzie (Jul 06 2018 at 19:12):
Orders can point to kinds or instances. Events can point to kinds or instances. Kind vs. instance is independent of workflow. We typically have one resource that can handle kind or instance (and easily switch from one to the other depending on what elements you populate). The relationships between kinds and instances are managed through terminology, not direct relationships.
John Silva (Jul 06 2018 at 20:20):
OK, so they are orthogonal to the workflow patterns; thanks. What happens though if a FHIR server doesn't implement terminology services or the FHIR server is a facade on a legacy system that doesn't expose a (FHIR) terminology interface? In the example of the MedRequest (order) for a 'general concept of an analgesic' (Kind), there's no (FHIR) terminology service that does the lookup/assignment of the Kind to a specific coded Medication, it's the pharmacist on the PIS (legacy Pharmacy Info System) that might communicate this 'decision' out via a FHIR API or even V2 messages. (I guess I'm stuck in the 'legacy world' so I keep thinking of how these concerns affect legacy implementations.)
Lloyd McKenzie (Jul 06 2018 at 20:44):
Systems don't need to use FHIR terminology services. Systems (and humans) were figuring out whether "APO Amoxicillin 100mg tablets" was a legal dispense against a prescription for "Amoxicillin 100mg" long before FHIR was ever conceived. And if they can't figure it out with terminology or a human being, then they can't figure it out. No system I'm aware of provides explicit links at the medication level to say "this medication is an instance of that medication", except perhaps at the regulatory/knowledge-base level. (So not the resources you point to when prescribing/dispensing/administering)
John Silva (Jul 06 2018 at 21:50):
OK, of course back in the days of paper prescriptions (scripts) there was not necessarily a computer system that did the Kind to instance conversion; assuming the paper script was even readable enough for a pharmacist to interpret it and provide a correct drug to match the prescribing doctor's intent. However, you were talking about 'terminology services' as being the FHIR mechanism that did this; I was simply asking about when it wasn't present. It still seems to me, even in the paper prescription world, there still needs to be traceability from what (med) was ordered to what was actually administered for many reasons, including human error (e.g. illegible doctor's hand-writing), to abuse (someone dispensing a different drug than was ordered) or just plain old tracking for cost or other reasons. (I'll stop asking questions about this for now.)
Lloyd McKenzie (Jul 06 2018 at 21:53):
Terminology services not necessarily as in "FHIR terminology services", but more things like RxNorm or FDB or other terminologies that provide relationships between codings of medications at different levels of granularity. In terms of pure instances (e.g. bag 125784 of drug X), the instance would still have a code on it that indicates what type of medication it is.
Hans Buitendijk (Jul 09 2018 at 14:16):
Can you provide implementation examples where Device is actually not used as an instance? Would welcome others to joint in as so fart this discussion seems limited in number of participants to clearly understand perspectives (beyond those in the OO-HCD meetings where there is consensus to a split with a proviso of some data "duplication" to be finalized), so not clear what Lloyd's opinion represents.
Hans Buitendijk (Jul 09 2018 at 14:25):
Regarding the use case for other resources that indicate a need to split, let's be clear that, as in V3, one can always have a base resource combined and a mood code or equivalent recognize the difference. But generally that approach was seen as more cumbersome, too complex. So it seems that the argument should be more, why combine, which has not been made at all in a very clear manner. So far, examples used to keep it combined have been very light on how to distinguish a definition from an instance as most if not all examples deal with instances as the primary connection to track, not definitions. In LIVD, as would be in GUDID, the primary connection is with the definition. Just because the Device resource would be used in LIVD does not make it a definition. Either there is an indication that it is (absence of certain fields is a very poor means to unambiguously do so - that's not modeling purity - leaving profiling or splitting. Profiling is a poor mechanism as well to separate this fundamental difference in concept where elsewhere that is also separate. So I continue not to hear any real argument other than wanting all implementers to vote when the FMM is still very low.
Lloyd McKenzie (Jul 09 2018 at 15:07):
The resource boundaries are driven by what implementers do, not by what the modellers think they ought to do. If implementers typically have a single UI and database table to capture both kinds and instances, we shouldn't be pushing for a split just on the basis that the RIM defines such a split. The FMG is going to be very cautious about approving the split of the resource without seeing evidence that it's driven by implementers needing the split. The boundary of what's a kind vs. what's an instance turns out to be quite permeable in practice. The same codes are often used to describe both instances and kinds. The separation is really what properties happen to be populated. If you have a serial number, then you've got an instance. However, you can have situations where the serial number is present from ordering through to delivery and you can have other situations where it's never present and specific instances aren't tracked at all.
Asim (Jul 09 2018 at 16:11):
@Hans Buitendijk @John Rhoads @Lloyd McKenzie @Brian Reinhold in Koln WGM we agreed to merge Device and DeviceComponent Resources
Next steps were to:
• Define whether there should be just one resource or 2 resources ( DeviceDefintion and DeviceInstance) as there was no agreement during Koln WGM.
We should first have the merge list for the Device and DeviceComponent Resources, here is the merge list produced by the healthcare devices team: http://wiki.hl7.org/index.php?title=Device-DeviceComponent_Merge
The healthcare devices folks would like to have a single resource in line with the data elements in the above merge list.
We would like to have just a single Device resource and then profile it for specific use cases. But if the community decides to have 2 resources then there should be a resource called "Device" that must have the data elements mentioned in the above merged list.
Brian Reinhold (Jul 09 2018 at 16:22):
Having the Device unaffected by the presence of a DeviceDefinition is also consistent with the Observation and the ObservationDefinition. In addition, doing the agreed-up merge first would also give the DeviceDefinition needs and use case (which is relatively new compared to the Device) more time to evolve and define requirements.
Robert Dieterle (Jul 09 2018 at 18:23):
When this conversation regarding the various device resource started in early 2018, I proposed a single resource to address the current short comings: 1) limited ability to describe complex devices that have multiple components, each with a UDI, 2) limited ability describe only the catalog version of a device and not the instance (e.g. as defined in the FDA GUDID), 3) limited ability to define a device with multiples of the same component 4) limited ability to define device capability and settings (factory and individual instance). The single resource was complex with multiple nested backbone elements and needed multiple profiles to define the various instantiations of a device. The most limiting aspect was the need to have the "product information" (e.g. DI) replicated for each instance of the device. Splitting the concept into two resources made a lot of sense in that it allow the definition of the product without concern for the specific instance (e.g. each of the thousands of the entries in the GUDID database are in effect a deviceDefinition -- BTW this is current industry effort and not some concept for the future) and to define an instance that does not need to reproduce the product information, just reference it. If one needs to exchange dozens or thousands of instances for a single device, they only need to exchange the deviceDefinition once. While it may be challenging to get from the current device resource structure to the proposed structure, it is necessary to reflect the complexity of devices and establish an appropriate pattern for the future that will simply support more than just the definition of a single instance of a device.
Hans Buitendijk (Jul 10 2018 at 16:18):
@Asim - We are working through the list that Device should contain in the Tuesday 9-10 EDT OO-HCD calls, which includes substantial HCD representation who are looking out for that list. Note that during the meetings we also agreed jointly to split the Device and DeviceDefinition, while we are working through which elements that one technically could look up in Reference(DeviceDefinition) would be reasonable to still have in Device. Particularly those fields that would provide descriptors of the device but not allow for unique linking to the correct DeviceDefinition (given person documenting in a certain workflow). For those interested, today's minutes with latest spreadsheet (we got up to the red cell in column A/C): http://confluence.hl7.org/display/OO/OO+Conf+Call+Minutes+-+Devices+-+20180710.
The call is where decisions are made as those are formal OO-HCD workgroup calls.
Hans Buitendijk (Jul 10 2018 at 16:34):
@Lloyd McKenzie There are databases that combine and split those aspects, depending on their scope. We should be very cautious to drive resource definitions based on what systems do on their UI and database structures, rather ensure that the resources enable unambiguous communication of data. The RIM combined a number of concepts that in most databases are combined. Let's not just flip that to the opposite, but rather create reasonable resources that can be combined as needed, managed separately as needed, and let consuming/furnishing applications worry about how that is best stored in their environment. A FHIR resource should never be a dictate on how to store the data as-is in one's data base or how to present/report. As with V3, one can opt to implement close to that, but that can never be a requirement, which is what you seem to imply.
Lloyd McKenzie (Jul 10 2018 at 16:39):
What systems do in their databases and UIs provides good guidance as to where appropriate splits are - and also give insight into what sorts of splits systems can support. We can only split Definition off from Device if we're confident that almost all systems that deal with devices in any capacity are going to be able to cleanly and consistently determine what resource to use when exposing their data. I'm not clear that assessment has been done. And I'm still not clear on the rationale for the change. What implementation problem is caused by having a single Device resource that allows the capture of instance characteristics such as lot and serial number when relevant?
Malgorzata Schwab (Jul 10 2018 at 20:14):
The whole beautifully awesome idea is that resources are processed independently. They must stand on their own. A blueprint (type or definition) is an inherent part of an instance, just like DNA is inherent part of every cell, not a reference. The idea behind reference is to create a web of independent resources, not to link a resource's head with its tail.
Last updated: Apr 12 2022 at 19:14 UTC
