Hello, we figured out that the resource “Iteminstance” has been removed from Release 4.
as it was stated here (http://hl7.org/fhir/2018Sep/iteminstance.html), we see that it was just for trial use and that “has not yet undergone proper review by the appropriate Workgroups” and “considered only as a draft resource proposal for potential submission” but we think it can properly cover, as an abstract entitiy, lot of logistics use cases.
Actually we use also medication and devices for our cpoe module but we even started developing a drug logistics module based on “iteminstance” resource (that was available in Release 3.5. Now we moved our platform in order to be “release 4” compliant and we would like not to diverge from the data model. Do you think is it still possible to re-admit this resource in future version of the standard?
We would be glad to join a dedicated workgroup
The relevant work group is Orders & Observations. However, it’s unlikely that the resource will be re-introduced as it was controversial from the outset. We want to minimize the number of situations where the same real-world object can be represented using multiple resources - as that increases the number of places implementers must search to find things and creates opportunities for inconsistencies across systems. As well, we try to have resources correspond to how concept are typically persisted and displayed within existing systems - and ItemInstance was more of a modeling convenience than it was an accurate representation of how most systems store or render data.
It is far more likely that we will have a pattern that shows where common elements exist across “thing” resources such as Medication, Device, Substance, Specimen, etc.
Hi Lloyd, thank you for your reply, I definitely agree on the fact that from a data model perspective we should avoid duplication of information. The point that led us to adopt two different resources (ItemInstance for logistics and medication for clinical aspect) are the following:
-
the abstraction provided by the resource “ItemInstance” itself is great for logistics stuff because it can easily manage Rolls, Boxes, Packages that can eventually contain both medication and devices, specimens,…
-
we use medication resource for the cpoe module once the drug is requested, prescribed, administered or delivered because it fits with the patient/encounter association…
So we could even move to use specific resources for each “thing” that can be managed by the logistic module but in this case we have to introduce attributes such as SerialNumber, count in medication resource and define new resources for the container things that as well should have attributes like serial number, batch, expiration ,…
That’s why we think that a generic abstract resource can better solve logistics aspects.
General logistics is borderline as to whether it falls within the scope of FHIR. In general we don’t try to tackle domains that don’t contain at least something that’s healthcare-specific. If it’s a need that wouldn’t look any different managing supplies for a car manufacturer than it would a hospital, we generally treat that as outside FHIR’s scope or direct implementers to use “Basic”.
That said, this area isn’t fully settled yet. There’s ongoing discussion about catalogues and other similar topics and how best to handle them isn’t yet decided. Feel free to engage in the discussion on chat.fhir.org
Hi, we totally agree that fhir should cover only healthcare-specific… our intent is not to realise a generic purpose application but the use case we tried to model with fhir is the tracking of the logistics within a hospital and related to central pharmacy, sterilisation unit, and departments that move “things” among wards, operating theatre, intensive care units,…
All these organisations stores those “things” in their own stores, cabinet, shelves, … carts
The aim of our logistic module is to track all these kind of items inside the hospital till the effective administration to the patient.
We agree that when these “things” are prescribed, administered or delivered to the patient it would be better to use the real resource (medication, device, specimen,…), and in our pplication (in other modules) we do exactly like this, but till that time we think it is more appropriate to consider them more abstract (such as an “iteminstance”) so that it’s possible to manage and track properly even the containers (rolls, boxes, packages,…) used for the delivery of this things among locations (pharmacy, department,ward, [cabinet], [shelves], carts,)
Cool use case. If I understand, seems an interesting collision of clearly defined healthcare concepts (medication, device, specimen) and something like a BOM [bill of materials] for packaging/storing of those concepts/items. Reminded my of a fulfillment module I wrote BITD that cross some of these boundaries – samples and educational materials, etc. Also worked with Multum and FirstDatabank’s fine drug database APIs – both of which covered ‘packaging’ of underlying pharma concepts – to a level. All pre-FHIR of course and actually didn’t even hit HL7V2 as I recall.
Anyways, great to read and best of luck to you on your modeling!!