Identity and access management for healthcare and revenue cycle products, designed for clinicians with privileges at several facilities, agency staff, consultants and the enterprise provisioning requirements that arrive with every large deal.
Most product identity models assume a person belongs to one customer, holds one role and either has access or does not. Healthcare does not work that way. A physician practises at three organizations, a coder works for an outsourced vendor serving several clients, an agency nurse covers shifts across a region, and a consultant has temporary access to four customers at once. A model that cannot represent that produces workarounds, and the workarounds are shared logins.
Authentication gets somebody through the door. Authorization decides every door after that. And the joiner gets access because somebody is waiting, while the leaver keeps it because nobody is.
Enterprise healthcare buyers require directory integration, single sign-on and automated provisioning. A product without them either loses the deal or agrees to a roadmap commitment it then has to meet under pressure. Identity becomes a commercial capability with a delivery date rather than a security backlog item.
The deeper issue is that healthcare access is contextual. Whether somebody should see a record depends on their relationship to it, not only on their job title, and a role-based model alone cannot express that without creating a role for every combination.
Roles Multiply Until They Mean Nothing
Each new requirement creates another role until nobody can explain what the catalogue permits without reading code.
Deprovisioning Is Where It Fails
Joiners are handled because somebody is waiting. Leavers are not, because nobody is inconvenienced by the delay.
Shared Logins Appear Where the Model Cannot Cope
A front desk terminal, agency worker or temporary coder becomes a credential whose audit trail identifies nobody.
Machine Identities Outnumber Human Ones
Service accounts, integrations and automations are created for a purpose, scoped generously and rarely reviewed.
Access Is Contextual
Care relationship, client assignment and case scope cannot be expressed cleanly through categorical roles alone.
Nobody Reviews What Accumulated
Projects end, roles change and integrations retire while access quietly remains.
List everybody with access who no longer needs it.
Include people who changed roles, left customers, finished projects or ended contracts, plus service accounts created for integrations that were retired. It is one of the most common findings and entirely correctable once visible.
A healthcare identity model has to represent that a person can act in several organizations, hold different capability in each, and have access to a record because of a relationship rather than a title. Getting that structure right first makes everything else configuration.
Step 1
Model identity separately from membership, so one person can hold distinct roles and scopes at several customers without duplicate accounts.
Step 2
Separate the four questions: who is this, what may they do, whose data may they reach and which part of it.
Step 3
Express contextual access explicitly, including care relationship, assignment and case scope, rather than encoding it as more roles.
Step 4
Design roles as capability bundles with a governance process, so the list stays comprehensible and auditable.
Step 5
Treat machine identities as first-class, with an owner, a scope, an expiry and a review.
Step 6
Build enterprise provisioning early, since single sign-on and directory integration are deal requirements rather than enhancements.
Step 7
Make deprovisioning event-driven rather than request-driven, because a process depending on somebody remembering will fail quietly
Step 8
Design break-glass access deliberately: visible, logged, time-bound and reviewed.
Step 9
Test the boundary by attempting prohibited actions continuously, because denied access shows the boundary works.
Step 10
Produce the access evidence customers will ask for, including who can reach their data and what each person actually did.
Every shared login is a product design failure, not a customer discipline problem.
Shared credentials appear where the identity model cannot represent how the work is done. Where you find them, ask what the model could not express rather than why the customer is being careless.
Four layers: who somebody is, what they may do, how they get and lose access, and how you demonstrate any of it to a customer who asks.
Identity
Multi-Organization Identity Model
one person, several memberships, distinct roles and scopes per organization.
Authentication and Single Sign-On
enterprise federation, MFA appropriate to clinical settings and session behaviour for shared workstations.
Patient and External Identity
proofing, recovery and support paths for people who will not call an IT desk.
Machine and Service Identity
integration, automation and AI identities with owner, scope, expiry and review.
Authorization
Role and Capability Design
governed bundles of capability with a process for creating them.
Contextual and Attribute-Based Access
relationship, assignment, location, time and case scope
Tenant Scope Enforcement
customer boundary applied structurally at the data-access layer and carried through every path.
Break-Glass Access
deliberate, visible, logged, time-bound and reviewed.
Provision and Govern
Enterprise Provisioning
directory integration and automated account creation, update and removal.
Lifecycle Automation
joiner, mover and leaver handled as events rather than requests somebody remembers.
Access Review Tooling
customer-run review of who holds what and what each role permits.
Access Audit and Evidence
who can reach what, who did reach what and when, per customer and record.
What CaliberFocus does, and does not do.
Identity should reduce product complexity rather than add another layer. We treat enterprise provisioning as a commercial capability with a delivery date, design identity for people working across organizations, shifts and temporary assignments, and treat shared logins as a product finding rather than a customer failing.
Product identity models are usually built for the customer employee logging in during business hours. The third column is what each of the other types actually requires.
| Identity Type | Who They Are | What They Require |
|---|---|---|
| Customer Workforce | Staff at the organization that bought your product | Directory provisioning, and this is the only one most products handle well. |
| Multi-Organization Clinicians | Practising at several facilities with different privileges | One identity, several memberships. The model failure that produces most workarounds. |
| Agency and Temporary Staff | Present for weeks, covering shifts, then gone | Time-bound access with automatic expiry rather than a removal somebody must remember. |
| Outsourced and Offshore Teams | A vendor serving several of your customers | Access scoped per client assignment, with clear separation between them. |
| Consultants and Implementers | Configuring and migrating across several customers | Temporary, scoped, auditable access that does not require a permanent account. |
| Machine and API Identities | Integrations, automations and services | Owner, scope, expiry and review. They outnumber humans and are governed least. |
| AI Agents | Software acting with delegated authority | Separate grants for data, tools and actions, since capability must never imply permission. |
Administration Is a Capability, Not a Universal Permission
The ability to add users, configure workflows, manage integrations and assign roles does not require unrestricted access to patient information. Programmatic identities operate faster than humans and reach larger datasets, so their privileges should be narrower rather than broader.
Role-based access is the right foundation and cannot express relationship, assignment, time or case scope without creating a role per combination. Use roles for capability and attributes for context.
| Mechanism | What It Decides Well | Where It Breaks Down |
|---|---|---|
| Authentication | Who this person or system is | It is routinely treated as permission, which is where escalation begins. |
| Role | What category of work somebody does | Relationship, assignment and time. Adding roles for these is how lists reach fifty. |
| Tenant Scope | Whose data they may reach | Nothing. It is the foundation and it must be structural rather than a filter. |
| Attribute and Context | Care relationship, assignment, location, time, case | Complexity. Rules become hard to reason about if nobody owns the policy. |
| Record-Level Scope | Which specific records within a customer | Performance and design effort, which is why it is frequently skipped. |
| Break-Glass | Legitimate urgent access outside normal rules | Becoming ordinary if it is not time-bound, visible and reviewed. |
Engineering Discipline
Govern the role catalogue. Keep tenant scope structural and separate. Make time-bound access the default for temporary people. Design break-glass to be uncomfortable. Evaluate authorization in one place. Test prohibited actions in regression.
Service accounts, integration credentials, automation identities and AI agents typically outnumber human users in a mature healthcare product. They frequently hold broader access and are almost never included in an access review.
Service & System Accounts
Named human owner, stated purpose, scope and review date. An account nobody owns is an account nobody will revoke.
Integration & Partner Credentials
Per integration and environment rather than shared, so one revocation does not break everything.
Support & Engineering Access
Scoped, justified, time-bound and logged rather than standing.
AI Agent Identities
Data, tool and action authority granted separately because ability to request must never authorize.
Administrative Access
Customer administrators can widen access, add users and change configuration; that is privilege inside the customer estate.
Secrets & Credentials
Managed storage, rotation, scoping and tested revocation across product, integration and partner credentials.
The lifecycle has seven stages and one is usually missing.
Join → provision → change → review → suspend → revoke → remove. The change stage gets almost no attention, and most excess access comes from people taking on new responsibilities while retaining everything previously needed. For privileged access: request → reason → approval → scope → duration → logging → expiration.
Healthcare organizations need to review who has access to protected information, including access inside your product. If they cannot produce that list themselves, they will ask you repeatedly.
Access Governance
Customer-visible access reporting, self-service review tooling, meaningful privilege review and visibility into administrative access.
Lifecycle
Directory-driven joiner, mover and leaver; automatic expiry for temporary access; machine identities in review; complete customer offboarding.
Auditability
Who accessed which record, when and in what context; role changes logged; break-glass use recorded and reviewed.
Compliance Engineering
Evidence generated by the system, traceable authorization decisions, named identity-model ownership and authorization regression tests.
Give customers the access report rather than making them ask for it.
A clear export of who holds what access, with role meaning explained, turns a recurring compliance request into self-service and makes the product easier to keep in the customer estate.
The outcomes that matter are whether enterprise customers can onboard without a project, whether access shrinks when people leave, and whether anybody is still sharing credentials.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Cross-Customer Reach | How many identities can access more than one customer, human and machine, and why each still can | The clearest single measure of access risk in a multi-tenant healthcare product. |
| Enterprise Onboarding | Time to provision a customer with directory integration and single sign-on | A sales-cycle measure and common reason implementations run long. |
| Deprovisioning Latency | Time from a person leaving to access being removed, and accounts still active in error | The most common access finding and easiest to correct once measured. |
| Shared Credential Usage | Accounts showing concurrent or implausible use patterns | Each is an audit trail identifying nobody and a product-design signal. |
| Machine Identity Governance | Non-human identities with an owner, scope and expiry | They outnumber people and are reviewed least. |
| Role Comprehensibility | Number of roles and whether an owner can explain what each permits | A catalogue past auditability cannot support minimum necessary. |
Honest expectation setting
An assessment may find strong authentication but broad authorization, working SSO with manual provisioning, unrelated permissions accumulated in roles, overly broad support access, ownerless machine identities, or reviews that confirm accounts rather than challenge privileges. The objective is not more identity technology but a smaller and more defensible access model.
We will review your identity model against how healthcare work actually happens, audit active access against current need including machine identities, assess your enterprise provisioning readiness against what large customers require, and identify where shared credentials are compensating for something the model cannot express.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
