Mapping business requirements to authorization policy for medtech

The annual flu season is here! This time around, you come down with flu-like symptoms that are hard to shake off. You visit your General Practitioner (GP) and get an oral swab to check for the type of flu. Two days later, on your follow-up visit to the GP's office, he stares at his computer for a moment, looking puzzled and slightly embarrassed, and informs you that he is unable to find your lab report.

This is not a rare occurrence; certainly, some of us or people we know have encountered situations like this before. Well, it turns out that the patient care system software had been updated the night before. And the updates have messed up the default access rights of patient file authorization. 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. When these authorization policies are embedded within the core product code, they become vulnerable to unintended side effects from code changes on routine software updates.

Back at the GP, the delayed flu test report may seem manageable, right? You probably had a 24-hour delay in diagnosis to find out which flu virus caused it and get treated accordingly. Inconvenient, but likely not critical.

But what if this was a cardiologist wanting to decide whether or not to perform Coronary Artery Bypass Graft (CABG) surgery on a patient based on a blood test report? A delay of a few minutes can be a difference of life or death, in the literal sense. The stakes couldn't get any higher.

If anything, this situation makes the strongest case for decoupling capabilities into their own managed service, and in our case, it's separating the "authorization" capability. So, how do we get the process of "managing the complex authorization" away from the core application code? By delegating it to a purpose-built authorization management solution like Cerbos. The value proposition is simple; it is to take the complex, messy, and risky job of managing permissions out of the core application code, making compliant MedTech software simpler, safer, and much faster to build and manage.

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?

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 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.

While the interactions are taking place, we are going to highlight the Cerbos authorization policies at play. The CCC is a cloud platform that manages data from implantable cardiac devices like smart pacemakers across multiple hospitals. Patients have devices that send telemetry (heart rate, device status) to the cloud. Clinicians use the platform to monitor their patients, and device manufacturers use it to push firmware updates and analyze device health.

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. He has recently been operated on and implanted with the latest smart pacemaker. After a brief consultation, Dr. Aly accesses the CCC platform to review the patient's data and to see if the pacemaker is working as expected.

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

Resource/Action	Patient	Delegated Caregiver	Nurse	Physician	ER Physician	Manufacturer Engineer	Compliance Officer	Hospital Admin
PATIENT DATA ACCESS
View Own Patient Data	✅	✅ (Specific patient, time-limited)	✅ (Assigned patients)	✅ (Assigned patients)	✅ (With justification)	❌	❌	❌
Edit Clinical Notes	❌	❌	✅ (Basic notes)	✅ (Full access)	✅ (Emergency notes)	❌	❌	❌
View Patient History	✅	✅ (Limited)	✅ (Assigned patients)	✅ (Assigned patients)	✅ (Emergency access)	❌	❌	❌

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, and she updates the clinical notes for the patient to be discharged by the end of the day if the readings continue to be displayed in the normal range.

Cardiology wardroom 902

It's 9:30 AM; Dr. Aly enters room 902, but as she enters, she gets pulled over by the ward administrator for an emergency call from the Emergency Room (ER).

ER room 1

Dr. Aly gets called in for a patient in his mid-50s who has just been admitted complaining about the pain in his chest. The patient had been previously fitted with a smart pacemaker.

Dr. Aly logs into a nearby computer to access the patient's pacemaker reading in the CCC platform. She realizes she has not yet been provisioned with the ER Physician role to access other patients' data, who are not under her care. The role provisioning process usually takes a few hours, including the request and approval processes. Given the urgency and clinical justification, she opts to use the Breakglass feature to override standard access controls and view the necessary patient data in the emergency room.

Dr. Aly does the following actions:

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

Authorization matrix applicable for this scenario

Resource/Action	Patient	Delegated Caregiver	Nurse	Physician	ER Physician	Manufacturer Engineer	Compliance Officer	Hospital Admin
PATIENT DATA ACCESS
Edit Clinical Notes	❌	❌	✅ (Basic notes)	✅ (Full access)	✅ (Emergency notes)	❌	❌	❌
View Patient History	✅	✅ (Limited)	✅ (Assigned patients)	✅ (Assigned patients)	✅ (Emergency access)	❌	❌	❌
ACCESS MANAGEMENT
Break-Glass Access	❌	❌	❌	✅ (time-limited)	✅	❌	❌	❌

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 at the Cardiology Ward. She apologizes to the patient, who is an elderly woman in her late 70s, for the delay in following up. “It’s been quite a morning,” she says with a tired smile. The patient has been feeling generally well but thought she would come in and check in at the hospital because the pacemaker reading has been off lately. On reviewing her data, her outpatient doctor had recommended that she admit herself so a cardiologist could take a closer look.

Dr. Aly logs into the CCC platform and sees the readings are really way off the normal ranges, but the patient is absolutely fine. She initiates a call with the CCC platform vendor support; the customer service from the manufacturer responds to the call, and after a long discussion, they decide that they will attempt a firmware update on the pacemaker, as it has been out of firmware updates for a while.

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

Dr. Aly consults with the device manufacturer on ways to proactively prevent this scenario from happening. The device manufacturer agrees to work on a fix for the issue and requests to export the de-identified patient data for analysis. Dr. Aly turns to the elderly patient and says gently, “Would you be comfortable sharing your anonymized data to help improve the pacemaker’s performance? It could help the engineers in refining future updates.” After the patient agrees, Dr. Aly hands her a digital tablet to review and sign the consent form on the CCC platform. Once consent is provided, the manufacturer securely downloads the de-identified data for analysis.

Further actions taken are:

Vendor support:

1. Export patient data (de-identified)

Authorization matrix applicable for this scenario

Resource/Action	Patient	Delegated Caregiver	Nurse	Physician	ER Physician	Manufacturer Engineer	Compliance Officer	Hospital Admin
DEVICE CONTROL
Request Firmware Update	❌	❌	❌	✅	❌	✅ (Initiate)	❌	❌
Approve Firmware Update	❌	❌	❌	✅ (Required)	❌	✅ (Required)	❌	❌
View Firmware Version	✅	✅	✅	✅	✅	✅	✅	✅
PATIENT DATA ACCESS
View Own Patient Data	✅	✅ (Specific patient, time-limited)	✅ (Assigned patients)	✅ (Assigned patients)	✅ (With justification)	❌	❌	❌
Export Patient Data	✅ (Own data)	❌	❌	✅ (With consent)	❌	✅ (De-identified)	❌	❌

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

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

  rules:
    - actions: ["view_own_data"]
      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: ["export_data"]
      effect: EFFECT_ALLOW
      roles: ["physician", "manufacturer_engineer"]
      condition:
        match:
          any:
            of:
              - all:
                  of:
                    - expr: request.principal.role == "physician"
                    - expr: request.resource.consent == true
                    - expr: request.principal.hospital_id == request.resource.hospital_id
              - all:
                  of:
                    - expr: request.principal.role == "manufacturer_engineer"
                    - expr: request.resource.is_deidentified == true

In room 902, the elderly patient has a visitor, a 20-year-old granddaughter, who is concerned about her granny and discusses her case with Dr. Aly. She mentions to Dr. Aly that her granny is not tech savvy and would like to keep an eye out on the pacemaker readings on behalf of her grandmother. Dr. Aly highlights the CCC platform's option of granting a patient-delegate; she asks the granny's permission before she registers the granddaughter as a delegate to her granny's patient record, allowing the granddaughter to monitor the reading.

More actions performed are:

Dr. Aly:

1. Delegate Access

Granddaughter:

1. View own patient data (delegated)

Authorization matrix applicable for this scenario

Resource/Action	Patient	Delegated Caregiver	Nurse	Physician	ER Physician	Manufacturer Engineer	Compliance Officer	Hospital Admin
PATIENT DATA ACCESS
View Own Patient Data	✅	✅ (Specific patient, time-limited)	✅ (Assigned patients)	✅ (Assigned patients)	✅ (With justification)	❌	❌	❌
ACCESS MANAGEMENT
Delegate Access	✅ (Own record / delegates)	❌	❌	✅ (Assigned patient record)	❌	❌	❌	❌

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, and Dr. Aly remembers that she needs to pop into the meeting briefly to review the incidents for the week.

The internal compliance team reviews the incidents categorized by physicians, in which way they are discussed, and the physicians are on their way to attend to patients. First off, the rank -it's Dr. Aly's incidents.

The internal compliance team logs into the CCC platform and generates reports for compliance and notices that Dr. Aly has 2 incidents associated with her name in the CCC platform.

Actions performed by the internal compliance team:

1. Review breakglass events
2. Generate compliance reports

Authorization matrix applicable for this scenario

Resource/Action	Patient	Delegated Caregiver	Nurse	Physician	ER Physician	Manufacturer Engineer	Compliance Officer	Hospital Admin
Generate Compliance Reports	❌	❌	❌	❌	❌	❌	✅	✅ (Usage reports only)
Review Break-Glass Events	❌	❌	❌	❌	❌	❌	✅	✅

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

1. Breakglass

The internal compliance team reviews the Breakglass event and justification and deems it valid for the scenario and reminds Dr. Aly to submit her request for the ER Physician role in the system.

2. Exporting of patient data

In the compliance report, an event was flagged where patient data had been exported by the device manufacturer. The compliance team confirmed that the data was de-identified and proper consent had been obtained, meeting compliance. However, the reason for the data export had not been documented at the time. Dr. Aly later provided the justification, stating that the export was necessary to help the vendor address issues related to timely firmware updates for the pacemaker. This reason was added to the platform retrospectively, and all related events associated with Dr. Aly were marked as resolved.

Architecting the platform with decoupled authorization

Decoupling authentication is a well-known industry-wide phenomenon. All the software shipped these days has popular support for integration with third-party identity providers based on OIDC and SAML for authentication. Decoupling authorization is gaining traction by the day, and more and more vendors are taking advantage of a well-designed, dedicated solution to manage authorization.

As illustrated in the MedTech scenario in this article, Cerbos takes the complexity of managing authorization policies out of the platform code and puts it into an easily managed and versioned system. It makes sense for the modern enterprise software to allow for the decoupling of authorization, just as with authentication.

Centralized authorization policy is easier to understand and update by analysts rather than developers. Having the policy defined in YAML in its self-managed versioning system gives the ability for a well-maintained, up-to-date, and safer deployment of authorization policies.

Here is how a high-level architecture for the CCC platform may look, with Cerbos used as the authorization policy decision.

The Cerbos PDP can be available either embedded or as a sidecar for the CCC platform to call for authorization decisions, and the Cerbos Hub provides the policy updates to the PDP to decide on allow/deny decisions.

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.

Architects, developers, policy analysts, and program managers need to get authorization in MedTech right. Not just due to the stringent regulations or avoiding patient data breaches, but because it is about protecting lives.

In this article, we have seen how we can enable MedTech platforms like the CCC system to focus on what it does best, which is managing smart pacemakers and improving patient outcomes. Whereas authorization is handled by systems that are built for that purpose.

Let authorization policies be managed, updated, and maintained by policy analysts and not the developers so that they're completely de-linked from unintended side effects of code changes.

By decoupling authorization, MedTech teams can accelerate innovation, keep the platform compliant, ensure patient safety, and ship code changes faster. Let's decouple authorization, not just because it's the smart architectural decision, but because it's safer to do so.

If you’re interested in implementing externalized authorization - try out Cerbos Hub or book a call with a Cerbos engineer to see how our solution can help streamline access control in your applications.

To explore mapping business requirements to authorization policy for other domains - check out our foundational guide, or dive into this blog specific to the fintech or the HR spaces.