Zyposoft
Identity and access

Being a nurse is not the sameas being this patient's nurse.

One login through the identity provider you already run, roles that come from your own directory, and access that depends on the ward, the shift and who is actually in your care.

One loginYour identity providerRolesAnd the situationAll of it recorded
The same nurse, the same record, four situationsIllustrative
A staff nurse, signed in with her hospital login
Asking to open the same patient record every time
Role: Staff Nurse
The situation
On shiftHer wardHer patient
The answer
Opened

Right role, right ward, and this patient is in her care.

Access recorded against her name.
Same person. Same record. The situation decides.
Knowingwhosomeoneisgetsyouhalfway.Ajobtitledoesnottellyouwhoserecordstheymayopen.Thewardtheyareondoes.Sodoestheshifttheyareworking.Andwhensomeonedoesneedtooverrideit,thatshouldbepossibleandimpossibletodoquietly.
What gets asked

Five questions, answered before anything opens.

1

Are you who you say you are?

People sign in once, through the identity provider the hospital already runs. We do not create another username and password for staff to forget, write down, or share on a busy ward.

HowSingle sign-on, federated with yours
One loginYour identity providerJoiners and leaversSessions that expire
2

What is your job here?

Roles come from your directory, not from a list we keep separately. When someone changes job or leaves, that flows through — you are not relying on anyone remembering to tell us.

HowRoles mapped from your directory
Roles from your sideGrouped by functionChanges flow throughNo parallel list
3

What is your relationship to this patient?

This is the one most systems skip. Being a nurse does not mean every patient in the hospital. Access depends on the ward, the shift and whether this patient is actually in your care right now.

HowThe situation decides, every time
WardShiftCare teamThis encounterRight now
4

What if you genuinely need to override it?

Emergencies do not respect access rules. So there is a deliberate way through — one that asks for a reason, opens the record, and puts the person's name against it for review.

HowBreak-glass, never silent
Deliberate actionReason capturedFlagged for reviewName attached
5

What about the systems, not the people?

Integrations get treated the same way. Every connected system has its own credentials, its own scope, and shows up in the same records as any human caller.

HowSystems prove themselves too
Service credentialsScoped narrowlySame audit trailRevocable
The record

Every open, and every refusal, leaves a trace.

Who opened it
Which record
When
From where
What their role was at the time
Whether it was a break-glass override
The reason they gave
And every attempt that was refused
The refusals matter as much as the approvals. A record of who tried to open something they should not have is often the first sign that something is wrong.
The awkward questions

The ones your security team will ask on the first call.

Someone left last month and still has access.

That is a directory problem, not an application problem — which is exactly why roles come from your identity provider rather than a list we keep. When they are disabled on your side, they are disabled here.

Our consultants cover four wards and rotate constantly.

Then ward alone is the wrong rule for them. Contextual access is configurable per role — for rotating staff it usually keys off the care team and the active encounter instead.

Break-glass sounds like a hole in the security.

It is a deliberate door rather than a hole. The alternative is worse: staff sharing logins to get around the rules in an emergency, which leaves you with no record at all.

We need to prove all this to an auditor.

The access records are queryable and exportable. What retention period applies, and who is allowed to run those queries, is something we set up with you rather than decide for you.

How this ends up configured is a decision for your team, not ours — which roles exist, what context each one is bound to, who may break glass and how long records are kept all get agreed during implementation. Specific protocols, providers and retention periods are confirmed per engagement rather than claimed on a web page.
Setting it up

Six conversations, in this order.

The third one is where projects usually go wrong — deciding what context actually means for each role takes longer than anyone expects, and it is worth the time.

01
Connect to your identity provider
Which providerSingle sign-onTest accountsWhat happens when it is down
02
Agree the roles
The list of rolesHow they map from your directoryWho approves changes
03
Decide what context means for each one
WardShiftCare teamEncounterWhich rule fits which role
04
Set up break-glass properly
Who may use itWhat it asks forWho reviews itHow quickly
05
Try to break it
Wrong roleWrong wardExpired shiftStale sessionCheck nothing leaks in the error
06
Keep reviewing it
Who has whatBreak-glass reviewsRefused attemptsAfter every reorganisation
Zyposoft Technologies is a product engineering company based in Bangalore, building software for healthcare and enterprise operations. Our products are Zypocare One, the connected hospital platform; Zypo Clinical AI, which adds intelligence a clinician can overrule; and the Integration Platform that keeps them working with the systems already in place.
Products
Zypocare OneZypo Clinical AIIntegration Platform
Solutions
Healthcare TransformationEnterprise Product EngineeringAI and AutomationCloud, Data and Integration
Company
About ZyposoftLeadershipPartnersCareersContact
Get in touch
Bangalore, IN
#7, Nisarga Layout
Chikkalsandra
Bangalore 560061
India
info@zyposoft.com
Security & GovernanceIdentity & AccessData PrivacyData Security
© 2026 Zyposoft Technologies. All rights reserved.
Privacy PolicyTerms of UseSitemap