Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • Multiple providers per encounter (Design Page)
Skip to end of metadata
Go to start of metadata

This project is assigned to the OpenMRS 1.9 release milestone

Background

Historically, encounters within OpenMRS only have allowed a single provider.  In many instances, there is more than one provider involved in an encounter.  For example, both a doctor and a nurse involved in an outpatient encounter or multiple surgeons involved in a surgical encounter.  The goal of supporting multiple providers per encounter is to allow for these people to be documented and connected to the encounter, including their role(s) within the encounter.

Design

encounter_provider

Definitions

  • Provider: someone who provides care for patients.  Provider do not have to use or have access to the system (e.g., a provider could be a doctor at a hospital on the other side of the country used for referrals).  Must have at least name & identifier to be useful, though provider identifiers may vary by implementation/context.  Provider can link to a person, but will not extend person (i.e., provider_id ? person_id).
  • Encounter role: a role specific to the encounter.  While these could match up to existing organizational roles (e.g., "Nurse"), they don't have to (e.g., "Lead Surgeon").

Notes

  • Is person_id required or optional?
    • Required -- a person record must exist for every provider
    • Optional -- providers can be loaded without referring to a person (would require base demographics in provider table: name, identifier)
  • Where to put provider identifier(s)?  Do we wait for (or depend on) having person identifier?
  • Is codifying encounter role overkill?

See Also

Assigned Developer

(TBD)

Interested Parties

Associated Tickets

type key summary assignee reporter priority status resolution created updated due

Data cannot be retrieved due to an unexpected error.

View these issues in Jira

5 Comments

    • We may want to use tags on role instead of linking directly to encounter types (informal linkage)
    • We may want provider_attribute (or use person_attribute, constraining certain person attributes to providers)
  1. Defining "allowed" roles for each encounter type may become burdensome.

    Leaning toward tagging.

  2. Since HL7 doesn't require a provider for PV1/PV2, we don't need to require a provider for every encounter.

  3. Three use cases for providers:

    1. A zillion providers in a big list (e.g., import all providers for a given insurance coverage)
      1. Need at least name(s), identifier, and ideally specialty
    2. Local providers as a list of names
      1. Need at least name(s), identifier +/- specialty
    3. Local providers as a list of persons
      1. Link to person record
      2. Identifier(s)
      3. Provider role(s) / specialty
      4. License(s)
      5. Reference to HR system
    4. Getting to provider information for users -- e.g., Bob is ordering a medication and we need his DEA number
  4. I think that we should make the encounter_provider.encounter_role_id column optional.

    (This will allow us to migrate existing data from the encounter.provider column to just have a null role, rather than having to create a core "Unknown Encounter Role" object.)