Stream: terminology
Topic: atc or atc_ddd_index
Giorgio Cangioli (Jul 08 2021 at 13:09):
@Julie James @Grahame Grieve @Rob Hausam
What is the uri to be used for WHO ATC
http://www.whocc.no/atc
as in the FHIR specs and in many (all?) published IGs (this is what I used so far....)
OR
https://www.whocc.no/atc_ddd_index/
as reported in the HTA page https://confluence.hl7.org/pages/viewpage.action?pageId=104584082
Giorgio Cangioli (Jul 08 2021 at 13:10):
thanks for clarification
Rob Hausam (Jul 08 2021 at 13:11):
@Reuben Daniels @Carol Macumber?
Julie James (Jul 08 2021 at 14:14):
@Giorgio Cangioli The HTA page contains the information as authorised by the WHO ATC folk, as you will see on it. So this is the URI that should be used
Lloyd McKenzie (Jul 08 2021 at 14:19):
The problem is if that decision is made when there's been an official URL in long use, it breaks systems. The HTA MUST check to see if there's already a URI in use by the FHIR community and listed in the FHIR spec before assigning URLs to things. The URL for ATC has been established by FHIR since DSTU1. It's way too late to change. WHO's preferences simply can't matter here.
Rob Hausam (Jul 08 2021 at 14:20):
@Julie James Was there a discussion of the http://www.whocc.no/atc url that has already been used and a specific recommendation that implementers should no longer use that url (and that the FHIR specifications need to be updated accordingly)? Is there some discussion on it documented in the minutes (or somewhere)?
Lloyd McKenzie (Jul 08 2021 at 14:20):
Transitioning breaks interoperability and costs enormous amounts for the community when we're talking about a code system that's widely used.
Rob Hausam (Jul 08 2021 at 14:21):
Yes - I definitely agree with Lloyd's points.
Lloyd McKenzie (Jul 08 2021 at 14:21):
There's no need to transition. Code system authors don't get to dictate what URL gets used for their code systems in a standard anymore than they get to dictate what database column name is used when people store their codes.
Lloyd McKenzie (Jul 08 2021 at 14:22):
HTA needs to correct their 'official' URL ASAP before it creates significant confusion within the community
Lloyd McKenzie (Jul 08 2021 at 14:24):
Discussing with the custodian what the URL should be is fine for code systems that don't already have and assigned URL. Where one has been assigned, HTA must simply adopt what's there.
Rob Hausam (Jul 08 2021 at 14:24):
I think that we (as the entire FHIR community and particularly the Vocabulary community within FHIR) haven't settled on that last point that Code system authors don't get to dictate what URL gets used for their code systems .... But we need to come to an understanding and agreement on it.
Lloyd McKenzie (Jul 08 2021 at 14:28):
If code system authors create IP rules that try to dictate what URL must be used, then we should avoid using those code systems because they obviously don't care about impact on implementation or the harm that can be done.
Lloyd McKenzie (Jul 08 2021 at 14:28):
@Wayne Kubick
Julie James (Jul 08 2021 at 14:39):
@Lloyd McKenzie Thank you for your comments. May I politely request that those who have chosen to use identifiers that are not authorised by code system owners check with code system owners before they publish and use them, rather than "dictate" after the fact? Your views on the policy (not dictatorship) are well known, Lloyd; thank you for sharing them again. They are noted. Giorgio asked a question. I have answered. You are at liberty not to like my answer and you are at liberty to ignore my answer with whatever consequences may or may not follow from that. It does not change my answer.
Lloyd McKenzie (Jul 08 2021 at 14:40):
Code systems have never authorized identifiers for their use. That's not their role.
Lloyd McKenzie (Jul 08 2021 at 14:40):
Code systems define what codes are allowed. Not how they're stored or transmitted.
Lloyd McKenzie (Jul 08 2021 at 14:41):
Because we would like the URLs for code systems to resolve usefully, it makes sense to reach out to code system owners for a URL that we can count on resolving when we don't already have one in use. But that's the only reason to talk to code system owners about the URL at all.
Julie James (Jul 08 2021 at 14:42):
Well, let's agree to differ on that, shall we? :)
Lloyd McKenzie (Jul 08 2021 at 14:42):
We've been sharing codes in HL7 standards for over 30 years. Code system owner permission for the v2 code or OID has never been a requirement
Mark Kramer (Jul 08 2021 at 14:42):
Some code system authors do not have a clue what makes a good canonical URL for FHIR purposes. For example, NCI wants http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl which is a horrible canonical (it brings in the physical formatting of their master data). I do not think code system owners should have carte blanche make this decision for the FHIR community.
Lloyd McKenzie (Jul 08 2021 at 14:42):
Can't agree to disagree when HTA policy breaks existing interoperability and spawns confusion for implemeners.
Lloyd McKenzie (Jul 08 2021 at 14:43):
Implementer impact matters more than code system authors being happy here. End stop.
Lloyd McKenzie (Jul 08 2021 at 14:43):
If the HTA can't prioritize implementer impact, then they shouldn't have this responsibility.
Mark Kramer (Jul 08 2021 at 14:45):
In violent agreement with @Lloyd McKenzie
Julie James (Jul 08 2021 at 14:45):
As I say, we have to agree to differ, because your view of the world does not match mine. I personally will not worship at the altar of implementation, it is far to fragile, as we have seen over the years.
Lloyd McKenzie (Jul 08 2021 at 14:46):
Without implementation, we're wasting our time. Implementation is what gives interoperability. Without that, all we have is shelfware.
Lloyd McKenzie (Jul 08 2021 at 14:48):
We need to respect terminology author's IP. Their IP doesn't dictate the identifiers used to store/convey their IP. Breaking implementations (and costing hundreds of thousands of dollars or more to the community to accommodate change, plus the patient risk that results) is pure foolishness.
Julie James (Jul 08 2021 at 14:49):
Agreed that implementation is important. Almost all the systems I've ever been involved in building (with two exceptions) are still working. But it is not my god. I'm really sorry guys, but I cannot sacrifice the principles I know to be true. So, if that doesn't fit your world, that's sad. I'm trying to get things better for you on terminology, but it's really hard when efforts are so rejected. I personally worked with the ATC folk to get everything aligned. Clearly in your view I wasted my precious time. I would have better spent it in the garden!
Julie James (Jul 08 2021 at 14:50):
So, I'm going to close my end of this because it is clearly not helping you. The sun is shining, I'll go into the garden :)
Wayne Kubick (Jul 08 2021 at 15:54):
While HTA can set policy moving forward for URIs of newly-added code systems, I agree with Lloyd that we cannot make breaking changes to existing implementations without assessing the impact - especially in this case when it would involve breaking systems that had been using an existing URI for many years before the policy was created. Whether we like it or not, we're obligated to support what we previously defined unless the community agrees to the breaking change, so HTA should adjust their process to include verifying that no significant breaking changes will occur before making agreements with external terminology providers about URIs. In this case, the prior URI as listed in the FHIR spec should be used.
Lloyd McKenzie (Jul 08 2021 at 16:04):
What would be useful - and what is needed - is a policy that looks like this:
When assigning URIs for a code system, the following priorities shall be adhered to, in order of priority:
- Code system URIs SHALL be static. Change to a URL in use by the community may only be contemplated in the following cases:
- the same URI has been accidentally issued to multiple code systems or what was thought to be a single code system has turned out, through its behavior, to be more than one. (Here, the change is to ensure semantic interoperability where system + code has consistent meaning)
- there is a typo in the URL that is going to cause significant confusion to the community AND the community has determined that the pain of dealing with the confusion is greater than the pain of making the change (which generally means that the code system is not yet in wide use)
NOTE: this requirement does not apply across standards families. For example, if v3 used an OID, FHIR can use a meaningful URI because transformation is already a requirement at the boundary between v3 and FHIR.
-
Code system URIs SHOULD be human-readable and human meaningful. This is a key aspect of reducing implementer burden and learning curve. As much as possible, we avoid URIs made of of OIDs or UUIDs or other character sequences that don't reflect to a human what the code system actually is. Note that this does not trump #1. If (unfortunately) an OID is already in widespread use in FHIR implementations, that defacto becomes the mandated URI
-
Code system URIs SHOULD be concise. A URI is something that will need to be typed many thousands of times and will also appear in millions or billions of instances. Over-long URIs impose a cost on implementers, storage and bandwidth.
-
Code system URIs SHOULD be URLs that resolve to some useful description of the code system and SHOULD be defined such that they can be expect to reliably resolve for a long time (many decades). I.e. they should be established as permalinks. This isn't essential, but is certainly a nice-to-have
In cases where a URI is not already in use by the community, the HTA should work with amenable terminology providers to determine an appropriate URI, primarily because the terminology provider is generally the best organization to achieve #4. However, in meeting the objective for #4, all prior priorities must be respected. If #4 cannot be achieved in a manner that also adheres to the higher priorities, the HTA should assign a URI that adheres to the first 3 priorities and, if possible, relies on HL7 to establish the permalink that will achieve #4.
In cases where a URI is already in use by the community, the HTA should confirm that the entity pointed to by the URI is in fact a single distinct code system, and having confirmed that, publish the URI already in use.
If the IP usage rules of an organization preclude the use of a URI that adheres to #1, we should treat that code system in the same manner we treat code systems that do not enforce code-concept permanence. I.e. A code system that is not safe for use and that should be avoided.
Jean Duteau (Jul 08 2021 at 16:14):
#3 seems strange. I don't see why "typed many thousands of times" should have anything to do with the choosing of a URI. Almost all DBs are optimized for dealing with strings that are 50 vs 20 chars long.
Lloyd McKenzie (Jul 08 2021 at 16:18):
Software developers will end up typing the URIs many times when writing code, creating test cases and examples, doing manual searches, etc. Plus bandwidth for exchange also matters.
Jean Duteau (Jul 08 2021 at 16:25):
i don't buy that argument. #3 is a pretty weak reason in my books. If it came down to "we have a 50-char URI and a 20-char URI, which should we choose?", sure, but I find it hard to believe that will ever be a sticking point.
Jean Duteau (Jul 08 2021 at 16:26):
if we really cared about length, we wouldn't be assinging these URIs but codes.
Lloyd McKenzie (Jul 08 2021 at 17:06):
#3 isn't pushing for 10 character URIs, but it is saying "try to avoid 150 character ones". If you can get a 150 character URI that will resolve, you should still look at it as suspect. (In part because 150 characters suggests that the URI is pretty deep, which makes the likelihood of it sticking around as a permalink pretty low.)
Julie James (Jul 08 2021 at 17:18):
Hello @Wayne Kubick As you know, the HTA policy has been in place for some years now. You have never, to my personal knowledge, said that "HTA must take into account any breaking change". May I suggest that you are now offering a "breaking change" to policy? Where is the written policy, please, that states that "we" (whoever we are) are "obligated" to support what has previously been written somewhere (I am not sure that "defined" has any meaning whatsoever in this context). May I request that you attend HTA to propose your "breaking change" to its policy, please?
Max Masnick (Jul 08 2021 at 20:34):
Re: #3, an IG that I work on (the SMART Health Card Vaccination IG) is negatively affected by long code system URIs -- our resources have payload size constraints in order to fit inside a QR code. For this use case (which is admittedly probably pretty rare), there is a tangible difference between 20 and 50 chars -- it could in some cases be the difference between a patient having to carry two QR codes instead of one to represent their COVID vaccine series.
Peter Jordan (Jul 08 2021 at 23:17):
From my collection of COVID-19 Vaccine Codes...
Shortest Code System URI ... http://nzmt.org.nz
Longest Code System URI... https://www.humanservices.gov.au/organisations/health-professionals/enablers/air-vaccine-code-formats
Size matters!
Carmela Couderc (Jul 13 2021 at 12:03):
Thanks for your thoughts Lloyd. Thank you Julie for so eloquently describing the service HTA provides. To Lloyd's points,
#1 ignores reality, urls will change. Implementers should design for change - just as a patient identifier such as medical record number has a probability of changing, so does a code system url.
#2 good thing to aim for, however might not always be possible especially when considered with #3.
#3 ignores the fact that copy/paste has been around for decades (cost to implementers argument) and storage is a shaky argument at best. - storage costs also hasn't been an issue for years (noting the exception of QR codes).
The comment about database column names is specious - database schemas are not used when designing for interoperability.
HTA works with terminology providers to ensure that HL7 is representing the provider's owned and managed content as required. HL7 is not in the driver's seat, but is working with the terminology owner to guide and inform them. The priority is for the terminology owner and their IP to be respected, not for HL7 implementers to feel free to use whatever they want. HL7 is not a dictatorship as suggested by the dramatic last sentence about safety for use.
Michael Lawley (Jul 14 2021 at 23:12):
Wayne Kubick said:
While HTA can set policy moving forward for URIs of newly-added code systems, I agree with Lloyd that we cannot make breaking changes to existing implementations without assessing the impact - especially in this case when it would involve breaking systems that had been using an existing URI for many years before the policy was created. Whether we like it or not, we're obligated to support what we previously defined unless the community agrees to the breaking change, so HTA should adjust their process to include verifying that no significant breaking changes will occur before making agreements with external terminology providers about URIs. In this case, the prior URI as listed in the FHIR spec should be used.
I agree and distinctly recall a Vocab discussion on this very topic several years ago (in Montreal?) and the issue of incumbent URIs was foremost. This is cannot be claimed as a new issue to HTA.
The frustration I have here is that the HTA page has no apparent acknowledgement of a pre-existing URI, nor that this was raised with the owner and that the impact / cost of selecting something different (which is very large) was understood and only done with some reasonable/specified justification.
Lloyd McKenzie (Jul 15 2021 at 01:33):
(and consultation with the community impacted)
Michael Lawley (Jul 15 2021 at 21:58):
Digging a little further, I see this spreadsheet https://confluence.hl7.org/download/attachments/91999004/HTA_External_Terminologies_Analysis-RD-20201014-1.xlsx?version=1&modificationDate=1602682649082&api=v2 which tracks information relating to external terminologies but omits any reference to http://www.whocc.no/atc even though it (at least) sits directly on this page of the FHIR spec: https://www.hl7.org/fhir/terminologies-systems.html
It is hard not to conclude that some failure of process means that this prior use was not ever considered and that the decision should be revisited?
Lloyd McKenzie (Jul 16 2021 at 15:19):
As I understand things at the moment, apparently HTA doesn't consider pre-existing URIs mandated by the FHIR specification to be relevant to their process. (which is a HUGE problem...)
Carol Macumber (Jul 19 2021 at 21:23):
Hi All - The HTA process did require requestors to check for existing URLs before requesting a new one. It specifically suggested checking the FHIR Code System page.
"Requestor does due diligence - searching of existing code system information (e.g., Uniform Terminology Governance Repository, FHIR Codesystem Registry, OID Registry, FHIR Community Codesystem Registry, HTA External Terminologies Registry) PRIOR to contacting HTA for assistance"
With the release of THO, the policy has been updated to require requestors to check THO and the HTA confluence pages. Work is in progress to migrate and align the information on HTA confluence with the information at THO by @Reuben Daniels and others. The spreadsheet Michael refers to was an artifact created by Reuben as part of that process, identifying areas of improvement with legacy HTA pages that pre-dated most of the current HTA members.
All that being said, I've added this topic to the upcoming HTA meeting so we can come to a resolution on ATC in particular. I'm hopeful we'll come to a combined understanding of a way forward that supports implementers, respects the existing HL7 policies and processes with regards to the use of external terminologies, and utilizes (where necessary) the tools in place to support instances where change to code system information needs to be communicated and documented.
@Jessica Bota and @Ted Klein As a side note, we also need to look at the existing THO entries. It appears that the drug related ATC "Anatomical Therapeutic Chemical" information has been melded with a codesystem for "American Type Culture Collection".
http://build.fhir.org/ig/HL7/UTG/CodeSystem-atc.html
http://build.fhir.org/ig/HL7/UTG/NamingSystem-atc.html
URL appears to be for drug ATC, while OID appears to be American Type Culture Collection related.
Mark Kramer (Jul 20 2021 at 20:04):
And please take up the issue of permanency. A canonical URI for a code system should be technology-independent. It should not end with .owl or .xlsx or dot anything, since file types will change. A code system identifier should never refer to a FORMAT. This has been violated at least once (NCI Thesaurus).
Michael Lawley (Jul 21 2021 at 03:02):
IMO it should not matter what the URI looks like (whether it ends with .owl or whatever) as long as it is identifying the "thing" - ie the code system rather than a specific representation of the thing.
For these cases, since the OWL itself includes a declaration of the ontology's URI (which just happens to end with .owl), I have taken that to be the identification of the thing. Used as a URI, nobody should ever really be looking at the sub-parts of the string to infer anything.
Lloyd McKenzie (Jul 21 2021 at 03:41):
Ideally the canonical URL would resolve to a a variety of syntaxes depending on the Accept header, so a specific file extension would be misleading at best. I don't know that we'd refuse a URL with an extension, but it certainly would be best practice to avoid it if defining a new one. It's not something we'd consider changing a URL for though.
David Simons (Feb 11 2022 at 11:27):
Running into this now...
1) What system-uri to use: http://www.whocc.no/atc or https://www.whocc.no/atc_ddd_index/ ?
2) Can this codesystem be added to tx.fhir.org?
Are these not two separate CodeSystems, now combined under https://www.whocc.no/atc_ddd_index/?
A) The ATC classification system groups the active medical substances...
B) The DDD is a unit of measurement and is linked to the ATC code...
(trying to understand, WHOCC to provide clarity)
Grahame Grieve (Feb 11 2022 at 12:47):
I think we've had problems getting hold of licensed source for that code system?
Lloyd McKenzie (Feb 11 2022 at 17:36):
The system that shall be used for ATC codes is http://www.whocc.no/atc. I can't speak for whether ATC_ddd constitutes a new code system, or two code systems.
Rob Hausam (Feb 11 2022 at 21:06):
We've been able to get the complete source for ATC. But right now the ATC version on tx.fhir.org is May 2020, and we still don't have a regular and reliable way of getting the full updates.
Carol Macumber (Feb 11 2022 at 23:18):
Not commenting on acquisition...
URL from FHIR for ATC stands...as we've agreed is the case for all previously defined URLs in R4 UNLESS community has agreed a technical error was made and agrees to a change. The codesystem URL for ATC is https://www.whocc.no/atc and is shown as such at THO and in FHIR. Both the HTA and FHIR external code system metadata are being reconciled and systematically (by @Reuben Daniels as part of the next planned THO release) migrated to THO as the single source of truth (as agreed upon by HTA, FHIR-I, Vocab, TSMG and TSC). In that process any remaining inconsistencies in the older HTA pages will be resolved.
The question about ATC and DDD being one or two code systems is new and separate question (as far as I understand it) and will be on the agenda for the TSMG call next week (instead of waiting until the next HTA call in two weeks).
Carol Macumber (Feb 22 2022 at 22:22):
HTA has confirmed via ATC SMEs that there is only one code system with respect to ATC. The ATC code system is composed of ATC codes that may have a defined daily dose (DDD) attribute.
Lloyd McKenzie (Feb 22 2022 at 23:00):
To confirm @Carol Macumber, And the DDD attribute codes are considered to be ATC codes (just as LOINC Answer codes are considered LOINC codes)?
Rob Hausam (Feb 22 2022 at 23:39):
I don't think that is likely to end up being the case, as the DDDs are quantity attributes associated with particular ATC code/route combinations. An example is here for the ATC code for semaglutide (A10BJ06).
Lloyd McKenzie (Feb 23 2022 at 01:26):
I actually meant the DDD unit, which I think was the original question
David Simons (Feb 23 2022 at 14:16):
Looking at the example that @Rob Hausam shared:
Seems the "The DDD is a unit of measurement" wording on https://www.whocc.no/ddd/definition_and_general_considera/ set me on the wrong foot ... Rather "The DDD is the assumed average maintenance dose per day for a drug used for its main indication in adults."
Seems the DDD is a quantity rather than only a unit.
Will https://confluence.hl7.org/pages/viewpage.action?pageId=104584082 be updated?
Mind the https vs http in http://www.whocc.no/atc!
Julian Sass (Feb 23 2022 at 14:47):
We have an experimental CodeSystem of the German ATC adaption which is very similar to the WHO ATC. Agree with @Rob Hausam that the DDDs should be properties. We have them as string type properties currently, although quantity would be more suitable for DDDs. Quantity is none of the supported concept property types though.
Link to the CodeSystem with DDDs: https://simplifier.net/MedizininformatikInitiative-ModulMedikation/CodeSystemATC2020/~json
Last updated: Apr 12 2022 at 19:14 UTC
