Delivered remotely for a business based in Melbourne, Australia. Names withheld by agreement.
Project Overview
Industry: Healthcare — clinical workforce coordination and practitioner-to-practitioner collaboration.
Type of solution: A cloud platform with a REST API and administrative back office, paired with a native iOS application for practitioners in the field.
Business context: Healthcare depends on a coordination layer that has never been properly digitised. When a practitioner needs support for a scheduled procedure, cover at short notice, or a colleague's opinion, they fall back on personal relationships and personal phones. That works until it does not — and it carries a second problem that is easy to overlook: those conversations contain patient details, and consumer messaging channels are not an appropriate place for them.
General users: Practitioners, who both raise and respond to requests; clinical teams with their own membership; facility/practice roles; and platform administrators managing the network through the back office.
General purpose: To convert an informal professional network into a structured one — with visible availability, verified professional profiles, routed requests, recorded outcomes and communication safe enough for clinical content.
The Business Challenge
Coverage was arranged through personal networks. Finding an available, appropriately qualified colleague meant working through a contact list. Availability was unknown until someone answered, and a practitioner's reach was limited to the people they happened to know well.
Urgent requests had no reliable mechanism. A group text asking for urgent cover is a broadcast with no delivery guarantee, no visibility of who has seen it, and no way to prevent three people responding to something one person can do.
Patient information was moving through consumer channels. Any coverage or consultation conversation necessarily involves patient context — the procedure, the reason, relevant notes. Conducted over ordinary messaging, that is both a governance problem and an unrecorded one.
Professional credentials were assumed, not visible. Credentials, licensing and experience were established by reputation. In a network extending beyond people you personally know, they need to be part of the profile.
Scheduling was disconnected from availability. Practitioners had no way to publish when they were available, so every request started from zero rather than from a known answer.
No record of what was agreed. Requests, acceptances and the reasoning behind them lived in phone histories. Nothing was auditable, and nothing was reportable.
Mobile-first, in demanding environments. The users are practitioners between procedures, in facilities with unreliable connectivity. The application had to be fast, resilient offline and immediately legible — not a web page in a wrapper.
Our Approach
Design the data model around what must be protected. Before features, we established which attributes constitute sensitive clinical and personal information — patient names, procedures, clinical reasons, free-text notes, message bodies — and made protecting those attributes a property of the model layer rather than a concern each feature would have to remember.
Model the three request types honestly. A directed request to one colleague, a request to a professional network, and an urgent broadcast that several people may answer independently are not the same thing with different labels. We modelled them separately, particularly the urgent case, where multiple independent responses are the expected behaviour rather than a conflict.
Generate the API surface, hand-write the interesting parts. With a wide domain model, hand-writing and maintaining a controller for every entity is waste that turns into inconsistency. We built a generation layer producing REST resources from the model definitions, with explicit overrides where behaviour needed to differ, and separate hand-written routes for the action endpoints — accept, decline, send — where the real logic lives.
Make asynchronous work asynchronous. Notification delivery, message dispatch and other outbound work was moved onto a queue with a dedicated worker process, so a practitioner's action completes immediately regardless of how many people it notifies.
Build the client natively. Given the environment — practitioners between procedures, imperfect connectivity, list-heavy screens — we built the mobile application natively, with local persistence so the app remains useful offline and asynchronous rendering so lists stay smooth.
Containerise the environment. The platform runs in containers with scripted setup and data refresh, so every engineer works against an identical environment and onboarding is measured in minutes.
The Solution
Professional profiles with credentials. Practitioners hold a profile carrying credentials, licensing detail, years of experience, certifications, affiliations, practice address and contact information — so a request can be directed to someone appropriately qualified, including outside the immediate personal network.
Colleague network and teams. Practitioners invite colleagues, who accept or decline, forming the network through which requests are routed. Teams provide a second grouping layer with its own membership management.
Availability publishing. Practitioners define their availability at day and time level, turning "are you free on Thursday?" from a phone call into a lookup.
Coverage requests. A practitioner raises a request carrying the procedure, reason and relevant notes; recipients accept or decline; the outcome is recorded against the request rather than in someone's phone.
Consultation requests. The same structured mechanism applied to seeking a colleague's professional opinion, with the clinical context attached and the response captured.
Urgent broadcast requests. Urgent needs are broadcast, and each recipient's response is captured independently — the model reflects how urgent coverage actually works, where several people may respond and the request needs to resolve cleanly.
Scheduling and appointments. Accepted engagements become scheduled appointments with their own accept/decline handling, giving practitioners a single view of committed work.
Clinical coding support. Requests can carry standard clinical procedure and diagnosis codes, so the clinical context is expressed in shared vocabulary rather than free text alone.
Secure in-app messaging. Conversations happen inside the platform, with message content encrypted at field level — so the clinical detail that inevitably appears in these conversations is held appropriately rather than sitting in a consumer messaging app.
In-app video consultation. Practitioners can hold a video consultation within the application, keeping the interaction inside the platform's security and record-keeping boundary.
Notifications across channels. Push notifications with a device registry and read-state tracking, backed by SMS delivery through redundant providers — because a missed urgent request is not an acceptable failure mode.
Administrative back office and audit trail. Administrators manage the network, entities and reference data through a back office, with model-level change history captured for accountability.
Key Features
Field-level encryption of clinical and personal data Sensitive attributes — patient names, procedures, clinical reasons, notes and message bodies — are encrypted individually at the model layer, so protection is a property of the data rather than something each feature must remember to apply.
Credentialled practitioner profiles Licensing, certifications, experience and affiliations are part of the profile, so requests can be routed to appropriately qualified practitioners beyond the immediate personal network.
Colleague network with invitation flow Practitioners build their network through invitations that are explicitly accepted or declined, giving the platform a real graph to route requests through.
Availability publishing and scheduling Day and time level availability, feeding into appointment scheduling with accept/decline handling and a consolidated view of committed work.
Coverage and consultation requests with structured outcomes Requests carry clinical context and resolve through recorded accept/decline decisions, replacing phone calls with an auditable process.
Urgent broadcast with independent responses Urgent requests reach multiple practitioners simultaneously, with each response captured independently — modelled for how urgent coverage actually behaves.
Secure in-app messaging Conversations stay inside the platform with encrypted message content, so clinical detail is not distributed across consumer messaging channels.
In-app video consultation Practitioner-to-practitioner video within the application, keeping remote consultation inside the platform's security boundary.
Multi-channel notification with redundancy Queued push notifications with device registration and read-state tracking, plus SMS delivery through two independent providers for time-critical messages.
Administrative back office with audit history Full administrative management of the network and its reference data, with model-level change logging for accountability.
Technical Architecture
Mobile client. A native iOS application with a local persistent store mirroring the domain model, manager classes per functional area encapsulating API interaction and local state, asynchronous list rendering for smooth scrolling in data-heavy screens, and object/image caching to reduce repeat network calls.
API layer. A stateless REST API secured with signed tokens, covering authentication lifecycle (login, refresh, activation, password recovery, profile) and the full domain surface. Resource endpoints are generated from model definitions for consistency, while action endpoints — accept, decline, send — are hand-written where meaningful logic exists.
Application and business logic layer. A plugin-structured application with a domain plugin owning models, administration controllers and schema, an authentication plugin owning token issuance and lifecycle, an API plugin owning generation and routing, and an audit plugin capturing change history. Non-CRUD behaviour lives in dedicated service classes: notification management, user and facility management, messaging clients and queue job handlers.
Data layer. A relational database holding the practitioner network, requests, schedules and messaging, with designated attributes encrypted at field level so sensitive values are not stored in readable form.
Asynchronous processing layer. A queue backed by an in-memory data store, with a dedicated worker process handling notification dispatch, so user-facing actions complete immediately regardless of downstream fan-out.
External services. Cloud object storage for media, two independent SMS pathways, a video communications platform for in-app consultation, and mobile push delivery.
Runtime. Containerised application and database services behind a web server with a PHP process manager, with scripted environment setup, data refresh and worker supervision.
Flow: iOS app (local store + cache) → HTTPS/token-authenticated REST API → Plugin-structured application layer → Business services → Relational database with field-level encryption → Queue + worker → Push / SMS / video / object storage
Technology Stack
| Category | Technology |
|---|---|
| Backend language | PHP |
| Backend platform | October CMS (Laravel-based), structured as custom plugins |
| Database | MySQL |
| Cache & queue | Redis |
| API authentication | JWT (token issue, refresh, activation, recovery) |
| API layer | Custom REST generation layer with hand-written action routes; CORS handling |
| Audit | Model-level change auditing |
| Asynchronous processing | Queue worker process for notification dispatch |
| Mobile platform | Native iOS (Objective-C) |
| Mobile persistence | Core Data |
| Mobile UI performance | Texture / AsyncDisplayKit, PINCache, DTCoreText |
| Video | Twilio Video SDK |
| SMS | Twilio and AWS SMS (redundant providers) |
| Object storage | AWS S3 |
| Crash reporting | Crashlytics |
| Web serving | Nginx with PHP-FPM |
| Environments | Docker / Docker Compose with scripted setup and data refresh |
| Testing | PHPUnit at application and plugin level |
| iOS dependencies | CocoaPods |
Technical Challenges & Solutions
| Challenge | Our Approach |
|---|---|
| Protected health information flowing through requests and messages | Field-level encryption applied through a model behaviour to named sensitive attributes — patient names, procedures, clinical reasons, notes and message content — so protection is enforced at the data layer regardless of which feature writes the record. |
| Three request types with genuinely different semantics | Directed requests, network requests and urgent broadcasts modelled separately, with the urgent case built as a broadcast plus independent response records so multiple responders are expected behaviour rather than a race condition. |
| Maintaining a REST API across a wide domain model | A generation layer producing resource controllers and routes from model definitions, with an explicit override mechanism for controllers needing custom behaviour and separate hand-written routes for action endpoints — consistency across the surface, effort concentrated where the logic is. |
| Notification fan-out slowing user actions | Notification dispatch moved onto a queue with a dedicated supervised worker, so raising a request returns immediately no matter how many practitioners it reaches. |
| Time-critical messages that must not be missed | Two independent SMS pathways alongside push notification with device registration and read-state tracking, so delivery does not depend on a single channel or a single provider. |
| Mobile use in facilities with poor connectivity | A native client with a local persistent store mirroring the domain, so previously loaded data remains available offline, plus caching to reduce repeat requests. |
| Scroll performance in data-heavy list screens | Asynchronous rendering through a dedicated UI framework, with image and object caching, keeping feeds smooth on the devices practitioners actually carry. |
| Reproducible environments across a distributed team | Containerised application and database services with scripted setup, schema refresh and worker supervision, so every engineer runs an identical stack. |
| Accountability for a healthcare-adjacent system | Model-level audit logging capturing change history across the domain, alongside recorded request outcomes, so who did what and when is answerable after the fact. |
Security & Reliability
Authentication. Signed-token authentication for the API with a complete lifecycle — issuance, refresh, account activation and password recovery — so mobile clients remain authenticated without long-lived credentials on the device.
Authorisation. Role-based permissions, including a distinct role for facility-level users, with the colleague and team relationships providing a second scoping layer over who can be reached and what is visible.
Encryption of sensitive data at rest. Named clinical and personal attributes are encrypted at field level. Direct database access does not yield readable patient names, clinical reasons, procedures, notes or message content.
Secure communication channels. In-app messaging and video keep clinical conversation inside the platform's boundary rather than distributed across consumer channels.
Auditability. Model-level change logging plus explicitly recorded request outcomes provide a defensible history of what was requested, by whom, and how it was answered.
Cross-origin control. Explicit CORS policy governing which clients may call the API.
Client-side protections. Separate debug and release entitlements, keychain-backed credential storage support, and crash reporting to surface real-world failures.
Operational resilience. Redundant SMS providers, queued dispatch with a supervised worker, and cloud object storage for media so application instances hold no irreplaceable state.
Scalability & Performance
Queue-backed asynchronous dispatch. Outbound notification work is decoupled from request handling, so fan-out volume affects worker throughput rather than user-facing latency.
In-memory queue and cache layer. A dedicated cache and queue backend keeps job handling fast and reduces repeat database work.
Consistent, paginated API resources. Generated endpoints share pagination and filtering behaviour, so no endpoint accidentally returns an unbounded collection as the network grows.
Purpose-built lightweight endpoints. Frequently polled values such as unread notification counts are served by dedicated endpoints rather than by fetching and counting collections.
Client-side persistence and caching. A local store and object/image caching reduce network round trips and keep the app responsive on poor connections.
Asynchronous UI rendering. List rendering performed off the main thread keeps scrolling smooth in the screens practitioners use most.
Externalised media storage. Files are held in cloud object storage rather than on application servers, keeping application instances stateless and horizontally scalable.
Containerised deployment units. The application runs as containers, so scaling out is a matter of running more instances behind the web tier.
Business Outcomes
- Coverage requests reach beyond personal contact lists, because the platform routes through a structured network with visible credentials and availability.
- Urgent needs are broadcast reliably, with independent responses captured and delivery backed by redundant channels rather than a group text.
- Clinical detail stays inside a secure boundary, through encrypted in-app messaging and video instead of consumer messaging apps.
- Availability becomes information rather than a phone call, so scheduling starts from a known answer.
- Engagements are recorded and auditable, replacing phone histories with structured request outcomes and change logging.
- Professional credentials are visible, enabling practitioners to work with qualified peers beyond their immediate personal network.
- Practitioners can use it where they actually work, with a native application that stays fast and usable in facilities with poor connectivity.
- The network is administrable, with a back office allowing the platform operator to manage practitioners, teams and reference data as it grows.
Why it worked
Healthcare software is judged on the parts that never appear in a demo. Anyone can build a request form. Building one where the patient's name is encrypted at field level, where an urgent broadcast resolves correctly when three people answer at once, where a notification still arrives if one provider fails, and where the whole history is auditable afterwards — that is a different discipline.
Our team approaches sensitive-domain systems by deciding what must be protected before deciding what the screens look like, then enforcing that at the data layer so no future feature can quietly bypass it. We model business behaviour honestly rather than forcing distinct workflows into one generic shape. We push fan-out and outbound work onto queues so user actions stay fast. And we build redundancy into the channels where failure has real consequences.
Our teams work across PHP platform engineering, REST API design, queue-based asynchronous architecture, native mobile development with offline capability, and third-party integration for messaging, video and storage — the full stack a connected clinical product requires, delivered by people who understand that in this domain, correctness and confidentiality are the feature.
Final Summary
Clinical coordination — who is available, who can cover, whose opinion is needed — runs on personal networks and personal phones. It works because clinicians make it work, but it is invisible to the organisation, unreliable under time pressure, and inevitably carries patient detail through channels that were never intended for it.
Our team built a platform and native mobile application that gives this coordination a proper structure. Practitioners hold credentialled profiles, build a colleague network through explicit invitations, publish their availability, and raise coverage or consultation requests that carry clinical context and resolve through recorded decisions. Urgent needs broadcast to multiple practitioners with independent responses captured. Conversations happen through in-app messaging and video rather than consumer apps. Underneath, sensitive attributes are encrypted at field level, notification dispatch runs asynchronously through a queue with redundant delivery channels, and model-level auditing records what happened.
The engineering emphasis was on the qualities this domain demands: confidentiality enforced at the data layer rather than per feature, workflows modelled to match real clinical behaviour, asynchronous processing so time-critical actions never wait on fan-out, and a native client that stays usable in the environments practitioners actually work in. For any organisation digitising coordination in a regulated field, this is the pattern — structure the network, protect the data at its source, and make the record defensible.