Post-MI Implant and Rehab

v 0.4 - 9 Mar 2015

Background

Alice is a 55 year-old veteran who has had an myocardial infarction complicated by serious arrhythmias and received an Implantable Cardiac Defibrillator (ICD) and an activity monitor wristband (Fitbit) at her VA medical center. Now, 18 months after the MI, Alice is moving to Rwanda where she will be followed by an internist in private practice. This use-case is inspired by the actual experience of an ICD patient and has been reviewed by two cardiology specialists.

There are four devices in Alice's situation. The smartphone is her principal interface and also serves as a connectivity hub for the other devices.

ICD ICD Programmer Activity Monitor Device Relay and Control

Alice's situation is increasingly common. Alice has a relationship with two doctors she trusts and she has been fitted with connected technology from two major vendors. Each vendor's device connects to that vendor's cloud. Each doctor is practicing in a separate hospital using electronic health record systems (EHRs) that don't trust each other and don't trust the device vendor's cloud either. Alice's trust in her doctors is the only common denominator.

Alice is also experiencing the Internet of Things. This use-case illustrates increasingly urgent cybersecurity issues. Life-critical devices such as a defibrillator or neural stimulator need to be both programmed and monitored. Simple things we wear are tracking us wherever we go. People travel with these devices and they travel to places where network connectivity is unreliable and insecure.

As engineers and privacy advocates we can envision a standard "Public" interface for Alice's devices, their vendor's systems, and the doctor's EHRs. Alice will then be able to authorize, monitor, and control the vital information that flows between the connected systems using her chosen portal. Because everything is based on a standard for connectivity and authorization Alice can use her smartphone to connect and manage all of the devices in her life including, for example, unlocking her car and her home.

Overview

The use case has three people and four devices. The people are Alice and her doctors Bob (VA) and Carol (Rwanda). The doctors communicate via their respective EHRs. The doctors also use a Programmer to wirelessly configure the ICD. The Programmer can connect to the Internet for software updates and audit but for security reasons the ICD can't be programmed directly from the Internet - a doctor must be present and authorized by the patient.

There is no identity federation in this use case. Drs. Bob in the US and Carol in Rwanda are in separate jurisdictions. The FitBit and its cloud are not HIPAA entities. For security reasons, the ICD programmer is open source software.

The Actors:

1. Alice - a patient with three devices she owns including a smartphone to control everything
2. Bob - a physician that programs Alice's ICD
3. Carol - a physician that monitors Alice's ICD and her activity during rehab

The Domains:

1. Patient Domain - services that Alice runs, owns, contracts, or otherwise controls
2. VA domain - services directly in control and view of the VA
3. Rwanda domain - services directly in control and view of another jurisdiction

The Services:

1. VA Cardiologist EHR - FHIR - has the capability to manage secure storage
2. Rwanda Internist EHR - FHIR - has the capability to manage secure storage
3. ICD Built-in Server - encrypted - has the capability to manage secure storage
4. Fitbit Built-in Server - encrypted and paired with smartphone
5. ICD and Fitbit Relay App on smartphone - FHIR
6. ICD Vendor Cloud - FHIR
7. Fitbit Vendor Cloud - FHIR
8. UMA Authorization Server - accessible via the patient domain, also functions as an OAuth 2.0 server and OpenID Connect IdP

Alice's Privacy Requirements:

1. Unlinkability - Each of the 4 services (VA, Rwanda, ICD Cloud, Fitbit Cloud) sees a different Alice persona
2. Control - Cardiologist installs VA and Alice certs in ICD before implanting
3. Transparency - Alice’s UMA AS logs all authorization transactions
4. Sovereignty - Alice could use any standard programmer to remove or add certs to her ICD
5. Convenience - Alice can choose her Authorization Server (AS) - aka: no multiple portals problem
6. Security - Alice can be authenticated by different IdPs at different servers using a standard identity protocol

Standards:

1. Token-based Authorization - common to all application programming interfaces (OAuth2)
2. Policy-based Authorization - can operate even when Alice is off-line (UMA)
3. Personal Area Network - connects to ICD and Fitbit (Bluetooth Smart)
4. Identity Federation - without a shared secret (OIDC)
5. Data Resource Standards - are presumed across the devices and EHRs - (FHIR)

Storyboard

0 - Alice's friend offers her an Authorization Server

Alice's friend is a diabetic and a fan of the Nightscout project. She has just discovered an open source Authorization Server on GitHub. It's available as standard virtual machine with instructions for how Alice can set it up with a $5/mo hosting service. Alice now uses her AS to manage access to her college transcript and her online calendar. The Authorization Server is a convenient way for Alice to manage sharing in one place. In most cases, the policy-based AS can handle new access requests by potential employers or new collaborators without having to approve them one at a time. Occasionally, the automation is inadequate and she signs-in to the AS to add or adjust a policy.

As part of its services, the authorization server also provides alice with a re-usable digital identity, which she ties to a set of variable factors including her trusted devices (a phone and laptop). Several of Alice's favorite websites accept Alice’s digital identity. Alice is very pleased because websites no longer force her to store complex passwords that change every 3 months. For the first time, the number of entries in her password manager has actually gone down.

Alice's health, unfortunately, is about to take a temporary turn for the worse.

1 - Alice has an MI and is fitted with an ICD

Alice has a family history of heart disease. She suffers a myocardial infarction one morning and is rushed to the VA hospital. Alice is asked to register and sign the usual HIPAA Notice of Privacy Practices by the hospital. This registration form allows Alice to control access to her health records at the VA, manually through the MyHealtheVet patient portal, and automatically through the VistA Public API.

As part of their recent security and interoperability upgrade, the VA's authentication system has been enhanced to allow for a patient-supplied digital identity and a patient-specified authorization server. Alice registers with her email address, which points to her IdP to complete the OIDC transaction.

Instead of filling out yet another repetitive consent form, Alice enters the URL of her Authorization Server - the same one she is using to manage her other consents. It's a simple bit.ly address she can easily remember. Alice is asked to sign-in to her AS. This assures the VA that Alice is indeed in control of her authorization system. The VA treats this process as the digital signature on the HIPAA registration form and has now transferred much of the breach and accounting for disclosures liability to Alice's AS. Alice, for her part, appreciates having a central consent management point instead of having to sign-in and check all of the 6 different portals her recent troubles have brought into her life.

Her treatment is excellent and she recovers quickly but over the next weeks she nearly passes out and on one occasion she actually faints. Alice is diagnosed with Ventricular Tachycardia and she is to be fitted with an Implantable Cardiac Defibrillator by Dr. Bob, a VA electrophysiologist.

Before installing the ICD, Dr. Bob uses a Programmer to configure it for Alice. The Programmer installs two security certificates into the new ICD. One is paired with a private key that Alice will control. The second is paired with a private key controlled by the hospital. The ICD vendor has their own certificate installed by default. The certificates will be used for authentication and encryption in a way that is similar, if not identical, to the common SSH protocol.

After the ICD is installed Dr. Bob uses the private key associated with the hospital certificate via the Programmer to configure Alice's ICD.

2 - Alice begins Cardiac Rehab and adds a Fitbit

Alice's VT is now under control and she begins her cardiac rehab program. She needs to monitor her activity carefully during exercise and she purchases a Fitbit activity tracker.

Data from the tracker is relayed via her smartphone to a Fitbit account in the cloud. Alice introduces her Authorization Server to the Fitbit server to control access by her doctors and exercise pals.

Alice’s was fortunate to have a choice of devices. For peace of mind, she chose both the ICD and the Fitbit on the basis of their Fair Information Practice (FIP) rating. The core FIP principles of data minimization, data persistence minimization, and transparency are described by each of the two vendors in their posted privacy policy:

• Data Minimization: Unnecessary data is not sent to the cloud. (1) The device connects to the smartphone relay using an open protocol accessible from an open source app like Dr. Bob's rehab app. The app, under Alice's control can then choose what data to send to the vendor's cloud, and (2) The vendor's cloud connects to the device using open protocols for authentication and authorization so that Alice can choose to be pseudonymous on the vendor server, to use a standard second factor for authentication and to specify her Authorization Server.

• Data Persistence Minimization: Alice has a choice of how long data is stored by the vendor, if at all. This reduces the vendor's liability for breaches. In their advanced implementation, Alice's Authorization Server policies can be linked to the persistence of her data on a standards-compliant server. Alice chooses to have her ICD data deleted as soon as it has been accessed by Dr. Bob.

• Transparency: Both device vendor's support an independent logging ability for all transactions. A standard e-receipt is available to Alice and can be sent to the destination specified by her Authorization Server. Alice chooses her email as the destination. She sets the ICD vendor cloud to be notified of alerts sent to Dr. Bob and access to her record by Dr. Bob. This feedback around her symptoms provides tremendous peace of mind.

The data from the tracker is managed by an app on her smartphone that allows Dr. Bob to prescribe activity limits and it allows Alice to mark situations when her ICD is triggered unnecessarily.

3 - Dr. Bob teaches Alice to annotate her symptoms

False-positive shocks are very unpleasant and Dr. Bob can access the Fitbit data as well as the ICD data through the VistA EHR to manage Alice's care. Based on this data, Alice can come in and have Dr. Bob use the Programmer to adjust her ICD.

4 - Alice moves to Rwanda and needs her ICD to be reprogrammed

Alice takes a job in Rwanda. She is referred to the internist, Dr. Carol, who will take over monitoring her rehab and programming her ICD as necessary. The ICD vendor has no representative in Rwanda and Dr. Carol's EHR is not automatically trusted by the VA.

Alice uses her Authorization Server that is trusted by the VA to mediate the health information exchange between the two hospitals in two different trust domains. The VA can depend on Alice's use of her secure standard authentication token to securely grant access to her records.

Dr. Bob and Dr. Carol can actually collaborate in Alice's management and Dr. Bob suggests a reconfiguration of her ICD. Dr. Carol is able to download the Programmer from a trusted site but he does not have the private key that Dr. Bob uses for access. Fortunately, Alice has control of her private key to her own ICD and she uses it to add Dr. Carol's certificate to her ICD for programming.

5 - Alice loses her smartphone and needs to recover control

In Rwanda, Alice's smartphone and keychain are stolen. Her Authorization Server is not affected and existing policy-based authorizations, including the health information exchange between Dr. Bob and Dr. Carol continue as before. She is not in immediate danger but she has temporarily lost access to all the accounts that were tied to her lost devices via her IdP, which she can no longer directly access.

Alice buys a new smartphone and installs the ICD relay app. The ICD reconnects with its cloud and the two EHRs automatically but Alice's cardiac rehab app needs to be registered with her AS before she can use it and her trusted device is gone.

Fortunately, since Alice is using a federated identity to access all of these systems, she is able to go through account recovery with the IdP on her virtual machine and is able to regain control over all of her accounts. At the same time, she completely disconnects and blacklists her stolen phone from the AS, so any access to the AS (including its IdP capability) through that device will be immediately flagged. The re-provisioning actions are all logged for audit at the AS, which sends Alice notifications of the actions through her registered email forwarding address.