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

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.