Instance vs Kind Extend and harmonize FHIR resources to support material and information flows

Current situation Different resources have different ways to handle “physical instance” Lack of clear support and guidance for instance has caused traceability to be a problem in implementations: Standards-guided implementations do not consider “instances” or do so inconsistently. In border cases (medication containing devices), this can cause issues. Inconsistency can also require extensions and further divergence. E.g. for adopting the EU Serialization directive, need to add “serial number” to the medication. What and where is that extension? Resources impacted: Substance Medication Device

Medication - Kind Medication - Instance { "resourceType" : "Medication", "code" : { "coding" : [ "code" : "261000", "display" : "Codeine phosphate" } ], "text" : "text representation" }, "status" : "active", "form" : {"text" : "tablets"} This is Probably a “Kind” resource { "resourceType" : "Medication", "code" : { "coding" : [ "code" : "261000", "display" : "Codeine phosphate" } ], "text" : "text representation" }, "status" : "active", "form" : {"text" : “capsules"}, "package" : { "batch" : [ "lotNumber" : "%string%", "expirationDate" : "2017-08-24T18:00:01+02:00" ] The “instance” attributes are in Package.Batch. To specify an instance, the “package” element becomes mandatory There is no link (reference) between the kind and the instance. The code is a common element, but that may not be enough – notice that the instance is for same code but different form. Without Instance information is missing, it is not clear whether this is an instance or a kind (this isn’t necessarily a problem – implementers have typically used this approach: With “instance” payload -> it’s an instance. Without “Instance” payload - > it is either a kind or a reference to an instance but without specifying in more detail.

Instance information is scattered; Device - Instance { "resourceType": "Device", "id": "example", "identifier": [ {"system": "http://regulatory_catalog_server/devices/id","value": ""}, {"type": { "coding": [ {"code": “DeviceCatalogNbr"}], "text": “Catalog Reference" }, "value": "AMID" } ], "status": "active", "type": { "coding": [{"system": "http://snomed.info/sct", "code": "86184003", "display": "Electrocardiographic monitor and recorder"}], "text": "ECG"}, "model": "AB 45-J", "version": "21", "contact": [{"system": "phone", "value": "ext 4352"}] } { "resourceType": "Device", "id": "example", "identifier": [ {"system": "http://goodcare.org/devices/id","value": "345675"}, {"type": { "coding": [ {"system": "http://hl7.org/fhir/identifier-type", "code": "SNO"}], "text": "Serial Number" }, "value": "AMID-342135-8464" } ], "status": "active", "type": { "coding": [{"system": "http://snomed.info/sct", "code": "86184003", "display": "Electrocardiographic monitor and recorder"}], "text": "ECG"}, "lotNumber": "43453424", "manufacturer": "Acme Devices, Inc", "manufactureDate": "2015-06-28", "expirationDate": "2015-06-28", "model": "AB 45-J", "version": "21", "patient": {"reference": "Patient/example"}, "owner": {"reference": "Organization/ACMEClinics"}, "location": {"reference": "Location/ACME_HQ"}, "contact": [{"system": "phone", "value": "ext 4352"}] } Identifier may not make sense - but e.g. for GUDID identifier or code is needed. Instance information is scattered; UDI information is assumed to be for Instance – but GUDID information is also needed – barcode, issuer, etc.

General remarks How does this work with inventory management? Inventory= “which instances do we have of each kind?” How to handle the thin line between medication and devices?

Requirements: (Should) Better differentiate whether it is an instance or a kind (Must Identify a kind without specifying instance (Should) For an instance, provide unambiguous link to kind E.g. when scanning a barcode, we are scanning one instance of A (Must) Identify an instance - without having to redefine the kind i.e. when specifying an instance, provide the “instance” information, and the rest link to the kind. (Should) Better support AIDC (barcodes and rfid) –scanning a barcode is not on a kind, but on an instance. Increase consistency where possible to guide implementers

Options Harmonize – simply create a pattern. Little impact, easier hard to adopt, possible because resources do not have many mandatory attributes Create a “dedicated” resource Will not be consistent across devices, medication… so not feasible Split resources? E.g. medication => medication + medicationInstance device => device + deviceInstance

Option 1 – A harmonized pattern for “instance” Instance attributes are grouped and optional. The presence of this group indicates it is an instance (Instance can have a link to kind, so that when specifying an instance, it’s possible to link to kind) Item (kind) Item (instance) 0..?

Step 1: Regroup “instance” attributes. For device, note that UDI can refer to Kind (defined at GUDID), including DIs Instance (e.g. barcode), including DIs + Pis

Extra: barcode support Step 1: Regroup “instance” attributes. Also add “serial” in medication To support the EU directive Extra: barcode support …and others such as preparation date, etc.

Other ideas Need to link an instance to its kind Add instance.kind (Reference)? Need for an identifier Only applicable for instances? Or also for Kind (seems that both make sense) Add a resource .identifier, which can be used for instances (and, if needed, for kind) Some attributes need not be duplicated. When scanning a barcode of a product, it is not needed to identify any other attributes, the only information needed is the barcode AIDC, HRF – or the actual barcode elements (lot, serial…) if the barcode is decoded. This is already covered, well with the fact that no attributes of the medication are mandatory.