In a recent post, we talked about the challenges of describing medical devices such as needles, tubes and catheters in a structured format. The existing device HL7-FHIR resources and OpenEHR archetypes are weighted in favour of electro-mechanical devices, rather than those of the non-communicating “dumb” variety.
The efforts of the SCATA Open Standards Working Group to tease out the unique properties of the non-electro-mechanical devices may ultimately bring a new set of resources that manufacturers can leverage to describe their products in greater detail, in a standard way.
2D Barcodes
As of 2022, according to wikipedia, there are 43 different 2D barcode systems. This number is likely to change as different systems are adopted as standards, or fall away through disuse.
Product manufacturers use barcodes extensively for a variety of purposes. For better or worse, the 2020 pandemic has given the QR code a real shot in the arm – pun intended. Although not unique to the QR code, it has the ability to encode a URL which can be scanned using the camera on a smartphone. The smartphone can then give the user the option to open the URL in a browser. We’ve become familiar with this routine in the form of the check-in at the entrance to restaurants, pubs and clubs, with the URL essentially taking the user to a form where they input some personal information.
Linking the QR code URL to an Open API
An extension of this idea imagines a staff member with a smartphone in healthcare scanning a QR code on the packaging of a device such as an ET tube or a CVC kit. The URL is an API call (most likely a GET) with the ID of the product as a parameter.
An example might be https://someopenapi.com?deviceid=1234567
Clearly, there is a debate to be had about who manages the API, how many APIs are needed (just one, or one for each supplier/manufacturer?), how products are validated and what happens if validation fails, the product is missing, or the data returned is incomplete or inaccurate. Also, the actual ID of the product will have to be universally unique – not a major challenge to generate, but with significant overhead on the part of the supplier (or intermediate data controller) to manage and maintain.
Leaving those concerns aside for a moment, vendors are familiar with printing barcodes (2D or otherwise) on their products. If, as a result of scanning a 2D barcode on a product, a smartphone browser-based app could return data from an API, then in theory it could pass that data to an application, which can then store it.
Our intent is to build an open API prototype as a proof-of-concept, to demonstrate that using the camera on a smartphone, a healthcare worker can populate a section of a clinical record, namely the properties of a device (or devices in the case of a kit) used in an episode of care.
