The Patient Choice Technical Project
Dataset Considerations Candidate Standards Mapping Companion Document
April 12th, 2016
Table of Contents
Title
Slide
Introduction to detailed mapping and approach
3
High-Level Findings
11
Candidate Standards Examples
2
Introduction to detailed mapping and approach
3
Consent Directive Type Scale
From “No to All” Patient Choice
•
No consent: Health information of patients is automatically included—patients
cannot opt out;
•
Opt-out: Default is for health information of patients to be included
automatically, but the patient can opt out completely;
•
Opt-out with exceptions: Default is for health information of patients to be
included, but the patient can opt out completely or allow only select data to be
included;
•
Opt-in: Default is that no patient health information is included; patients must
actively express consent to be included, but if they do so then their information
must be all in or all out; and
•
Opt-in with restrictions: Default is that no patient health information is made
available, but the patient may allow a subset of select data to be included.
•
Patient Choice: There is no default policy imposed by institution
Patient Choice Data Requirements
Candidate Standards Spreadsheet
Along the Rows - 4 Use Case Data Requirement Tables:
• Consent Location Query – Find Metadata
• Consent Location Response – Return Metadata
• Consent Directive Query – Request Consent Directive
• Consent Directive – Content of Returned Consent Directive
Patient Choice Data Requirements
Candidate Standards Spreadsheet
Across the Columns: 5 Candidate or Affiliated Standards:
• BPPC [IHE Basic Patient Privacy Consent]
• APPC [IHE Advanced Patient Privacy Consent
• HL7 version 2 Consent Segment [Chapter 9 Medical Records]
• HL7 Consent Directive CDA Implementation Guide
• HL7 FHIR Consent Directive profile on Contract Resource
Consent Location Query Map
Section 13.1
Table 19
Data Element
Data Element Description
Consent
Location
Query
CBPPC
o
m
m
Requester uses
Registry Query for
Consent
Required for HIE
and Source patient
id
Patient Identifier
Identifier for the patient who is the subject
of the consent
Patient Name
Name of the patient who is the subject of the May
consent
Administrative Gender
Female/ Male/ Unknown
May
Patient Date of Birth
Birth date of the patient
May
BPPC - Basic Patient Privacy
Consent
APPC - Advanced
V2 Chapter 9 Consent
Patient Privacy Consent
To know if a specific patient
has acknowledged a specific
Patient Privacy Consent Policy,
ClinicalDocument/recordTarge Likely Required
t/patientRole/id. CDA
supports 1..* PatientRole ids.
The XDS Affinity Domain
patient ID can be mapped from
the patientRole/id element
using transactions from the ITI
PIX or PDQ profiles.
*XDSDocumentEntry. patientId
- 3.18.4.1.2.3.7.1
FindDocuments
http://www.ihe.net/Technical
_Framework/upload/IHE_ITI_T
F_6-0_Vol2a_FT_2009-0810.pdf
Patient Name is optional in
Likely May
CDA and in PCC, which BPPC is
based on, but required on CCDA General Header, which is
likely the base standards upon
which BPPC metadata will be
drawn.
Patient gender is optional in
Likely May
CDA and in PCC, which BPPC is
based on, but required on CCDA General Header, which is
likely the base standards upon
which BPPC metadata will be
drawn.
Patient Date of Birth is
Likely May
optional in CDA and in PCC,
which BPPC is based on, but
required on C-CDA General
Header, which is likely the
base standards upon which
BPPC metadata will be drawn.
Required
CDA Consent Directive
FHIR ConsentDirective
Required
ConsentDirective.subject
query
Required
Optional
Required
7
Consent Location Response Map
Section 13.2
Table 20
Consent
Location
Response
Data Element
Data Element Description
C
o
Required
Consent ID
The unique identifier associated with the
consent directive
Patient Identifier
Identifier for the patient who is the subject
of the consent
Patient Name
Name of the patient who is the subject of the
consent
Consent Originator ID
Unique identifier for the organization that is Yes
responsible for the consent
Consent Originator
Organization
Name of the organization that is responsible Indirectly
for the consent
Consent Directive Location
Identifier or other information that will
allow the requester to determine where to
send the query for the consent directive
Required
Denial Code
An indicator that the query recipient is
unable to respond to the query
T
h
e
c
BPPC
XDSDocumentEntry.uniqueId:
This value shall be the
ClinicalDocument/id in the HL7
Required
XDSSubmissionSet.sourceId – a
repository may choose to
accept submissions only from
Map from
Consent Directive Location is
returned based
8
Consent Directive Query Map
9
High-Level Findings
11
General Points about Findings
• All more/less support core elements of Consent Directives[CD]:
» Patient, PHI Custodian, CD Requester, PHI Requester, PHI, Purpose of Use,
Status [active/revoked], restrictions, exceptions, and handling instructions
• All can be more/less well transformed into the others with some
semantic loss
• All but FHIR [still under development] are used today within the HIT
ecosystems for which they were designed
• However, the boundaries of those ecosystems are rapidly dissolving,
which makes inter-standards interoperability increasingly important
IHE Basic Patient Privacy Consent [BPPC]
• High adoption rate by XDS HIEs – but likely little adoption elsewhere because
architecturally specific
• Policies are unstructured legal agreements specific to an Affinity Domain,
but may be agreed to for Cross Affinity Domain exchanges
• BPPC Enforcement includes configuring HIE Actors to comply with Domain
Patient Privacy Policy obligations, refrains, purposes of use, authorization
restrictions, and display of Privacy Marks
• However, these Domain Privacy Policies are very terse, unstructured legal
rules represented as OIDs
» A BPPC Consent Directive may contain 1..* policy OIDs
» OIDs are not directly computable or adjudicatable
» Implementers assign Access Control Rules by hard-coding policy rules to ACS
authorization decision and enforcement mechanisms
» Number of discrete policies are limited to reduce permutations on the ACS
decision and enforcement requirements
IHE Basic Patient Privacy Consent [BPPC]-cont.
• XD* ebXML Metadata “slots” [aka “fields, elements] are populated with CDA R1
Header data through transform as well as information from local provider and
patient directories
• CDA limits proper modeling – i.e., treated like a clinical episode instead of an
agreement
• Most Document retrievers and disclosers typically do not retrieve a patient’s
BPPC
» Requesters only check XDS metadata with Patient’s list of Domain patient privacy
policy OIDs to make decisions about whether to publish; retrieve; permit access,
use, disclosure
IHE Basic Patient Privacy Consent [BPPC]-cont.
• Downside: Metadata is privacy leaking – especially with DIRECT XDR or XDM –
» May indicate that patient sees substance abuse provider, admitted to substance
abuse facility, or agreed to disclosure of substance abuse information to authorized
requester
» Requester may not be authorized to see certain metadata
» BPPC recommended mitigation is to either segregate metadata or not include in HIE
due to limited ability to control access to the metadata
» Privacy leaks mitigated by HL7 Data Segmentation for Privacy by constraining XDS
and XDR metadata, but that solution has not been adopted for BPPC, APPC, or HL7
Consent Directive CDA
IHE Advanced Patient Privacy Consent [APPC]
Adoption Status:
• Under IHE/AHIMA development since late 2015
• On IHE BPPC roadmap for sometime
• Goal is to move to structured/computable patient privacy policies
» See IHE/AHIMA APPC Project Overview Jan. 2016
• Progress – APPC cochairs are actively involved in FHIR Consent Directive
development
• Upside – With uptake, would improve agility, interoperability of IHE
Consent Documents
• Potential Issues: Entrenched BPPC deployment and difference in
exchange patterns and enforcement mechanisms, IHE may not get
adoption rate – e.g., lack of uptake for FHIR XD* Document Reference for
metadata
HL7 Version 2 Consent Segment
• Adoption rate within and outside of Enterprise is not clear, but v2 isn’t
going away as the source of consent information that may be used to
populate interoperable Consent Directive standards
• Currently use is to push Consent Directive related to a Medical Record
within an Enterprise as well as the Enterprise “source of truth” for multiple
consent flags used in Orders, Admission, and Financial transactions
• Some HIEs may use as input to generation of CCDAs with appropriate
confidentiality codes
• With transforms, could be used to populate IHE, CDA, and FHIR Consent
Directives
HL7 V2 ADT Access Restriction Value [AVR]Segment
Patient privacy preferences may also
collected on admission in the ARV
segment along with Confidentiality
Code from other segments for
Access Control throughout the
enterprise, and includes:
•
Action Restriction Action Code:
Add/Insert, Delete, Update, No Change
•
Access Restriction Values: Specifies the
information to which access is restricted.
•
Access Restriction Reason Code: Used to
convey the reason for the restricted
access.
•
Special Access Restriction Instructions:
Used to specify instructions about the
release of information to family and
friends.
HL7 Consent Directive CDA IG
Upside
•
CD policy is encoded so can be computably processed and adjudicated using Rules
Engine
•
May include Rules Engine Language representation of policy using XACML, XRML,
ODRL, or other
•
Includes Security Labels assigned to Protected Information by Type for:
» Confidentiality
» Governing Policy
» Obligations
» Refrains
Downside
•
Same XD* metadata privacy leak risks
•
Same BPPC/APPC modeling issues – based on a Clinical Document not an
agreement
» Clinical ServiceEvent used to record Consent Directive Event with clinician
performer
•
Due to commitment to BPPC backward compatibility design principle
HL7 Consent Directive CDA IG
CDA limitations on representing CD Types
• CD CDA represents all types as LOINC Codes:
» 64292-6 Release of information consent
» 57016-8 Privacy policy acknowledgment Document
» 57017-6 Privacy policy Organization Document
• LOINC codes are less specific than ActConsentDirectiveType codes [e.g.,
Opt-out, Opt-in with restrictions], which should be used instead or in
addition to the LOINC codes
• CD CDA represents CD effective time as the effective time of a Clinical
ServiceEvent rather than the effective time of an agreement
HL7 FHIR Consent Directive
• Status – under development for September FHIR Ballot
• Potential Adopters include DAF and SDC in US, and possible as the structured
content for IHE APPC
• Designed to support BPPC/APPC/v2/CDA Consent Directive data elements in
line and/or as Attachments – i.e., backward compatible to other major Consent
Directive specifications
• Attachment can be scanned paper Consent Directive Form and the Legal basis
for the ConsentDirective – e.g., a statutory citation [42 CFR Part 2
Confidentiality provisions], a Notice of Privacy Practices, or a BPPC set of
Patient Privacy Policies
• Supports Digital and Wet Signature as well as delegation/countersigning
• FHIR ConsentDirective.terms enable specification of restriction and exception
rules
HL7 FHIR Consent Directive
• FHIR Consent Directive is only one component in the FHIR Privacy Consent
Directive Implementation Guide, which is slated to include a FHIR Privacy
Consent Questionnaire/Questionnaire Response.
• A Patient’s FHIR Privacy Consent Questionnaire Response is a Patient Friendly
rendering of the choices allowed under a Consent Directive scheme
• Used to populate the interoperable/computable FHIR Consent Directive, which
is what the Access Control Systems use to decide and enforce patient choice
• May be the right place to capture v2 Consent elements such as use of
interpreter and additional information to inform patient consent.
HL7 FHIR Consent Directive
• Unlike other Consent Directive [CD] standards, designed as a Contract
rather than a Clinical Statement, which makes affinities to real world
concepts about CDs easier to represent, e.g., effective time is directly
related to the CD and any CD terms.
• Makes Provider Organization the Grantee, which is asking the Patient
[Grantor] to either consent or acknowledge the Organization’s privacy
policy.
• Easier to specify whether PHI as a whole is the governed by the entire CD,
or whether some subset of PHI is governed as a whole or in a CD restriction
or exception term.
Candidate Standards & Pilots
• Pilots may be interested in scenarios that involve 1..* Candidate
Standards.
• A HIE may want to use FHIR Consent Directive to carry BPPC elements
“in line” and/or as an URI/Attachment.
• A HIE might demonstrate how v2 Consents are used to populate a CDA
Consent Directive, and then how the CDA Consent Directive can be
mapped into a FHIR Consent Directive “in line” and/or as an
URI/Attachment.
• FHIR Connectathon participants might simply demonstrate the use of
FHIR Consent Directive in a Track [Use Case] that reflects possible
implementations.
Candidate Standards Examples
25
IHE Basic Patient Privacy Consent [BPPC]
XDS Metadata:
Consent Document
Ack of 9.8.7.6.5.4.3.2.1
Structured and Coded CDA Header
Patient, Author, Authenticator, Institution,
Time of Service, etc.
St r u c t u r ed Co nt ent wi th c od ed s ec t i on s :
•Scanned Document details
•Privacy Consent details
•Policy 9.8.7.6.5.4.3.2.1
Base64 encoded
Graphical representation of consent with wet signature
26
IHE Advanced Patient Privacy Consent [APPC]
27
IHE BPPC/APPC/CDA/FHIR + DocumentReference Consent Directive Exchange
Interactions
Document Source
XDS Actors and
transactions
Document Consumer
Document Source
XDR Transaction
Document Recipient
Portable Media
Creator
XDM Transaction
Portable Media
Importer
Content Creator
Share Content 
Content Consumer
28
HL7 CDA Consent Directive
29
30
Manage Electronic Privacy Policy (ePolicy)
FHIR Consent Directive
FHIR ConsentDirective is a profile on FHIR Contract Resource
• Based on foundational HL7 Privacy and Security ISO 2260 Privilege
Management and Access Control
• Underlying model is more attune to the policy structure of Consent
Directives vs. trying to use a Clinical Document structure
HL7 FHIR Consent Directive
33
HL7 FHIR Consent Directive
34
HL7 FHIR Consent Directive
35
FHIR BPCC
Example
FHIR BPPC Example
FHIR BPPC Example
FHIR BPCC
Example
Project Contact Information
OCPO-ONC Lead
Jeremy Maxwell
[email protected]
Project Coordinator
Johnathan Coleman
[email protected]
Project Manager
Ali Khan
[email protected]
Project Support
Taima Gomez
[email protected]
Staff SME
Kathleen Connor
[email protected]
Staff SME
David Staggs
[email protected]
38
Thank you for joining!
@ONC_HealthIT
@HHSONC