BPPC Privacy Policy Definition for Connectathon Testing
Introduction:
The Connectathon Managers set policy for the XDS Affinity Domain(s) at the Connectathon, including these 2 BPPC-related items:
1.
They determine the codes accepted by the Registries: http://ihexds.nist.gov:12090/xdsref/codes/codes.xml…including valid
confidentialityCode values to include in XDS metadata, and the meaning associated with those codes. For the
Connectathon these values are defined:



2.
<Code code="N" display="Normal" codingScheme="2.16.840.1.113883.5.25" />

Normal confidentiality rules (according to good health care practice) apply. That is, only authorized individuals with a legitimate medical or
business need may access this item. Documents created by Doc Sources and PMCs should contain this code unless a test indicates
otherwise.
<Code code="R" display="Restricted" codingScheme="2.16.840.1.113883.5.25" />

Restricted access, e.g. only to providers having a current care relationship to the patient. For the Connectathon, an “R” document is only
created when a test instructs a Source to do so.
<Code code="V" display="very restricted" codingScheme="2.16.840.1.113883.5.25" />

Very restricted access as declared by the Privacy Officer of the record holder. For the Connectathon, a “V” document is only created when a
test instructs a Source to do so.
They define a Patient Privacy Consent Policy for testing the BPPC profile and BPPC-related options in other profiles and the
sharing rules associated with that policy. For the Connectathon this is an artificial policy, but it creates conditions which
make BPPC testable. Details follow.
Connectathon Affinity Domain Privacy Consent Policy:
The Connectathon Privacy Consent policy has two components:
1.
By default, in this Connectathon affinity domain:
 All patients agree to always share documents with a confidentialityCode of “N” (Normal). It is not possible to
“OPT-OUT” of sharing Normal documents in this affinity domain.
 Documents with a confidentialityCode of “R” (Restricted) are not shared **unless** a patient explicitly “Opts in”,
by submitting a BPPC Acknowledgement Document for “OPT-IN” (via a Content Creator in the BPPC Profile; see
section below).
 Documents with a confidentialityCode of “V” (Very Restricted) are never shared. This is an artificial condition that
enables testing.
2.
In the Connectathon Affinity Domain, the following policy a Patient may optionally choose to “OPT-IN” to this policy:
Connectathon Affinity Domain
Patient Privacy Consent Policy
In this Connectathon Affinity Domain, healthcare data is contained in exclusively in
documents shared via the XDS.b, XDR, or XDM profiles.
The Patient agrees to share documents with a confidentialityCode of “R”.
The confidentialityCode is contained in a document’s XDS metadata.
3. For the Connectathon “XUA_Policy_Test”, we state that “InternetProtocol” is an invalid authentication method in our affinity
domain.
BPPC Content Creators at the Connectathon are required to enable a Patient to “OPT-IN” to this policy to enable access to his/her
“Restricted” documents

If the Patient chooses to “OPT-IN” the BPPC Content Creator creates a Patient Privacy Consent Acknowledgement'
document with content as specified in ITI TF-2:5.1.2 (with no scanned doc) or ITI TF-2:5.1.3 (with scanned doc)
o There are specifications in those sections for the content of that document. For Connectathon testing for
XDSDocumentEntry.eventCodeList, you will use the “OPT-IN” code for this affinity domain. See
http://ihexds.nist.gov:9080/xdsref/codes/codes.xml. The value is

<Code code="1.3.6.1.4.1.21367.2006.7.108" display="OPT-IN" codingScheme="Connect-a-thon

There is no “OPT-OUT” in the Connectathon affinity domain
eventCodeList" />
In summary: Relationship between confidentialityCode & Privacy Consent Policy
***At the Connectathon***:
 Documents with a confidentialityCode of “N” are always shared
 Documents with a confidentialityCode of “V” are never shared
 Documents with a confidentialityCode of “R” are only shared if the patient has submitted an “OPT-IN” Patient
Privacy Policy Consent Document (via a BPPC Content Creator). Otherwise, they are not shared.
Actors that support “Basic Patient Privacy Enforcement”
1. XDS.b/XDR Source or XDM/PMC, at the Connectathon…
a. You will be asked to create 3 documents, one with each of the confidentialityCodes (N, R, V). In a clinical setting,
you might have to configure a specific policy to trigger a certain code. At the Connectathon, the condition for
creating docs with different codes is determined by a Connectathon test that tells you to create one or the other.
2. XDS.b Doc Consumer, at the Connectathon…
a. For Stored Query or Retrieve Doc Set, you will always provide access to (eg enable the user to see query results
with) documents with a “N” confidentialityCode.
b. For Stored Query or Retrieve Doc Set, you will never provide access to documents with a “V” confidentialityCode
(you are enforcing our Connectathon Affinity Domain Policy).
c. **IF** the Consumer has the capability of querying the Registry to determine that the patient has submitted an
“OPT-IN” Consent document, then you may provide access to documents with “R” confidentialityCode. Otherwise,
you will never provided access to these documents.
3. XDR Doc Recipient, at the Connectathon…
a. This actor does not have IHE transactions (query, retrieve) that enable us to test this definitively. The Recipient
will demonstrate for the Connectathon monitor how it configures product capabilities (eg user access controls,
business rules, other…) to enforce the policy for access to documents with confidentialityCode of N, R, V.
Consumers that support “Basic Patient Privacy Enforcement”
1. See ITI TF-2a: 3.18.4.1.3.8
a. Per IHE BPPC, the class code is <Code code="57016-8" display="Privacy Policy Acknowledgement
Document" codingScheme="2.16.840.1.113883.6.1" />
b. Per Connectathon policy, the eventCodeList is <Code code="1.3.6.1.4.1.21367.2006.7.108" display="OPT-IN"
codingScheme="Connect-a-thon eventCodeList" />