Stream: implementers
Topic: Product Type vs Physical instance.
Jose Costa Teixeira (Feb 26 2017 at 11:21):
I am looking at STU3 resources for implementing, and i now face an issue:
Jose Costa Teixeira (Feb 26 2017 at 11:22):
Use case is simple:
Prescription is Medication X = brand Y, manufacurer Z, 30 per box, etc. It's a type, as usual in orders.
When administering, we are saying "I used THIS specific instance of this medication, lot=123, serial=456, expiry date=76453". It's an instance, as usual (always) in events.
Paul Knapp (Feb 26 2017 at 11:23):
Device contains those elements.
Jose Costa Teixeira (Feb 26 2017 at 11:23):
Current options in Administration / DeviceUseRequest are to either use a codeableConcept, or point to a medication. Latter seems obviously more appropriate.
Jose Costa Teixeira (Feb 26 2017 at 11:24):
So, the order points to a TYPE resource (medication or device), but the administration must point to what? another device resource instance?
Jose Costa Teixeira (Feb 26 2017 at 11:25):
the way i see it, this requires that systems must implement ONE resource for storing the TYPE information, and ADDITIONALLY ONE RESOURCE FOR EACH PHYSICAL INSTANCE.
Jose Costa Teixeira (Feb 26 2017 at 11:26):
meaning, if I have 10 packs of medication in sotck, each with different lot and expiry date (not to mention serial numbers in each unit), then I would have 11 resources - one for the type and another for each instance.
Paul Knapp (Feb 26 2017 at 11:26):
I don't see a serial number on Medication.
Jose Costa Teixeira (Feb 26 2017 at 11:26):
comments?
Paul Knapp (Feb 26 2017 at 11:27):
Can you not just refer to the same instance of Medication?
Jose Costa Teixeira (Feb 26 2017 at 11:27):
@Paul Knapp don't worry, serial number will eventually be there (core or extension). but that is not the point here.
Jose Costa Teixeira (Feb 26 2017 at 11:28):
No, because two people administering different medication instances must capture different lot numbers. So needs to be stored diffferently
Paul Knapp (Feb 26 2017 at 11:30):
Ok, that's beyond me - hoping a pharma person will jump in to assist.
Jose Costa Teixeira (Feb 26 2017 at 11:30):
same applies for devices.
Jose Costa Teixeira (Feb 26 2017 at 11:32):
Order "deviceX, GTIN=12312312312312". Resource id=1
DeviceUseStatement = device XY, GTIN=12312312312312, lot=123, expiry=2017-09-09, serial=123, ResourceId=??
Paul Knapp (Feb 26 2017 at 11:33):
For devices I'd expect a separate device instance for each device as each contains a single UDI equivalent - yes like you've just included above.
Jose Costa Teixeira (Feb 26 2017 at 11:34):
i have seen projects crash because of this, and now i need to provide some implementation guidance, so I want to put this to test.
Jose Costa Teixeira (Feb 26 2017 at 11:38):
thx Paul, for devices, indeed that is the way I can see it working with the current resources - and then each physical instance resource would point to the "parent" type, which has the "static" info and can even contain other characteristics.
Jose Costa Teixeira (Feb 26 2017 at 11:39):
It would be a rather large number of devices though, and eventually not all device instances need to contain all the information on the device type. Example, recalling a previous discussion: in each device INSTANCE, you don't have to store if it has latex or not, because it could point to a device TYPE, and the device TYPE says "has latex".
Jose Costa Teixeira (Feb 26 2017 at 11:39):
and this will be definitely fun (or funny) when we have to implement serialization in medication - each medication in a hospital having a unique serial number :)
Jose Costa Teixeira (Feb 26 2017 at 11:41):
My current idea is to consider a logical pattern for "physical instance", and this pattern could be used in either
a) the resources like Medication and Device
b) in the Event resources
Jose Costa Teixeira (Feb 26 2017 at 11:42):
in any case, i would say a consistent pattern would be better.
Jose Costa Teixeira (Feb 26 2017 at 11:42):
logical model
Jose Costa Teixeira (Feb 26 2017 at 11:43):
Any ideas?
Lloyd McKenzie (Feb 26 2017 at 15:31):
When administering or dispensing, some use-cases will allow you to just capture the type with no "lot" or similar instance data. In those cases, you can get away with using the same medication instance. But if you're going to capture lot information, then the dispense and administrations will absolutely need to point to a different medication than the request. (In many cases, the references will be at different levels of granularity too - ordering a generic formulation but administering a specific manufactured drug.) I'm not sure I understand the issue with doing this though . . .
Jose Costa Teixeira (Feb 26 2017 at 18:59):
the operational issue i can see is that we must embed or point to a different resource for each serial number, which means thousands of resources
Lloyd McKenzie (Feb 26 2017 at 19:02):
Sure. Every distinct serial number is a distinct inventory item, so not sure why that would be an issue. You'd have been doing the same thing in the v2 world.
Jose Costa Teixeira (Feb 26 2017 at 20:04):
the messages in v2 are a bit more transient. and we never stored the full description of an item for each inventory item, so we never stored "aspirin 100 mg, bayer, ....., lotX, SerialY". We'd store the definition and inventory differently: product1: "aspirin 100 mg, bayer, ..." . Item 1 = "product1,lot, serial".
Lloyd McKenzie (Feb 26 2017 at 20:14):
If you don't want them as separate resource instances, you can make them contained.
Jose Costa Teixeira (Feb 26 2017 at 20:45):
this is where i was going with separating: Why not link the definition part, and contain the inventory item part?
Jose Costa Teixeira (Feb 26 2017 at 20:47):
having separate resources does not mean they would be separate in the application's database, i understand that. but it would seem sensible to at least have a good separation between those two parts - type (definition) vs physical item.
Lloyd McKenzie (Feb 26 2017 at 20:51):
It's the same thing. If you were going to store the inventory information in your database - one vial, lot xyz, manufacturer Q, that would be on the same record as captured what kind of drug it was and what its ingredients were.
Jose Costa Teixeira (Feb 26 2017 at 20:53):
inventory and type information would be in different data structures(tables)
Jose Costa Teixeira (Feb 26 2017 at 20:55):
for a given clinical event, we have both. But for inventory management, it would be best not to store 20k lines saying "aspirin, acetylsalisilic acid, bayer, box of 30, price.... lot 1, serial 2, expiry date 3/4". We'd store one table with aspirin, and another with only the inventory-specific properties
Jose Costa Teixeira (Feb 26 2017 at 21:10):
maybe unintended consequence: if we need to send "inventory lists", i.e. system A tells System B about stock at hand, we'd have a lot of overhead if we have to send one medication resource per inventory item.
Lloyd McKenzie (Feb 26 2017 at 21:20):
This has nothing to do with what you store - it's about what you send. And you need to send both. If you want to store them separately, you can.
Jose Costa Teixeira (Feb 26 2017 at 21:27):
yes, but the definition part (type) could be by reference, the physical item part by embedding.
Jose Costa Teixeira (Feb 26 2017 at 21:31):
we can make today's resources work because everything is optional , and I can send only the relevant part. But i see no way to say that "this aspirin 100 mg, lot 123 is actually a physical instance of the aspirin 100 mg that i have in my catalog". Only repeating the description info
Jose Costa Teixeira (Feb 26 2017 at 21:34):
i think i will bring up the use cases.
Jose Costa Teixeira (Feb 27 2017 at 00:21):
http://fhir3.healthintersections.com.au/open/MedicationAdministration/ihemedadmin0171-a1
Jose Costa Teixeira (Feb 27 2017 at 00:27):
this is an administration of a single tablet. Using FHIR feels strange (i think the medication Resource will struggle with its identity as definition of a type and physical item). It has some issues:
1. Don't have serial number,
2. can't link the medication administration to the instance order and to the original prescription,
3. I have to "add" a resource for the physical item. this is not intuitive. I would rather add the physical item part, not a whole medication resource. Perhaps it is my perspective.
Lloyd McKenzie (Feb 27 2017 at 00:35):
I don't know why MedicationAdministration doesn't have basedOn as per the Event pattern. That would have let you point to the order(s) and seems like something that ought to be in the 80%. If you're in an environment that does inventory management, the Medication instance with the lot number, etc. would already have existed. If not, then a contained resource would be appropriate.
Jose Costa Teixeira (Feb 27 2017 at 09:49):
It has "prescription" which allows to link to the prescription (i think that is what BasedOn corresponds to), but if I need to link to the instance order, that is not possible
Simone Heckmann (Oct 20 2017 at 10:01):
Have there been any Change requests resulting from this discussion? I currently have the problem that I want to create a catalogue of device type resources, but I don't see a way of how to distinguish these "abstract" types from the "instance" types.
Jose Costa Teixeira (Oct 20 2017 at 10:48):
Hi Simone. no updates to the resources yet. I will try to create a few tracker items. Would love to have your input, especially because you are confirming that the difference Type/Physical is relevant.
Jose Costa Teixeira (Oct 20 2017 at 10:49):
meanwhile, hope you are aware of the Catalog discussions
Jose Costa Teixeira (Oct 20 2017 at 10:49):
basically the catalog is an "Authored/Curated list of device types including their relationships and additional metadata"
Eric Haas (Oct 20 2017 at 22:57):
We discussed a few options at last week's OO conf call and look forward to seeing them mocked up in a way that will help us move forward on an approach for Device.
Last updated: Apr 12 2022 at 19:14 UTC
