OHDSI Home | Forums | Wiki | Github

New Comprehensive Hierarchy for Providers, Visits (and Place of Service, Specialty, Care Site)

(Christian Reich) #1

Friends (and tagging @aostropolets, @MPhilofsky, @rimma, @jenniferduryea, @mgkahn, @Dymshyts, @Gowtham_Rao, @Patrick_Ryan, @hripcsa, @bailey)

Please consider this completely revised solution in Googledoc (see at the end for URL and instructions). This is a significant surgery of how we would characterize the healthcare settings of the data. Please tell me what you think.


We have 3 types of tables: VISIT_OCCURRENCE and _DETAIL (both referred to as Visit from now on), CARE_SITE and PROVIDER. Visit refers to a structured process where the patient receives care, Care Site tells us the organization and Provider the flesh-and-blood healthcare provider. To describe these three we currently have a number of vocabularies and some self-cooked concepts:

  • Provider
  • Visit
  • Place of Service
  • UB04 Typ bill
  • Specialty
  • ABMS
  • NUCC
  • HES Specialty

It’s a mess. They are highly duplicative and all over the place. For example, the Medicare Specialty vocabulary contains concepts like “Skilled Nursing Facility” and “Radiation Therapy Center”. HES Specialty also has those types of facilities in there. NUCC, which contains the typical physician specialties, also features things like “Funeral Director”. In Medicare Specialty, we have non-medical entities like “Part B CAP Drug Vendor”. And so on.


  1. We need a comprehensive hierarchical system for this all. We can’t expect the ETLer to know what a “Doula” is, or if “Occupational Therapy” is some kind of a department or what kind of person is using an occupation as a therapy.
  2. One domain should describe the Provider, such that the provider_concept_id can define any such person. Providers can be of the medical (physicians and nurses) and non-medical kind (specialists, vendors).
  3. Another domain needs to characterize the way healthcare is organized. After long thinking and discussing with people, I believe this should describe the Visit, and not the Care Site.
  4. Care Sites need not have anything semantically characterizing them. They should be relegated to a mere physical or logical entity with a name attached.

This will be unfamiliar to some folks. In particular, I expect some flak over the following consequences:

  • Care Sites can no longer have specialties. @mgkahn might have a fit over this. And I agree it is counter-intuitive at first glance, because there are these General Surgery Departments and Internal Medicine Wards all over the place. But all that Care Sites do is to enable visits to happen, and physicians with different specialties or non-medical providers delivering the care during those visits. And the visits could be of different kind for the same Care Site.
    For example: My wife runs a Urogynecology outpating department in a hospital. Most of the physicians have that specialty (concept_id=45756773). But there are also ordinary gynecologists and an oncologist running around, plus a Nurse Practitioner. Now what? What specialty has the place?
  • Visits cannot have specialties, either. There is no such thing as a “Dermatology Office Visit”. What you can have is a Outpatient Office Visit with a Dermatologist doing something.

  • What used to be a specialty is really a descendant of the Provider concept “Physician”. There are also some specialized nurses, but not many.

Here is why you will like it:

You don’t have to stress anymore what exactly a Care Site is, and whether it is a physical or logical entity. In my wife’s example, the outpatient offices are located in an ugly 80ies brick building. But the surgeries are done in the OR of the main hospital 2 miles away. Unless that one is booked, then they can use an ambulatory surgery in the “old building”. Still following? It is impossible to model this stuff. But it doesn’t matter. The Care Site “Mount Auburn Urogynecology Associates” is registered with the insurance companies, and that’s all we need.

ETL will be very much simplified. Based on the coding system, it is very simple to create Visits. In the example of my wife’s department, all activities will result in Office, Clinic, Hospital Outpatient or Ambulatory Surgical Center Visits, no matter if claims or the EHR system was used to generate the records. And everything rolls up into “Outpatient Visit”.

We now have a hierarchy that allows stratifying things in a meaningful way. In Visit, we still have the existing top 5 Visits:

  • Emergency Room and Inpatient Visit
  • Inpatient Visit
  • Outpatient Visit
  • Emergency Room Visit
  • Long Term Care Visit (renamed to “Non-hospital institutional visit”)

In addition, we also have 6 new ones:

  • Laboratory Visit
  • Telehealth Visit
  • Pharmacy Visit
  • Home Visit
  • Transportation Visit
  • Rehabilitation Visit
  • Case Management Visit

In Providers everything rolls up into:

  • Physician
  • Counselor
  • Supplier/Commercial Service Provider
  • Allied Health Professional
  • Nurse
  • Pharmacist

We can also address the problem of multiple provider specialties by picking the most granular common hierarchical concept. So, somebody who declares the specialties “Hepatology” and “Nephrology” gets “Internal Medicine”.

This is the full set in Google Doc.The Concepts are in green, the hierarchy in yellow, and the deduplications with one mapped to its equivalent in red. Synonyms are in brown.

Let me know.

Visit vs place of service
Care sites and specialty, specialty code clean-up
Hospice - Inpatient vs Outpatient
Condition_occurrence, Death diagnoses
Place of Service - no standard concepts
EHR data to OMOP CDM Work Group
CARE_SITE and LOCATION in context of providers and visit_details
Concept id 38004515, Hospital, rolls up to both 9201 Inpatient Visit and 9202 Outpatient Visit
(Gowtham Rao) #2

@Christian_Reich thank you for all the work you have done leading this important work. I wanted to focus on one section of your argument first.

I would mostly agree with you here. My disagreement is that care_sites may have specialty, and my agreement is that this care site specialty has limited bearing on determining the service rendered in the visit (I argue that service should be captured in visit_concept_id).

This is because specialty of care_site is an attribute of credentialing/licensing/contracting. Services may be provided outside the credentialed/licensed. Payers/governments credential care_sites to offer certain types of services, if services that are not credentialed are provided - payment/penalties may be impacted. Matchinb between credentialing and service rendered have implications on copay and coinsurance (health economic use cases).

In US facility claims, UB04 type of bill is matched with the billing facilities credentialing , and if they are compatible - facility claim is adjudicated. But, from what i know, UB04 does not have a field for the facilities specialty. @jenniferduryea , do you know if in UB04 facility claims (USA) we get the ‘specialty of the facility’ in the claim form? @ericaVoss or @mvanzandt who have expertise on US claims data procured from secondary sources - do you have access to claim level information that 1) differentiates between facility claims vs professional claims, 2) if able to differentiate, do you know the ‘specialty’ of the facility where the person received care e.g. the facility was short term acute care hospital? (Note: we are not talking about the specialty of the providers who treated the person.)

I agree with these comments:

Yes - visits should describe the actual service thru visit_concept_id/visit_source_concept_id

Agree - in many cases, the address of the credentialed entity billing for the claim is probably the only available information in the claim, vs. the pin-point physical address where the actual service was rendered may not be available.

(Gowtham Rao) #3

@Christian_Reich i would recommend mapping UB04 Type of bill vocabulary to ‘Place of Service’ vocabulary. Place of service may be parent of UB04 Type of bill vocabulary something like this

UB04 Type of bill full vocabulary --> UB04 type of bill vocabulary --> Place of service vocabulary --> Visit vocabulary

OMOP visit vocabulary created by OHDSI community may need some clarification:

  • If we have Emergency Room and Inpatient Visit, then should the other Emergency Room Visit be called ‘Emergency Room Visit without Inpatient Visit’. Should we also make
    Inpatient Visit
    unambiguous and call it ‘Inpatient Visit without Emergency room Visit’
  • regarding ‘Long Term Care Visit’ as ‘Non-hospital institutional visit’, but what is ‘non hospital’? is it ‘nursing home’, ‘skilled nursing’?
  • At what point do we distinguish between institutions that are ‘hospital’ vs ‘non-hospital’ (care_site specialties? ) Why not call it ‘non-hospital inpatient visit’, because ‘inpatient’ would differentiate from non-hospital visits like ‘home visit’ or ‘partial hospitalization visit’.
  • What is ‘Inpatient Visit’? Maybe we should call this ‘Inpatient Hospital Visit’, to differentiate from ‘Non-hospital institutional Visit’?

Place of service vocabulary in OMOP has concepts that dont exist in the source as described here . Example: concept_id 8970, 8892, 8882, 8677 need to be deprecated because they are phantoms!

Agree - we should map place of service vocabulary to these concepts in Visit vocabulary.

(Christian Reich) #4

Understood. But that is way outside a patient-centric analytic data model. That’s for running an insurance company. However, there is nothing preventing you from adding a specialty_concept_id, and allow concepts of the domain_id=‘Provider’ and concept_class_id='Physician specialty". But the CDM should stay clean. A specialty is something that a provider obtains through training. That’s how it is meant to be here.

I did exactly that. Here is the source: https://www.ncci.com/Articles/Documents/DR_PlaceServiceCrosswalk.pdf

Sounds good.

Well, I am thinking patient experience, and how it will work ex-US. The CMS has all these defined institutions, and they really make not that much sense from a patient perspective. E.g. the difference between “Nursing Facility” and “Skilled Nursing Facility” is really mostly a legal one. So, my idea was:

  • Hospital: Full-fledged hospital, all services, physicians call the shots
  • Non-hospital institution: medical services, but below hospital… Usually nurses calling the shots, with physicians making home-like visits.
  • Home: no medical service institutions or the actual home

Would that work?

The inpatient really means the patient stays in bed during the night and doesn’t go home. Again. We are characterizing the visit, not chasing how the Care Site is organized

Happy to do that.

That’s done. Filter by vocabulary “Place of Service”, and the green ParentID1, ParentID2 and ParentID3 will tell you the hierarchical relationship.

(Jen Duryea) #5

The UB04 claim does not have a separate field to specify facility specialty. Payers actually use the second digit in the Type of Bill (TOB) value to determine the facility specialty (please see here for CMS rules). You also may need to use the third digit in the TOB to determine if services are paid under the inpatient or outpatient coverage for insurance coverage. Though helpful for health econ studies, it may not be relevant to the “patient-centric analytic data model” @Christian_Reich suggests OMOP is.

Also, for the following:

I have experience with Medicare LDS, SEER Medicare, Truven Marketscan, Optum, Medassets, and DRG. The TOB or facility specialty (second digit of TOB) is available in one form or another in each of these datasets. For answers to your questions 1) yes you can decipher between facility and professional claims and 2) yes because the TOB information is available in one way or another. I have seen the TOB reported as is. I have also seen the TOB suppressed, but the dataset have variables that report facility type or service type (which is a combination of the second and third digits of the TOB) in the dataset. So it can be stored.

(Gowtham Rao) #6

@jenniferduryea good post. Thank you so much for clarifying.

Overall, @Christian_Reich i think we all agree that facilities don’t have specialty.


The CMS link says that it is “Type of care”. I interpret this as ‘Type of service’, something that should be used to populate visit_source_concept_id and visit_concept_id. With UB04 Type Of Bill vocabulary mapped to CMS Place of service vocabulary, and CMS place of service vocabulary considered a standard vocabulary of the VISIT domain - i think we are in good shape here.

(Melanie Philofsky) #7


I have a couple questions that require clarification to further my understanding of the spreadsheet.

Are you taking place_of_service_concept_id out of the Care Site table? I noticed all place_of_service_concept_ids are now non-standard.


Will we have a care giver/clinician title/role/whatever you want to call it _concept_id in addition to the specialty_concept_id?

  1. We also need a Consult Visit. In Colorado, our children and adult hospitals have many Consult Visits.

(Gowtham Rao) #8

@MPhilofsky - I am not sure if a decision was made to deprecate the field care_site.place_of_service_concept_id in a future version of the CDM, but it was discussed. The rationale for this, in US claims place of service is a claim level attribute that is used to help represent the type of service delivered. Place of service is in every professional US claim - i.e. it is a claim level attribute, not a credentialing attribute. Place of service is not in facility US claims, there we have Type of Bill. Type of Bill maybe crosswalked (maps to) to Place of service.

Because of these reasons, many months ago, the vocabulary ‘Place of Service’ became standard and part of the VISIT domain [ref]. Because this is a claim level attribute, it may be used to populate visit_occurrence.visit_concept_id . In facility claim, type of bill may be used to populate visit_occurrence.visit_source_concept_id and the ‘maps to’ place of service concept id is used to populate visit_occurrence.visit_concept_id. There is a hierarachial relationship between vocabulary place of service, and the traditional VISIT vocabulary (Inpatient, outpatient, emergency room etc) ref

Regarding deprecating care_site.place_of_service_concept_id ; i think we could rename it to care_site.care_site_specialty_concept_id (30 characters) and use it to represent the specialty of the care_site as in credentialing (@Christian_Reich thoughts?)

(Gowtham Rao) #9

Are consult visits something that would be used to populate visit_occurrence.visit_source_value/visit_source_concept_id/visit_concept_id? There are 400+ concept_id’s in the VISIT domain here . Is anyone semantically close to CONSULT visits. If not, what is different about these consult visits? Are they inpatient visits or outpatient visits? Are they tele visits?

(Christian Reich) #10

Yes, I want to. Say something now or hold your peace forever. These things are Visits.

Yes, but they will be all mapped to the equivalent concepts. So, they really are still there. I think a few survived and are now the Standard.

You will have “Psychiatry” as a provider_concept_id (with concept_class_id=‘Physician Specialty’ doing a consult. The fact that this was an inpatient consult is currently not in the hierarchy. It ends at the detail level of claims. We need to add it, and all the other things that are pertinent to what’s going on inside the institutions. Another one that comes to mind is the recovery room you mentioned. Your EHR Workgroup will help. We need to send out a survey.

(Gowtham Rao) #11

Claim detail = visit detail. Everything fits

(Christian Reich) #12


For claims databases. For EHRs, there are no claims. There are records of what happened to the patient. And the standard vocabularies we have (Medicare Specialty, CMS Place of Service) are all claim level. EHRs have way more detail.

(Melanie Philofsky) #13


The EHR WG discussed Visits, Providers, Care Sites, Place of Service, etc. on our call this morning. We have a few questions/comments

This works for our data. Things like “Urgent Care” & “Observation Room” are now available as visit_source_concept_ids and the ambiguity (is it an outpatient visit, inpatient visit or ER visit??) is taken out by your hierarchy.

Is Atlas able to distinguish the visit_source_concept_ids? We want Outpatient Visits, but not ones with a source concept id = Observation Room? Or we only want patients with a visit = Urgent Care?

Yes, send out the survey. A few things that we discussed today: Telehealth is being used more often by providers and persons. Sometimes this looks like an outpatient visit with a real time discussion between a provider and a person. Other times this is messaging via a portal with signs/symptoms discussed and a drug exposure order & dispense. We would like guidance on concepts with finer granularity, i.e. telephone, email, messaging via portal, video conference with provider/person, etc. Another visit type we discussed is the face to face visit. This one needs more discussion with the EHR community, but our Provider researchers in Colorado frequently ask questions about their clientele and want data only for the F2F visits. @burrowse also has the same data requests.

And after you send out the survey, we will have even more :slight_smile:

(Melanie Philofsky) #14


Christian is correct. EHR data is like Santa. We know EVERYTHING :slight_smile:


(Christian Reich) #15

Well, again, apologize for the screw-up.

Absolutely. It is going to work just the other hierarchical domains. Like you can define Type 2 diabetes mellitus, but then take out all the pregnancy-related ones. Same idea.

Right now, the concepts cover what the claim system has. You EHRers have a lot more detail. Bring them on and we extend the hierarchy. Same is true for international folks who have slightly different concepts.

Inpatient and outpatient visits are supposed to be face to face. The patient comes to the institution. Or did you have something else in mind.

Bring them on any time, and we bake them in. Because this is going to be work in progress. I already put “Consult” in the backlog. Sounds to me like a child of “Inpatient Visit”.

(Karthik) #16

Sorry for coming to the conversation late and have clearly missed some key meeting, so apologies for asking something that’s already been discussed. I have one question:

  • Is the visit_source_concept_id going to be a non-standard, which gets mapped to a standard concept in visit_concept_id, or are we suggesting that they are both standard and this is a way to get more granularity with type of service in the source_concept_id? It sounds like the latter to me based on the Observation Room example.

Since I well with ETLs, it easier for me to understand with a specific example…So, when I look at ambulatory surgeries, it looks like they all map to “Ambulatory Surgical Center” (OMOP ID 8883), and 8883 ISA “Outpatient Visit” (OMOP ID 9202) which makes sense. Now say I have a TOB claim for an ambulatory surgery (OMOP ID 32274), which is a non-standard code. According to the spreadsheet, this now maps to the standard code for “Ambulatory Surgical Center”. In this case, do I populate the visit_source_concept_id with the non-standard code for ambulatory surgery and have the visit_concept_id with the standard code “Ambulatory Surgical Center”. OR do I populate the visit_source_concept_id with “Ambulatory Surgical Center” and the visit_concept_id with “Outpatient Visit”?

I know this sounds more of a Themis issue, but the example of using Atlas to filter based on source concept seemed to different from what I am used to, which is stay away from source concept ids when creating cohorts :slight_smile:

(Gowtham Rao) #17

I would do this (above) and not this (below)

above is now derivable by using omop vocabulary hierarchy. ambulatory surgery center (standard) is child of outpatient visit (standard). so i would map visit_concept_id to lowest level detail in standard concept - ie. ambulatory surgical center.

(Chris Knoll) #18

Is a consult an overnight stay? because I thought Inpatient Visit meant you stayed overnight.

(Melanie Philofsky) #19

The EHR WG discussed other forms of person and provider direct, real time communication. @burrowse described visits which include video and phone conferencing that occurs in real time. The EHRers need more guidance with visits of this nature.

Thanks! “Consult” is a little ambiguous and needs context to be defined correctly because it can occur as an Outpatient or an Inpatient visit. As an Outpatient visit, it is the primary visit. As an Inpatient visit, it is a visit detail of an inpatient visit.

(Christian Reich) #20

That’s the question. We need the EHR folks to chime in.

In my experience, the consult happens during an inpatient stay, when the patient develops a problem outside of the specialty of the Care Site of the inpatient stay. For example, a patient is in a surgical ward and becomes anxious and confused, so a psychiatrist is called for a psych consult to help with diagnosis and treatment recommendations. Which means, the consult itself is not strictly an inpatient visit, but happens during an inpatient visit.

Anything similar in the outpatient world would be a referral, not a consult.

Well, we now have 5083 “Telehealth Visit”, with 581399 “Interactive Telemedicine Service” the only direct child (I should make that a synonym, really). If you need phone or video or any of that nature, please make a proposal.