Support Provider Roles

The Provider Management module that is included in the Reference Application introduces the idea of "Provider Types". We need to implement an equivalent mechanism in openmrs-core.

Background

• http://notes.openmrs.org/Design-Forum-2013-01-23
• http://notes.openmrs.org/Design-Forum-2014-06-23
• http://notes.openmrs.org/Design-Forum-2015-11-02
• https://notes.openmrs.org/2017-08-16-Design-Forum
• FHIR practitioner resources: Practitioner, PractitionerRole

Acceptance Criteria

1. Add role column to the provider table. (See Dev Notes)
2. Add specialty column to the provider table. (See Dev Notes)
3. Communicate with akanter to create reference lists for these two properties as sets in the CIEL dictionary, taking FHIR's value sets as a starting point
4. Update RA-1174 with relevant details based on this implementation

Dev Notes

We believe the OpenMRS provider table most closely matches to FHIR's PractitionerRole resource. burke wants to ensure that we link explicitly to provider roles within data (e.g., from an encounter), since people may have more than one provider role (especially over time) and references to providers should be unambiguous. So, rather than creating a separate provider_role table, we think the simplest approach to supporting provider roles is to add the role (what FHIR refers to as PractitionerRole.code) and specialty to our provider table.

• Add two columns to provider table:
  • role: specifies Attending Physician, Clinical Officer, Student, Nurse, Pharmacist, etc. like PractitionerRole.code's value set
  • specialty: specifies the specialty of the provider with values like PractitionerRole.specialty's value set

This is a pragmatic approach (small step) to incorporate provider roles in the Platform, satisfies the most common use case of providers in a single role, and would allow our current references to provider to unambiguously reference a provider's role. We assume that a person who has multiple roles (e.g., both Endocrinologist and General Medicine provider) would have multiple provider records (one for each role) and a person who changes roles over time (a Student becomes a Clinical Officer and later becomes an Attending Physician) would have a separate provider record for each of these roles.

We will use concepts for provider specialties & roles (instead of separate lookup tables).

• We believe specialties would probably best be concepts, since there are well-defined specialties in existing terminologies (e.g., see FHIR's Practice Setting Code Value Set)
• provider.role may require more customization for local needs, so CIEL should provide many options, to avoid implementations needing to request new ones in initial use cases.