ClearInsight AI
Dental referral and workflow platform
A referral platform connecting referring dentists, specialists and practice administrators, with enterprise sign-in, least-privilege access, an audit trail on patient data, live treatment rooms and document extraction at intake.
- Period
- Status
- Succeeded by SC-Oracare
- Role
- Software engineer and architect: backend, identity and security, cloud infrastructure, release automation
- Team
- Four-person team: the client as product owner, an RPA and plugin solutions engineer, marketing and customer relations
- Stack
- Django
- Django REST Framework
- Django Channels
- PostgreSQL
- Redis
- Microsoft Entra External ID
- Azure AD B2C
- Azure Document Intelligence
- Microsoft Graph
- Docker
- Azure
The problem
Dental practices refer patients to specialists, and each referral has to carry the patient’s records and documents between offices that do not share a system. Referring dentists, specialists and practice administrators each needed exactly the access their role required, over patient data handled to HIPAA requirements. Every referral also needed the patient’s consent before records were shared, and had to reach specialist offices that were not yet on the platform.
The engineering challenge
- Regulated data. Every operation on patient data needed an authorization check and an audit entry, with encryption in transit and at rest.
- Roles that cross practices. A referral puts people from different offices on one case, and each of them sees only what their role allows.
- Live work. Referral status, team chat and document extraction at intake all had to update in real time, without a page reload.
Architecture
Identity provider
- Entra External ID, Azure AD B2C, OAuth 2.0, OIDC
Delivery
- CI/CD pipelines, GitHub Actions, Azure DevOps
Microsoft 365
- Microsoft Graph, User provisioning, email
Application environment
- Redis, Real-time messaging
- Admin panel, Staff only, same database
- Azure Front Door, Entry point
- Azure App Service, Django, DRF, Channels (Docker)
- Azure Database for PostgreSQL, Encrypted at rest
- Azure Blob Storage, Documents
- Azure Queue Storage, Log shipping
- Application Insights, Logs, metrics, alerts
- Azure Key Vault, Secrets
- Azure Document Intelligence, Custom extraction model
Sign in and authorize
- Sign in. Browser to Entra External ID (OIDC sign-in, JWT). Doctors and office staff sign in through Microsoft Entra External ID and Azure AD B2C over OAuth 2.0 and OpenID Connect, using MSAL. The platform maps the token’s claims to a user and works with JWT-secured sessions from then on.
- Authorized request. Permitted. Browser to Azure Front Door (HTTPS); Azure Front Door to Azure App Service (Request); Azure App Service to Azure Database for PostgreSQL (Query, audit entry). Requests reach the Django application through Azure Front Door. Every patient data operation passes an authorization check for the caller’s role, and the audit trail records who accessed or changed each record.
- Outside the role. Refused. Browser to Azure Front Door (HTTPS); Azure Front Door to Azure App Service (Request). Role based access control enforces least privilege, so a request outside the caller’s role is refused.
Create a referral
- Upload documents. Browser to Azure Front Door (HTTPS); Azure Front Door to Azure App Service (Request); Azure App Service to Azure Blob Storage (Documents). A doctor starts a referral and uploads the patient’s documents, which are stored in Azure Blob Storage.
- Extract patient details. Azure App Service to Azure Document Intelligence (Extract fields). A custom Azure Document Intelligence model reads the patient’s name, date of birth, email and phone from the documents, with a confidence score for each field.
- Stream the fields back. Azure App Service to Browser (WebSocket updates). The extracted fields stream back to the open referral form over a WebSocket, ready for the doctor to confirm.
- Save the referral. Azure App Service to Azure Database for PostgreSQL (Query, audit entry). The referral, its ordered treatments and its treatment team are saved to PostgreSQL, and the team gets a treatment room.
Consent and collaboration
- Consent request. Azure App Service to Microsoft Graph (Email). The patient is asked for consent with a time-limited, single-use link, sent by email through Microsoft Graph or shown as an encrypted QR code.
- Patient consents. Permitted. Browser to Azure Front Door (HTTPS); Azure Front Door to Azure App Service (Request). The patient confirms consent. The token is validated, then expires.
- Treatment room. Azure App Service to Redis (Publish status); Azure App Service to Browser (WebSocket updates); Azure App Service to Azure Blob Storage (Documents). The team works in the treatment room: chat, treatment plan steps and notifications update live through Django Channels and Redis, verified at 100+ concurrent connections, and attachments go to Blob Storage.
Referral to an office not on ClearInsight
- Held. Azure App Service to Azure Database for PostgreSQL (Query, audit entry). A referral addressed to an office that is not on ClearInsight is held and recorded as an invite request, not delivered.
- Staff review. Admin panel to Azure Database for PostgreSQL (Held referrals). It appears in the staff-only admin panel, which works on the same database.
- Invite. Admin panel to Microsoft Graph (Invite, provision). Staff contact the office and send a time-limited sign-up invite. The admin panel also provisions users in Entra External ID through Microsoft Graph.
- Sign up and release. Permitted. Browser to Entra External ID (OIDC sign-in, JWT); Azure App Service to Azure Database for PostgreSQL (Query, audit entry). When the office signs up through the invite, the token is validated and the held referral appears on its new dashboard.
Operate and ship
- Secrets and telemetry. Azure App Service to Azure Key Vault (Secrets); Azure App Service to Application Insights (Telemetry); Azure App Service to Azure Queue Storage (Logs). Secrets live in Azure Key Vault. Structured logs, metrics and alerts flow to Application Insights, and logs are also shipped through Azure Queue Storage.
- Ship. CI/CD pipelines to Azure App Service (Build, test, deploy). GitHub Actions and Azure DevOps pipelines take a commit to a deployed environment.
View diagram
A dental healthcare startup in the US engaged me through Shidul from August 2023 to June 2026, as the software engineer and architect in a four-person team: the client as product owner and manager, an RPA and plugin solutions engineer who built the data extraction plugins for practice management systems, and marketing and customer relations. I owned architecture, backend development, identity and security, cloud infrastructure and release automation.
The platform is a Django application written in Python with PostgreSQL and JavaScript, running on Django Channels so the same service handles HTTP and WebSockets, served by Uvicorn. Django REST Framework exposes the APIs for referral routing, patient records, document exchange and practice administration, and Redis carries the real-time layer.
It is containerized with Docker for reproducible builds across local and Azure environments, and runs on Azure services including App Service, Front Door, Azure Database for PostgreSQL, Blob and Queue Storage, Key Vault and Document Intelligence. A separate, staff-only admin application works on the same database.
Referrals and treatment rooms
A doctor creates a referral to another doctor on the platform or to a specialist outside it, sets the order of treatments and assembles a treatment team across specialties and offices. Accepting a referral opens a treatment room, where the team keeps the treatment plan, shares documents and images, and talks in real time.
Around that sit the pieces a practice needs: availability and appointments, direct messages between doctors, in-app notifications, and connections between doctors in different practices.
Document intelligence
Referral intake starts from the patient’s documents. When a doctor uploads them, a custom Azure Document Intelligence model extracts the patient’s name, date of birth, email and phone, each with a confidence score, and the fields stream back to the open referral form over a WebSocket for the doctor to confirm.
Admin application
Staff run the platform from a separate admin application that only ClearInsight staff can sign in to. It creates each user in Entra External ID through Microsoft Graph and in the platform database in one step, releases features and controls which subscription plans expose them, and reads sign-in audit logs.
It also takes in referrals addressed to offices that are not on ClearInsight yet: the referral is held, staff contact the office and send a time-limited sign-up invite, and the referral appears on the office’s dashboard once it signs up. The same application hosts the REST API that CI-Assistant connectors call: JWT access and refresh tokens, the package catalogue and SAS-signed package links.
Key decisions
WebSockets for the live features
Options considered: polling, server-sent events, WebSockets.
Why: treatment-room chat and document extraction are two-way, and extraction streams binary from the browser, which server-sent events cannot carry. Once those need a socket, one transport for notifications too means one sign-in path and one reconnect strategy. Polling would make a live conversation between clinicians feel broken.
Trade-off accepted: WebSockets cost more to run: an ASGI server, a Redis channel layer, reconnect handling and origin checks. For notifications alone they would not be worth it.
Sign-in on Microsoft Entra External ID
Options considered: stay on Azure AD B2C, or move to Microsoft Entra External ID.
Why: External ID is the successor to Azure AD B2C, and Microsoft no longer takes new B2C tenants, so anything built now starts there. Accounts are keyed on the directory’s object ID, so moving existing users comes down to keeping that ID.
Trade-off accepted: both products run side by side while the migration completes, so user management has to read and write accounts through one consistent configuration.
Identity tokens stay on the server
Options considered: keep tokens in browser storage, in page memory, or in a server-side session.
Why: the session is established on the server from the token’s claims, and the browser holds only a session cookie. A script injected into a page finds no token to steal and use elsewhere, and the token’s expiry still decides when the session ends.
Trade-off accepted: sign-in now rides on a cookie the browser sends by itself, so cross-site request forgery becomes the risk to defend, with Django’s CSRF protection and secure-only cookies.
Security and identity
People sign in through Azure AD B2C and Microsoft Entra External ID over OAuth 2.0 and OpenID Connect, using MSAL, and sessions are secured with JWT. Role based access control enforces least privilege across referring dentists, specialists and practice administrators, and which features each account can use follows its subscription plan.
The platform was built to HIPAA requirements: TLS in transit, encryption at rest, an authorization check on every patient data operation, and an audit trail recording who accessed or changed each record. Patient consent and new doctors’ onboarding both use time-limited, single-use tokens; consent can also be requested through an encrypted QR code. Secrets come from Azure Key Vault, and session and CSRF cookies are secure-only.
Pick a role below to follow the sign-in path: the token carries the role, the policy decides, and the audit log records the decision.
- Browser to Entra External ID: Sign in (OIDC)
- Entra External ID to Browser: Authorization code
- Browser to Django API: Callback with code
- Django API to Entra External ID: Exchange code
- Entra External ID to Django API: Tokens (JWT)
- Django API to RBAC policy: Check role
- RBAC policy to Django API: Permitted
- Django API to Audit log: Write audit entry
{
"iss": "https://example.ciamlogin.com",
"aud": "example-api",
"sub": "example-user",
"roles": ["practice-administrator"],
"exp": 1767225600
}Practice administration: Permitted
Delivery and operations
pytest unit and integration tests cover authentication, RBAC enforcement and referral state transitions. Structured logging, Azure Application Insights metrics and alerting trace request failures, authentication errors and WebSocket connection health, and logs are also shipped through Azure Queue Storage. Docker Compose runs the application, PostgreSQL and Redis locally; GitHub Actions and Azure DevOps pipelines take a commit to a deployed environment on Azure App Service. In total I provisioned and operated nine Azure services to production standards.
Referral status and notifications update live over WebSockets using Django Channels and Redis. Separate WebSocket consumers handle team chat, direct messages, document extraction and connector sessions. I verified the real-time layer at more than 100 concurrent connections with Apache JMeter and Azure Load Testing.
Result
The client ceased operations before commercial launch, so there are no customer or usage numbers to report, and none are claimed here. What was verified: the real-time layer under load at more than 100 concurrent connections, and nine Azure services provisioned and operated. The platform still runs as a live demonstration, and it became the foundation for SC-Oracare, which kept its referral core and grew around it.
Demo
The sign-in demo in Security and identity steps through the permission model with each role. The referral platform itself lives on in SC-Oracare: open the SC-Oracare live demo (opens in new tab), which runs on synthetic data on a free tier, so the first load can take up to a minute.