OHDSI Home | Forums | Wiki | Github

How to identify the actual billable concept?

Vocabulary Users
#1

How can I identify the actual billable concepts? I would like to see a query by search terms that returns ONLY the billable standard concepts.
It appears that multiple standard concepts are stored in a hierarchy where parent concept “Subsumes” child(ren) concepts. Does this mean that the parent concepts are generic and are for organizational purposes only, and the bottom-most or “leaf” concepts (those that do not subsume others) are the only actual billable goods/services/procedures? If so, I’m assuming that the billable ones are those that do not have children. Is this correct?

Also, some concept classes, like Procedures, make use of these relationships, and others, like Drugs, appear not to. Is that expected?

#2

[quote=“TylerWilson, post:1, topic:5053”]
Does this mean that the parent concepts are generic and are for organizational purposes only,
[/quote] It works this way for ICD9/10(CM) hierarchy; In OMOP it’s a little different though. You’re fine with:

  • all CPT4 and HCPCS codes that are standard. The same with ICD10PCS, although it contains all possible permutations of procedural attributes, so some of its procedures have never happened in real life and therefore have never been used in billing.
  • those RxNorm concepts that have relationships to (‘Mapped from’) NDC codes (which are the actual billing codes but non-standard).
  • those Snomed concepts that are mapped from original ICD10/9 (CM) codes with concept_class_id = ‘7-char billing code’. The latter will be non-standard as well.

Hmm, have I forgotten anything?

#3

There are 17,187 CPT or SNOMED concepts that are marked as Standard, yet have 1 or more child concepts that are also Standard. Are the parents incorrectly marked as standard, or are they truly billable, like the children? Some are very generic and have hundreds of children.
See:
SELECT c.concept_id, c.concept_name, c.concept_class_id, c.domain_id, c.vocabulary_id, count(c2.concept_id) cnt, min(c2.concept_name) Sample1ChildConceptName, max(c2.concept_name) Sample2ChildConceptName
FROM concept c
JOIN concept_relationship r ON r.concept_id_1 = c.concept_id AND r.relationship_id = ‘Subsumes’
JOIN concept c2 on c2.concept_id=r.concept_id_2 AND c2.standard_concept = ‘S’ AND c2.domain_id = ‘Procedure’
WHERE c.vocabulary_id IN (‘CPT4’, ‘SNOMED’)
AND c.domain_id = ‘Procedure’
AND c.standard_concept = ‘S’
GROUP BY c.concept_id, c.concept_name, c.concept_class_id, c.domain_id, c.vocabulary_id
ORDER BY cnt DESC

#4

Brief answer before I dig into: you can do it only for CPT4. For SNOMED it’s mappings from ICD only

#5

@TylerWilson:

“Standard” does not mean “billable”. Whether a code is billable is subject to rules between providers, associations and payers, including the government. We don’t really care about that in the OMOP CDM, we take whatever we get. And billable codes can have hierarchical relationships to each other, like you showed in your query.

Standard Concepts are those that are used in the canonical concept_id fields of each record. Source concepts are the ones that are mapped into them.

If you need billable codes for some use case, you can find them as following:

  • CPT4: All concepts with concept_class_id=‘CPT4’ are billable during the period they are valid. The others are hierarchical classification or modifier concepts.
  • HCPCS: All concepts with concept_class_id=‘HCPCS’ are billable during the period they are valid. The others are hierarchical classification or modifier concepts.
  • ICD9Proc: All concepts with “bill” or “billing” are billable (3 or 4 digit codes) during the period they are valid. The others are hierarchical classification concepts.
  • ICD10PCS: All concepts with concept_class_id=‘ICD10PCS’ are billable during the period they are valid. The others are hierarchical classification concepts.

Hope this helps.

#6

Thank you both for your thoughtful responses. “Billable” may be the wrong term to use. I would like to create a query to find the canonical procedure concept(s) matching some set of keywords. I’m only interested in the currently performable procedures --not the concepts which are used only for organization. I assume I’d need to do something like the following:
check synonyms
union with
check standard and non-standard procedure concepts (then find the standard concept via the Maps To relationship)
then group on the standard concepts

Does that sound about right?

.

#7

Does the following query look correct?
DECLARE @SearchTerm VARCHAR(50) = ‘vasectomy’

SELECT s.concept_id, s.concept_name, s.concept_class_id, s.domain_id, s.vocabulary_id
FROM
(
SELECT c.concept_id, c.concept_name, c.concept_class_id, c.domain_id, c.vocabulary_id
FROM concept c
LEFT JOIN concept_synonym cs ON cs.concept_id = c.concept_id
WHERE c.domain_id = ‘Procedure’
AND c.standard_concept = ‘S’
AND (cs.concept_synonym_name LIKE ‘%’+@SearchTerm+’%’
OR c.concept_name LIKE ‘%’+@SearchTerm+’%’)

UNION

SELECT c2.concept_id, c2.concept_name, c2.concept_class_id, c2.domain_id, c2.vocabulary_id
FROM concept c
JOIN concept_relationship r ON r.concept_id_1 = c.concept_id AND r.relationship_id = 'Maps To'
JOIN concept c2 on c2.concept_id=r.concept_id_2
WHERE c2.vocabulary_id IN ('CPT4', 'SNOMED', 'HCPCS')
AND c2.standard_concept = 'S' 
AND c2.domain_id = 'Procedure'
AND c.domain_id = 'Procedure'
AND c.concept_name LIKE '%'+@SearchTerm+'%'

) s
GROUP BY s.concept_id, s.concept_name, s.concept_class_id, s.domain_id, s.vocabulary_id
ORDER BY s.concept_name

This returns 24 results, whereas the Athena search filters returns 17. Would someone please post the Athena query or modify this one to match?

#8

Can you please recommend an improvement to the query above? @aostropolets @Christian_Reich

#9

You used concept_synonym! Way to go! People tend to forget about this table.
First of all, you need to specify the vocabs in the first part of your query: it will eliminate OPCS4. You may also add apply lower case to your concept_name or make it case-insensitive.
Nevertheless, the results do differ; I’ll post an issue about that. Otherwise, your query is fine, so I’d suggest using this approach rather than the downloading the result from Athena.

#10

lower added

I think it still can be improved

What about checking for is valid (deprecated errorenous concepts with errors)

DECLARE @SearchTerm VARCHAR(50) = lower('vasectomy')

SELECT distinct * from 
(
--standard concepts
		SELECT c.concept_id, c.concept_name, c.concept_class_id, c.domain_id, c.vocabulary_id
		FROM concept c
		LEFT JOIN concept_synonym cs ON cs.concept_id = c.concept_id
		WHERE c.domain_id = 'Procedure'
		AND c.standard_concept = 'S'
		AND (  lower(cs.concept_synonym_name) LIKE '%'+@SearchTerm+'%'  OR lower(c.concept_name) LIKE '%'+@SearchTerm+'%')

		UNION
--Maps To concepts of those above (but the query lacks synonyms (has erro)
		SELECT c2.concept_id, c2.concept_name, c2.concept_class_id, c2.domain_id, c2.vocabulary_id
		FROM concept c
		JOIN concept_relationship r ON r.concept_id_1 = c.concept_id AND r.relationship_id = 'Maps To'
		JOIN concept c2 on c2.concept_id=r.concept_id_2
		WHERE c2.vocabulary_id IN ('CPT4', 'SNOMED', 'HCPCS')
		AND c2.standard_concept = 'S' 
		AND c2.domain_id = 'Procedure'
		AND c.domain_id = 'Procedure'
		AND lower(c.concept_name) LIKE '%'+@SearchTerm+'%'
) s
#11

Thanks, I’ve added checks for vocabulary to the first query and c.valid_end_date > GETDATE() to both. (I didn’t bother adding “lower” because my database collation is case insensitive.)
I see 2 remaining issues:

  1. Some concepts are included that appear to be generic types of procedure. i.e., “Vasectomy” (concept_id: 4330583) shows up, but I would expect to only see the specific types of vasectomy procedures
    Can these generic concepts be eliminated by filtering out any concept that has a “Subsumes” relationship? Is there a better way?
  2. Some concepts appear to be duplicates: i.e., Vasectomy using silicon plug (4150395) and Injection vasectomy (4172860). I could be wrong, but they sound like the same thing, and are peers under Vasectomy.
    If one is a duplicate of the other, I would expect only one to be the standard. Are these duplicates? Is there a way to recognize the canonical one?
#12

Hi @TylerWilson

  1. My idea is to use ICD9Proc as they have billable/nonbillable indication and mapped to SNOMED in OHDSI. So we take SNOMED concepts ICD9Proc are mapped to:

    select
    –a.concept_code as source_code, a.concept_id, a.concept_name, a.vocabulary_id, a.concept_class_id, – uncomment if you want to see how the source looks
    b.concept_id, b.concept_name, b.vocabulary_id, b.concept_class_id
    from concept a
    join concept_relationship r on a.concept_id = r.concept_id_1 and r.invalid_reason is null and r.relationship_id =‘Maps to’
    join concept b on b.concept_id = r.concept_id_2
    and a.vocabulary_id=‘ICD9Proc’ and relationship_id = ‘Maps to’
    and a.concept_class_id not like ‘%nonbill%’
    –checking your case
    and lower( a.concept_name) like ‘%vasect%’

As we can see ICD9Proc “63.73” Vasectomy is a billable concept, So excluding concepts with the descendants you’ll lose this one.

  1. let’s just look on Wikepedia:
    https://en.wikipedia.org/wiki/Vasectomy

Intra-vas device: The vasa deferentia can also be occluded by an intra-vas device (IVD). A small cut is made in the lower abdomen after which a soft silicone or urethane plug is inserted into each vas tube thereby blocking (occluding) sperm
Injected plugs: There are two types of injected plugs which can be used to block the vasa deferentia. Medical-grade polyurethane (M.P.U.) or medical-grade silicone rubber (MSR).

Vasectomy using silicon plug (4150395) might describe intra-vas-device case (not only the injection).
Injected plugs made from medical-grade silicone rubber maps to SNOMED “Vasectomy using silicon plug (4150395)”

Medical-grade polyurethane injection maps to “Injection vasectomy (4172860)”, because it has parent concept 4107447 “Cyanoacrylic injection”, and the child concept must include the meaning of the parent concept.

It looks messy in SNOMED, actually. Seems, it should be this way: “Injectiovasectomyn vasectomy” should have child concepts
“Cyanoacrylic injection vasectomy”, “silicon injection”;
“Intra-vas device vasectomy” concept should be added with children:
“silicone plug vacesctomy insertion” and “urethane plug vacesctomy insertion”.
You can report the issue to the SNOMED https://www.snomed.org/
I can’t find the proper link at a glance but you can try.

#13

This will be difficult. The concepts don’t know if they are used that way or not. The Standardized Vocabularies provide all Procedure concepts from the supported vocabularies (CPT4, HCPCS, ICDs, SNOMED, OCPS4, etc.). Which of them are used in the data - you have to ask the data. The billing rules are specific and concrete for each area, created by some mixture of CMS, other insurers and medical associations. But we don’t have those rules in an comprehensive system or so where you can look them up.

Also note that the Procedures don’t follow yet the rule of no duplicates. @Dymshyts is working on such a system. But today we have tons of parallel concepts for the same thing.

Bottom line: Query a real database for use of concepts.

What are you trying to achieve anyway? What’s the overarching use case?

#14

I would like to create a website allowing users to lookup specific performable procedures and find clinics close by that can perform the specific procedure. So, the user would not be interested in a general category of Vasectomy, but rather one of the specific instances of a vasectomy. If the user clicks on silicone plug option, the results would only include facilities doing that specific procedure, and exclude those that only perform vasectomy via traditional open surgery.
I am not sure yet whether a simple text search is the best option. It might be best to provide a hierarchical drill down to the specific one.

#15

Thanks for the clarifications on these procedures Dmytry. I submitted this suggestions via the UMLS, err NLM site. https://www.nlm.nih.gov/research/umls/implementation_resources/community/index.html

#16

Makes sense. But then I really don’t understand why you don’t just create a list based on the actual data of those clinics. Instead of trying to guess it.

#17

Very good point. =) I will do that for the clinics that are willing to share. Some may not use real codes if they don’t deal with insurance, so I’ll still have to map to the closest procedure I can find.

#18

Hm, this way you don’t need to have predefined list of precedures. You map to all SNOMED procedures, and then you get this desirable list of real precedures.

#19

Good.
I suppose they redirect you to some SNOMED page.
So, please, let me know about their answer.

t