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

2. 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

3. 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" : " T18: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.

4. Instance information is scattered;
Device - Instance {
"resourceType": "Device",
"id": "example",
"identifier": [
{"system": " ""},
{"type": {
"coding": [ {"code": “DeviceCatalogNbr"}],
"text": “Catalog Reference" },
"value": "AMID"
} ],
"status": "active",
"type": {
"coding": [{"system": " "code": " ",
"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": " "345675"},
{"type": {
"coding": [ {"system": " "code": "SNO"}],
"text": "Serial Number" },
"value": "AMID "
} ],
"status": "active",
"type": {
"coding": [{"system": " "code": " ",
"display": "Electrocardiographic monitor and recorder"}],
"text": "ECG"},
"lotNumber": " ",
"manufacturer": "Acme Devices, Inc",
"manufactureDate": " ",
"expirationDate": " ",
"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.

5. 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?

6. 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

7. 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

8. 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..?

9. 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”

10. 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.

11. 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.

12. 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)

13. 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)

14. 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?

15. 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.

16. 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)

17. 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

18. 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

19. 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)