So that would then be the only case for a modification that works.
Should we list this as version or as own terminology ?
If we list it as own terminology people have to be aware of using *
I think for all those cases (even different ICD flavours) should be fine to consider them their own thing
2 Likes
Hi
How you define the terminology and code for HGNC codes?
They typically define the code as HGNC:1100. Would you then do: HGNC::HGNC:1100|BGCA1| ?
I would follow FHIR advice
This value set includes all HGNC Codes, which includes multiple code systems. In this guide, Gene IDs from HGNC are used as CodeableConcepts, which must be sent with the HGNC gene ID including the prefix âHGNC:â as the code and the HGNC âgene symbolâ as display. CAUTION: HGNC also indexes gene groups by numeric ID (without a prefix), and older systems may send HGNC gene IDs without the prefix, so care must be taken to confirm alignment. We have separately included the genegroup code system to draw attention to this ambiguity and potential error.
2 Likes
Well fhir uses urls, we will be using namespaces.
But they do it excalty like that:
âHGNC:2621â
So it would end up as bjorn said i guess ?
I dont know about HGNC if it can have different prefixes or so
1 Like
If thatâs how they represent their codes, i.e. with âHGNC:â prefixed, then thatâs how we do it. However, are we sure that the âterminologyâ in this case is also just âHGNCâ? It probably is, but we should check. If it really is, then @bna is right. Looks a bit funny, but otherwise no problem.
1 Like
Should be HGNC as per UMLS
https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/HGNC
1 Like
1 Like
Are we on one level here with the list, i would then suggest we make a first attempt to make it more accessible/public and see how it goes ?
Anymore comments, corrections please note them.
@thomas.beale @yampeku @linforest @ian.mcnicoll
2 Likes
Iâll be honest and declare that I have doubts about the value of doing this against the FHIR approach. At the very least our list should contain the equivalent FHIR uris, as whether we like it or not these regoing to dominate in the wider market.
I would currently advise clients to use FHIR codesystems uris (many are doing that already) , and not e.g âSNOMED-CTâ, as that just complicates migration/ integration.
People already use namespaces, and you canât expect everyone to switch to URLs in openEHR, especially with legacy data (even thou they are not enforced).
Namespaces are also easier to maintain than requiring existing URLs. For example, some older ICD versions donât have official URLs, so people just make something up (hl7/âŚ) â and those URLs arenât resolvable, which defeats the purpose of using a URL in the first place.
I donât see any real value in using URLs, though I donât have strong personal feelings about it.
Adding fhir urls to them is anyhow a good idea (as a mapping).
2 Likes
I largely agree that namespaces are better but it might be interesting to get a feel for what the wider community is actually doing, esp for SNOMED, given the preponderance of FHIR-based Terminology services.
Interestingly FHIR Shorthand does allow the use of namespaces for Codesystems though these are locally defined. There probably is value in trying to keep this closely aligned with , or even jointly managed with FHIR. Adding FHR uri to the table would be a good start.
1 Like
Maybe something for june then, is there an agenda or smt ?!
We can add that along talking about Dosage and timing standardization for example.
1 Like
Itâs mainly ideology (like HL7âs earlier obsession with ISO Oids, thankfully that didnât stick). Namespaces make for more resilient data and software. We actually do use the URLs in code binding values, but not anywhere else in the ecosystem.
The reality is that the FHIR URL approach is not fully worked out, and as soon as you go outside a small number of well known terminologies, there are no defined URLs. But there are namespaces that we can use from NLM and similar places.
Transformation on the fly in and out of e.g. FHIR data is no problem. Thatâs why the table we are talking about here is useful. I agree having the FHIR URL column would be useful. Iâll put that in our version and reshare it.
2 Likes
Please PR if you find anything or want to add anything @thomas.beale @ian.mcnicoll @yampeku @linforest @bna to the terminologies.json.
Currently, it contains 51 terminologies (some of those not included in HL7 or OMOP so quite a hollistic list, surely there is still stuff missing).
I also added a OMOP mapping column, i didnt add omop as a terminology, cause its very unlikely we use them to e.g. integrate data into openEHR (@yampeku what do you think)
@sebastian.iancu maybe we can move that over to openEHR, i dont have the rights sadly.
For now i kept the - / and spaces and just did capital letters. We may change that if we want. I would have deleted the - etc as OMOP does, but we already use that for SNOMED-CT.
2 Likes
Good question⌠they DO have custom codes, but seems unlikely we will end up finding omop codes in an openehr system (but knowing people, they probably will someday soâŚ)
Here is our file, with an added FHIR mapping column.
code_systems.doc (2.0 KB)
Rename this to .csv.
Note that the namespace is the second column, not the first. Each ISO code-set is treated as if it is a distinct terminology, same for IANA.
We take a different line than HL7 for terminology URIs: the URIs we use reflect the primary maintaining org, not HL7. Thus, ISO, IANA etc have URIs pointing to them, not HL7. However, it appears that HL7 is the primary maintainer of CVX and NDC, so they are the HL7 URIs.
Your current list doesnât have any of the ISO or IANA entries. Our list doesnât have most of your rows yet 
3 Likes
Severin, was just looking at your list - are you thinking to use the name column as the technical namespace name? Notice that some entries have spaces in them, and thatâs going to be a problem for parsing situations, e.g. if names like âICD-10 CMâ are used in openEHR style stringified codes like âICD-10 CM:O44â, depending on what kind of lexing is being used, the space could mess things up. Also, I am not sure namespace names used in various frameworks (XML schema, etc) can have spaces.
Personally I stay away from spaces in such things if they are meant to be parsed.
We could create a transform that generates a form of the ânameâ with e.g. spaces replaced with underscores.
Also we are currently using lower-case for everything, but if we agreed that the names are case-insensitive, that wonât matter.
1 Like
Yeah i first wanted to collect, thinking about the format once we got to see what other did. i think spaces need to be deleted out of the reasons you named. I think its maybe easier to just delte them instead of underscoring (as OHDSI e.g. does it).
I will adapt some of your column also they make sense. Just didnt had the time yet.
1 Like