Stream: terminology
Topic: HCPCS
David Teirney (Dec 19 2017 at 02:55):
Has a FHIR system URI been published for HCPCS codes (http://oid-info.com/get/2.16.840.1.113883.6.285)?
Rob Hausam (Jan 17 2018 at 15:31):
@David Teirney It doesn't appear that we have so far, but I assume that we should. I don't know what the url should be, but we can figure that out.
David Teirney (Mar 05 2018 at 10:22):
@Rob Hausam any thoughts on when there might be some movement on what the FHIR HCPCS system URL should be?
Rob Hausam (Mar 07 2018 at 04:55):
Thanks for the reminder, David. I haven't heard of any further progress on this, but we should make some. Let's propose a url to use (you're welcome to suggest one, if you like) and let's see if we can get it included before the deadline this Sunday.
Travis Bean (Jul 23 2019 at 21:31):
Sorry for responding to an old thread, was a URL ever selected for HCPCS? I don't see any references on the terminology page.
Bryn Rhodes (Jul 25 2019 at 21:33):
It's kind of long, but this has the benefit of actually resolving to the release page for the system: https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/
Rob Hausam (Jul 26 2019 at 02:20):
I think we could go with something like that (but it doesn't seem particularly "canonical"). Or we can think about creating a terminology.hl7.org url, which we have done in a lot of cases. Unless there would be some way to encourage and convince CMS to create a simple and stable canonical url, which (if it was possible) would be ideal.
Michael Lawley (Jul 26 2019 at 04:38):
It's the plural in that URI that bothers me -- this is supposed to identify a single CodeSystem.
Rob Hausam (Jul 26 2019 at 10:39):
Agree.
Robert McClure (Jul 29 2019 at 13:57):
It is the responsibility of HTA to define a process for this. Not sure where the url that Bryn came from but we need to put a stop to randomly making these up if that did not come from CMS as their decision. I understand there could be time pressure for this sort of stuff. I'll reference this thread to HTA. Until they chime in, please be cautious about deciding this is resolved. I encourage anyone with questions like this to send them to termauth@lists.hl7.org
Grahame Grieve (Jul 29 2019 at 13:58):
we shouldn't randomly make them up but we should also reserve the right to do that if the relevant party is non responsive
Robert McClure (Jul 29 2019 at 13:58):
The relevant party is HTA and it should be responsive.
Rob Hausam (Jul 29 2019 at 14:07):
Of course, the most relevant party for HCPCS is CMS, but as far as I know we don't expect their involvement. If HTA agrees this is their task (and that is also generally understood), that's next.
Robert McClure (Jul 29 2019 at 14:12):
TSC has clarified that this is HTA responsibility. This clarification is new information to HTA so it will take a bit of time to work out all the process requirements. While you are correct that CMS is the terminology Authority, HTA is the entity responsible for getting the canonical uri. So it is the relevant entity.
Julie James (Aug 19 2019 at 16:29):
At the September WGM, HTA will be producing a policy for this, based on "graceful degredation" - i.e. from the best (code system owner manages and publishes a canonical URL) through to the worst (code system owner is totally non-responsive).
Lloyd McKenzie (Aug 20 2019 at 11:16):
@Julie James Is the HTA going to take on the task of engaging with the relevant owners? And can we commit to providing a URL in a "reasonable" timeframe (i.e. 6 months or less)?
Julie James (Aug 20 2019 at 11:34):
@Lloyd McKenzie The HTA is going to develop the policy that WGs should follow to engage with code system owners as necessary, including some supporting material (e.g. draft letter to explain and hopefully make clear what the "ask" is), for those code systems that are not already documented on the HTA pages. And to get the WGs to provide content to update those pages so that others can re-use the information. But the HTA will not be taking over the role of WG Vocabulary Facilitators :)
Part of the policy with its "graceful degredation" will be to give guidance as to "reasonable" timeframes for responses etc. and next steps to take.
It would be very helpful if you could point me to where exactly what the "ask" is, clearly documented with examples. It seems, particularly for the provision of "canonical URLs", that term is sadly not canonical, as it means many things to many people.
Lloyd McKenzie (Aug 20 2019 at 13:55):
My recommendation would be to actually avoid engaging with any terminology authors that HL7 doesn't already have good quality relationships with and who are likely to understand what it is we're trying to do. Expending a bunch of energy to get an authority-assigned URL rather than issuing an SID within the HL7 namespace doesn't make much sense - especially if we don't expect the organization to understand/care about the ramifications of changing their website organization going forward. The HTA's responsibilities should be:
1. determining whether the owner of a code system is one of the few organizations with which we have a sufficiently strong relationship (and which have a terminologically aware web policy) that it makes sense to reach out to;
2. verifying the determination of the Vocabulary facilitator that the proposed code system is indeed 'new' and in need of a new URL
3. vetting proposed SIDs in the HL7 namespace to ensure they meet the criteria of short, descriptive, non-confusing
And either of the latter two could actually be delegated to the Vocabulary WG if desired
Lloyd McKenzie (Aug 20 2019 at 13:57):
The benefit of an HL7-assigned SID is that we can update the metadata (via NamingSystem) to point to any organization-defined website needed as websites get refactored. It also means that we can ensure that URLs are version-independent, stable and nor horribly long and ugly.
Michael Lawley (Aug 21 2019 at 09:30):
I'm quite sympathetic to this position, but it would be very easy to always classify all orgs as "difficult" by default, and then end up misunderstanding the ins and outs of their code system(s) leading to mis-application of HL7's own rules.
Lloyd McKenzie (Aug 21 2019 at 12:19):
There's certainly a need to understand the ins and outs of the code system. Engaging with them on that level makes good sense. The issue is more about who should create/manage the CodeSystem canonical URL. For that, we need to worry more about whether the organization understands/cares about HL7's processes and needs more than what we understand about the code system. To properly issue a URL, all HL7 needs is a proper understanding of the boundaries of the code system namespace.
Lloyd McKenzie (Aug 21 2019 at 12:21):
If the terminology organization doesn't genuinely understand the purpose of the URL and the essentialness of keeping it unchanged (and short and simple) once established, they shouldn't be issuing it. We can (and have) created URLs for lots of code systems without capturing any guidance about their use as part of the specification.
Robert McClure (Aug 21 2019 at 13:38):
I agree with @Lloyd McKenzie but with a clarifying caveat: we are defining a canonical URL to be used in the context of HL7 specifications. Yes, it can be used elsewhere but we need to be clear this is OUR identifier for the code system and is not meant to be more then that because we do not have the authority to do any more. Based on that I think we should consideralways using NamingSystem unless we get a well formed for our needs canonical url from the TA.
Rob Hausam (Aug 21 2019 at 13:53):
I think that can work. But for consistency, we maybe should (as our own best practice) always create a NamingSystem resource instance in every case, regardless of whether the code system owner gives us a "good" canonical url or not.
Last updated: Apr 12 2022 at 19:14 UTC
