OHDSI Home | Forums | Wiki | Github

Who creates visits from HCPCS codes?

CDM Builders
#1

Hello friends,

Based on some recent forum posts, here and here, I’m curious who uses HCPCS codes to create records in Visit Occurrence or Visit Detail table?

Those of us with EHR data use our source encounter/visit records because they contain most or all the attributes of a visit (start_datetime, end_date, end_datetime, provider, care site, admitted from, discharged to). The HCPCS only provides a person, date and usually a provider. Therefore, we choose to use the source encounter/visit records over the anemic HCPCS records.

Does anyone use the HCPCS records to create visits? I’ve never seen a post on the forum asking for these records to be moved into the visit domain, so they can be used to create visit records. But I also don’t read every forum post. If no one has requested this change or uses these records in this way, then maybe we should just leave them in the Observation domain where they have existed for many years since these codes identify the way to charge for a visit more than actually representing the visit itself. By moving them to the Visit domain, everyone needs to update their ETL or the records won’t be in the CDM. Which is fine if folks aren’t using them.

@DTorok @Christian_Reich @Alexdavv

CPT Hierarchy errors - lost children in 2023 and changed domains
#3

HCPCS is obviously a US claims data artifact - at a high level there are two types of US claims Professional, Institutional (there are drug, DME etc but lets ignore those for now).

Because Visit is an OMOP construct and not in claims data - we have to build rules to standardize claims data to omop - the visit table is thus ‘derived’, and so it becomes an ETL convention.

However - there are several tricks here that insurance companies (e.g. BCBS) follow and to find if a patient truly received in patient visit. These tricks are not known to the ETl’r and so there is a high potential for many misclassification during ETL. Other times the misclassification may be introduced by the mid data vendor - who is sourcing the claim and deriving fields. The mid data vendor may be basing this on a lossy transformed data.

#4

Don’t know about ETLing, we would have to ask. Do we actually have a good email list of ETLers?

I know that they using it in cohort definitions, in lieu of a proper ETLing: data.ohdsi.org/PhenotypeLibrary phenotype 251. They are picking CPT4 procedures “indicating ER visit”. This stuff is hard to take. It’s the worst of both worlds.

#5

Chiming in here, since I have a related post where the re-classification of CPT codes from Procedure to Visit caused our ETL and an ongoing health equity analysis to break.

We don’t use HCPCS or CPT codes to create visits, since we have EHR data that provides an easier ETL path to create visit_occurrence and visit_detail.

However, we do use CPT E&M codes in some of our analyses. For example, we are studying potential delay in diagnosis and referral of patients with CKD (based upon GFR values), and one of the outcome cohorts is new patient office visits to nephrologists. We use the CPT codes 99202-99205 to identify new patient visits (rather than using the first visit to a nephrologist with a long preceding clean period). We have also been planning other analyses of treatment variability where we needed easy access to CPT codes within Atlas cohorts.

The January changes to the vocabulary stack caused our ETL to delete all such E&M codes, so we had to revert to and older vocabulary stack; and I haven’t seen clarity from the community yet on where E&M codes should live (Observations, Procedures, other?) so that we can include them in Atlas cohorts in the new environment since the January '23 vocabulary release.

CPT Hierarchy errors - lost children in 2023 and changed domains
#6

All - Let’s continue this discussion on this thread

t