704057 HCPCS COVID sampling wrong mapping and covid sampling new hierarchy

[stephanieshong]

Describe the problem in content
A clear and concise description of what you found and how it is affecting your processes, ETL or analysis.
https://athena.ohdsi.org/search-terms/terms/704057 HCPCS code is mapped to 37311061 SNOMED which is mapped to condition domain and we think this is an error.

HCPCS code do not have a result associated in the source data.
If you look here, https://athena.ohdsi.org/search-terms/terms/704057
this is specimen collection for severe acute respiratory syndrome coronavirus 2 (sars-cov-2)
but it is mapped to 37311061 (SNOMED)
Non-standard to Standard map (OMOP) COVID-19
37311061 SNOMED which is mapped to condition domain.
Mapping a covid-19 test to condition when there is lack of test results showing a positive test would be incorrect.
We cannot say with certainty that having a test done is not same as COVID dx.

We think this is incorrect since the test requires a test result.
test cannot be mapped to a condition without a valid result.
How to find it
Help us reproducing the problem and researching the issue. Links to Athena concepts can be helpful.
https://athena.ohdsi.org/search-terms/terms/704057

Expected adjustments
A clear and concise description of what you expect the Vocabulary Team to change. If you have collected information in a spreadsheet, please share it with us.
HCPCS code associated with a test should be mapped to measurement or procedure domain, but not condition. Not sure if the source data would have the result of the test to add needed information. Source data would have to determine if they have this information, but meanwhile a visit to COVDI test should not be mapped to COVID dx.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.
This mapping is currently causing mapping issue as we map this code according to what is mapped from non-standard to standard "maps to" relationship for patient with the HCPCS code without the proper result of the test, but it is mapped to condition as if the patient is COVID dx patient without the valid confirmation that the result was positive.

Please feel to inform us in our N3C DI&H team if you have any question.

[stephanieshong]

Emily Pfaff, Harold Lehmann Johanna Loomba and Ken Wilkens from N3C agreed to participate in this discussion, should we need to review it again. Thank you. Would like to flag this issue as urgent.

[bryanlaraway]

Just to add to Stephanie's description after a little more investigation, the HCPCS code currently maps to two concepts:

1. An outpatient visit in the Visit domain.
2. COVID-19 in the Condition domain.

However, the HCPCS code would seem to refer to an outpatient visit for the collection of a specimen (a procedure) to test for the presence of COVID-19 (a disease) caused by an SARS-CoV-2 (an organism in the Observation domain). The mapping to the disease seems incorrect, as the sample we are collecting is testing for the presence of the organism that causes the disease, and not the disease itself. While we could probably represent the full semantic space by mapping to the visit, procedure, and organism observation concepts, perhaps mapping to just the following two concepts would suffice:

1. An outpatient visit (Visit domain).
2. Specimen collection for severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) (Coronavirus disease [COVID-19]), any specimen source (Procedure domain).

My one concern about mapping to a concept in the Measurement domain (example SARS-CoV-2 lab test) is that if we don't have an associated result for the source HCPCS code, then we should probably stick with the Procedure domain, indicating that a procedure was performed (sample collection) instead of a test being performed with the expectations of returning a result.

[stephanieshong]

Agree if source is using the HCPCS code then mapping to the procedure would be better than mapping to condition.

[m-khitrun]

Hello. Thank you for the comment. Obviously, we have a mistake in our mapping. We will remap this code to the Procedure domain.

[stephanieshong]

@m-khitrun - hi Maryia, was I sitting across the table from you at the OHDSI symposium? I should have to talk to you about this on Sunday. I was wondering how soon we can receive an update with this correction.

[JohannaLoomba]

I think that this issue (with that code mapping appearing in the condition domain) was introduced in version v5.0 29-AUG-22. Prior to that vocab update, I saw the code only in procedure tables.

[kmkostka]

For additional context, the magnitude of impact is >300K persons tagged with COVID who didn’t have COVID.

I’d reiterate Steph’s assertion this is a high priority issue to address in the next release. It will impact anyone studying COVID. The newness of the issue is in our favor as we know many sites lag to update vocabs. If fixed quickly, we narrowly avoid a bigger issue.

[Alexdavv]

Hi everyone!

Thanks for a good catch, bringing it in and extensive explanation. We should not change any mapping considerations based on the target Domain. According to OMOP conventions, the Domains are strictly defined by their definitions, and it is completely ok for a Measurement to represent only a fact of a measurement if it doesn’t contain a result in it.

My understanding of this disease-specific sampling concept in general is that we need to capture the facts:

• A disease-specific sampling could be a covid suspicion or a screening. Since we don’t know, we map this piece of information to 0. For other disease samples (e.g. rabies or antrax) it could be more clear that disease was suspected. But I’m not sure if we are able to come up with good conventions here. So still goes out.
• So basically, the question is whether each covid or other disease sampling fact leads to the actual lab test. If we assume yes for a level of precision we want to achieve, we would make a small change to the covid and SNOMED conventions to deStabdardize all disease-specific sampling concepts and map them over to the disease-specific lab test (without a result) and to a general disease-agnostic sampling concept that still could be pretty much specific (e.g., nose swab). I have no good idea how, but ETL will need to take care of the Measurement duplicates. Otherwise, we keep both concepts Standard (Measurement and disease-specific sampling Procedure), and both HCPCS mentioned in the post will be mapped over to a sampling Procedure concept. Then you resolve the issue during a phenotyping task.

Thoughts?

@cgreich @kmkostka

[kmkostka]

@Alexdavv - we should not be ascribing a disease label that confirms said disease when the original non-standard concept is not a confirmation. This is the issue at hand. We should not be going from a non standard code that says, “patient X is being tested for the presence of a disease” to a standard that asserts, “patient X has disease.” This is how we get a bunch of records (>300K) of people tested for COVID that are not actually COVID+.

The source code here does not expect to have a result attached to it. It’s the payment for the procedure to do the test. We cannot tether its standardization to an expected result and assert that expected result as an attribute of the procedure.

We don’t care about duplicate measurements. We know how to handle that. We only care about measurements that try to run for dictatorship and assert a clinical attribute they do not have. The first bullet point you raised is the more important point. We need to remove the disease coding if the non standard is vague and doesn’t have that level of certainty.

[bryanlaraway]

@Alexdavv, to clarify why I believe we should be mapping to a specimen collection procedure instead of a diagnosis or measurement, consider the starting non-standard concept. for HCPCS code C9803: Hospital outpatient clinic visit specimen collection for severe acute respiratory syndrome coronavirus 2 (sars-cov-2) (coronavirus disease [covid-19]).

The mapping from "hospital outpatient clinic visit" to outpatient visit is straightforward. As for mapping to the specimen collection procedure instead of a measurement/lab test, recognize that although the starting concept indicates a specimen was collected, there is no indication of what happened to this collected specimen next. It could have been used in a lab test/measurement, it could have been transferred to a freezer for storage (potentially for testing at a later date, at which point the specimen collection procedure and the measurement/lab testing are separate dates), it could have been purposefully discarded or even accidentally destroyed. I did find some additional guidance here:
Please keep in mind that G2023/G2024 or C9803 should only be used when the provider or facility is not running the test. If the provider or facility is running the test, the appropriate test code should be billed, not the specimen collection code.

This is why I think the mapping to the specimen collection procedure for SARS-CoV-2/COVID-19 or a similar specimen collection procedure is more appropriate than a diagnosis or measurement.

One additional thought regarding the G2023/G2024 codes mentioned but not previously linked above: I note that both codes have an "Is a" mapping relationship with "Measurement of Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) in Unspecified specimen". I think this would be incorrect given the above reasoning about specimen collection being a procedure separate from the actual measurement, and I also note that all of the other concepts subsumed by this measurement concept are measurements, while the G2023/G2024 codes are both procedures.

Let me know what you think.

[cgreich]

@bryanlaraway:

I think you nailed it. This is what we can safely record.

The question is if we want to make a leap of faith and say "well, once they collected they probably sent it in". I would not do that, as you pointed out.

[Alexdavv]

Also, we maybe need to address this in OMOP Extension because I don’t see a good guy in SNOMED except one very specific swab sampling. HCPCS is not a good choice to stay Standard here.

@m-khitrun @MariaRohozhkina Please investigate this and move forward aiming on the nearest vocab release.

[stephanieshong]

@Alexdavv - my take is that clinic visit for COVID test collected should not be mapped to COVID dx in condition when there is NO indication that the test result was completed with a positive test result.

[mik-ohdsi]

@Alexdavv and @stephanieshong - Wouldn't Taking of swab for SARS-CoV-2 (severe acute respiratory syndrome coronavirus 2) count as a fairly good equivalent (and be mapped just together with that existing visit concept, no additional measurement)? I don't see a lot other ways of taking a specimen than a swab here...

[m-khitrun]

@stephanieshong, hello! That wasn't me at the OHDSI Symposium :)
After extensive research, we have come to the conclusion that it would be best to add a new Standard Procedure concept to the OMOP Extension vocabulary and map the C9803 and G2023/G2024 codes to it after de-standardizing them. Our careful deliberations made us discard the idea to use the existing SNOMED concept, because the specimen taking might not be limited to swab taking and it would lead to false specificity. The new concept will be embedded into the SNOMED hierarchy by linking to the generic specimen collection concept as a parent. The hierarchy of the G2023/G2024 concepts will be also changed respectively.
We would be glad to learn your opinion @kmkostka, @bryanlaraway, @stephanieshong

[bryanlaraway]

@m-khitrun, I like this solution. While I mentioned mapping the C9803 (a non-standard HCPCS code) to G2023 (a standard HCPCS code), I wasn't quite sure that that was appropriate (hence mentioning "a similar specimen collection procedure" in my prior comment). I think adding a new OMOP Extension concept to manage the mapping as you suggested is a better solution.

[stephanieshong]

@m-khitrun -yes. I like your solution too. And it is much better than what we currently have.

[mik-ohdsi]

Dear @stephanieshong and @bryanlaraway - Thanks to quite a bit of extra effort by @m-khitrun and @MariaRohozhkina , the fix for this bug was delivered with the latest release. Please check in with us if your problem is solved so that we can close this ticket! Thanks! ~mik

[stephanieshong]

@mik-ohdsi - Ok, we will let you know once we update and confirm. Thank you so very much for a fast turn around.

[kmkostka]

@mik-ohdsi, I believe this issue was resolved in the 31OCT2021 release. Motion to close this ticket. @stephanieshong, ok with you?

[bryanlaraway]

Looks good to me in both Athena and in N3C's concept/concept_relationship tables.

[stephanieshong]

@mik-ohdsi - confirming that our update is all good. All looks good so far. FYI, I added another ticket regarding a missing code. (T43.65 new code)

[kmkostka]

@mik-ohdsi Please close this ticket. 😄 It is creating confusion!!