Download
1 / 12
130 likes | 251 Views
Privacy Architecture Considerations. Part 2: How Standards Support Policy. Kathleen Connor Fox Systems Inc. Role Based Access Control. IHE Basic Patient Privacy Consent Profile. RBAC Support 4 Opt-in / Opt-out. Masking Supports Conditional OPT-IN / OPT-OUT.
E N D
Privacy Architecture Considerations Part 2: How Standards Support Policy Kathleen Connor Fox Systems Inc
Role Based Access Control IHE Basic Patient Privacy Consent Profile
Masking Supports Conditional OPT-IN / OPT-OUT HL7 Shared Secret Message Model
Shared Secret supports Conditional Access that is time limited and may be revoked by the Patient
RBAC and Masking Issues • Mapping User Types to Roles • Defining Teams • Mapping Roles to Authorizations • Downstream application of consent parameters • Ontology of roles, authorizations, and consent parameters needed for computable interchange • Security mechanisms to support time limited, renewable, and revocable shared secret, e.g., scheduled change of key hash with patient ability to revoke key access
NHIN Support for Consent • Standards for electronic representation of Node consent policies and patient consents • Computable access to Node consent policies • Computable patient consent transmitted with associated PHI • Standards for computable negotiation of multiple node policies associated with a patient’s PHI
IHE BPPC Masking Use Case • An Affinity Domain may have jurisdictional or organizational policies that require support for more complex patient privacy consent policies. • These privacy policies may require that a patient explicitly consent to disclosure of protected or sensitive health information to specific entities. • To implement such policies using the BPPC profile, an Affinity Domain would include sufficiently explicit functional roles as well as contextual and user specific role information to support these policies. • For example, in a jurisdiction that requires explicit patient consent to disclose psychotherapy notes, the Affinity Domain would include a sensitivity marker for psychotherapy notes and may only permit access by the functional role (1) “Named entity”, where the named entity identifier must match the identifier of the named entity in the patient’s associated consent document associated with the patient’s health document; (2) An “unnamed entity” based on a time limited [i.e., time-bomb] and non-transferrable “shared secret key” supplied to the entity by the patient and authenticated by some algorithm the information in the patient’s associated consent document; or (3) An emergency provider who submits a “break the glass key” administered by the Affinity Domain that has an appropriate audit trail with documentation of the provider’s reason and context for use per Affinity Domain policy.
IHE BPPC Use Case cont. • The psychotherapy notes would be submitted to the XDS using the confidentiality code indicating that it is available only to these entities. • In addition to document type level sensitivity markers, e.g., psychotherapy notes, an Affinity Domain may support sensitivity markers for types of health information that might be included in documents of many types. • There may be sensitivity markers for any document that includes diagnosis, procedure, medication, location, or provider information which the patient believes may indicate that the patient has genetic, substance use, HIV/AIDs, mental health or other conditions, which the patient wishes to mask. • Another use for sensitivity markers is for victims of abuse who wish to mask all records containing their demographic information.
