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
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 |
|
5 Comments
Burke Mamlin
Burke Mamlin
Defining "allowed" roles for each encounter type may become burdensome.
Leaning toward tagging.
Burke Mamlin
Since HL7 doesn't require a provider for PV1/PV2, we don't need to require a provider for every encounter.
Burke Mamlin
Three use cases for providers:
Unknown User (darius)
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.)