Supply of Products for Healthcare (SUPPLY)
0.3.0 - ci-build
Supply of Products for Healthcare (SUPPLY), published by IHE Pharmacy Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.3.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/pharm-supply/ and changes regularly. See the Directory of published versions
In the Operating room, a patient is receiving a lung catheter. The procedure has been scheduled 2 weeks in advance, and when preparing the patient for surgery, the team notes that patient intolerance to latex is not documented, so they decide to use latex-free materials.
In the Operating Theater stock, there are catheters in consignment. Some contain latex and others contain Liquid Silicone Rubber. All these devices are labeled with a UDI label and barcode, and are registered in the central registry for devices (in the US, the GUDID).
To prepare for the surgery, the nurse retrieves the items from the local inventory. When scanning the UDI Barcode, the OR system parses the barcode, obtaining the lot number, serial number and expiry date. The expiry date is still in the future and the product is considered valid for implant.
But the OR system can also lookup the product in the local catalog, to obtain more information like the price (for charges) or any other information. The OR system submits the product GTIN and obtains the catalog information, which includes “Device labeled as containing natural rubber latex or dry natural rubber (21 CFR 801.437)”.
The OR system has been informed that the patient may be allergic to latex, and this immediately triggers an alert to the nurse. The nurse retrieves another device.
After the product characteristics are obtained, the product is matched against what was ordered or the patient.
This is done by submitting the product information (Product ID or attributes) against the EHR which contains the order, whether for a specific product ID or containing specified characteristics. The EHR responds with the result of the matching.
This use case introduces the following requirements:
There is a need to look up one product type. This is in all aspects similar to the physical product lookup, except that the physical product attributes (lot, etc.) are not required. Since the physical product lookup contains a superset of the information in the Catalog Item Lookup request, it may be that this is not strictly a new requirement, but can be covered by the Physical Item Lookup. This is supported by using standards-based interactions with a product data repository, like GS1’s GDSN.
As a result of the Catalog Item Lookup request, the response is expected to be a descriptive set of product characteristics. In this case, it is a presence of latex or something else. It can also be a broad set of characteristics, from which the receiver can select those appropriate. These are “catalog” characteristics, so they are defined for the product type.