Stream: terminology
Topic: AllergyIntolerance severity classifications GINA/ARIA etc
Alexander Henket (Apr 26 2021 at 14:23):
In talking to allergists we discovered that they have to use 4 international classifications for coding specific classifications for severity that more or less map well into SNOMED CT, but where it is imperative we define the mappings for them. To that end I'm looking for how to identify these systems. Given the international nature of these systems I'm thinking an international identifier makes more sense than a Dutch one.
The systems concerned:
- Global INitiave on Asthma or GINA - see report page 39
- Allergic rhinitis and its impact on asthma or ARIA. In collaboration with the World Health Organization. Executive summary of the workshop report. 7-10 December 1999, Geneva, Switzerland Allergy . 2002 Sep;57(9):841-55 - see report page 16
- Three Item Severity or TIS score - Scoring the severity of atopic dermatitis: three item severity (TIS) score as a rough system for daily practice and as a prescreening tool for studies. Acta Derm Venereol 1999; 79:356–9 - see scientific article
- EAACI/GA²LEN/EDF/WAO guideline for the definition, classification, diagnosis and management of urticaria, Allergy 2018 Jul;73(7):1393-1414. Note the actual severity classification is mentioned in the following article, not in the guideline: Comparison of Urticaria Activity Score Over 7 Days (UAS7) Values Obtained from Once-Daily and Twice-Daily Versions: Results from the ASSURE-CSU Study Am J Clin Dermatol (2018) 19:267–274 table 1 - see this link
To be clear: I'm looking for OIDs not system uris. Using "urn:oid:" I'm totally good on uris if we have the OIDs, when we cross the FHIR bridge for this part. How does the process work for international systems? (@Ted Klein)
Lloyd McKenzie (Apr 26 2021 at 18:00):
If we define these in FHIR, we'd definitely want to define URIs. We don't want to use urn:oid: in FHIR if we can possibly avoid it.
Robert McClure (Apr 26 2021 at 18:32):
@Alexander Henket Even if we only want to use a portion of a code system, we need HTA to help get the canonical url. There is an HTA page on the process that I'm assuming is up to date. @Carol Macumber @Julie James
Alexander Henket (Apr 28 2021 at 06:08):
I'll file that Jira ticket for HTA. @Lloyd McKenzie I don't mind that a URI exists, as long as the OID exists too. Any URI without an OID is a step towards HL7 not supporting V3 anymore. Having an OID allows a way into FHIR. Having just a URL does not allow me a way out of FHIR. The legend of the Roman senator Carto Maior comes to mind in this topic :-)
Alexander Henket (Apr 28 2021 at 06:15):
Created https://jira.hl7.org/browse/HTA-39
Lloyd McKenzie (Apr 28 2021 at 14:17):
If the URI exists, you'll have to use the URI in your FHIR interface - you can't conformantly use urn:oid:xxx if there's a standard URI defined.
Lloyd McKenzie (Apr 28 2021 at 14:17):
Totally fine with you having both to support conversion with v3.
John Moehrke (Apr 29 2021 at 11:39):
Lloyd McKenzie said:
If the URI exists, you'll have to use the URI in your FHIR interface - you can't conformantly use urn:oid:xxx if there's a standard URI defined.
I find this unfortunate. The OID and URL should be considered equal. Where is this rule stated in FHIR?
Lloyd McKenzie (Apr 29 2021 at 14:35):
Core spec - "If a URI is defined here, it SHALL be used in preference to any other identifying mechanism" at the top of each of the code system, value set and naming system pages. It's super important to have consistency across all systems. If 5 different systems all have 5 different URIs for "U.S. social insurance number" or "Alberta Unique Lifetime Identifier", you've got no chance of interoperability. NamingSystem allows you to convert easily from non-authoritative to the 'official' URI. And it's much cheaper to force all source systems to do that than it is to force all querying systems to search across all of them.
Alexander Henket (May 06 2021 at 07:55):
I'm aware of that text and we stick to it. The problem comes when FHIR invents a URI when OIDs are already in use as system URI. So for any system: either invent an OID and a URI in tandem or accept that the OID (with urn:oid:) is fine going forward. We have at least 10-20 times more active OIDs in use in FHIR than we have URIs. It saves the whole ecosystem a lot of headaches for each and every thing that does not needs conversion. As we have working OID Registries that people know where to find, and that support NamingSystem export, having OIDs is never an issue.
Lloyd McKenzie (May 06 2021 at 16:43):
If you want to avoid change, the simplest thing is to have a standard URI registered and start mapping from day 1 rather than auto-convert to an OID now and have to worry about mapping later. The desire is to absolutely minimize the number of places that OIDs appear in FHIR instances - because OIDs are not developer-friendly.
Alexander Henket (May 07 2021 at 13:31):
Agreed ... if we are going to have URLs at all, then they should be in place from the start. As for not developer-friendly: I continue to beg to differ.
Lloyd McKenzie (May 07 2021 at 13:38):
URLs can be read by humans, understood by humans and have the ability to be resolved. OIDs have none of those. If we hadn't used OIDs in v3, no one would be proposing their use now. Making mapping to v3 easier while making use of FHIR harder is not a good trade-off. V3 will eventually disappear. If OIDs get mandated for use in FHIR, implementers will be stuck with them for a long time.
Alexander Henket (May 07 2021 at 13:56):
OIDs have well defined governance, URLs do not. Exactly because they are strings you cannot read, they have less debate to set up. URLs are prone to change because of readability issues, because of domain changes, because of taste issues. The resolving is overrated: many of the system URIs out there do not resolve at all. The days I've spent debating URLs just this year far exceed what I ever spent on OIDs.
Introducing a new identification system after using one that works for 20 years forcing everyone with any investment in the current methodology into keeping records of both is a bad value proposition. It is exactly because we have had OIDs for the longest time that we should not have opted for a different thing that has readability as its best and worst argument.
Lloyd McKenzie (May 07 2021 at 14:13):
I've had just as much argument about OID hierarchy and changing OIDs when organizations merge and split as I've had with URLs. I've never had to explain what a URL is - I always have to explain what an OID is. When we embarked on FHIR, the primary concern was "what is easiest for net new implementers" - if we were concerned about what was easiest for those migrating from v3 or CDA, we'd have stuck with that. Converting is going to be necessary when you migrate between standards. NamingSystem makes that pretty straight-forward. Also, converting is now mandatory no matter what, so avoiding some conversions when others are mandatory doesn't really buy you anything - other than the ongoing pain of using OIDs...
Alexander Henket (May 07 2021 at 14:17):
Well all I can say is that I was in the room with you for this decision. I disagreed then and I disagree now. We comply with URLs if they exist, I/we don't strive for them to be created when OIDs exist. The pain of creating them and then mapping them is not worth it.
Craig McClendon (May 07 2021 at 22:18):
Counterpoint - I've "made up" many URLs when mapping data into FHIR the past few years.
If you need to define a local codesystem or identifier namespace it's quick and easy. Take the organization's top-level domain name and make something up underneath it that is relatively descriptive and likely unique.
Using domain names in this way has worked for Java package naming since the mid 90s with billions of lines of Java code written since and no major problems of which I am aware with name clashes. I'm sure there have been more than 0, but it's just not a likely enough problem to warrant an onerous governance process, IMO.
If I had to register an OID every time I've needed a namespace a 20 second process would turn into hours or more.
Team URL here.
Michael Lawley (May 09 2021 at 04:44):
And I'll just drop in here to remind people that these are URIs we're talking about, not URLs. Also, they should never (or extremely rarely) need to change.
Last updated: Apr 12 2022 at 19:14 UTC
