1. Intelligent Health Platform (IHP) Consent Management

2. INTRODUCTION

3. THE BENEFITS OF IHP CONSENT MANAGEMENT
THE NEED
PATIENT DATA SECURITY
HIPAA in the US as well as GPDR in the EU requires more robust and traceable sharing of patient information between two or more parties.
PATIENT EMPOWERMENT
The patient should have the ultimate say on what kind of information about them is shared, from whom, to whom, by when, until when, for what purpose.
RIGHT TO BE FORGOTTEN
As long as within legal limits, consent management allows patients to purge information the system keeps about them.
THE BENEFITS OF IHP CONSENT MANAGEMENT
STANDARDS-BASED
IPP Consent Management utilizes OAuth for user authentication and authorization. HL7 FHIR is used as the clinical data model to contain the patient information.
DATA AND ACCESS AUDITING
Every access to the patient’s data is audited, allowing for improved intrusion detection.
AUTO ENFORCE CONSENTS
The system automatically loads consents applicable for the requesting user and patient record being accessed, and performs the redaction of information transparently.
TRY CONSENT
This feature allows a patient to see what information about him/her will be visible and what will be redacted based on a given consent record.

4. Technical Architecture
Healthcare
Provider
Patient
Admin
Custom authentication module
SMART-on-FHIR OAuth authenticator
FHIR Terminology Service
Patient $everything service
Patient data purge service
Other services (e.g. audit logging)
IHP FHIR Server
FHIR Store
Services Layer
Data Access Layer
Authorization Layer
Authentication Layer
REST API (FHIR, Custom)
Sharing taxonomy store
“Consent to share” authorizer
SMART-on-FHIR authorizer
Custom authorizer module
Customizable components:
FHIR terminology service – the IPP FHIR server has an implementation that covers most use cases for FHIR terminology services (i.e. code lookup and validation, valueset expansion). However, it can also talk to a more fully-featured external FHIR terminology service
Authentication layer – out-of-the-box support is based on OAuth/OpenID using a customized version of the CloudFoundry User Account and Authentication (UAA) server. This is paired with SMART-on-FHIR identity scope checks to tie the particular OAuth user to his/her record in the FHIR server. A Service Provider Interface (SPI) is provided wherein clients can implement their own custom authentication mechanism and have them loaded by the FHIR server upon startup for use.
Authorization layer – out-of-the-box support is based on SMART-on-FHIR clinical scope identity checks + a pre-built module focused on “consent to share” semantics for sharing of patient information. A SPI is provided wherein clients can implement their own custom authentication mechanism and have them loaded by the FHIR server upon startup for use.
FHIR server’s default consent management module is only focused on enabling patient information to be shared between two parties. It does not cover nor provide rules to restrict updates to the data in the FHIR server (including who gets to update patient’s data).
SMART-on-FHIR provides restrictions regarding what a user is allowed to access (i.e. which specific resources can be read or written to). However, it does not do fine-grained access control (e.g. it only checks that a practitioner is allowed to read or write to all Observation resources, but not that the Observation resource has to belong to a patient for which the practitioner has seen or is the care provider).
Technology Stack:
FHIR Store – IPP FHIR server supports ArangoDB, Cassandra and Postgres.
Application Layer – IPP FHIR server utilizes SpringBoot framework running as a microservice.
Deployment – Docker and Kubernetes are used for deployment and management of FHIR server instances.
Infrastructure/Platform – primarily deployed in Amazon Web Services (AWS), but can be deployed to other cloud providers or on-prem as it has no technological dependencies on any one cloud provider.
OAuth/OpenID application server – CloudFoundry UAA server
Out-of-the-box component
Legend:
Customizable component

5. CONCEPTS

6. THE DIFFERENT TYPES OF CONSENT MANAGEMENT USERS
SITE ADMIN
Administrator of the Consent Management application. Able to create organization, physician and patient accounts as well as manage application settings.
ORGANIZATION
This includes institutions, hospitals, clinics, places, etc. that provision health-related services to one or more patients.
PHYSICIAN
Individuals who are directly or indirectly involved in the provisioning of care to a patient. They may be affiliated by one or more organizations.
PATIENT
An individual receiving care or other health-related services from an organization and/or physician.
As per current implementation, anyone will be treated as an admin if they have a specifically-named scope from their access token (e.g. myadmin). The name of this scope is configurable.

7. WHAT MAKES A VALID CONSENT MANAGEMENT USER?
Example access_token response: {
"access_token" : "0a c4f21aeb5b0cd857a2a0c",
"token_type" : "bearer",
"expires_in" : 43199,
"scope" : "openid profile patient/Patient.* patient/Observation.read",
"jti" : "0a c4f21aeb5b0cd857a2a0c“,
“id_token" : “aa.bb.cc“ }
ASSIGNED SCOPES
Every user must be assigned OAuth and SMART-on-FHIR scopes
ACTIVATED OAUTH ACCOUNT
Consent Management will not recognize a user until they have a valid and activated OAuth user account
Example UserInfo response: {
"user_id" : "6368d10d-ae5e-404e-8ca6-313efef7f8e3",
"user_name" :
"name" : “Bob Joe",
"given_name" : “Bob",
"family_name" : “Joe",
"phone_number" : " ",
" " :
" _verified" : true,
"previous_logon_time" : null,
"sub" : "6368d10d-ae5e-404e-8ca6-313efef7f8e3“,
“profile" : “ }
Do we need to create a dedicated FHIR record in FHIR server to tie to the OAuth user?
A: No. If the FHIR server will only ingest and contain data from one source (e.g. hospital), then there’s no need to create separate FHIR records to link to these OAuth users.
However, when handling data from multiple providers, a dedicated FHIR record is recommended and linkages to the FHIR record and same records from the providers be set in the FHIR server. This is to enable use cases such as “give me all the patient information for Patient A across all the information we have from some or all hospitals.”
LINKED TO FHIR SERVER RECORD
All users except site admin must have a corresponding record in the FHIR server

8. This exists… … we want to take it a step further

9. CONSENT IS AN EVER CHANGING THING
Patient desires shift
Care teams change shape
Regulations alter access permissions
Clients have a real and pressing need – which is getting more pronounced with the expansion of interoperability
We have a distinct opportunity to create fuller consent capabilities:
As a Service; and
As a Product.
This is globally applicable, with use cases in Health, Public Service, Life Sciences, CMT, and Financial Services

10. Well thought out, existing logic
ADDITIONAL CONSENT FUNCTIONALITY TO BE ADDED
Well thought out, existing logic
Based upon real world experience and client needs
Expands RBAC to include Legitimate Relationships and Sealed Envelopes
Leverages existing Consent to Data Sharing
Ready to be reviewed and codified

11. THE NEXT STEP
Expand existing consent functionality to include broader data access logic (previous slide)
Extend consent decisions to be held within distributed ledgers (Blockchain) functionality
Create containerized product which can be deployed within client infrastructure
Create a Consent Platform which can be utilized by multiple clients and/or tenants

12. THE ASK