Stream: IG creation
Topic: system values for transport addresses
Brian Reinhold (Nov 29 2018 at 22:17):
@Grahame Grieve what would it take to get system identifiers for transport addresses (also a way to uniquely identify a device?
Right now we have
Device.identifier.system = "urn:iso:std:iso:11073:10101" for the system id value in the MDC coding system
But what we need are identifiers for Bluetooth Address (an EUI-48), Ethernet MAC address (also an EUI-48), ZigBee address (64-bits but I am not sure if it is an EUI-64) and USB pid-vid.
Right now I am using a made-up http://hl7.org/fhir/sid/eui-48 for the BT and MAC address and have made a code system to populate the Device.identifier.type.coding.code element with either "BTMAC" or "ETHMAC".
Does http://hl7.org/fhir/sid/eui-48/bluetooth and http://hl7.org/fhir/sid/eui-48/ethernet make sense? Would make slicing a lot easier!
Not sure if http://hl7.org/fhir/sid/eui-64/zigbee would be okay and I have no idea how to handle USB
I have one day left before this goes into freeze!
Grahame Grieve (Nov 29 2018 at 23:29):
system identifiers have their challenges. In theory, we decide. We prefer to decide collaboratively with the native owners, but I'm guessing that's not possible in these cases?
Brian Reinhold (Nov 30 2018 at 00:18):
system identifiers have their challenges. In theory, we decide. We prefer to decide collaboratively with the native owners, but I'm guessing that's not possible in these cases?
@Grahame Grieve I am not sure who the native owners are. But I needed something because I cannot slice on an identifier using the type ... it doesnt work. Lloyd told me so as I tried it and got errors. Made no sense. Had to slice on system or value in the identifier
Grahame Grieve (Nov 30 2018 at 00:56):
ok go with:
- http://hl7.org/fhir/sid/eui-48/bluetooth
- http://hl7.org/fhir/sid/eui-48/ethernet
- http://hl7.org/fhir/sid/eui-64/zigbee
Note somewhere in the narrative that these are not finalised yet
Lloyd McKenzie (Dec 10 2018 at 23:53):
And add a change request so w can follow up and nail them down for a future version
Brian Reinhold (Feb 18 2021 at 12:03):
Grahame Grieve said:
ok go with:
- http://hl7.org/fhir/sid/eui-48/bluetooth
- http://hl7.org/fhir/sid/eui-48/ethernet
- http://hl7.org/fhir/sid/eui-64/zigbee
Note somewhere in the narrative that these are not finalised yet
I know this is ancient but I use these URLs in the PHD IG but now the validator gives me an error saying that they do not resolve. I do not recall if I made a JIRA issue (I probably did) because it was so long ago.
Found the issue: It is
https://jira.hl7.org/browse/HTA-15?filter=-2
In the mean time I replaced the bluetooth URL with this one
https://standards.ieee.org/products-services/regauth/oui/index.html
throughout the guide which does resolve (which I would gladly revert).
Brian Reinhold (Feb 21 2021 at 12:35):
@Grahame Grieve @Lloyd McKenzie
Any news on this?
Thanks
Grahame Grieve (Feb 24 2021 at 03:26):
I forget what the issues are on this one
Brian Reinhold (Feb 24 2021 at 12:48):
Grahame Grieve said:
I forget what the issues are on this one
It's just a system value for a Bluetooth Address (or other transport addresses). We have one for the IEEE EUI-64 System Identifier. That's this long and ugly Oid: urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680 but we need one for some of the other much more commonly used device identifiers such as the Bluetooth, ethernet MAC, and ZigBee addresses. You had previously suggested that list above and I went with it. But today the validator gives an error on that link as it is unresolvable. To get around it I have used an IEEE URL which points to information about a obtaining a Bluetooth Address https://standards.ieee.org/products-services/regauth/oui/index.html
I have no idea how persistent or relevant that URL is.
Grahame Grieve (Feb 24 2021 at 20:09):
well, we don't have any formal standing for the idea other than that I suggested it, right? Do you want to make a task for FHIR-I to sign off on them?
Brian Reinhold (Mar 01 2021 at 13:57):
Grahame Grieve said:
well, we don't have any formal standing for the idea other than that I suggested it, right? Do you want to make a task for FHIR-I to sign off on them?
Yes please. I will need something to pass the validator. How should I do this?
Brian Reinhold (Mar 03 2021 at 12:26):
@Rick Geimer Rick, being part of FHIR I can you help here?
Brian Reinhold (Mar 08 2021 at 13:55):
@Grahame Grieve @Lloyd McKenzie
Should I just use the proposed URLs in the guide and explain the errors? Otherwise this guide will never get published.
Lloyd McKenzie (Mar 08 2021 at 14:36):
We can't publish URLs without approval from HTA. @Reuben Daniels @Julie James @Carol Macumber: https://jira.hl7.org/browse/HTA-15 seems to have been stalled for close to 2 years. Can we please get a final decision so @Brian Reinhold can publish?
Carol Macumber (Mar 08 2021 at 15:23):
@Brian Reinhold
I've commented on the JIRA ticket and registered the following with HTA:
http://terminology.hl7.org/CodeSystem/eui-48/bluetooth
http://terminology.hl7.org/CodeSystem/eui-48/ethernet
http://terminology.hl7.org/CodeSystem/eui-64/zigbee
Note, code system metadata must be gathered and documented for each code system here:
https://confluence.hl7.org/display/TA/48-bit+Extended+Unique+Identifiers+%28EUI-48%29+-+Bluetooth
https://confluence.hl7.org/display/TA/48-bit+Extended+Unique+Identifiers+%28EUI-48%29+-+Ethernet
https://confluence.hl7.org/display/TA/48-bit+Extended+Unique+Identifiers+%28EUI-48%29+-+Zigbee
Lloyd McKenzie (Mar 08 2021 at 15:25):
Um, why do we have a complex path beneath CodeSystem? CodeSystem ids can't have a "/" in them. So presumably it should be eui-48-bluetooth, not eui-48/bluetooth, for example? @Carol Macumber
Brian Reinhold (Mar 08 2021 at 17:01):
Thanks Lloyd
Brian
Brian Reinhold (Mar 08 2021 at 19:42):
@Carol Macumber
Can you give me an example of one that is filled out?
Carol Macumber (Mar 08 2021 at 20:21):
Lloyd McKenzie said:
Um, why do we have a complex path beneath CodeSystem? CodeSystem ids can't have a "/" in them. So presumably it should be eui-48-bluetooth, not eui-48/bluetooth, for example? Carol Macumber
Updated to replace / with -
Carol Macumber (Mar 08 2021 at 20:30):
@Brian Reinhold We're in the process of utilizing the new template which prepares data to be transferred to THO, so there is only one that is in progress that follows the new template (SNOMED CT International). Here are some pages with the old format that give you an idea of what level of documentation is appropriate.
https://confluence.hl7.org/pages/viewpage.action?pageId=97452084
Brian Reinhold (Mar 09 2021 at 15:28):
@Carol Macumber
I'm am having a hard time with dealing with this system as these transport addresses can be anything. I am not sure it is a code system per se.
Here is an example of its use in a Device.identifier element:
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
"code": "SYSID",
"display": "System Identifier"
}
]
},
"system": "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680",
"value": "00-00-00-00-00-00-00-00"
},
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
"code": "BTMAC",
"display": "Bluetooth Address"
}
]
},
"system": "http://hl7.org/fhir/sid/eui-48/bluetooth",
"value": "00-17-E9-54-C8-52"
}
]
Who 'owns' these? I think IEEE defines at least the Bluetooth addresses. One has to register a Bluetooth address with IEEE in any case. I assume its the same for the Wireless MAC address as well; I don't know about ZigBee. There is code system the IG has defined to identify that this is a Bluetooth address but the Bluetooth address itself does not have a system associated with it. You see that the system identifier (the first entry) does have a system value. Who owns this? FHIR? How do I define the possible codes (a Bluetooth address is not really a code but a unique identifier of a device)?
Rob Hausam (Mar 09 2021 at 15:46):
I agree that a Bluetooth address is an identifier and not a code.
Rob Hausam (Mar 09 2021 at 15:49):
But an identifier also has a 'system' element: "The namespace for the identifier value" - which is what I think your example shows.
Brian Reinhold (Mar 09 2021 at 22:41):
@Rob Hausam You hit the nail on the head. I am looking for the system element of that identifier. It is not a code system. Code systems have system elements, too. But I need a URL for the system value in that identifier that wont cause an error in the Validator. How does one register an identifier system value?
Brian Reinhold (Mar 10 2021 at 10:12):
Rob Hausam said:
But an identifier also has a 'system' element: "The namespace for the identifier value" - which is what I think your example shows.
That's what I need - an acceptable identifier 'namespace' or some acceptable value for the system element of the Device.identifier. Grahame suggested some a couple of years ago and I am using them, however, the validator rejects them because they do not resolve. How can this be fixed?
Brian Reinhold (Mar 11 2021 at 12:43):
Carol Macumber
!! UNABLE TO EDIT YOUR FORMS !!
Please add the (probably never will be used case) for usb 'http://hl7.org/fhir/sid/usb"
Though since these are identifiers and not code systems we probably need a different namespace designation than the suggested with CodeSystem in it.
Carol Macumber (Mar 11 2021 at 14:14):
@Brian Reinhold
Are you logged into Confluence? The pages aren't locked down, just require users to be logged in.
Also, apologies as I assumed incorrectly that these were well formed and known code systems that had been in use. I don't think the way we've defined them as code systems here is correct either. We'll get back to you on recommended changes.
Brian Reinhold (Mar 11 2021 at 16:03):
@Carol Macumber
Thank you. What do I use to log into COnfluence? I have a login for Confluence my company uses but I don't think that applies here.
Carol Macumber (Mar 11 2021 at 17:23):
@Brian Reinhold , you can request an account on the main HL7 Confluence page
https://confluence.hl7.org/
Brian Reinhold (Mar 11 2021 at 18:51):
@Carol Macumber Turns out I already had an account. Could use the one I had for HL7 JIRA
Lloyd McKenzie (Mar 11 2021 at 18:54):
Jira and Confluence counts are one and the same.
Brian Reinhold (Mar 15 2021 at 18:01):
@Carol Macumber Any news on the identifier front?
Carol Macumber (Mar 15 2021 at 18:06):
Hey Brian -
Apologies. Vocab chairs discussed late last week. Connecting you with Jessica Bota (PM for UTG project), as we think that the solution here is to use the Naming System resource at Terminology.HL7.Org. From there you would use the NamingSystem.uniqueId.value as the system.identifier in your resources. To create the resource, Jessica can walk you through the JIRA process.
C
@Jessica Snell @Ted Klein
Brian Reinhold (Mar 16 2021 at 19:25):
@Carol Macumber
Is this barking up the right tree?
{
"resourceType": "NamingSystem",
"id": "bluetooth-id",
"url": "http://hl7.org/fhir/sid/eui-48/bluetooth",
"name": "Bluetooth Address device identifier",
"status": "active",
"kind": "identifier",
"date": "2021-03-16",
"publisher": "Personal Health Device Implementation Guide",
"contact": [
{
"name": "Devices on FHIR Working Group",
"telecom": [
{
"system": "email",
"value": "devicesonfhir@lists.hl7.org"
}
]
}
],
"responsible": "Devices on FHIR Working Group",
"description": "Bluetooth EUI-48 address used in communicating medical devices",
"uniqueId": [
{
"type": "uri",
"value": "http://hl7.org/fhir/sid/eui-48/bluetooth",
"preferred": true,
"period": {
"start": "2021-03-21"
}
}
]
}
Jessica Bota (Mar 16 2021 at 19:49):
@Brian Reinhold , you are very close. In terminology.hl7.org, we need to use extensions for title, url, and version. Here is a link to an example.
@Carol Macumber @Ted Klein
Jessica Bota (Mar 16 2021 at 19:51):
http://build.fhir.org/ig/HL7/UTG/NamingSystem-icd10CM.json.html
Brian Reinhold (Mar 16 2021 at 20:25):
@Jessica Snell
I didn't catch the example you sent but picked the MDC one I found through the list in the guide.
How about this?
<NamingSystem xmlns="http://hl7.org/fhir">
<id value="dev-transport-addresses"/>
<extension url="http://hl7.org/fhir/tools/StructureDefinition/extension-title">
<valueString value="Communicating Devices Transport Addresses"/>
</extension>
<extension
url="http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url">
<valueUri value="http://terminology.hl7.org/NamingSystem/dev-transport-addresses"/>
</extension>
<extension
url="http://terminology.hl7.org/StructureDefinition/ext-namingsystem-version">
<valueString value="2.1.0"/>
</extension>
<name value="DevTransportAddresses"/>
<status value="active"/>
<kind value="identifier"/>
<date value="2021-03-16T00:00:00-04:00"/>
<publisher value="Devices on FHIR working group"/>
<contact>
<name value="Brian Reinhold"/>
</contact>
<responsible value="Devices on FHIR working group"/>
<description
value="The namespaces identify different types of transport addresses used in communicating medical devices; Bluetooth, ZigBee, Ethernet MAC, USB."/>
<uniqueId>
<type value="uri"/>
<value value="http://hl7.org/fhir/sid/eui-48/bluetooth"/>
<preferred value="true"/>
<comment value="Bluetooth EUI-48 address" />
</uniqueId>
<uniqueId>
<type value="uri"/>
<value value="http://hl7.org/fhir/sid/eui-48/ethernet"/>
<preferred value="true"/>
<comment value="Ethernet EUI-48 Mac address" />
</uniqueId>
<uniqueId>
<type value="uri"/>
<value value="http://hl7.org/fhir/sid/eui-64/zigbee"/>
<preferred value="true"/>
<comment value="ZigBee EUI-64 address" />
</uniqueId>
<uniqueId>
<type value="uri"/>
<value value="http://hl7.org/fhir/sid/usb"/>
<preferred value="true"/>
<comment value="USB PID and VID communication identifiers" />
</uniqueId>
</NamingSystem>
Jessica Bota (Mar 16 2021 at 20:31):
@Brian Reinhold It pasted below the message. I should have noted that the THO entries are XML files (but we do display the json translation on the build pages too). If you use those three extensions for title, url, and version then it should work with THO.
Brian Reinhold (Mar 16 2021 at 21:14):
@Jessica Snell Do I need a separate resource for each of the transport address identifiers, or can I use just one?
Lloyd McKenzie (Mar 16 2021 at 21:30):
Separate for each if they're separate namespaces
Peter Jordan (Mar 16 2021 at 22:51):
That NamingSystem resource has 4 preferred identifiers of type uri and they appear to be for different types of identifier. so I definitely agree that you probably need a separate NamingSystem resource for each one. However, I would suggest that you look at the Endpoint Resource as an alternative way of serving your use case as NamingSystem is really meant for identifier management, not transport addresses.
Brian Reinhold (Mar 17 2021 at 12:32):
@Peter Jordan The requirement to use the NamingSystem resource is from the Terminology group. This is the resource they have asked me to use and they have certain fields that must be set in certain ways for their purposes. Not that I understand them all yet, but I am working on it.
Brian Reinhold (Mar 17 2021 at 12:50):
@Jessica Snell
Okay, here I have another attempt for a single case. We have a PHD oriented DoF (Devices on FHIR) WG meeting in 15 minutes. Would be nice (but not expected given the short notice) if you could comment before then ....
{
"resourceType" : "NamingSystem",
"id" : "bluetooth-address-identifier",
"extension" : [
{
"url" : "http://hl7.org/fhir/tools/StructureDefinition/extension-title",
"valueString" : "Bluetooth Address as a device identifier"
},
{
"url" : "http://terminology.hl7.org/StructureDefinition/ext-namingsystem-version",
"valueString" : "2.2.1"
}
],
"name" : "Bluetooth_Address_Identifier",
"status" : "active",
"kind" : "identifier",
"date" : "2021-02-16T00:00:00-04:00",
"publisher" : "IHE PCD",
"contact" : [
{
"name" : "Devices on FHIR working group; IHE PCD"
}
],
"responsible" : "IHE PCD",
"description" : "THe IHE PCD handles standardization of communicating medical devices for both acute point of care and remote patient monitoring uses.",
"uniqueId" : [
{
"type" : "uri",
"value" : "http://hl7.org/fhir/sid/eui-48/bluetooth",
"preferred" : true,
}
]
}
Jessica Bota (Mar 17 2021 at 13:01):
@Brian Reinhold , I agree with Lloyd and Peter that they should be separate NamingSystems.
Jessica Bota (Mar 17 2021 at 13:03):
@Brian Reinhold Your example is close but missing the extension for url. Should be like below for your last example:
<extension
url="http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url">
<valueUri value="http://terminology.hl7.org/NamingSystem/bluetooth-address-identifier"/>
</extension>
Brian Reinhold (Mar 17 2021 at 14:16):
@Jessica Snell
A new and improved version!!! Hot off the press! (I suppose the 'preferred' element can be removed. There is only one.)
{
"resourceType" : "NamingSystem",
"id" : "bluetooth-address-identifier",
"extension" : [
{
"url" : "http://hl7.org/fhir/tools/StructureDefinition/extension-title",
"valueString" : "Bluetooth Address as a device identifier"
},
{
"url" : "http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url",
"valueUri" : "http://terminology.hl7.org/NamingSystem/bluetooth-address-identifier"
},
{
"url" : "http://terminology.hl7.org/StructureDefinition/ext-namingsystem-version",
"valueString" : "2.2.1"
}
],
"name" : "Bluetooth_Address_Identifier",
"status" : "active",
"kind" : "identifier",
"date" : "2021-02-16T00:00:00-04:00",
"publisher" : "IHE PCD",
"contact" : [
{
"name" : "Devices on FHIR working group; IHE PCD"
}
],
"responsible" : "IHE PCD",
"description" : "THe IHE PCD handles standardization of communicating medical devices for both acute point of care and remote patient monitoring uses.",
"uniqueId" : [
{
"type" : "uri",
"value" : "http://hl7.org/fhir/sid/eui-48/bluetooth",
"preferred" : true,
}
]
}
Lloyd McKenzie (Mar 17 2021 at 14:21):
Small typo in description (THe -> The). Can you expand the PCD acronym? Other than that, looks good to me.
Jessica Bota (Mar 17 2021 at 14:25):
Looks good to me too. Just note that to submit it through UTG to get it into terminology.hl7.org it will need to be in XML format.
Brian Reinhold (Mar 17 2021 at 15:10):
@Jessica Snell
Here it is in xml form. What is UTG?
<NamingSystem xmlns="http://hl7.org/fhir">
<id value="bluetooth-address-identifier"/>
<extension url="http://hl7.org/fhir/tools/StructureDefinition/extension-title">
<valueString value="Bluetooth Address as a device identifier"/>
</extension>
<extension url="http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url">
<valueUri value="http://terminology.hl7.org/NamingSystem/bluetooth-address-identifier"/>
</extension>
<extension url="http://terminology.hl7.org/StructureDefinition/ext-namingsystem-version">
<valueString value="2.1.0"/>
</extension>
<name value="Bluetooth_Address_Identifier"/>
<status value="active"/>
<kind value="identifier"/>
<date value="2021-03-16T00:00:00-04:00"/>
<publisher value="IHE Patient Care Devices (PCD)"/>
<contact>
<name value="Devices on FHIR working group; IHE Patient Care Devices"/>
</contact>
<responsible value="IHE Patient Care Devices"/>
<description value="The IHE Patient Care Devices handles standardization of communicating medical devices for both acute point of care and remote patient monitoring uses."/>
<uniqueId>
<type value="uri"/>
<value value="http://hl7.org/fhir/sid/eui-48/bluetooth"/>
<preferred value="true"/>
<comment value="Bluetooth EUI-48 address" />
</uniqueId>
</NamingSystem>
Lloyd McKenzie (Mar 17 2021 at 16:16):
UTG is the process of requesting changes to terminology using the Jira project - https://jira.hl7.org/projects/UP
Jessica Bota (Mar 17 2021 at 19:21):
Thanks Lloyd. I responded via email but should have here as well. More info here: https://confluence.hl7.org/display/VMAH/Vocabulary+Maintenance+at+HL7
Brian Reinhold (Mar 22 2021 at 13:11):
@Lloyd McKenzie Lloyd, THO does not want to include identifiers in its scope so they suggested I turn to the FHIR registry. I am not sure what that is. Is there a good home for identifiers?
Lloyd McKenzie (Mar 22 2021 at 13:29):
@Rob Hausam Do we know why vocabulary is taking that position? THO is the logical place to manage 'identifier' NamingSystems. The same requirements in terms of community review and custodianship apply and, like CodeSystems, they are independent of product family.
Lloyd McKenzie (Mar 22 2021 at 13:30):
Also, the notion of engagement with external organizations is pretty much identical (where it makes sense to bother)
Brian Reinhold (Mar 22 2021 at 13:39):
Lloyd McKenzie Would it look something like this?
(See attachemnt) at
http://build.fhir.org/identifier-registry.html
identifiers.docx
Lloyd McKenzie (Mar 22 2021 at 14:05):
That's where those are now - but the intention is that all of those move into THO
Rob Hausam (Mar 22 2021 at 15:15):
@Lloyd McKenzie The discussion in Vocab was basically around the sense that terminology and identifier systems are different things, and therefore identifier systems potentially should be managed in a different place (like the FHIR registry?), and also that the additional resources needed to handle the creation and maintenance of the identifier systems aren't really available in Vocab and for THO so the focus there should remain on terminology.
Brian Reinhold (Mar 22 2021 at 15:17):
@Lloyd McKenzie
I was just hoping that might solve the issues with the PHD IG. If they eventually move to THO those identifiers can move with them. Is it a difficult process to add those identifiers to that list?
Lloyd McKenzie (Mar 22 2021 at 15:47):
@Rob Hausam This decision needs to be revisited. (And I want to be part of the discussion.) This isn't something that's FHIR-specific - these are cross-family issues. Proposals for addition and revision require public review and comment. There's a need to tie into our processes for engagement with external organizations. FHIR registry doesn't meet any of those requirements. I understand the resource challenges, but those challenges exist regardless of where we put the work. The work belongs with THO - where there are people who understand what a 'namespace' actually is, who can evaluate whether a request coming in is appropriate as a code system vs. an identifier system, who understand the backward compatibility and cross-standard impact of updates, etc.
Lloyd McKenzie (Mar 22 2021 at 15:49):
Also, this is content that needs to be updated 'continuously' and available to all IGs. We have that machinery in place for THO. We don't have it in place for anything else.
Lloyd McKenzie (Mar 22 2021 at 15:50):
@Brian Reinhold Understand you're getting caught in the middle here. Adding stuff to the list you referenced won't be officially published until 2022. We can put it in the CI build, but that's not going to help for an R4 IG.
Lloyd McKenzie (Mar 22 2021 at 16:17):
@Robert McClure
Lloyd McKenzie (Mar 22 2021 at 16:17):
@Reuben Daniels
Lloyd McKenzie (Mar 22 2021 at 16:17):
@Ted Klein
Lloyd McKenzie (Mar 22 2021 at 16:18):
@Carol Macumber
Brian Reinhold (Mar 22 2021 at 19:07):
Lloyd McKenzie said:
Brian Reinhold Understand you're getting caught in the middle here. Adding stuff to the list you referenced won't be officially published until 2022. We can put it in the CI build, but that's not going to help for an R4 IG.
Any suggestions what I should do for the PHD IG?
Ted Klein (Mar 22 2021 at 19:08):
Although the last thing I want or need is to increase the scope of what UTG and THO needs to deal with, I agree with Lloyd. It can only be addressed in THO and UTG if we can find a way to get far enough towards what is needed with what we currently have with little or no changes. Otherwise any major enhancements will delay it for an unknown period of time.
Lloyd McKenzie (Mar 22 2021 at 21:06):
We already support NamingSystem in UTG. I expect we'd want another List and page in the IG. Change request process should be similar. Ideally we'd want a new request type, but if that triggers too much grief, we could fudge it in the short term
Ted Klein (Mar 22 2021 at 21:39):
@Peter Jordan suggests above that NamingSystem would be inappropriate. I am not familiar with FHIR-I guidance and teaching on the use of NamingSystem in FHIR @Lloyd McKenzie so I cannot have an opinion. There are a raft of UI changes for UTG/THO on the list, and if the final decision is to make use of NamingSystem (with an appropriate value in <kind>) then it will just have to get slotted into the list of stuff to do. We know how to do all this, it seems we just do not yet have consensus.
Lloyd McKenzie (Mar 22 2021 at 21:47):
The use-case here is identifiers, not endpoints. NamingSystem is the correct choice.
Carol Macumber (Mar 22 2021 at 21:48):
Vocab co-chairs discussed today...unfortunately as Ted explained to us, THO currently does not support representing identifier systems in a separate List and there would be work that isn't currently planned to make it happen. @Ted Klein can expound if there are questions on current limitations. Ideally, we would be able to support this identifier system, along with those here https://www.hl7.org/fhir/identifier-registry.html at THO so we are consistent and have a process (via UTG) in place for maintenance. In the meantime, can we add the transport address identifier system to this page?@
Lloyd McKenzie , we can discuss further at either our next chairs call (Monday's at 3pm Eastern) or on the next Vocab WG Call (4/1 @330 Eastern).
@Carmela Couderc @Reuben Daniels @Rob Hausam @Robert McClure
Ted Klein (Mar 22 2021 at 21:58):
It is mostly UI work in the NamingSystem area of THO, and there is pending UI work in this area to support the HTA requirements. So not a huge amount of work, but competing with a large number of other tasks in the same area. Up to you all to decide the direction and priority.
Lloyd McKenzie (Mar 22 2021 at 22:01):
I'm supposed to be on vacation next week, but I'll make time - which call would you prefer me at?
Peter Jordan (Mar 23 2021 at 00:26):
Lloyd McKenzie said:
The use-case here is identifiers, not endpoints. NamingSystem is the correct choice.
I'm not sure how you've reached that conclusion. IMO, Transport Addresses for the likes of Bluetooth and Ethernet are best placed in Endpoint Resources, rather than as identifiers on other resources (such as ??). A second best option is to use an extension on ContactPoint.system.
Lloyd McKenzie (Mar 23 2021 at 01:38):
We're sharing the Device and providing an identifier for that Device. The use-case isn't about saying "here's how to talk to the Device". If we were doing that, we'd be exposing a very different set of information.
Peter Jordan (Mar 23 2021 at 04:56):
OK - thrown by the use of transport/network address and protocols in this thread. :thinking: For device identifiers, aren't you in GTIN Territory?
Lloyd McKenzie (Mar 23 2021 at 05:20):
They'd probably have one of those too - but we want to represent the bluetooth ids too
Ted Klein (Mar 23 2021 at 15:34):
Sigh. GTIN is one of those items that was added several years ago to V3 coremif as an identifier system, but as V3 had no special resources for identifiers systems, it was modeled as a CodeSystem. It quietly came on board with the coremif import and it sitting in THO awaiting decisions on how we intend to handle identifier systems and when to schedule the cleanup of such old dross.
Lloyd McKenzie (Mar 24 2021 at 18:33):
@Carol Macumber @Robert McClure Preferences for the Monday vs. Thursday call?
Carol Macumber (Mar 24 2021 at 19:18):
I'd say this Monday. However Rob and I are going to be at the ONC meeting for portions of the day. @Robert McClure , can you make our normal 3pm chairs call? If not, then we should plan for the following Monday.
@Carmela Couderc , depending on the answer from Rob, we will need to add this item as the first on our docket for the chairs call.
Robert McClure (Mar 25 2021 at 15:45):
I will not be able to make the chair call at 3p ET Monday. The ONC breakout is "Social Determinants of Health Information Exchange: Innovation, Consent, Referrals, and Equity" so I have to be there. Next week? @Carol Macumber @Lloyd McKenzie
Lloyd McKenzie (Mar 25 2021 at 16:01):
That works better for me. So Apr. 5 at 3 Eastern?
Brian Reinhold (Mar 29 2021 at 12:04):
@Lloyd McKenzie @Peter Jordan Lloyd is right here. These transport addresses are a means to identify the device, as they are unique for a device instance. One can use these addresses as identifiers whether or not the transport is actually used to communicate data.
Given that, it is used in slicing to identify the PCHA identifier used in conditional creates to avoid data duplication. Would it be reasonable to state in the guide that the namespace for the identifier will be eventually listed in the FHIR system but for the time being the namespace's purpose is only a means for a reader distinguish between the possible transport addresses. For example, both the MAC and BT addresses are EUI-48's and there is no way to distinguish between them without the namespace.
Brian Reinhold (Apr 14 2021 at 13:15):
@Lloyd McKenzie Any results with respect to transports/namespaces/identifiers in the April 5th meeting?
What action do I need to take to move forward?
Lloyd McKenzie (Apr 15 2021 at 20:53):
There was an agreement to on responsibility for this in terminology.fhir.org and someone from the vocab group is supposed to work with you to get the proposals through.
Brian Reinhold (Apr 28 2021 at 19:48):
@Lloyd McKenzie No one has gotten in contact with me yet. Can you give me a name? The link is broken.
Lloyd McKenzie (Apr 28 2021 at 22:17):
I think it was Jessica Bota, but I'm not positive (and she doesn't seem to be on Zulip?) @Carol Macumber @Robert McClure - do either of you know who's supposed to be helping Brian with his NamingSystem proposal in UTG?
Brian Reinhold (Apr 28 2021 at 22:39):
@Lloyd McKenzie Thanks
Jessica Bota (Apr 29 2021 at 13:57):
@Brian Reinhold , I can help you submit a Naming System proposal. If you haven't, check out the Submitter section on this page: https://confluence.hl7.org/display/VMAH/Vocabulary+Maintenance+at+HL7. Feel free to email me with questions. This request is new to me, so if there is additional context I need, please let me know.
@Lloyd McKenzie , apologies, my Zulip account was still using my old name. I updated it. :)
Brian Reinhold (Apr 29 2021 at 15:05):
@Jessica Bota would submitting these namespaces be considered under 'How to Submit a UTG Change Proposal'? In my first attempt a few months ago I created a NamingSystem resource for each of the namespaces.
Jessica Bota (Apr 29 2021 at 15:39):
@Brian Reinhold , apologies, I do remember this now and we chatted via email. Things came to a stop when we weren't sure where identifier systems should live.
You've basically done the hard part by creating the content. But you do need to create a branch and commit the changes to the souce of truth. Starting back on your ticket (https://jira.hl7.org/browse/UP-177), click 'Draft a Proposal' to enter the Proposal Draft state. Since you are an IG developer, you can follow these instructions: https://confluence.hl7.org/display/VMAH/Create+a+Proposal
The last piece I think we are missing is a folder to place identifier systems in the source of truth. Originally @Ted Klein was going to create a folder for 'identifiers systems' in ...\input\sourceOfTruth\external and you could add your naming systems to that directory. Ted, is that the approach we should take again now that we have agreement to keep these in THO?
Thanks for sticking with this Brian...
Brian Reinhold (Apr 29 2021 at 19:16):
@Jessica Bota I do not seem to be able to find the 'Draft a Proposal' option in https://jira.hl7.org/browse/UP-177
Am I missing some step?
Jessica Bota (Apr 29 2021 at 19:20):
Do you see this button at the top?
image.png
Brian Reinhold (Apr 29 2021 at 19:22):
NO I do not. I have the 'edit', 'assign', and 'more' buttons but not the last two. Perhaps they need special permissions?
John Moehrke (Apr 29 2021 at 19:24):
are you logged in? I think that is not a special permission
John Moehrke (Apr 29 2021 at 19:24):
you can look at jira ticks without logging in
Brian Reinhold (Apr 29 2021 at 19:28):
Yes I am logged in - at least it has my profile. What I am confused about is that I also have a confluence account for business in addition to an HL7. I wonder if that is causing confusion.
Jessica Bota (Apr 29 2021 at 19:34):
@Brian Reinhold , you do need to have special Jira permissions as a submitter. You can request from https://confluence.hl7.org/display/VMAH/Vocabulary+Maintenance+at+HL7. You may want to try your other account and see if you have the button.
John Moehrke (Apr 29 2021 at 19:37):
@Lloyd McKenzie ?
Brian Reinhold (Apr 29 2021 at 20:12):
@Jessica Bota FHIR Tools and the tool for notepad++ both failed to install. The first failed near the end because it could not find some package which I dont remember (long name and uncopyable from the error message) and the notepad++ plugin failed to install due to not finding a fhir core package though I clearly saw that install in the first one.
Jessica Bota (Apr 29 2021 at 20:21):
@Brian Reinhold , you already created the naming systems, so you shouldn't need the FHIR tools (this is more for folks not comfortable editing XML). That error is a known bug with the FHIR toolkit, but does not affect UTG submitters. The notepad++ plugin is not used in UTG. If you plan to use git commands, then you shouldn't need Sourcetree either.
I think I misled you by pasting the wrong link for submitting for IG developers. This is the correct link: https://confluence.hl7.org/display/VMAH/Submitting+Change+Proposals+for+Advanced+and+Experienced+IG+Developers
Brian Reinhold (Apr 29 2021 at 20:36):
@Jessica Bota Sorry to say I have another point of confusion. I assume I do not have to create a new issue - UP-177 is sufficient, but when I read what's here
https://confluence.hl7.org/display/VMAH/Submitting+Change+Proposals+for+Advanced+and+Experienced+IG+Developers
the repo appears to be in bitbucket and not git-hub. I did find an 'imposter' repo in git-hub. If it is in Bitbucket instead, I will need to know what the URL is to that. Thanks.
Lloyd McKenzie (Apr 29 2021 at 20:41):
@Jessica Bota @Ted Klein Why is special permission needed to be a submitter? That's not something we do for other change requests, so it's not clear why we'd create a barrier here...
Jessica Bota (Apr 29 2021 at 20:52):
@Brian Reinhold , I admit the advanced process is not something I am familiar with, so it is good for me to get some feedback on it. I believe the repo link you need is https://bitbucket.hl7.org/scm/utg/utg.git . I will add it to the page too.
Jessica Bota (Apr 29 2021 at 20:54):
@Lloyd McKenzie , I think there are two main reasons. One is that I think it isn't a Jira role/permission we can assign every new user with how it is currently set up. The second is that there has been discussion on the UTG task force about who can submit proposals (such as HL7 members only)
Brian Reinhold (Apr 29 2021 at 20:56):
This information is also not present ''Create branch' button from the Jira ticket in the 'Development' area'. There is no such option or area in UP-177.
I think what I need to do is clone the bitbucket repo shown above (I will place it in the same area I have for my IGs). Once I have done that create a new branch with name UP-177 and then add my xmls under
/input/sourceOfTruth/external/hta/namingSystems
Does that sound correct? (I just cloned the repo in any case). What's the git-hub variant? They seem to be identical.
Of course I will review my four NamingSystem resources.
By the way I am an HL7 member - at least last I remember!
Jessica Bota (Apr 29 2021 at 21:03):
@Brian Reinhold , that create branch link won't be there until you can click that "draft a proposal" button. I'd rather you not put them in the hta/namingSystems and wait for Ted to add a folder for identifiersystems/namingSystems or something like that. @Ted Klein
Brian Reinhold (Apr 29 2021 at 21:25):
@Jessica Bota Okay. I cloned the repo anyways - I will do nothing more until I get further instructions. I can always fetch any new material created. It seems like trying to solve the blocking of the 'draft a proposal' option for me might be something that takes ages to solve - permission issues usually are, especially on Linux systems. If I could just be told what to name the branch I would think I could go from there...unless there are side-effects of clicking that 'draft a proposal' that are under the hood.
Jessica Bota (Apr 29 2021 at 21:30):
@Brian Reinhold , it is hard to say what the branch should be called without the Create branch link. If it is wrong, everything gets messed up in the build. The permissions issue should only be Jira-related, so once we get a Jira admin to make sure you are a submitter (@Joshua Procious or @Ted Klein ) then you should be good to go. Do you remember filling out a short form to be a submitter? If not, that is likely the blocker here.
Brian Reinhold (Apr 29 2021 at 21:39):
I did it a few hours ago since all my logins were failing to expose that option
Brian Reinhold (May 10 2021 at 11:41):
A whole bunch of stuff previously entered by Jessica is now gone. All those links are gone. Aargg!
Brian Reinhold (May 10 2021 at 11:44):
@Jessica Bota Tried responding a few minutes ago. It seems to have gone out in space. There may be duplicates. Created the change request and now have lost it. Still far to go in the instructions. It may all be corrupt and things could get very messy. Found the duplicate and deleted it.
Okay, nothing is consistent with the instructions anymore so I will just plow forward.
Made the branch based upon UP-177. Sourcetree did not work regardless of approach. Used Tortoise git to clone the branch instead. That appears to have worked.
Of course nothing else worked so the behavior in the instructions no longer mean anything. I have the directory cloned on my system with the correct branch. If anything else is awry, I do not know. I have made Naming Resources some time ago. Is it clear yet where I should put them? ( I will review them of course).
How about here?
utg\input\sourceOfTruth\external\hta\namingSystems
Jessica Bota (May 10 2021 at 12:36):
@Brian Reinhold , sorry for the difficulties. Sure, put them in there for now and I will move them to a correct location that doesn't yet exist at a later date. I hate to hold you up waiting on it any longer. I'm off this week but if you run into additional issues we can meet next week to resolve them. I'd also like to hear about the issues you had with Sourcetree and the documentation so that we can fix/improve those.
Brian Reinhold (May 10 2021 at 12:58):
@Jessica Bota THe message that you had all the instructions in and links has vanished from this site. No idea why. SO I can't really give much info.
Jessica Bota (May 10 2021 at 14:14):
@Brian Reinhold ughhh, okay. I can send the links again in about 30 min.
Jessica Bota (May 10 2021 at 14:46):
@Brian Reinhold
All info on UTG is linked to from this page: https://confluence.hl7.org/display/VMAH/Vocabulary+Maintenance+at+HL7
Submitting for IG Devs: https://confluence.hl7.org/display/VMAH/Submitting+Change+Proposals+for+Advanced+and+Experienced+IG+Developers
Creating/modifying contents of proposal (you have already done this): https://confluence.hl7.org/display/VMAH/Specifying+the+Details+Inside+the+Proposal
Now that you have the local copy, all you should need to do is move your four naming systems into the folder specified above, commit/push the changes, and submit the proposal back from the Jira ticket (UP-177).
Brian Reinhold (May 10 2021 at 14:59):
@Jessica Bota It would have been very easy in my case if I knew what the naming convention of the branch was. I could have simply created the branch and given it that name and would have avoided all the other difficulties. It's easy in my case because I already have all the tooling installed.
Brian Reinhold (May 17 2021 at 14:00):
@Jessica Bota I have pushed my changes on the 177 branch with the namespace identifiers.
Jessica Bota (May 17 2021 at 15:36):
@Brian Reinhold , looks good. All you need to do now is to click that 'Submit' button after you enter a sponsor approval date via 'Edit' first.
Brian Reinhold (May 24 2021 at 13:40):
@Jessica Bota Okay, Vote is taken and everything is done.
Jessica Bota (May 24 2021 at 13:44):
@Brian Reinhold Excellent, everything looks good. It will be processed for Consensus Review to be open for voting. This usually happens in a couple days, may be a bit delayed due to the WGM but it is first in the queue.
Last updated: Apr 12 2022 at 19:14 UTC
