Stream: IG creation
Topic: Null pointer exception
Brian Reinhold (Nov 25 2018 at 15:22):
THe IG Publisher is throwing a null pointer exception but I cannot tell from the output where this is happening. The stack trace is as follows:
[java] java.lang.NullPointerException
[java] at org.hl7.fhir.igtools.publisher.IGKnowledgeProvider.getProperty(IGKnowledgeProvider.java:186)
[java] at org.hl7.fhir.igtools.publisher.IGKnowledgeProvider.getLinkFor(IGKnowledgeProvider.java:471)
[java] at org.hl7.fhir.igtools.publisher.Publisher.load(Publisher.java:1804)
[java] at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:582)
[java] at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:526)
[java] at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:4925)
[java] Exception in thread "main" java.lang.NullPointerException
[java] at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:4935)
I did add a new codesystem and two value sets to handle Device Identifiers. Before the addition there was no problem building. However, I cannot see what is wrong with what I have done. THe new system and values sets are added to the guide and they follow other coding systems/valuesets I have done.
Is it because I am extending a coding system for the Identifier.type? Do I need to do something special when extending an existing coding system (I needed to add Bluetooth Address, USB PID.VID, ZIGBEE MAC, SystemId, etc identifiers for a device that were not present in the current list.
Lloyd McKenzie (Nov 25 2018 at 16:50):
You can't extend a code system - ever. You can define codes in a new code system and define a value set that draws from both an original code systema nd a new code system. In this case, are these new identifier types or identifier systems? It seems that at least some of them should be systems...
Brian Reinhold (Nov 25 2018 at 19:25):
You can't extend a code system - ever. You can define codes in a new code system and define a value set that draws from both an original code systema nd a new code system. In this case, are these new identifier types or identifier systems? It seems that at least some of them should be systems...
I didn't think so and I did not extend the system. I defined a new codesystem containing the identifiers and two values sets, one for the system id and the other for the transport addresses.
Lloyd McKenzie (Nov 25 2018 at 19:48):
Why are you defining types for these instead of systems?
Brian Reinhold (Nov 25 2018 at 20:10):
Why are you defining types for these instead of systems?
@Lloyd McKenzie Not quite sure of what you are asking. I am not defining types but just a set of codes, like I do for the ASN1 and COntinua PAN and HFS. That is because the already defined IdentifierTypes code system does not include Bluetooth Address or System Ids as a possible identifier type. It is actually customer demand that is driving the inclusion of the transport address in the Device resource.
The new code system has these values
<concept>
<code value="SYSID"/>
<display value="IEEE 11073 System Identifier"/>
<definition value="This code indicates that the identifier is the IEEE 11073 SystemId from the equivalent of the System-Id attribute"/>
</concept>
<concept>
<code value="BTMAC"/>
<display value="Bluetooth MAC address"/>
<definition value="This code indicates that the identifier is the Bluetooth MAC address, either classic or low energy"/>
</concept>
<concept>
<code value="USB"/>
<display value="USB PID and VID designators"/>
<definition value="This code indicates that the identifier is the USB Pid and Vid values"/>
</concept>
<concept>
<code value="ZIGBEE"/>
<display value="ZigBee MAC address"/>
<definition value="This code indicates that the identifier is the ZigBee MAC address"/>
</concept>
And the two value sets group a subset of the above codes like this
<compose>
<include>
<system value="http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers"/>
<concept>
<code value="BTMAC"/>
</concept>
<concept>
<code value="USB"/>
</concept>
<concept>
<code value="ZIGBEE"/>
</concept>
</include>
</compose>
Lloyd McKenzie (Nov 25 2018 at 21:51):
What is the system for those identifiers? I.e. What's the namespace in which they're globally unique? If the identifier type has a unique system, there's no need to specify a type.
Brian Reinhold (Nov 25 2018 at 21:57):
What is the system for those identifiers? I.e. What's the namespace in which they're globally unique? If the identifier type has a unique system, there's no need to specify a type.
@Lloyd McKenzie My identifiers (in an actual Device resource) look as follows:
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
"code": "SYSID" // Indicates that this identifier is the IEEE 11073 System-Id
}
]
},
"system": "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680",
"value": "74-E8-FF-FE-FF-05-1C-00"
},
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
"code": "BTMAC" // Indicates that this identifier is the Bluetooth Address
}
]
},
"system": "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680",
"value": "00-1C-05-FF-E8-74"
}
],
The identifier.type (which is a CodeableConcept) is using this new code system. Just like I did for the Observation.component, I slice on value and the path is the type element. I then use the value set for the binding in the two cases. There is really no difference between this and the handling of the Observation.components.
Note that the identifier.system is the same for both types of identifiers, thus the need for the identifier.type element.
Lloyd McKenzie (Nov 26 2018 at 03:51):
What is the 1.2.840.10004 namespace?
Richard Townley-O'Neill (Nov 26 2018 at 04:09):
ISO/IEEE 11073 "Health informatics -- Point-of-care medical (or, Personal health) device communication"
Richard Townley-O'Neill (Nov 26 2018 at 04:10):
http://oid-info.com/cgi-bin/display?oid=1.2.840.10004&action=display
Lloyd McKenzie (Nov 26 2018 at 05:33):
The description doesn't really sound like an identifier namespace. Who manages it? How is it ensured that the identifiers within it are globally unique?
Brian Reinhold (Nov 26 2018 at 09:37):
What is the 1.2.840.10004 namespace?
@Lloyd McKenzie IEEE. Both PoCD and PHD have been using it for quite a while and it has not been causing an issue with the IG publisher. The new part of the identifier is the addition of the 'type' element. That has not been in PHD or PoCD. PoCD has no need for the transport address.
Stefan Karl (Nov 26 2018 at 09:59):
OID 1.2.840.10004.1.1.1.0.0.1.0.0.1.2680 is defined in the HL7 OID Registry (http://www.hl7.org/OID/). It's for EUI-64, so I think it doesn't apply for EUI-48. According to this page using HL7 OID is the preferred choice if no FHIR system identifier is defined.
Specific system identifiers for EUI-64 and EUI-48 have been proposed in this discussion, but didn't find their way into the FHIR specs.
Brian Reinhold (Nov 26 2018 at 11:28):
OID 1.2.840.10004.1.1.1.0.0.1.0.0.1.2680 is defined in the HL7 OID Registry (http://www.hl7.org/OID/). It's for EUI-64, so I think it doesn't apply for EUI-48. According to this page using HL7 OID is the preferred choice if no FHIR system identifier is defined.
Specific system identifiers for EUI-64 and EUI-48 have been proposed in this discussion, but didn't find their way into the FHIR specs.
I can't find an oid for EUI-48 so I am dropping the system value altogether and relying on the type.coding.code to identify the kind of transport address
I found the problem. An extra comma in a hand-edited JSON example. It would help if the tool did indicate which file caused the exception. Teaches me a lesson though. If you hand-edit these files, use a syntax checker even if it was one line!
Stefan Karl (Nov 26 2018 at 14:28):
Yes, you can make your own definition for Identifier.type. But it would greatly improve interoperability if everyone who is encoding EUI-64 or EUI-48 does it the same way.
@Lloyd McKenzie can we add the proposed "http://hl7.org/fhir/sid/eui-64" and "http://hl7.org/fhir/sid/eui-48" system identifiers to the FHIR specs?
Brian Reinhold (Nov 26 2018 at 14:53):
Yes, you can make your own definition for Identifier.type. But it would greatly improve interoperability if everyone who is encoding EUI-64 or EUI-48 does it the same way.
@Lloyd McKenzie can we add the proposed "http://hl7.org/fhir/sid/eui-64" and "http://hl7.org/fhir/sid/eui-48" system identifiers to the FHIR specs?
There are other transports as well in PHD: ZigBee, USB, and NFC. In the future there could be more.
Lloyd McKenzie (Nov 26 2018 at 15:01):
Each transport is presumably a distinct namespace and should have a distinct system - the combination of system + value must be globally unique. Identifier type is ignored when comparing identifiers to see if they match.
Brian Reinhold (Nov 26 2018 at 15:03):
@Lloyd McKenzie Would be nice ... and if they do it would be nice to find out what they are!
Lloyd McKenzie (Nov 26 2018 at 15:09):
It's possible they haven't been defined yet. But it's not a "would be nice" situation. If the values have different namespaces, they must have different systems.
Brian Reinhold (Nov 26 2018 at 16:32):
@Lloyd McKenzie What would it take to define these systems?
"http://hl7.org/fhir/sid/eui-64" for system id or the OID
"http://hl7.org/fhir/sid/eui-48" for Bluetooth mac
? for Ethernet MAC (48-bit value but I do not know if it is an EUI)
? for USB
? for ZigBee (64-bit value but I do not know if it is an EUI)
Lloyd McKenzie (Nov 26 2018 at 16:36):
Change requests to the attention of the vocab work group
Brian Reinhold (Nov 26 2018 at 17:00):
Change requests to the attention of the vocab work group
@Lloyd McKenzie seems tough to get done in time for ballot
@Stefan Karl Got any good ideas here?
for the system id we already have urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680
For the Bluetooth Address which is an EUI-48 ?
For the Ethernet MAC address which is an EUI-48
For the ZigBee address which is 64 bits?
For the USB designator which is the VID and PID?
For NFC which I know nothing about but is a PHD transport?
Stefan Karl (Nov 26 2018 at 17:07):
For EUI-64 and EUI-48 there is a good guidance document here. 48-bit MAC addresses are also considered EUI-48.
Brian Reinhold (Nov 26 2018 at 17:13):
For EUI-64 and EUI-48 there is a good guidance document here. 48-bit MAC addresses are also considered EUI-48.
@Stefan Karl How does one know that one is a Bluetooth address and the other is an Ethernet MAC address? My Android has both. There needs to be some way to distinguish between these different types of addresses which are of the same 'type'. Customers have 'demanded' the inclusion of these addresses as they are often on the device itself. But you need to know what 48-bit number you are looking at, or in the case of ZigBee, 64-bit.
Brian Reinhold (Nov 26 2018 at 20:49):
In the absence of all else, and the apparent NEED to use only system and value in the identifier to discriminate (the type does NOT work so you cant invent codes to solve the problem) how about these for the transport addresses (placeholders until something real comes along:
"http://hl7.org/fhir/sid/eui-64/ZigBee"
"http://hl7.org/fhir/sid/eui-48/BTMAC"
"http://hl7.org/fhir/sid/eui-48/ETHMAC"
"http://hl7.org/fhir/sid/USB"
Lloyd McKenzie (Nov 26 2018 at 21:29):
If eui-48 is, itself a unique namespace, we don't actually need BTMAC and ETHMAC. I.e. If you have an arbitrary value and you know it's an EUI-48, and you match with another EUI-48, does that tell you for certain it's the same instance?
Brian Reinhold (Nov 26 2018 at 21:31):
@Lloyd McKenzie I'm looking for a way for a reader to be able to tell that one of the EUI-48's is a Bluetooth Address and the other is an Ethernet MAC address. A device can have both (for example an Android)
Null pointer exception
Lloyd McKenzie (Nov 26 2018 at 21:43):
I understand. The question is what the right division is between "type" and "system". The system defines the namespace that ensures global uniqueness - and that's all it does. We need to ensure that systems are defined at the level of what ensures that uniqueness. Is EUI-48 a single namespace across which all identifiers are unique? I.e. there's no possibility that the Bluetooth address of one device might end up being the MAC address of a different device?
Brian Reinhold (Nov 26 2018 at 21:48):
I understand. The question is what the right division is between "type" and "system". The system defines the namespace that ensures global uniqueness - and that's all it does. We need to ensure that systems are defined at the level of what ensures that uniqueness. Is EUI-48 a single namespace across which all identifiers are unique? I.e. there's no possibility that the Bluetooth address of one device might end up being the MAC address of a different device?
@Lloyd McKenzie That is a good question. I do not know. But from what I have read, standards (like Bluetooth) only require that the Bluetooth address be unique, and of course this is in the context of Bluetooth transports. Given that the physical mechanisms are different, a Bluetooth address that happens to be the same as an Ethernet MAC address is not going to cause a clash. So it does not seem like there is a reason for them to be unique across both transport platforms. That being said I have never seen the two be the same. However, it is often the case that a device that has both Ethernet and Bluetooth get the chips from separate manufactures ensuring uniqueness (the OUI).
Nevertheless, there is still no way to tell which of the two EUI-48s are Bluetooth or Ethernet MACs if all you have is an EUI-48 system value.
Lloyd McKenzie (Nov 26 2018 at 21:58):
The question is whether the EUI-48 mechanism prevents collisions because all identifiers are from the same namespace. If the answer is yes, then there should only be one system id.
Brian Reinhold (Nov 26 2018 at 22:04):
The question is whether the EUI-48 mechanism prevents collisions because all identifiers are from the same namespace. If the answer is yes, then there should only be one system id.
@Lloyd McKenzie
So then I see something like this:
"identifier": [
{
"system": "http://hl7.org/fhir/sid/eui-48",
"value": "74-E8-FF-FE-FF-05"
},
{
"system": "http://hl7.org/fhir/sid/eui-48",
"value": "00-1C-05-FF-E8-74"
}
],
Which is the Bluetooth address and which is the Ethernet MAC address? I need some more information. So do I need to keep my Code System for the 'type' if I want to let the downstream readers know?
(slicing on fixed system value does work).
Lloyd McKenzie (Nov 26 2018 at 23:21):
IF they have the same namespace, then yes you'll need to slice by both Identifier.system (by value) and Identifier.type (by pattern)
Last updated: Apr 12 2022 at 19:14 UTC
