Modeling Provider Organizations

Introduction​

Large digital healthcare organizations frequently employ teams of physicians, organized by specialty, brand, and/or product offering. In this guide, we'll discuss how to model the structure of a large provider organization with multiple divisions and service lines.

We'll cover

• How to model divisions and sub-divisions inside a provider group
• How to model provider care teams
• How to assign practitioners to multiple divisions and teams

Modeling the Organizational Hierarchy​

To model groups, it is recommended to use the Organization resource. Organizations model how people are grouped, and can be organized in a hierarchical structure by utilizing the partOf reference field.

Use a separate Location hierarchy for physical places. Location.partOf describes physical containment, while Location.managingOrganization connects a place to the organization maintaining it. See Organizations and Locations for a worked example across scheduling, clinical care, and billing.

Let's look at the example organization called "Acme Provider Group" with four clinical divisions, "Mental Health", "Dermatology", "Sexual and Reproductive Health", and "Diet and Nutrition". You would create an Organization for the top level Acme Provider Group.

Each of the four divisions would then be represented as separate Organization entities and connected to the parent organization using the partOf reference field. You can further divide each of these divisions, such as "Men's Health" and "Women's Health" divisions within Sexual and Reproductive Health.

  graph BT
  A["Acme Provider Group"]
  B["Mental Health"]
  C["Dermatology"]
  D["Sexual and Reproductive Health"]
  E["Diet and Nutrition"]
  F["Men's Health"]
  G["Women's Health"]
  F -->|partOf| D
  G -->|partOf| D
  B -->|partOf| A
  C -->|partOf| A
  D -->|partOf| A
  E -->|partOf| A

Note: This hierarchical structure works well for digital health practices with organizational monoliths. To model more complex many-to-many relationships, refer to the OrganizationAffiliation resource.

Modeling Care Teams​

At the bottom of the hierarchy, you may have teams of providers that work closely together to provide care. We advise using the the CareTeam resource to model these provider teams.

The CareTeam resource enables you to easily specify members of a team through the participant field and assign roles within the team. The US Core guidelines recommend that CareTeam.participant.role be selected from the Care Team Member Function ValueSet, which is a subset of the SNOMED CT code system.

  graph TD
  A["CareTeam"]
  B["Practitioner: Primary Care Physician"]
  C["Practitioner: Registered Nurse"]
  D["Practitioner: Care Coordinator"]
  A -->|participant.role: Primary Care Physician| B
  A -->|participant.role: Registered Nurse| C
  A -->|participant.role: Care Coordinator| D

Modeling Service Lines​

The Organization resource is designed to model how a practice is structured, while the HealthcareService resource focuses on their function. In the context of digital health, the HealthcareService resource can be thought of as a "service line" or even a "product offering."

Not all digital health companies will require the use of the HealthcareService resource. Many practices offer a single service line per division.

However, some practices have providers working on distinct services within the same organization, with certain providers working on multiple services simultaneously. Adding a HealthcareService resource can help keep track of which providers are assigned to each service (see diagram in next section)

For instance, in the "Acme Provider Group" example, the "Women's Health" group might offer both STD and fertility services, with some providers working on one or both services. To assign a specific service to a given organization, you can use the HealthcareService.providedBy field. This allows you to accurately represent the various services offered by providers within a large physician group or healthcare organization.

Assigning Providers to Organizations​

  graph LR
  A["👩🏽‍⚕️ Practitioner: Dr. Alice Smith"] --> B["PractitionerRole1\nspecialty: Ob/Gyn"]
  A --> C["PractitionerRole2\nspecialty: Internal Medicine"]
  E["🏥 Sexual Reproductive Health"]
  F["🏥 Dermatology"]
  G["🩺 HealthcareService: Fertility"]
  H["🩺 HealthcareService: STD"]
  H --providedBy--> E
  G --providedBy--> E
  B -- organization --> E
  C -- organization --> F
  B -- healthcareService --> G
  B -- healthcareService --> H

The Practitioner resource in FHIR is used to describe the person who is the healthcare provider. Each provider should have only one Practitioner resource, which contains their name, demographic information, contact information, and qualifications (refer to our guide on Provider Credentials for more information). This resource is also used as their profile during authentication and authorization

The PractitionerRole is used to assign practitioners to Organizations, CareTeams, and HealthcareServices.

For a simple directory, start with one PractitionerRole per practitioner per organization. A role can reference multiple HealthcareServices and Locations when the same responsibilities and eligibility apply to those associations. Create separate roles when those associations need different responsibilities or eligibility, even within one organization. For example, the state-by-state licensure model uses a role per service or service line so each can carry its own licensed jurisdictions.

There are two additional fields that describe how the provider participates in the organization:

• PractitionerRole.code describes roles which this practitioner may perform as part of the organization, and uses the same value set as CareTeam.participant.role (Care Team Member Function)

• PractitionerRole.specialty can be used to indicate which specialty a provider is performing at a given organization. For instance, Provider A may act as a Cardiologist at Organization 1, but as an Internal Medicine Doctor at Organization 2. The recommended terminology for this field is the NUCC Health Care Provider Taxonomy

Alongside these directory roles, the scheduling configuration workspace can create a separate facility-assignment role without an organization. See Scheduling configuration ownership when using it with the directory model.

When adding a practitioner to a CareTeam, it is important to add the PractitionerRole resource, rather than the Practitioner resource itself. This approach makes it easier to keep track of in-network and out-of-network providers for billing purposes (see our guide on Modeling Insurance Networks more information on this topic).

  graph TD
  A[SRH Care Team 1]
  B[SRH Care Team 2]
  C[PractitionerRole:\nJane Smith, MD]
  D[PractitionerRole:\nBob Cheng, RN]
  E[PractitionerRole:\nJulie Cooper, MD]

A --participant--> C
A --participant--> D
B --participant--> D
B --participant--> E

Conclusion​

The Organization, CareTeam, and HealthcareService resources are the primary building blocks for modeling your practice, and the Practitioner and PractitionerRole resources allow you to flexibly model your provider group.

While the model described works well for an in-house group or PC, more complicated organizations and coordination with 3rd parties might require more complicated models. Consult the Da Vinci Plan Network Implementation Guide or contact the Medplum team for more information!