Doctor Service¶
Overview¶
The Doctor Service is responsible for managing healthcare providers within the VitalBridge platform.
A provider represents a licensed healthcare professional who delivers services to patients.
Examples include:
- Physicians
- Surgeons
- Specialists
- Therapists
- Nurses
- Telehealth Practitioners
The Doctor Service acts as the authoritative source for provider information across the platform.
Responsibilities¶
The Doctor Service is responsible for:
- Provider onboarding
- Provider profile management
- Provider lifecycle management
- Professional credentials
- Taxonomy classification
- Tenant assignment
- Provider event publication
The service does not manage:
- Provider schedules
- Appointment booking
- Video consultations
Those responsibilities belong to dedicated services.
Service Architecture¶
flowchart TB
ADMIN["Tenant Administrator"]
DOCTOR["Doctor Service"]
DOCTOR_DB[("Doctor DB")]
ADMIN --> DOCTOR
DOCTOR --> DOCTOR_DBService Ownership¶
The Doctor Service owns all provider-related information.
flowchart TB
DOCTOR["Doctor Service"]
PROVIDER["Provider Profiles"]
CREDENTIALS["Professional Credentials"]
TAXONOMY["Taxonomy Classification"]
DOCTOR --> PROVIDER
DOCTOR --> CREDENTIALS
DOCTOR --> TAXONOMYNo other service may directly modify provider records.
Provider Lifecycle¶
Providers progress through a defined lifecycle.
stateDiagram-v2
[*] --> Pending
Pending --> Active
Active --> Inactive
Inactive --> Active
Active --> Archived
Archived --> [*]Pending¶
Provider has been created but onboarding is incomplete.
Active¶
Provider can participate in scheduling and consultations.
Inactive¶
Provider is temporarily unavailable for operations.
Archived¶
Provider is no longer operational within the tenant.
Provider Data Model¶
erDiagram
PROVIDER {
uuid id
uuid tenant_id
uuid identity_id
string first_name
string last_name
string email
string mobile
string status
datetime created_at
datetime updated_at
}
PROVIDER_TAXONOMY {
string code
string classification
string specialization
}
PROVIDER ||--o{ PROVIDER_TAXONOMY : classified_asProvider¶
Represents a healthcare professional operating within a tenant.
| Field | Description |
|---|---|
| id | Provider identifier |
| tenant_id | Owning tenant |
| identity_id | Identity Service reference |
| first_name | Provider first name |
| last_name | Provider last name |
| Provider email | |
| mobile | Provider mobile |
| status | Lifecycle status |
Tenant Ownership¶
Providers are tenant-scoped resources.
flowchart LR
TENANT["Tenant"]
PROVIDER["Provider"]
TENANT --> PROVIDERA provider belongs to exactly one tenant.
Cross-tenant provider access is prohibited.
Taxonomy Classification¶
Providers are classified using healthcare taxonomy codes.
flowchart LR
PROVIDER["Provider"]
TAXONOMY["NUCC Taxonomy"]
PROVIDER --> TAXONOMYExamples include:
| Taxonomy Code | Classification |
|---|---|
| 207Q00000X | Family Medicine |
| 207R00000X | Internal Medicine |
| 207V00000X | Obstetrics & Gynecology |
| 208D00000X | General Practice |
Taxonomy classification enables:
- Provider discovery
- Search filtering
- Clinical categorization
- Reporting
Provider Creation Workflow¶
sequenceDiagram
participant Admin as Tenant Administrator
participant Doctor as Doctor Service
participant DB as Doctor DB
Admin->>Doctor: Create Provider
Doctor->>DB: Save Provider
DB-->>Doctor: Provider Created
Doctor-->>Admin: SuccessIdentity Provisioning¶
Provider creation requires identity provisioning.
sequenceDiagram
participant DoctorService
participant IdentityService
participant Keycloak
DoctorService->>IdentityService: Provision Provider Identity
IdentityService->>Keycloak: Create User
Keycloak-->>IdentityService: User Created
IdentityService-->>DoctorService: Identity ProvisionedThe Doctor Service remains responsible for provider data while the Identity Service manages authentication-related identities.
Relationship with Scheduling¶
The Doctor Service owns provider information.
The Doctor Schedule Service owns provider availability.
flowchart LR
DOCTOR["Doctor Service"]
PROVIDER["Provider Profile"]
SCHEDULE["Doctor Schedule Service"]
DOCTOR --> PROVIDER
PROVIDER -. Referenced By .-> SCHEDULEThis separation allows provider information and scheduling information to evolve independently.
Relationship with Appointments¶
The Doctor Service does not own appointments.
flowchart LR
DOCTOR["Doctor Service"]
APPOINTMENT["Appointment Service"]
DOCTOR -. Provider Reference .-> APPOINTMENTThe Appointment Service references providers but does not manage provider records.
Domain Events¶
The Doctor Service publishes provider-related events.
flowchart LR
DOCTOR["Doctor Service"]
KAFKA["Apache Kafka"]
DOCTOR --> KAFKAExamples include:
- provider.created
- provider.updated
- provider.activated
- provider.deactivated
- provider.taxonomy.updated
Event Flow¶
flowchart LR
DOCTOR["Doctor Service"]
OUTBOX["Transactional Outbox"]
KAFKA["Apache Kafka"]
DOCTOR --> OUTBOX
OUTBOX --> KAFKAAll events are published through the Transactional Outbox pattern.
Authorization Model¶
Providers are tenant-scoped resources.
flowchart TB
SUPER["ROLE_SUPER_ADMIN"]
ADMIN["ROLE_TENANT_ADMIN"]
PROVIDER["ROLE_PROVIDER"]
TENANT["Tenant"]
SUPER --> TENANT
ADMIN --> TENANT
PROVIDER --> TENANTTenant Administrator¶
Can:
- Create providers
- Update providers
- Deactivate providers
Provider¶
Can:
- Access their profile
- Update permitted profile fields
Cannot:
- Manage other providers
Design Principles¶
Provider Ownership¶
The Doctor Service owns provider information.
Tenant Isolation¶
Providers always belong to a single tenant.
Taxonomy-Driven Classification¶
Healthcare providers are classified using standardized taxonomy codes.
Event-Driven Integration¶
Provider state changes are propagated through domain events.
Separation of Concerns¶
Scheduling and appointments are delegated to dedicated services.