Privacy & Security Maturity Model

Levels of MaturityMaturity Criteria

1 - All traffic between POS & HIM is encrypted using TLS- POS & HIM nodes are mutually authenticated at the device level.- Mirrored audits are collected between the HIM and infrastructure services whenever PHI is conveyed.

2 - Level 1 + - All traffic between all systems (POS, HIM & backing services) is encrypted using TLS.- All nodes are mutually authenticated at the device level- Audits contain the X.509 Subject field of the requesting party

3 - Level 2 + - POS systems are able to assert user identity, location and purpose of use to the HIM- Mirrored audits are collected between all parties (POS > HIM & HIM > Service)- POS systems are able to send relevant audits to central audit-repository- All audits contain the asserted user identity, location and purpose of use.

4 (a) - Level 3 + - POS systems are able to supply an appropriate “confidentialityCode” on XDS queries (POS acts as PDP)- POS systems are able to demonstrate correct interpretation of “confidentialityCode” in XDS responses (POS

acts as PEP)4 (b) - Level 4 +

- Infrastructure is capable of interpreting a filtering results (XDS Registry or HIM acts as a PEP/PDP)- Infrastructure is capable of maintaining a list of policy directives (HIM or other acts as a PIP)

Profile Speak

Maturity AT NA XUA BPPC BPPC + Enforcement

1 X* X

2 X X

3 X X X

4 (a) X X X X X*

4 (b) X X X X X

* - Partial compliance across entire infrastructure

Node Authentication (NA)

How it Works: NA

• All actors carrying PI over non-isolated network must implement

Get Documents

Challengew/PublicKey

Public Key

CRL?

X Enterprise User Assertion

• Provides a mechanism for asserting a user identity• Typically WS-SEC + SAML• Can be used on any WS-* transaction• The X-Service User may determine the contents of the identity assertion

X-Assertion Provider(clinic.com)

How it works: XUA

X-Service Provider

X-Service User

User Authentication

Provider

Document Consumer

Document Registry

Registry Stored Query(ITI-18)

Provide X-User Assertion (dsmith@clinic.com)(ITI-40)

Dr. Smithdsmith

EU

A /

Oth

er

Auth

: dsm

ith

Audit Repository

Get X

-Use

r Ass

ertio

n

for d

smith

Record Audit

(dsmith@clinic.com)

(ITI-20)

User:

dsmith?

XUA (ish) Alternatives

• For REST interfaces• Use IUA – Internet User Assertion

• Other options from POS <> HIM (which the HIM can map to XUA)• OAuth• JWT Tokens• WS-Trust based assertions• Any format which conveys “User” at “Clinic” querying “because”

Sample Purpose of Use Codes

• OSCAR uses this list as a POU source.• Just another vector used in the policy decision process

Code PurposeTREATMENT Treatment – Information will be used for treating the patientOPERATIONS Healthcare Operations – Used for record maintenancePSYCHOTHERAPY Use or disclosure of psychotherapy notesFAMILY Disclose to a family member or relativeEMERGENCY Patient is not able to give direct consent due to incapacity or an

emergencyREQUEST At the request of the patient.RESEARCH To perform one or more operations on information for conducting

scientific research.PRESENT Use and disclosure with the individual present.

BPPC?

• Basic Patient Privacy Constraints• Content & Enforcement Profile• Content = BPPC Consent Document

• CDA document documenting expression of consent• ITI TF Vol. 3

• Option = BPPC Enforcement Option• DOC source MUST populate confidentiality code with an acceptable policy.• DOC consumer MAY populate confidentiality code in query• DOC consumer MUST enforce any confidentialityCodes received (must not disclose documents carrying codes not understood)• DOC Registry may enforce confidentialityCode query parameter

• BPPC option implemented on DOC_SOURCE and DOC_CONSUMER roles• One or more “policies” are defined by the affinity domain (logically)

• “Share with Clinic A”• “Share with Project Y”

• (optional) Sources attach one or more policies to a shared file• Consumers apply the policy

• Based on current user roles• Based on current site

BPPCDuring Setup of an Affinity Domain

1.2.3.4

ID Name Policy Legalese

Share With Clinic A Clinic A Privacy Policy.PDF

1.2.3.5 Share With Project Y Project Y Privacy Policy.PDF

BPPC @ OpenHIE Maturity Level 4 (a) When Joining a POS to the HIE

PolicyConfig.xml

ID Name

1.2.3.4 Share With Clinic A

1.2.3.5 Share With Project Y

Doctors Allow: View, Import, Export, Disclose

Everyone Deny: View, Import, Export, Disclose

Not Configured (Everyone is Denied All Access Rights)

- Each POS configures their system to adhere to policies (application specific behavior)- Each POS must be validated prior to receiving their certificate from an HIE administrator / privacy officer

BPPC @ OpenHIE Maturity Level 4 (a)

John Smith1980-05-20123 Main Street WestHamiltonjsmith@myoscar.ca

1

John Smith1980-05-20123 Main Street WestHamiltonjsmith@myoscar.ca

0

John Smith1980-05-20123 Main Street WestHamiltonjsmith@myoscar.ca

211

1 @ MyOSCAR211 @ Clinic A

Share Extract Apply

Policy 1.2.3.4

Share Extract Apply

Policy 1.2.3.4

ITI-42

ITI-9

211 @ Clinic A0 @ Affinity Domain

ITI-18

PID: 0 @ Affinity DomainPolicy: 1.2.3.4

Policy.xml

BPPC @ OpenHIE Maturity Level 4 (a)

1. User wishes to share document2. User customizes content

A. IF CDA Extract: Content for export is selectedB. IF PDF / Blob : A PDF/A of the content is produced

3. (optional) User selects consent policies which apply to the document or a default is applied

4. (optional) User agreement with policy legalese is displayed and agreed to, ifA. user has never submitted a BPPC consent document for the selected policy(ies), orB. BPPC consent has expired

5. A PIX message is sent to resolve the local identifier to an enterprise identifier6. An XDS submission set containing the BPPC consent document is sent to the affinity

domain7. An XDS submission set containing the appropriate “confidentialityCode” entries and the

payload selected in #2 is sent to the affinity domain.

Sample Process

Maturity Level 4 (b)

• Very robust implementation• User identity is conveyed to infrastructure• Infrastructure (XDS registry / repository) consult PIP and enforce policies prior

to disclosure• Granular policies can be defined

• Only share with provider X• Only share in an Emergency• Only share Discharge Summaries if the purpose of use is for Treatment

OpenHIE Maturity Level 4 (b)

Share Extract Apply

Policy 1.2.3.4

Share Extract Apply

Policy 1.2.3.4

ITI-42

ITI-9

211 @ Clinic A0 @ Affinity Domain

ITI-18

Dr. X is asking:PID: 0 @ Affinity DomainPolicy: 1.2.3.4Purpose: TREATMENT

Policy.xml

Get Consent Policies

Assert I am Dr. XAssert I am using data for TREATMENTRequest Token

Apply Policies

PID: 0 @ Affinity Domain

PIP

OpenHIE Maturity Level 4 (b)

• Policy Information Point (PIP)• Could be a PHR or patient facing service

• Simplifies the BPPC policy list• Can be “Share with Stone Church”, or • “Share with my Family Health Team” … Which providers are in “Family Health Team” is deter

• Patient can easily modify consent access independent of XDS meta-data (i.e. document meta-data is always “Share With Family Health Team”)

• Could be a flat-file • Could be an administrative service like the HIM

What can I do at each maturity level?Objective 1 2 3 4a 4b

Identify which POS executed a particular query on a specific date/time * X X X X

Identify which records were disclosed to a POS system * X X X X

Identify which user accessed which patient record at a particular date/time X X X

Identify which clinic a particular user was operating in when they accessed a record

X X X

Block all users from accessing an entire patient profile (big on/off switch) X X

Block a specific user / clinic from accessing an entire patient profile * X

Block a specific user / clinic from accessing any one document * X

Block a specific user / clinic from accessing entire profile, except in case of emergency

* X

Centrally manage policy behaviors X

What do *we* (OpenHIE) have to do?Maturity Level GAP

1 - OpenHIE 1.0 compatible- Ensure that TLS (NA) and audit trail is setup “out of the box” on backing systems

2 - OpenHIE 1.0 can be configured to behave this way- Ensure that TLS is used between HIM and backing server- Ensure that POS systems send audits before they get their key

3 - HIM would have to be able to audit the server side of the POS audit- Ensure HIM can pass XUA soap headers through routes / mediators

4 (a) - Ensure HIM enforces “confidentialityCode” is passed from POS or a default is supplied

4 (b) - One of:- Implement HIM mediator to apply PIP policies (in a HIM is PDP/PEP model)- Install an XDS registry which can acts as a PDP/PEP (HIEOS for example)

- (Optional) Implement a fancy PIP management system (or use a flat file)

What do our *POS* vendors have to do?Maturity Level GAP

1 - Ensure client TLS certs can be installed- Ensure client can “speak” XDS/PIX or some transformable format

2 - Nothing more than Level 1

3 - Ensure client can send audits in some form to the HIM- Ensure client can convey : User ID, Clinic/Organization, and POU to the HIM in some

form4 (a) - Ensure client can add allowed consent policy filter to document filter (if HIM can’t

perform this function)- Ensure client adheres to returned policies identified in the response message

4 (b) - Nothing – infrastructure enforces policy- (optional) Client can implement a “supply other POU” functionality to do BTG