Stream: terminology
Topic: OMOP Standard Terminologies
Grahame Grieve (Aug 26 2021 at 06:12):
I'd love it if some vocab people could review this mapping of the OMOP Vocabularies table to HL7 standard OIDs and FHIR URIs.
I'll make changes or I can give edit access if you ask.
@Ted Klein HCPCS - which is correct?
Once we've reviewed this, I'll work with the HL7 / OHDSI joint project to get this table filled out and agreed, and hopefully, added to OMOP itself
Grahame Grieve (Aug 26 2021 at 06:18):
@Michael Lawley fyi
Michael Lawley (Aug 31 2021 at 12:01):
I'm unsure about the vocabulary_concept_id column - these may be the ids in a specific instance of the vocab data, but my understanding is that these are internal ids, allocated during a vocab load process, and not portable across tooling deployments?
Michael Lawley (Aug 31 2021 at 12:05):
I notice AMT is not included in the list. This may not be a bad thing - the support for AMT is archaic (dates back to AMT V2), but given that SNOMED is limited to a non-standard combination of US + UK + INT, that orphans AMT as well.
Michael Lawley (Aug 31 2021 at 12:06):
It may also be useful to have a FHIR Version column corresponding to the vocabulary_version column, since they also don't, in general, align.
Grahame Grieve (Aug 31 2021 at 12:15):
well, we need to talk about Australian usage more generally, but that discussion belongs elsewhere.
Grahame Grieve (Aug 31 2021 at 12:15):
I thought vocabulary_concept_id was standardised by athena?
Michael Lawley (Aug 31 2021 at 12:20):
They are specific to an Athena instance. If you run your own (rather than relying on https://athena.ohdsi.org/), then you will get different values. (Also if you reload from scratch with new versions - but I don't know how this is managed specifically for https://athena.ohdsi.org/)
Michael Lawley (Aug 31 2021 at 12:25):
My main concern is that they are surrogate keys, not intrinsically stable. I would be much happier if they were a function of the code system + code pair (and + version, where the codesystem doesn't support concept permanence), since then they'd be stable (and you wouldn't need a giant lookup table/map).
Grahame Grieve (Aug 31 2021 at 12:28):
well, anyway, that's kind of an OMOP problem more than a FHIR problem, I think. Doesn't affect this table, right?
Michael Lawley (Aug 31 2021 at 12:38):
not substantively, no
Ted Klein (Sep 01 2021 at 22:44):
ok finally getting a few moments to look at this...the entry for HCPCS in the spreadsheet is, I think, messed up. Syntactically correct, semantically wrong I believe. "HPC" the originally (back prior to 2001 I believe more than 20 years ago) this was entered as part of the pro forma import of UMLS. It is the entirety of the technical composition of Healthcare Financing Administration (HCFA) Common Procedure Coding System (HCPCS), however no one in the real world of implemented systems uses this - it covers all three "levels" the first of which is CPT-4, and the others are CDT-2 dental codes and HCPCS modifier codes. What I believe is actually used is now referred to as "HCPCS(II)" or just "HCPCS" and was formed to disentangle the conflation confusion originally. The official title is "Healthcare Common Procedure Coding System (HCPCS) level II alphanumeric codes" and is identified with 2.16.840.1.113883.6.285 (for OID based terminology systems). So I don't know if the entry for this in the OMOP stuff is accurate, or reflects an incomplete understanding of the etiology and use of this beast. The HTA page at https://confluence.hl7.org/display/TA/Healthcare+Common+Procedure+Coding+System+%28HCPCS%29+Level+II has pretty complete information, and the CodeSystem resource "stub" in THO at https://build.fhir.org/ig/HL7/UTG/CodeSystem-hcpcs-Level-II.html should also be correct.
Ted Klein (Sep 01 2021 at 22:45):
Do you want me to examine the other two items highlighted in yellow? I am not sure what the column headings on the first row of the google sheet actually are intended to mean ("vocabulary reference"? "vocabulary_id"?).
Grahame Grieve (Sep 01 2021 at 22:45):
all but columns B and C are from the omop table
Grahame Grieve (Sep 01 2021 at 22:46):
I'm not sure I've got the yellow ones right, so sure, please review
Grahame Grieve (Sep 01 2021 at 22:51):
And do we have anything on all the empty pale yellow squares?
Ted Klein (Sep 01 2021 at 23:49):
We do, on several but not all. I have not time to do the diligence required, but for sure some of these need straightening out. @Davera Gabriel I think is involved in this in some way, perhaps she can take some time to look into these?
Davera Gabriel (Sep 02 2021 at 18:08):
Hi guys... I can provide some context which may help.
I am a member of the newly-minted OMOP Vocab WG., its only met 3 times thus far. The OMOP Vocab work used to be folded under the OMOP Common Data Model group, but due to changes in community requirements the need for a separate WG was embraced and thus formed. Thus far the group has developed a mission and as of yesterday proposed a set of objectives and key results, most of which (in their draft form) aim to improve the vocab content development processes. One thing we identified as a community need is an historical set of OMOP vocab releases, which are unavailable as static info. Right now they employ a machine process which generates changes between development and production instances, but do not retain full histories / versions. A work item at the upcoming annual symposium (unfortunately co-occuring during our next Connectathon) is the Vocab WG will be crowd-generating a "time machine" (their term) of full prior versions to host on an open resource. Additionally, one of the SIG-like group of tasks identified for the WG is "version control / concept lifecycle management" As such, please take-away that the OHDSI Vocab group is aware and has prioritized this as an area for work / improvement.
An additional SIG-like activity identified in this group's formation is "FHIR Terminology Alignment" for which I have been designated as the lead. I see my role therein as being focused on detailed activities that (it would seem) stem from the larger HL7 / OHDSI joint project. Your spreadsheet is something I envisioned as being a key objective / starting point. But I suppose the immediate take-away is to echo what @Michael Lawley stated regarding discontinuity of OMOP concepts at times and add that the OHDSI Vocab WG is keen to improve the versioning processes. HL7 FHIR will be better off while engaging to understand where they are with that and not make assumptions regarding the continuity (ie: canonical-like) assertions of declaring versioning information / identifiers of components of the OMOP Vocabulary just yet.
How can I assist with your goals? I am happy to work with you.
Grahame Grieve (Sep 02 2021 at 19:23):
not make assumptions regarding the continuity
Sure. but that kinds of means we're stuck at no go stage; the first thing to do is to assign code system identifiers so we can use codes...
Davera Gabriel (Sep 02 2021 at 19:28):
@Grahame Grieve if you can help me understand more fully the need / context, I will be sure that is a priority item in the "FHIR Terminology Alignment" work. But note: I gather not a lot of progress may be made until after their symposium, but we can try. I will look at your ss again and queue-up questions re: what I might not understand. The next OHDSO Vocab WG is at the end of September, perhaps we can get this ask on that agenda
Grahame Grieve (Sep 02 2021 at 20:29):
well, I think the question of continuity isn't relevant here. The question is whether we (FHIR + OMOP communities) can agree to identify the OMOP vocabularies consistently. For things external to OMOP, HL7 needs to assign OIDS and URIs to them, and then we need to get them into our agreed list. Then, we need to agree what they are for the OMOP internal ones. And finally, we need to agree where this list is mastered and published
Davera Gabriel (Sep 02 2021 at 21:13):
got it, thank-you. I am happy to share this need to assign and engage the OHDSI Vocab WG, or ask for an agenda spot and invite you or appropriate FHIR designee(s) to engage on this topic. Does this work as a next step?
Grahame Grieve (Sep 02 2021 at 21:14):
sure that works. What time are the calls?
Davera Gabriel (Sep 02 2021 at 21:27):
Standby: there was a spot kicking around on 9/21, and since that's during our WGM, I am double checking to see if that is actually the case and when the next one after that is scheduled so both options can be considered
Davera Gabriel (Sep 02 2021 at 21:29):
... in the future maybe we can get them to join our WGMs :)
Michael Lawley (Sep 02 2021 at 22:00):
hi @Davera Gabriel I am very keen to understand how I might be able to engage with the OHDSI Vocab WG. As you might expect "FHIR Terminology Alignment" is something I (and a broader Australian OHDSI user community) are very keen on.
Davera Gabriel (Sep 03 2021 at 15:20):
@Michael Lawley That's great news. The WG is just forming, finalizing their key objectives to initiate work on after the symposium. As I eluded to above the community as a whole is absorbed with execution / attendance at their annual symposium 9/12-15. I expected to be able to review the overarching key objectives and discern / develop what FHIR Terminology Alignment also fell within those. Grahame's list of identifiers is a nice ask that at least somewhat falls in that general domain. Perhaps we could work on a set of FHIR Alignment objectives / activities together / as a group? Also, I am pretty sure the OMOP Vocab WG is an open meeting, although occurring at a time that's not so convenient for you. I think I can help by facilitating convos / engagement between the respective Terminology communities, and am also thinking we might consider convening some meetings more conducive to participation among our Southern Hemisphere membership as well... Can I suggest we start with the FHIR Alignment objectives based on their WG OKRs? Certainly keen on my part to divide and achieve :)
Davera Gabriel (Sep 03 2021 at 15:28):
@Grahame Grieve the OHDSI Vocab WG meets every other Tuesday at noon EASTERN (US) with some variance for the 5-week months. the pattern is to meet at the same time as the OMOP CDM WG, but opposite weeks. The next meeting is 9/21, which means the following is October 5. What works for you?
Grahame Grieve (Sep 03 2021 at 18:16):
well, noon eastern isn't really very practical - 2am.
Grahame Grieve (Sep 03 2021 at 18:16):
I agree that alignment objectives are a good place to start
Davera Gabriel (Sep 13 2021 at 17:20):
Hello @Grahame Grieve I see there are a couple of OHDSI / HL7 workshops aiming to drum up community involvement that have been scheduled at the end of the month. I expect to have met again with the OHDSI Vocab group again before those workshops. Does this obviate the need for the course of action you & I have been discussing in this thread? Or might I press ahead? Please advise & thanks
Grahame Grieve (Sep 13 2021 at 17:21):
no please press ahead. Those workshops would naturally include a summary report from one of of us regarding progress on this
Grahame Grieve (Sep 13 2021 at 17:21):
and probably working through the need for it
Davera Gabriel (Sep 13 2021 at 17:25):
good deal: just wanted to check potential cross-purposes :)
Davera Gabriel (Sep 16 2021 at 14:19):
Hello @Grahame Grieve Reviewing the referenced ss (for context to queue-up an agenda item in the OMOP Vocab WG next week) was this generated against OMOP v5.3.1 or 6.0?
Grahame Grieve (Sep 16 2021 at 18:42):
probably 5.3.1? I couldn't get the scripts to generate 6 to run - syntax and logic errors in 6.0.
Grahame Grieve (Sep 16 2021 at 18:42):
mind you, there were errors to fix in 5.3 too. Quite surprising
Davera Gabriel (Sep 16 2021 at 19:00):
fwiw: 5.3.1 is the most stable, deployed version. This was established in late 2019 when they conducted a big community hackathon and surveyed the participants re: their deployed versions. The reason for this is the Atlas / other tooling stacks run on 5.3.1 and were not yet converted to 6.0. As such, the 6.0 CDM was developed, and is now in re-development. Theya re actively working on 6.x in the CDM WG in 2021. Im not sure of the newly minted "6" will be 6.1 or not. I gather there were so few adopters of 6.0 that they might just stick w that. So... definitely do your work for now on 5.3.1. This is what we used for the N3C implementation for the reason stated above. The CDM WG is actively working on 6, but its not in any sort of widespread use. Put conversion to 6.x on the development roadmap somewhere and be at-ease knowing your user base will likely be running 5.3.1 for the time being.
Davera Gabriel (Sep 16 2021 at 19:48):
Hello again @Grahame Grieve Mik (at OHDSI) is asking what the significance of the red shaded cells? I've sent over your comments above about the yellow highlighted cells. Also: they are starting up the OHDSO Vocabulary WG the following week on 9/28, not next week 9/21 as I thought.
Grahame Grieve (Sep 16 2021 at 19:49):
the two red shaded cells are my proposal for OHDSI to approve, the canonical URLs for the OMOP vocabularies. They show what the pattern would be
Emma Jones (Sep 16 2021 at 20:27):
@Ted Klein - Would it be safe to use the following as the codeSystem from https://terminology.hl7.org/CodeSystem-HCPCS.html?
see code system http://terminology.hl7.org/CodeSystem/HCPCS
Emma Jones (Sep 17 2021 at 13:44):
@Ted Klein Does this mean we (implementers) can use either of these as the code system in our FHIR implementations?
http://terminology.hl7.org/CodeSystem/HCPCS or http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets
Ted Klein (Sep 20 2021 at 20:05):
Sorry just saw this now - The Canonical URL for HCPCS is https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets. This is in the most recent THO Published Release 2.1.0 and is considered authoritative. The URI that was created algorithmically through the import from the old V3 coremif content when the initial working set for THO/UTG was created (http://terminology.hl7.org/CodeSystem/HCPCS) was identified as erroneous and was corrected last year based on comprehensive information documented by HTA see page at https://confluence.hl7.org/display/TA/Healthcare+Common+Procedure+Coding+System+%28HCPCS%29+Level+II You should not be using the THO-anchored URI, as it was part of the initial dataset for THO before vetting and review. Is there any further information on this one, @Carol Macumber and @Jessica Bota ?
Christian Reich (Sep 21 2021 at 13:02):
New to this community here, so not sure it's the right place. But: How do you guys deal with the fact that the CMS only stores the current codes. They explicitly kill deprecated ones (to avoid having providers use it for billing). Do you keep them somewhere?
Davera Gabriel (Sep 22 2021 at 13:53):
@Christian Reich HL7 doesn't "keep" copies of external terminologies. The only exception to this is a "courtesy copy" of a portion of SNODENT in THO. External terminologies referenced in FHIR specs require an OID for the terminology and an immutable, canonical URI to support consistent publishing. Information about those requirements can be found here: https://confluence.hl7.org/display/TA/External+Terminologies+-+Information Ted is asking about resolution of this requirement in his comment above. We will need to develop an approach to this requirement in the OHDSI Vocab WG for OMOP. Looking forward to that discussion!
Davera Gabriel (Oct 12 2021 at 17:18):
Hello @Grahame Grieve ... do you have a JIRA ticket created for completion of your OMOP vocab mapping worksheet? I've just come from the OHDSI CDM Vocab WG meeting, and I have an update. Rather than message / chat, I thought it might be worthwhile to persist a chain of events as is enabled in JIRA? My reasoning is that its more than one monolithic decision that OHDSI needs to consider to complete your worksheet. mtia...
Davera Gabriel (Oct 12 2021 at 18:38):
... if there isn't one - I'm happy to create one. I just didn't want to create a duplicate
Grahame Grieve (Oct 12 2021 at 18:45):
I don't think there's one, thanks. I mean, I didn't create one because it doesn't - right now at least - impact on any published HL7 standards. But that doesn't mean we can't have one
Last updated: Apr 12 2022 at 19:14 UTC
