Privacy & Security Maturity Model

Levels of Maturity MaturityCriteria 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 MaturityATNAXUABPPCBPPC + Enforcement 1X*X 2XX 3XXX 4 (a)XXXXX* 4 (b)XXXXX * - Partial compliance across entire infrastructure

Node Authentication (NA)

How it Works: NA All actors carrying PI over non-isolated network must implement Get Documents Challenge w/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 (ITI-40) Dr. Smith dsmith EUA / Other Auth: dsmith Audit Repository Get X-User Assertion for dsmith Record Audit (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 CodePurpose TREATMENTTreatment – Information will be used for treating the patient OPERATIONSHealthcare Operations – Used for record maintenance PSYCHOTHERAPYUse or disclosure of psychotherapy notes FAMILYDisclose to a family member or relative EMERGENCYPatient is not able to give direct consent due to incapacity or an emergency REQUESTAt the request of the patient. RESEARCHTo perform one or more operations on information for conducting scientific research. PRESENTUse 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

BPPC During Setup of an Affinity Domain IDNamePolicy Legalese Share With Clinic AClinic A Privacy Policy.PDF Share With Project YProject Y Privacy Policy.PDF

OpenHIE Maturity Level 4 (a) When Joining a POS to the HIE PolicyConfig.xml IDName Share With Clinic A Share With Project Y DoctorsAllow: View, Import, Export, Disclose EveryoneDeny: 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

OpenHIE Maturity Level 4 (a) John Smith Main Street West Hamilton 1 John Smith Main Street West Hamilton 0 John Smith Main Street West Hamilton 211 MyOSCAR Clinic A Share Extract Apply Policy ITI-42 ITI-9 Clinic A Affinity Domain ITI-18 PID: Affinity Domain Policy: Policy.xml

OpenHIE Maturity Level 4 (a) 1.User wishes to share document 2.User customizes content A.IF CDA Extract: Content for export is selected B.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, if A.user has never submitted a BPPC consent document for the selected policy(ies), or B.BPPC consent has expired 5.A PIX message is sent to resolve the local identifier to an enterprise identifier 6.An XDS submission set containing the BPPC consent document is sent to the affinity domain 7.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 ITI-42 ITI-9 Clinic A Affinity Domain ITI-18 Dr. X is asking: PID: Affinity Domain Policy: Purpose: TREATMENT Policy.xml Get Consent Policies Assert I am Dr. X Assert I am using data for TREATMENT Request Token Apply Policies PID: 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? Objective1234a4b Identify which POS executed a particular query on a specific date/time*XXXX Identify which records were disclosed to a POS system*XXXX Identify which user accessed which patient record at a particular date/timeXXX Identify which clinic a particular user was operating in when they accessed a record XXX Block all users from accessing an entire patient profile (big on/off switch)XX 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 behaviorsX

What do *we* (OpenHIE) have to do? Maturity LevelGAP 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 LevelGAP 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 form 4 (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