Stream: IG creation
Topic: New NUCC Taxonomy Code System URL
Igor Sirkovich (Jun 24 2020 at 21:03):
My understanding is that recently, there was a decision to replace the NUCC Taxonomy Code System URL: the published URL is http://nucc.org/provider-taxonomy while the new one is http://www.nucc.org/taxonomy and that this change has already been incorporated in the Da Vinci Plan-Net IG.
However, for the new URL, IG Publisher returns an error "Unable to provide support for code system http://www.nucc.org/taxonomy". I'm wondering whether this is a known issue and whether it's expected to be resolved in a future version of the IG Publisher.
Grahame Grieve (Jun 24 2020 at 22:43):
I didn't know about this decision. Who made it?
Igor Sirkovich (Jun 24 2020 at 22:51):
I now that this was implemented in the Da Vinci Plan-Net IG, but I'm not sure who made the decision. @Saul Kravitz, could you please help with this question?
Igor Sirkovich (Jun 24 2020 at 23:35):
I also see that this new URL appears on the National Uniform Claim Committee (NUCC) Health Care Provider Taxonomy Confluence page. This page was added under the Terminology Authority/External Terminologies page tree on June 12th, so I assume this was approved by the Terminology Authority.
Grahame Grieve (Jun 24 2020 at 23:51):
@Reuben Daniels can you comment about this? HTA just changed something in operation without even telling anyone let alone consulting?
Reuben Daniels (Jun 24 2020 at 23:53):
I think @Carol Macumber should be able to shed some light. I can state that this was discussed in the HTA
Carol Macumber (Jun 25 2020 at 16:51):
A request was made for HTA to engage the owners of NUCC for an authoratative URL. @Robert McClure worked with them to identify not only an authoratative URL, but the additional guidance provided on the HTA confluence page.
Lloyd McKenzie (Jun 25 2020 at 17:09):
But if there's already an authoritative URL listed in the FHIR spec, HTA shouldn't be soliciting the creation of a new one...
Grahame Grieve (Jun 25 2020 at 19:57):
how can HTA even consider not engaging with the community on this? I'm going to escalate this
Grahame Grieve (Jun 25 2020 at 20:01):
@Carol Macumber what authority has HTA to override a balloted specification? I don't think you do
Jean Duteau (Jun 25 2020 at 20:09):
i have no skin in the game here, but if the NUCC decided that they wanted a different URL than what FHIR had created, doesn't that override the specification?
Grahame Grieve (Jun 25 2020 at 20:38):
maybe it does, but a process where a community working on a balloted specification is neither consulted or informed?
Carol Macumber (Jun 25 2020 at 21:42):
HTA is not intending to "override the balloted specification". We are engaging external code system owners, as requested by an HL7 community member, for authoritative information, including their officially sanctioned URL. It was our understanding that the IG process is supported by UTG's ability to support the existence of multiple identifiers within namingsystem resources, to support the reality that URLs may need to be updated over time, similar to the change that was made for ICD10PCS. The JIRA request to have this change offically made in UTG, and passed through the commnity notifcation process in UTG, is in the works. However, it is HTAs designated role to be "responsible for the creation, implementation, and management of HL7 processes involving external terminology management"
Grahame Grieve (Jun 25 2020 at 21:50):
@Carol Macumber none of this is to my point. You didn't check the existing spec, you didn't consult the community, you didn't inform the community. Are we unreasonable to have a problem with that?
Jean Duteau (Jun 25 2020 at 21:53):
@Grahame Grieve Are you saying that the owners of the code system (NUCC) don't have the right to publish what they consider the proper URL for their code system because the community has already decided on their own URL?
Grahame Grieve (Jun 25 2020 at 21:54):
no. Read what I wrote. Please. I'm saying that a decision like that can't be made by an HL7 committee without working with the affected community. Are you saying I'm wrong?
Robert McClure (Jun 25 2020 at 21:55):
I want to confirm Carol's response. HTA has an HL7 board charge to do the work of determining use of external terminologies in HL7 artifacts, specifically to work with the code system authority to determine the canonical url. Given the known situation where HL7 artifacts would have to define "a canonical url" before the authority decided to weigh in, we created a situation where a canonical url could, and has, changed. UTG has a process (that still needs a bit of work) to notify the community of these changes and we have chosen to keep track of these changes via NamingSystem and the provenance of the CodeSystem. To our understanding the community does not get to disregard the desires of an external IP owner. What they do need is clear notification and a tooling system that helps them deal with this change.
Jean Duteau (Jun 25 2020 at 21:55):
you didn't consult the community, you didn't inform the community
The JIRA request to have this change offically made in UTG, and passed through the commnity notifcation process in UTG, is in the works.
It seems that they are in the process of "consulting" and "informing" the community.
Grahame Grieve (Jun 25 2020 at 21:55):
because it's in the works? What?
Grahame Grieve (Jun 25 2020 at 21:56):
This is not acceptable, and I don't think this is good faith at all
Jean Duteau (Jun 25 2020 at 21:58):
Grahame Grieve said:
no. Read what I wrote. Please. I'm saying that a decision like that can't be made by an HL7 committee without working with the affected community. Are you saying I'm wrong?
Yes, I am. Someone followed HL7 process to have the HTA determine if the existing URL was an appropriate URL (given that it resolves to a 404) and the code system owner said "ooh, no, we want this URL" and the HTA is following its process to inform the community and affect the change.
Grahame Grieve (Jun 25 2020 at 21:58):
If the board remit does not include consulting properly with the community, I'll take it up with the board
Jean Duteau (Jun 25 2020 at 21:59):
so let me understand - you're upset that they have been given this role or you are upset that their community consultation isn't as fast you you want it to be?
Grahame Grieve (Jun 25 2020 at 22:00):
I'm not happy that there was no community consultation at all, and that somehow indicating that a process is in the works in the future makes this one ok, when we already had defined a URL, and we were not consulted or informed. And I'm not at all happy that neither you, Carol or Rob even understand why I'm not happy about that
Jean Duteau (Jun 25 2020 at 22:01):
Lloyd McKenzie said:
But if there's already an authoritative URL listed in the FHIR spec, HTA shouldn't be soliciting the creation of a new one...
Are you arguing that once a URL is created and listed in the FHIR spec, no matter how wrong it is, the code owners are not allowed to change it if they weren't consulted in the first place?
Jean Duteau (Jun 25 2020 at 22:03):
Where did the original NUCC Health Care Provider Taxonomy URL come from? (the http://www.nucc.org/provider-taxonomy one)? If it came from NUCC originally, then I agree with you and Lloyd. But it doesn't sound like that is the case.
Grahame Grieve (Jun 25 2020 at 22:12):
I think I made it up in consultation with the US realm steering committee, I think I recall. So it might well be that it's right to fix it, and at least it is not referenced in US Core.
Jean Duteau (Jun 25 2020 at 22:14):
Thanks, that was my first question way earlier today. :)
So it appears that we have a case of a Code System URL that HL7/FHIR defined that has ended up not being the official URL that the code system owner desires. What should be the process for the code system owner in this case?
Robert McClure (Jun 25 2020 at 22:15):
@Grahame Grieve That is my memory of this too - You and @Eric Haas did it to get things to run. As we do, as expected, in many places. It just highlights that such things might change in the future. I'll note that Eric also added fake codes to the code system that the NUCC folks are not to pleased about.
Grahame Grieve (Jun 25 2020 at 22:15):
They should ask HTA to change it. And then HTA should ask the community using it what the impact would be. At least, I think that. But it seems HTA doesn't think so.
Jean Duteau (Jun 25 2020 at 22:15):
From my understanding of HTA's purview, they consult the code system owner, find out their desires, and then put this through the UTG Community Change Process. Is that not happening here?
Grahame Grieve (Jun 25 2020 at 22:15):
I don't remember fake codes and would not have approved that
Grahame Grieve (Jun 25 2020 at 22:15):
There is no UTG change process.
Grahame Grieve (Jun 25 2020 at 22:16):
so either wait for it to be, or consult before making the change
Grahame Grieve (Jun 25 2020 at 22:16):
@Ted Klein is there a special UTG process for breaking changes?
Robert McClure (Jun 25 2020 at 22:17):
Fakes codes are things like base-1 Behavioral Health & Social Service Providers
And again, @Grahame Grieve you keep saying things that seem to indicate HL7 can control the canonical identifier of external IP where the owner wants something different.
Jean Duteau (Jun 25 2020 at 22:17):
Okay, we have a HTA External Terminology Confluence page that documents the official position of NUCC (the code system owner) and on that confluence page, there is a note that the JIRA UTG process should begin. Has it actually been changed in UTG?
Robert McClure (Jun 25 2020 at 22:17):
Hence I think we need to improve notification
Robert McClure (Jun 25 2020 at 22:18):
Jean Duteau (Jun 25 2020 at 22:19):
Jean Duteau said:
Okay, we have a HTA External Terminology Confluence page that documents the official position of NUCC (the code system owner) and on that confluence page, there is a note that the JIRA UTG process should begin. Has it actually been changed in UTG?
It doesn't appear to have changed in UTG yet:
https://terminology.hl7.org/CodeSystem-v3-nuccProviderCodes.html
So I'm still unsure what the problem is...HTA has recognized the need for a change and appears to be following their process to make it happen.
Grahame Grieve (Jun 25 2020 at 22:20):
the problem is that this is a breaking change that they 'decided' on (not in the process of deciding) without once consulting the community that was being broken. Is there any other committee at HL7 that you think can do that?
Jean Duteau (Jun 25 2020 at 22:21):
Grahame Grieve said:
the problem is that this is a breaking change that they 'decided' on (not in the process of deciding) without once consulting the community that was being broken. Is there any other committee at HL7 that you think can do that?
Who is "they" in your statement? NUCC? HTA? I'm not seeing the HTA "deciding" on anything, but merely reflecting the wishes of NUCC.
Robert McClure (Jun 25 2020 at 22:21):
UTG has not been updated yet because Ted wants it to flow through UTG. The notification from NUCC just happened
Grahame Grieve (Jun 25 2020 at 22:22):
the right process should be:
- oh, we are discussing changing a URL that is in use already
- let's start by telling everyone who might be using it that we're considering changing it, and finding out what the cost is (as best as we can communicate with them)
- once we have an estimate of the cost of change, that can discussed with the owner
- then we can tell the community that we did agree to the change, and discuss what the change over process looks like
Grahame Grieve (Jun 25 2020 at 22:22):
it's not enough to say 'the external authority wanted it to change'. Sorry.
Grahame Grieve (Jun 25 2020 at 22:23):
I did think that this was in US core and referenced by US legislation. Which should very much have weighed on the discussion, although that appears not the be case (this time)
Grahame Grieve (Jun 25 2020 at 22:24):
I don't understand why this is not obvious to a terminology authority
Jean Duteau (Jun 25 2020 at 22:25):
okay, it appears to me that their process was:
0) HL7/FHIR makes up a URL for a code system without consulting the external authority
1) HTA gets asked to verify the URL
2) HTA consults with the external authority
3) External Authority indicates that the made-up URL is incorrect and provides a proper URL
4) HTA documents the proposed change and submits it through the HL7-terminology-change-process
Robert McClure (Jun 25 2020 at 22:25):
Graham, that is like deciding you don't want to tell the owner of the car you stole and use every day to go to work, that you have it because it would cost you too much to buy a car of your own. I agree we need to fix the process, but we don't get to ignore the wishes of an IP owner
Jean Duteau (Jun 25 2020 at 22:26):
I would totally understand the frustration and concern if the existing code system URL had come from NUCC or had been decided in consultation with them. But since that isn't the case, we have really put the HTA in a "rock and a hard place" scenario here.
Grahame Grieve (Jun 25 2020 at 22:26):
really? It's a rock and a hard place to actually consult? wtf?
Jean Duteau (Jun 25 2020 at 22:27):
they are consulting?!??
Jean Duteau (Jun 25 2020 at 22:27):
They are following the UTG consultation process.
Grahame Grieve (Jun 25 2020 at 22:27):
how? they make a decision and we find out by accident and that's "consulting"?
Jean Duteau (Jun 25 2020 at 22:27):
you do know that it hasn't actually changed yet right??
Grahame Grieve (Jun 25 2020 at 22:27):
and it's entirely unsatisfactory to say that they are consulting by following a process that doesn't yet exist
Jean Duteau (Jun 25 2020 at 22:28):
UTG still has the code system listed with the old made-up URL
Jean Duteau (Jun 25 2020 at 22:28):
Grahame Grieve said:
and it's entirely unsatisfactory to say that they are consulting by following a process that doesn't yet exist
Oh, this is news to me. I was under the impression that there was a UTG change process that involved community feedback and such.
Grahame Grieve (Jun 25 2020 at 22:29):
there's going to be. Have you ever seen it at work?
Grahame Grieve (Jun 25 2020 at 22:29):
it hasn't actually changed yet right
That's not what anyone from HTA has said
Jean Duteau (Jun 25 2020 at 22:29):
Yes it is.
Grahame Grieve (Jun 25 2020 at 22:30):
where? WHat they said is 'we changed it, it's final, we announced it our page, you have no grounds for being unhappy'
Jean Duteau (Jun 25 2020 at 22:30):
wow, that's ascribing a lot of malice to Carol's original response.
Jean Duteau (Jun 25 2020 at 22:32):
what they ACTUALLY said was "we consulted with the external authority and Rob McClure has documented their desires"
A request was made for HTA to engage the owners of NUCC for an authoratative URL. @Robert McClure worked with them to identify not only an authoratative URL, but the additional guidance provided on the HTA confluence page.
She also said that they are engaging the UTG change process that involved community feedback.
The JIRA request to have this change offically made in UTG, and passed through the commnity notifcation process in UTG, is in the works.
Jean Duteau (Jun 25 2020 at 22:33):
so it appears to me, that there is still time to discuss the ramifications of this request from NUCC and to determine the best way forward.
Lloyd McKenzie (Jun 25 2020 at 22:37):
HL7 isn't bound to use the URI that the code system authority would like. It's absolutely a consideration, but it's not the only consideration. Making the code system authority happy, but costing our developer community hundreds of thousands of dollars (or more) isn't necessarily the best outcome. HTA assigning a URL where there isn't already one defined is fine. HTA assigning a URL where one is defined and published by FHIR - irrespective of whether the responsible terminology owner was involved - should only happen with consultation with the HL7 implementer community.
Jean Duteau (Jun 25 2020 at 22:37):
If we go way back to Igor's original question, I think it is obviously premature for the Da Vinci Plan Net IGuide to incorporate the new code system URL into their value set definition. Although NUCC has made that request of HL7, the correct URL is still http://www.nucc.org/provider-taxonomy so that would be incorrect on the part of the authors of that Implementation Guide.
Jean Duteau (Jun 25 2020 at 22:38):
Lloyd McKenzie said:
HL7 isn't bound to use the URI that the code system authority would like. It's absolutely a consideration, but it's not the only consideration. Making the code system authority happy, but costing our developer community hundreds of thousands of dollars (or more) isn't necessarily the best outcome. HTA assigning a URL where there isn't already one defined is fine. HTA assigning a URL where one is defined and published by FHIR - irrespective of whether the responsible terminology owner was involved - should only happen with consultation with the HL7 implementer community.
Totally agree with you here! My argument is that the HTA has not "assigned a URL" yet. It has simply consulted with the code system authority to find out their wishes.
Lloyd McKenzie (Jun 25 2020 at 22:39):
That consultation should have been preceded with a consultation with the community though. It's not a great process to say "Hey, what URL would you like" and then to come back and say "Umm, that URL you'd like is going to cost the community tons of money to change, so we want you to use this one instead"
Lloyd McKenzie (Jun 25 2020 at 22:41):
If there's one that pre-exists, the HTA should: a) find that out before starting the discussion and; b) try to get a sense of how widely used that URI is within existing systems; c) start their conversation with the terminology owner on that basis - generally with a desired outcome of keeping the one that exists, though perhaps setting up a redirect to the location where the data actually exists or updating our documentation for the code system to refer to that URL.
Jean Duteau (Jun 25 2020 at 22:41):
Lloyd McKenzie said:
That consultation should have been preceded with a consultation with the community though. It's not a great process to say "Hey, what URL would you like" and then to come back and say "Umm, that URL you'd like is going to cost the community tons of money to change, so we want you to use this one instead"
Okay, then we should provide feedback to the HTA accordingly. (I suspect this thread is doing that)
My problem with what you are saying is that we made up the URL without talking to them in the first place which was why I was asking the question
Grahame Grieve (Jun 25 2020 at 22:42):
I believe that we tried, but no one at NUCC cared back then.
Jean Duteau (Jun 25 2020 at 22:42):
isn't this a similar problem to the ICD-XX code system URL changes?
Lloyd McKenzie (Jun 25 2020 at 22:42):
The fact they care now doesn't mean were're in a position where change is possible.
Grahame Grieve (Jun 25 2020 at 22:42):
that's ascribing a lot of malice to Carol's original response
This was pretty upsetting
Lloyd McKenzie (Jun 25 2020 at 22:43):
@Carol Macumber @Robert McClure - Do my proposed additional process steps make sense to incorporate into the process going forward?
Lloyd McKenzie (Jun 25 2020 at 22:44):
As a side note, resolution isn't a requirement. SNOMED's URI still doesn't resolve...
Grahame Grieve (Jun 25 2020 at 22:44):
Your contention is that this is not a decision, it's simply documenting the wishes of the code system owner, and not binding. but I think you're not right. The reference @Robert McClure provided above is the HTA formal write up of what they decided. And also they advised the IG author to use. It's evident that it's a binding HTA decision from their pov
Jean Duteau (Jun 25 2020 at 22:47):
I see no "evident". I'm again just going by what Carol wrote earlier that implies it was a writeup of what NUCC had conveyed to HL7.
If they did indeed advise the IG Author to use this new URL, then that is out-of-line.
Jean Duteau (Jun 25 2020 at 22:49):
@Robert McClure Since the NUCC Health Care Provider Taxonomy is still undergoing the UTG Change process, can the HTA place a disclaimer on that confluence page stating something to the effect that this is what NUCC has proposed and that there is an existing Code System URL and that the UTG process is still being followed?
That would distinguish this page from the other pages which were documenting valid URLs and such.
Jean Duteau (Jun 25 2020 at 22:53):
@Robert McClure @Carol Macumber It seems to me, reviewing the existing HTA External Code System Engagement Process, that steps #4/5 and #9 need some changing.
#4/5 appear to be about reviewing and confirm the use of the external code system in existing artifacts. I believe that Lloyd's proposal of adding a community engagement step at this point should be inserted. You may very well be doing that but being explicit would be good here.
#9a has the creation of an informational page. As I just posted, I think that this informational page should have a DRAFT notice/disclaimer that is not made final until after the UTG project completes its change process.
Jean Duteau (Jun 25 2020 at 22:56):
Since I just found it, I thought I'd drop this link to the UTG Change Proposal process along with the Consensus Review and Voting piece:
https://confluence.hl7.org/display/VOC/UTG+Tooling+and+Proposal+Documentation
https://confluence.hl7.org/display/VOC/Consensus+Review+and+Voting
Robert McClure (Jun 25 2020 at 23:16):
I'll just say here that it news to me, and I suspect to others, that HL7 never intended to support external code system owner requests to use a requested canonical url when that request comes after HL7 has made up their own id. If there is some documentation of valid effort to obtain the desired url from the authority, I suspect that would be important for HTA to see and I would have expected, given the widely announced role of HTA, that they - HTA - would have been notified of such actions "by the community." This street goes both ways methinks.
As for the Plan-Net folks using the official NUCC url - that is on me. NUCC is pretty concerned about HL7's appropriation of their IP (of additional note, it seems they would like to see the use of NUCC changed within US Core.) But the plan-net change was due to my understanding, that I still think is correct, that the IP owner sets the url. I just assumed you all knew such changes would occur and had planned to support it because this has been discussed many times wrt the consequences of making up urls to get things published. Seems we've not completed that discussion.
Grahame Grieve (Jun 25 2020 at 23:32):
- of course we intend to support external owner requests. that has not once been the question here.
- that such changes occur in principle doesn't mean that instances of those changes happen without discussion.
- US core does not use NUCC at this time, I believe. at least, I don't see any reference in it
- how did we appropriate their IP? I'm still concerned about that
- we started using the NUCC URL in 2016. HTA was not paying attention to code system requests then. The process would be very different now
Robert McClure (Jun 25 2020 at 23:35):
@Grahame Grieve Careful. If you are justifying your arguments on use of NUCC you better check before yet another pronouncement.
Grahame Grieve (Jun 25 2020 at 23:36):
well, you're right. I'm wrong about US core, and this increases my concern. I don't know what was wrong with my search. US Core uses NUCC extensively and I rather think it's too late to change it, since it's referenced in regulation.
Grahame Grieve (Jun 25 2020 at 23:37):
@Brett Marquard FYI this is a US realm steering committee issue
Grahame Grieve (Jun 25 2020 at 23:37):
also, I see this:
Grahame Grieve (Jun 25 2020 at 23:37):
http://hl7.org/fhir/valueset-provider-taxonomy.html
Grahame Grieve (Jun 25 2020 at 23:37):
what do we need to do about that?
Lloyd McKenzie (Jun 26 2020 at 00:26):
If a terminology owner's licensing terms dictate the specific URL that must be used, we're bound to use it - unless we can negotiate other licensing terms. However, few if any terminology owner's license terms ever assert such a thing. (Must terminology owners would have no notion that a URI would even be relevant.) As such, so long as we use the terminology within the bounds of the license terms, HL7 is free to dictate whatever URI it wishes. It is certainly good practice to seek a URI from the terminology owner, but in cases where one has already been assigned, we need to be careful. Existing implementations matter - and in at least some cases, they're going to matter more than the preference of the terminology owner. We have a better process now than we did before, but that doesn't mean that the new process can ignore prior art when doing so negatively impacts the implementer community. Implementers could care less what process we used to get the URL. That's not their problem. But if we change the URL, it is we (HL7) who are creating a tremendous problem. We shouldn't do that without really good cause - and terminology owner preference doesn't necessarily constitute such.
Peter Jordan (Jun 26 2020 at 00:41):
Jean Duteau said:
isn't this a similar problem to the ICD-XX code system URL changes?
I think that this discussion will seem like a storm in a teacup in comparison to what might eventuate with ICD-XX URL changes unless we can agree on a process and some fundamental principles here.
Brett Marquard (Jun 26 2020 at 02:48):
This is a great example of where a conference call or in person discussion would benefit us all -- call me an optimist but I would hope a discussion with an external terminology provider about what the FHIR community is currently using and their future URL would result in a solid compromise.
Brett Marquard (Jun 26 2020 at 02:48):
@Robert McClure Did you ask NUCC if they had concerns with us using the current URL?
Robert McClure (Jun 26 2020 at 18:35):
@Brett Marquard Not that this will resolve the process issue we've discovered, but yes, I'm asking the NUCC (and AMA) folks if they will allow http://nucc.org/provider-taxonomy to be the canonical url. I'll note they had already expressed they did not want that url, but I've pointed them to this thread and if that doesn't scare them, nothing will.
Brett Marquard (Jun 26 2020 at 18:46):
I am not sure the nuance in my question came through -- Did you ask them up front about using the URL and then transitioning to their request in the future?
Robert McClure (Jun 26 2020 at 21:55):
Let it be known, let it be written...
NUCC has agreed to not change the canonical url and is accepting the canonical url that was crafted by HL7 and is included in terminology.hl7.org and in the base FHIR servers. That url is http://nucc.org/provider-taxonomy. They note that this "dashed" url will not resolve and may never resolve. I have updated the HTA NUCC page to indicate this decision. @Gail Kocher was responsible for this approval and will contact @Igor Sirkovich so that he can update the Plan-Net build to use the new-old official url.
I want to mention that this was done in the spirt of responsiveness that I'd like to assume all FHIR participants will exhibit as we address important issues wrt FHIR terminology. The process that allows IP owners the ability to define the canonical url for content they own does exist and we clearly need to improve how that is conducted.
I also want to point out that there remain some serious problems with the representation of the NUCC provider taxonomy within the FHIR core that continues to concern NUCC, specifically the addition of made-up codes. NUCC expects those codes to be removed - please see FHIR-27023. We need to resolve this tracker and I'm hopeful this bright shinning light will help that happen.
Wayne Kubick (Jun 26 2020 at 21:56):
I tend to agree with Brett that this is an issue that needs a meeting to resolve. While the HTA was created by the BoD, it was not with the intent that the HTA would implement changes that break existing specs and implementations. I can't believe HTA would knowingly do so either. In the future, there needs to be an impact assessment before such changes are rolled out, and there should have been more dialogue with the affected community. But it may not be clear to the HTA how best to do that. So we need more clarity about how to make HTA work more effectively with the FHIR community and WGs in the future. I don't know who actually talked to whom, but I'd also question whether NUCC would have required this change if they knew it would break existing FHIR specs. So clearly we need to improve the communication process as well as bring this issue to resolution. And I just saw Rob's response which at least alleviates the urgency. But we need to improve the process before it happens again.
Lloyd McKenzie (Jun 26 2020 at 22:00):
Thanks for the HTA's responsiveness here - and pass on thanks to the NUCC for their understanding as we work through this new process.
Grahame Grieve (Jun 26 2020 at 22:49):
thanks @Robert McClure. I hope that this underlines the need for forward thinking around community engagement.
Michael Lawley (Jun 27 2020 at 01:21):
BTW @Lloyd McKenzie GET on http://snomed.info/sct resolves with a 303 and has done for some time I believe.
Of course it is a URI and thus should not need to resolve for any tooling to work.
Lloyd McKenzie (Jun 27 2020 at 01:29):
I stand corrected. Yay! Agree that it doesn't need to, but it's very nice that it does.
Last updated: Apr 12 2022 at 19:14 UTC
