Mapping business requirements to authorization policy for medtech

HH.A. Writer September 28, 2025 14 min read

The annual flu season is here! This time around, you come down with flu-like symptoms that are hard to shake off... The GP informs that he has let the clinic's IT team know about this, and they are on it. They have assured him that the lab reports are going to be available for viewing the next day.

It is a well-known phenomenon in the technology space that a minor percentage of software updates have the potential to introduce or cause system errors that were working perfectly before. A recent example is the widely publicized CrowdStrike Falcon sensor update, which triggered blue screen errors (BSOD) across countless Windows systems worldwide.

Authorization policies are complex to manage at the best of times, and in Medical Technology (MedTech), the complexity is amplified. Architects and developers must navigate a minefield of strict regulatory requirements, including:

• HIPAA's minimum necessary principle and audit requirements.
• FDA 21 CFR Part 11's immutable audit trails.
• GDPR's consent and data minimization requirements.
• EU MDR's cybersecurity mandates.
• National frameworks like NHS RBAC.

These regulations leave little room for error, placing intense pressure on them to get authorization logic right to the dot. Beyond compliance, policies must account for actors, resources, and contextual parameters that dictate access...

Complexity pitfall of policies

In MedTech, the authorization policy encompasses a wide range of factors that influence "Who has access to what?"

We have:

1. Actors. Medical professionals like physicians, visiting faculty members, pre-med students training at the hospital, hospital administrators, patients who need access to their data, patient-delegates who act on behalf of the patients, and device manufacturers who need to push software updates.

2. Context. Figuring out who can access what is highly contextual in MedTech systems. For example, which physicians are allowed to access which patients? Who are the authorized delegates for specific patients? What time-based, device-based, or location-based constraints govern access?

NOTE

In a multi-tenant system, resident doctors typically have access only to their assigned patients. Visiting faculty may require access across multiple hospitals. Temporary access might also be granted for data sharing or consultations with out-of-network specialists, all of which must be managed securely and in compliance with strict regulatory frameworks.

3. Logging. Immutable logging of all accesses along with context information for compliance and auditing.

4. Resource/patient data. Who has access to which patient data? Is it read/write or read-only access? Does the data need to be encrypted in transit and at rest? What do the applicable regulatory standards dictate about the handling of patient information? An additional layer of control is the enforcement of Separation of Duties (SoD), which ensures that no single individual has unchecked access or authority across conflicting roles.

5. Overrides/breakglass. The ability to Breakglass to access data in the case of emergency, and who can perform Breakglass. The ability to securely log Breakglass actions for future audits.

With all of these factors at play, it's indeed complex to manage authorization policies. It makes a strong case for the separation of platform code and code that defines and maintains authorization information.

Let us look at how Cerbos can help in simplifying authorization policies in MedTech. In this article, we are going to walk in the shoes of a cardiologist, Dr. Aly, spending her day at the Cardiology Ward at the hospital, where she visits a few of her patients and interacts with the MedTech software "Connected Cardiac Care" (CCC) integrated with Cerbos for authorization.

A day at the hospital
Dr. Aly starts her day at the hospital at the Cardiology Ward, checking up on her patients.

Cardiology wardroom 901

It's 9:00 AM; Dr. Aly enters room 901 to check on a male patient in his late 50s... The actions Dr. Aly performs are:

1. View Own Patient Data
2. View Patient History
3. Edit Clinical Notes

Authorization matrix applicable for this scenario

Cerbos policy for the physician role

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: patient_record

rules:
    - actions: ["view_own_data"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["edit_clinical_notes"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["view_history"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.assigned_physician == request.principal.id
              - expr: request.principal.hospital_id == request.resource.hospital_id

The readings look as expected...

Cardiology wardroom 902

...but as she enters, she gets pulled over by the ward administrator for an emergency call from the Emergency Room (ER)... The actions Dr. Aly does are:

1. Breakglass action (60 min time-limited permission)
2. View patient history
3. Edit clinical notes

Authorization matrix applicable for this scenario

Cerbos policy for the physician role

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: patient_record

rules:
    - actions: ["edit_clinical_notes"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.note_type == "full"
              - expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["view_patient_history"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.assigned_physician == request.principal.id
              - expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["break_glass_access"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.emergency == true
              - expr: request.principal.hospital_id == request.resource.hospital_id
              - expr: request.time <= timestamp.add(request.resource.break_glass_activated_at, "60m")

Dr. Aly focuses on alleviating the patient’s discomfort and carefully outlines the next steps in the treatment plan.

Back to cardiology wardroom 902

It's 11:00 AM; Dr. Aly is back at room 902... The actions taken are:

Vendor support:

1. Initiate Firmware Update

Dr. Aly:

1. Approve Firmware Update
2. View Firmware Version
3. View own patient data

Authorization matrix applicable for this scenario

Cerbos policy for the physician role

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: device

rules:
    - actions: ["request_firmware_update"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["approve_firmware_update"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.approval_required == true
              - expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["view_firmware_version"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          expr: request.principal.hospital_id == request.resource.hospital_id

In room 902, the elderly patient has a visitor...

Cerbos policy for the physician role and delegate access

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: patient_record

rules:
    - actions: ["view_own_data"]
      effect: EFFECT_ALLOW
      roles: ["delegated_caregiver"]
      condition:
        match:
          all:
            of:
              - expr: request.principal.id in request.resource.delegated_caregivers
              - expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["delegate_access"]
      effect: EFFECT_ALLOW
      roles: ["physician"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.assigned_physician == request.principal.id
              - expr: request.principal.hospital_id == request.resource.hospital_id

Lunch break

It's noon; Dr. Aly heads over for her well-anticipated lunch break.

Post-incident review (PIR) meeting

The hospital where Dr. Aly works has a weekly 1:00 PM PIR meeting on a Friday. Today is Friday...

Actions performed by the internal compliance team:

1. Review breakglass events
2. Generate compliance reports

Authorization matrix applicable for this scenario

Cerbos policy for the compliance officer role

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: compliance_audit

rules:
    - actions: ["generate_report"]
      effect: EFFECT_ALLOW
      roles: ["compliance_officer"]
      condition:
        match:
          expr: request.principal.hospital_id == request.resource.hospital_id

- actions: ["review_break_glass"]
      effect: EFFECT_ALLOW
      roles: ["compliance_officer"]
      condition:
        match:
          expr: request.principal.hospital_id == request.resource.hospital_id

Architecting the platform with decoupled authorization

Decoupling authentication is a well-known industry-wide phenomenon... The CCC platform can continue to do what it does best; to read readings and stats from smart connected devices like pacemakers and make them available for viewing over the web and mobile for authorized personnel to review and take action as appropriate.

Conclusion

The best piece of technology in the MedTech space is one that gets out of the way of physicians consulting patients, and a well-designed MedTech platform empowers physicians by helping them focus on patient care...

By decoupling authorization, MedTech teams can accelerate innovation, keep the platform compliant, ensure patient safety, and ship code changes faster.