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 isPhysicalInstance:Boolean isCountableInstance:Boolean Option 1: nothing Option 2: split resources Option 3: additional “instance resource”

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.

Step 2 / “refined” option: Look at the data for its meaning, not the UDI. Separate Device Identifiers from Production Identifiers Use Instance to convey Production Identifiers Include a mandatory “isPhysicalInstance” attribute, since elements cannot be empty isPhysicalInstance:Boolean isCountableInstance:Boolean (the above is just a first mockup. I did not have time to alter the resource)

This was discussed in San Diego. Conclusion: we need something to align with the RIM This should be at the Common Product Model: What we do for devices, will apply for medications, biologically derived product,… The boundary between these is not clear and will not be clear in the future, and that is ok (we have to be ok with it)

Considerations We should: Have something consistent/reusable across medication, devices, etc. (because the boundary is not clear) Other use cases are not supported yet but will be impacted by this, e.g. Inventory management?

Proposals Option 1: Change resources as needed Option 2: Define a standard extension or logical model or other choice that would apply to device, medication, etc. Option 3: Make a new resource, PhysicalInstance, which links to the "kind" resource.

Option 1: Change resource Device: leave the “kind” attributes at one level, and put the “instance attributes” in another construct Device deviceIdentifier name jurisdiction hasLotNumber: Boolean hasSerialNumber: Boolean hasManufactureDate: Boolean AIDCCarrier ... physicalInstance (or whatever name) isPhysicalInstance location patient manufactureDate: Date expiryDate: Date currentSWVersion lotNumber serialNumber carrier (do the same for medication, renaming the "package" because "package" does not have any clear meaning now, since the medication itself can be a package package has since been removed)

Option 2: Standard logical model A standard construct - logical model or other choice - that would apply to device, medication, etc. PhysicalInstance ProductType: Reference (device | medication | biologicallyDerivedProduct...) location patient manufactureDate: Date expiryDate: Date currentSWVersion lotNumber serialNumber carrier AIDCCarrier

Option 3: New Resource Make a new resource, PhysicalInstance, which links to the "kind" resource. physicalInstance (or whatever name) ProductType: Reference (device | medication | biologicallyDerivedProduct...) location patient manufactureDate: Date expiryDate: Date currentSWVersion lotNumber serialNumber carrier AIDCCarrier

Pros / Cons All options should help in the Option 3 could work best for inventory management Option 3 is a more fundamental change Option 2 can support consistency Option 1 is easier to do by each WG (but risks inconsistency)