Skip to content
Work
Healthcare operationsPublic

Middlelink

Software ArchitectureBackend EngineeringIntegrations

Healthcare operations: booking, patients, ERP, CRM

Product and domain architecture

Context

Clinics ran scheduling, patient records, and billing as adjacent tools. Handoffs were people. A missed booking did not update the operational picture.

System boundary

In scope

  • locations
  • booking
  • patient workflows
  • CRM
  • ERP views

Out of scope

  • clinical decision support
  • device integration

Architecture

Domains are explicit: location, appointment, patient, commercial account. ERP and CRM read the same operational events; they do not keep a second booking calendar.

A clinic operations platform where booking, patient flow, CRM, and back-office ERP share identifiers instead of living as four products.
  1. Location
  2. Booking
  3. Patient
  4. Visit
  5. CRM
  6. ERP
  • Hub is the owning domain
  • CRM/ERP are views, not calendars
Published sequence
  1. Location
  2. Booking
  3. Patient
  4. Visit
  5. CRM
  6. ERP
Stages on each row
  • Row 13Booking · Patient · Visit
  • Row 22CRM · ERP
Roles in the diagram
  • service2
  • process1
  • store1
  • interface2

Counts from the published record. They describe structure, not a measured result.

How do the system domains relate?

domain

  • serviceLocation

operations

  • serviceBooking
  • storePatient
  • processVisit

consumers

  • interfaceCRM
  • interfaceERP
  1. LocationBooking
  2. LocationVisit
  3. BookingPatient
  4. PatientVisit
  5. VisitCRM
  6. VisitERP

Critical flows

  1. A booking is created against a location and practitioner

  2. patient record is bound

  3. visit workflow runs

  4. CRM sees the relationship

  5. ERP sees the commercial consequence.

Stages

  • Multi-location
  • Booking
  • Patient workflow
  • CRM
  • ERP

Decisions

01

One appointment object

CRM and ERP do not own calendars. They subscribe to operational facts.

02

Patient is not a contact

A CRM person and a clinical patient can relate, but collapsing them loses consent and record boundaries.

03

Location is a first-class node

Multi-clinic operations fail if “the clinic” is a label on a user.

When it fails

ConditionDetectionResponse
Double-bookSlot uniquenessReject write; show conflict
Orphan visit without patient bindWorkflow invariantBlock status change to arrived
ERP posting without visit closeEvent completenessQueue posting; do not invent line items

Infrastructure

  • Laravel
  • MySQL/Postgres
  • queues for notifications
  • backups
  • role-based access per location

Outcome

Clinics operate from one booking and patient core. CRM and ERP are views on that core.

Current state

In production across clinic operations. New locations attach to the same domain map.

  • Laravel
  • PHP
  • MySQL
  • Redis
  • Queues
  • ERP
  • CRM
Contact