PCC TF-1/BPPC

BPPC Integration Profile

The document sharing infrastructure provided by XD* allow for the publication and use of clinical documents associated with a patient. The XDS/XDR system requires that the Affinity Domain create and agree to a single policy (See IHE-ITI Vol 1:Appendix L). The Affinity Domain Policy is enforced in a distributed way through the inherent access controls of the systems involved in the Affinity Domain. This profile will use terms consistent with ISO 22600 - Privilege Management and Access Control (PMAC), but is not restricted to systems that implement PMAC. The systems involved in XDS are expected to support sufficient Access Controls to carry out the Policy of the Affinity Domain.

Today this single Affinity Domain Policy restriction means that much of the useful data is not entered into the XDS, or that the access to this data is too liberally allowed. This profile allows for the Affinity domain to have a small number of privacy consents. This allows for more flexibility to support some patient concerns, while providing an important and useful dataset to the healthcare provider.

Healthcare providers utilize many different sets of data to carry out treatment, billing, and normal operations. This information may include patient demographics, contacts, insurance information, dietary requirements, general clinical information and sensitive clinical information. This information may be published to XDS as independent documents under different privacy consent policies.

Healthcare providers in different functional roles will have different needs to access these documents. For example, administrators may need to be able to access the patient demographics, billing and contact documents. Dietary staff will need access to the dietary documents but would not need access to insurance documents. General care providers will want access to most clinical documents, and direct care providers should have access to all clinical documents.

This profile provides a mechanism by which an affinity domain can create a basic vocabulary of codes that identify affinity domain privacy consent policies with respect to information sharing. Each privacy consent policy should identify in legal text what are the acceptable re-disclosure uses, which functional roles may access a document and under which conditions. Each privacy consent will be assigned a unique XDS Affinity Domain wide OID by the administration of the XDS Affinity Domain with care to respect any inheritance of previous privacy consent policies. Future profiles may include structured and coded language that can be used to support dynamic understanding of the patient's directives (see HL7 and OASIS).

Basic Patient Privacy Consent Use-Cases

This section gives examples of some possible patient privacy consent policies and how the systems publishing documents and using documents might act. This is an informative section and should not be interpreted as the only way to implement the BPPC profile.

Wet Signature

Big Hospital has not yet fully digitized their patient consents process. They have a paper document that describes their Privacy Consent Policy. In our example this Privacy Consent Policy will be referenced as policy 9.8.7.6.5.4.3.2.1. Our example is ridiculous, but points out that the content of the policy is legal text, and that we provide no structured or coded way to interpret. This policy looks like:

It is the policy of Big Hospital that when a patient signs a consent that says "It's OK" then big hospital can do anything it wants with the patient's data.

Big Hospital has the patient acknowledge this consent through ink on paper. This act produces the Patient Privacy Consent, For Example:

Sample Consent: by A. Patient. It's OK

This acknowledgement is captured according to the XDS-SD profile, with the additional parameters specified in the BPPC profile also applied to the CDA wrapper. This is registered with the XDS as proof that the patient has consented to policy 9.8.7.6.5.4.3.2.1. This acknowledgement will have its own OID as any document registered in XDS will have, but this instance OID is not further used.

This example is available on the IHE wiki for educational purposes.

If the hospital wants to further provide authenticity protections they may apply a DSG digital signature to the whole package with the appropriate purpose and signed by an appropriate signing system/person.

The following shows this graphically:

Implied Consent vs Explicit Consent

This profile supports both Implied Consent as well as Explicit Consent environments. In order to provide a profile with global appeal we have supported both environments. In an implied consent environment a Document Consumer will not find an instance of a Patient Privacy Consent document in the XDS, as capturing the act of consenting would not be required. This may be true in an Explicit Consent environment as well in cases where getting the explicit consent is delayed due to medical reasons (e.g. emergency).

In an implied Consent environment, the clinical documents submitted to the XDS would need to be marked with the general use consent, where other documents may have additional explicit consents.

Electronic Patient Consent

In this use case we move forward to a XDS Affinity Domain where the patient has a unique Public Certificate. This use case has the patient digitally signing the consent. In this case we don't capture a wet signature. For this example we include the PDF of the consent text, and this is what the patient signs. The patient's digital signature is captured using the IHE Digital Signature (DSG) profile, as shown below:

bppc1.png

Administrative Use

Healthcare providers utilize many different sets of data to carry out the treatment, billing, and normal operations. When a patient presents, often the patient must fill out volumes of information used for patient demographics, contacts, and insurance.

For this example we might illustrate a registration system that captures a scanned image of the patient's insurance card. This scanned image can be submitted to the XDS using the confidentiality code indicating that it is available for administrative uses. This registration system could additionally capture the typical demographics and such in a form of coded clinical document that is also published as available for administrative use. Both of these documents don't have clinical information and thus wouldn't need to be restricted to direct care providers.

Now that we have shown how this information can be captured. We can see cases where the patient presents at a different clinic in the same XDS Affinity Domain. The administrative staff can now query the XDS and simply confirm that the information is the same.

Clinical Support Staff Use

The patient when staying for a few days might have special dietary needs based on their conditions. These dietary needs could be documented in the XDS and marked as for clinical support staff. This document could be accessed by the dietitian when preparing the meals.

Mixed Patient Privacy Consents

As can be seen by the use-cases shown already over time an XDS Affinity Domain may have a mixture of implied consent, wet signature consents and patient digital signature consents. The XDS Affinity Domain will also have multiple generations of patient consents.

Policies in an environment with comprehensive access controls

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. The BPPC profile provides a starting point for implementing these types of privacy consent policies, but does not explicitly specify how additional information needed to enforce the policy would be conveyed.

For example, in a jurisdiction that requires explicit patient consent to disclose psychotherapy notes:

1. The Affinity Domain would define sufficiently explicit functional roles as well as contextual and user specific role information to support these policies in the consent provided.
2. 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 and non-transferrable "shared secret key" supplied to the entity by the patient and authenticated by some algorithm the informaiton 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.

The psychotherapy notes would then 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 might also 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.

Privacy Access Policies (Informative)

One possible implementation may have a collection of policies and sensitivity markers form an access control matrix. A simple access control matrix is shown in Table 5.2 1.

Access Control Policies

Sensitivity Functional Role	Billing Information	Administrative Information	Dietary Restrictions	General Clinical Information	Sensitive Clinical Information	Research Information	Mediated by Direct Care Provider
Administrative Staff	X	X
Dietary Staff		X	X
General Care Provider		X	X	X
Direct Care Provider		X	X	X	X		X
Emergency Care Provider		X	X	X	X		X
Researcher						X
Patient or Legal Representative	X	X	X	X	X

The matrix can be sliced vertically. By slicing the matrix vertically (by sensitivity marker), a single patient consent policy (aka. sensitivity marker) vocabulary can be established. This vocabulary must then be configured in the XDS Affinity Domain.

Using the example above, the privacy consent policies would be.

Privacy Consent Policy	Description
Billing Information	May be accessed by administrative staff and the patient or their legal representative.
Administrative Information	May be accessed by administrative or dietary staff or general, direct or emergency care providers, the patient or their legal representative.
Dietary Restrictions	May be accessed by dietary staff, general, direct or emergency care providers, the patient or their legal representative.
General Clinical Information	May be accessed by general, direct or emergency care providers, the patient or their legal representative.
Sensitive Information	May be accessed by direct or emergency care providers, the patient or their legal representative.
Research Information	May be accessed by researchers.
Mediated by Direct Care Provider	May be accessed by direct or emergency care providers.

The access control matrix can also be sliced horizontally by functional role. This requires that a separate vocabulary for document Privacy Consent Policy be configured in the XDS Affinity Domain.

Privacy Consent Policy	Description
Administrative Staff	May access documents that describe their sensitivity with the Billing Information or Administrative Information code.
Dietary Staff	May access documents that describe their sensitivity with the Administrative Information or Dietary Restrictions codes.
General care providers	May access documents that describe their sensitivity with the Administrative Information, Dietary Restrictions or General Clinical Information codes.
Direct care providers	May access documents that describe their sensitivity with the Administrative Information, Dietary Restrictions, General Clinical Information, or Sensitive Clinical Information codes.
Emergency care providers	May access documents that describe their sensitivity with the Administrative Information, Dietary Restrictions, General Clinical Information, or Sensitive Clinical Information codes.
Researchers	May access documents that describe their sensitivity with the Research Information code.
Patient (or legal representative)	May access documents that describe their sensitivity with the Administrative Information, Dietary Restrictions, General Clinical Information, or Sensitive Clinical Information codes.

Other divisions of the access control matrix are possible, so long as a Privacy Consent Policy covers each cell granting access in the matrix.

References

The following list of references is provided as good references to understand the terms and concepts presented here. These references are not required by this profile.

• ISO/TS 21298 "Health informatics – Functional and structural roles".
• ISO/TS 22600 "Health Informatics – Privilege Management and Access Controls".
• CEN prEN 13606-4 "Health informatics — Electronic health record communication — Part 4: Security requirements and distribution rules"

Creating Privacy Consent Policies

A Privacy Consent Policy shall identify who has access to information, and what information is governed by the policy (e.g., under what conditions will a document be marked as containing that type of information). The XDS Affinity Domain shall publish privacy Consent Policies. The mechanism for publishing these policies is not described by this profile. The Privacy Consent Policies written by the XDS Affinity Domain must be able to be implemented by the technologies in all of the systems that have access to the XDS Affinity Domain. This means that the Privacy Consent Policies must be created with great care to ensure they are enforceable.

The implementation of Privacy Consent Polices under this profile makes it strongly advisable that policies describe under what situations a functional role shall have access to information, and do not include situations in which a functional role is not granted access. Take care when writing access control policies. The two policy statement examples below illustrate the problem.

1. A Researcher may >>only<< access documents that describe their sensitivity with the Clinical Trial 1 code.
2. A Researcher may >>only<< access documents that describe their sensitivity with the Research Project 1 code.

The first policy grants access to a researcher to one class of documents (those marked with the Clinical Trial 1 code), and due to the word "only", effectively revokes access to all other documents. The second policy does the same thing (for Research Project 1), and revokes access to all other documents. These two policies cannot be applied at the same time, as they are incompatible with each other. The solution is to strike the word >>only<< and thus the two Privacy Consent Policies are able to be aggregated.

An XDS Affinity Domain may have legacy documents that were published prior to all systems supporting the BPPC Profile, and thus will have confidentiality codes not defined under the BPPC Profile (e.g. For example, "N" from 2.16.840.1.113883.5.25). The XDS Affinity Domains will need to provide Privacy Consent Policies for granting access to documents that use these non-BPPC confidentiality code values.

Affinity domains should also determine their strategy for addressing the changing of Privacy Consent Policies and the policy vocabularies.

Finally, Privacy Consent Policies used within an XDS Affinity Domain will very likely be different than those used with the XDM or XDR Profiles. The patient may provide a consent given to share information on media to the provider creating the media for specific use, rather than for more general sharing within an XDS Affinity Domain. When transferring information that originated in an XDS Affinity Domain to media (XDM), the Privacy Consent Policies found in the XDS Affinity Domain might be changed during the publication process. There are also differences in the sensitivity that should be considered for consents shared on media or transmitted through XDR and those shared in an XDS affinity domain. See the section 5.10 Security Considerations later in this volume for more details.

Implementation of Access Control

Consumers of documents that implement this profile are required to enforce access control based on the policies described by the Affinity Domain. This is because the consumers of the documents are best aware of the functional role, how the data will be used, the relationship between provider and patient, the urgency of access, etc. The mechanism by which consumers associate individual users with functional roles is not within the scope of this profile. However it does allow for mechanisms to be used that take into account the structural role of the user, their association with the patient, the functional role that they are assigned with the session in which they are accessing data, and the declared sensitivity of the data being protected.

Actors/Transaction

There are two actors in the BPPC profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile. A Document Source or a Portable Media Creator may embody the Content Creator Actor. A Document Consumer, a Document Recipient or a Portable Media Importer may embody the Content Consumer Actor. The sharing or transmission of content or updates from one actor to the other is addressed by the use of appropriate IHE profiles described in the section on Content Bindings with XDS, XDM and XDR.

BPPC Actor Diagram

Options

BPPC Options

Actor	Option
Content Consumer	View Option (1)
	Document Import Option (1)
	Section Import Option (1)
	Discrete Data Import Option (1)
Content Creator	Referral Option (1)
	Discharge Summary Option (1)

Note 1: The Actor shall support at least one of these options.

Content Consumer Options

View Option

This option defines the processing requirements placed on Content Consumers for providing access, rendering and management of the medical document. See the View Option in PCC TF-2 for more details on this option.

A Content Creator Actor should provide access to a style sheet that ensures consistent rendering of the medical document content as was displayed by the Content Consumer Actor.

The Content Consumer Actor shall be able to present a view of the document using this style sheet if present.

Document Import Option

This option defines the processing requirements placed on Content Consumers for providing access, and importing the entire medical document and managing it as part of the patient record. See the Document Import Option in PCC TF-2 for more details on this option.

Section Import Option

This option defines the processing requirements placed on Content Consumers for providing access to, and importing the selected section of the medical document and managing them as part of the patient record. See the Section Import Option in PCC TF-2 for more details on this option.

Discrete Data Import Option

This option defines the processing requirements placed on Content Consumers for providing access, and importing discrete data from selected sections of the medical document and managing them as part of the patient record. See the Discrete Data Import Option in PCC TF-2 for more details on this option.

Content Bindings with XDS, XDM and XDR

It is expected that this profile will be used environment where the physician offices and hospitals have a coordinated infrastructure that serves the information sharing needs of this community of care. Several mechanisms are supported by IHE profiles:

• A registry/repository-based infrastructure is defined by the IHE Cross-Enterprise Document Sharing (XDS) and other IHE Integration Profiles such as patient identification (PIX & PDQ), and notification of availability of documents (NAV).
• A media-based infrastructure is defined by the IHE Cross-Enterprise Document Media Interchange (XDM) profile.
• A reliable messaging-based infrastructure is defined by the IHE Cross-Enterprise Document Reliable Interchange (XDR) profile.
• All of these infrastructures support Security and privacy through the use of the Consistent Time (CT) and Audit Trail and Node Authentication (ATNA) profiles.

For more details on these profiles, see the IHE IT Infrastructure Technical Framework, found here: http://www.ihe.net/Technical_Framework/.

Such an infrastructure is assumed by the use cases that focus on the context for defining the specific clinical information content for this profile.

A content binding describe how the payloads used in IHE transactions are related to and/or constrained by the data elements contained within the content sent or received in those transactions. This section is where any specific dependencies between the content and transaction are defined. The Patient Care Coordination Technical Framework defines a binding to use when grouping the Content Creator with the IHE ITI XDS, XDM or XDR Integration Profiles.

BPPC Bindings

Content	Binding	Actor	Optionality
Consent to Share Information	Consent Binding to XD* PCC TF-2: 4.1	Content Creator	R
		Content Consumer	R
Medical Documents	Medical Document Binding to XD* PCC TF-2: 4.1	Content Creator	R
		Content Consumer	R

Consent Content Module

A consent document is a kind of medical document, and shall conform to the requirements of the Consent content module specified in this profile. The content of a consent document shall include the effective time of the consent and coded vocabulary identifying the policies consented to (OID). The content of the consent document may include a text description of what the patient has consented to, and either a facsimile of a wet signature, or a digital signature by the patient (or legal representative). The consent if signed shall use the IHE ITI DSG profile.

BPPC Process Flow

The BPPC profile uses the normal process flow of the XD* profiles, depending upon which bindings have been declared.

1. Administrative tasks prior to BPPC use
   1. The Affinity Domain will write and agree to the Affinity Domain Policy (lots of lawyers involved).
   2. The Affinity Domain Policy will include a small set of Privacy Consent Policies (more lawyers). These are text documents very similar to the privacy consent documents used today.
   3. Each Privacy Consent Policy will be given an XDS Affinity Domain unique identifier (OID)
   4. The Affinity Domain Policy and all of the Privacy Consent Policies will be published in a way consistent with the Affinity Domain's Policy. It is expected that this will be sufficiently public to support local regulation.

1. Patient consents to a policy
   1. The Patient will be presented with the Affinity Domain – Patient Privacy Consent Policies.
   2. The Patient will agree to one or more of the Privacy Consent Policies. In most regions the patient must be fully informed and acknowledge the privacy consent. In some regions there is implied consent, and thus there is no need to capture a patient's consent.
   3. A system that captures patient privacy consents will capture this act in a BPPC Patient Privacy Consent Document.
      1. XDS Metadata
         1. authorPerson is the patient or legal guardian that is agreeing to the consent.
         2. classCode indicates this is a consent document
         3. confidentialityCode may indicate other consent OIDS that control this consent document
         4. eventCodeList indicates the Privacy Consent Policy identifier (OID)
         5. legalAuthenticator would be the digital signer if used, or the identity of the Affinity Domain representative that is confirming that the patient is agreeing.
         6. serviceStartTime and serviceStopTime indicate when this consent is effective.
      2. Patient Privacy Consent Document
         1. template ID = "1.3.6.1.4.1.19376.1.5.3.1.1.7 "
         2. The patient or legal guardian that is agreeing to the consent is identified as the author of the consent document.
         3. Any witness to this consent may be captured (i.e. participant typeCode='WIT')
         4. authorization indicates that this is a consent act
         5. Effective time is set
            1. When the privacy consent is first effective. This effective date may be retroactive based on the XDS Affinity Domain Policy.
            2. If necessary, when the privacy consent is expected to elapse
         6. If wet signature is used, the XDS-SD profile will be used to scan the paper and encode it into the consent document
            1. the XDS-SD CDA attributes are combined with the BPPC CDA attributes.
         7. If digital signature is used the DSG profile will be used to sign the consent document. This is an additional document that is published. This may be published in the same submission set, or may come after based on workflow.

1. System checking on a patient's consent status
   1. When a system/individual wants to know if a specific patient has consented it can do a query for consent documents on that patient.
   2. Note if the local regulations allow, some XDS Affinity Domains may not publish the consent documents, so systems should be able to handle these configurations.
   3. Note if the local regulations allow, some patients may have documents shared before informed consent can be captured.
2. Clinical documents are published into XDS Affinity Domain
   1. When clinical documents are published into XDS an assessment must be done to determine which of the XDS Affinity Domain – Privacy Consent Policies would allow the documents to be published.
      1. In some XDS Affinity domains this may require that the system check that a patient has indeed consented to the specific policy (see 3)
      2. This is likely based on human configuration of the document source system.
   2. The XDS Metadata – confidentialityCode - will include the OIDS of the appropriate (determined by the XDS Affinity Domain Policy) Privacy Consent Policy identifier (OID)
   3. The XDS Registry will validate that the confidentialityCode is one approved for use within the XDS Affinity Domain.
3. Clinical documents are used from the XDS Affinity Domain
   1. When a system queries the XDS Affinity Domain it should utilize the confidentialityCode in the queries to restrict the documents returned to those that the system can utilize
      1. For Example: If the system is a research application, then it should set the confidentialityCode in the query to the list of XDS Affinity Domain Policy identifiers (OIDs) that would allow for the documents to be used for the research.
   2. Even if the confidentialityCode is not specified, the system implementing the Document Consumer actor is still bound to enforce the XDS Affinity Domain Policies.
   3. The consumer system will enforce access controls based the returned metadata-confidentialityCode, system type, user, context, and any number of other factors that the system is capable of enforcing.

Grouping with Other Profile Actors

The capturing of the patient consenting could be futher covered by use of the IHE Digital Signature content profile (DSG). Systems should be prepared to see DSG related content associated with the Patient Privacy Consent document.

Security Considerations

Consents stored in an XDS affinity domain are also governed by privacy policies. The content of a Privacy Consent may itself contain sensitive information. For example, a terminally ill patient may decide that his prognosis should not be shared with his family members, but that other information may be. Sharing the Privacy Consent Act with family members would potentially inform them of a negative prognosis.

However, Privacy Consent Acts stored in the clear on media (XDM), or otherwise transmitted through XDR should not contain sensitive information. The rationale is that the receiver of the information must be able to read the consent that was used to share this information in order to understand how they must treat the information with respect to their own Privacy Consent Policies.

Implementation of Privacy Consent Policies within a healthcare environment has different considerations and risks than implementing similar access control policies within other non-treatment environments. This is for the simple reason that failing to provide access to critical healthcare information has the risk of causing serious injury or death to a patient. This risk must be balanced against the risk of prosecution or lawsuit due to accidental or malicious disclosure of private information. The XDS Affinity Domain should take care in writing their Privacy Consent Policies to avoid this.

One mitigation strategy often adopted in healthcare provides Accountability through Audit Controls. That is to say that healthcare providers are trusted not to abuse their access to private information, but that this is followed up by a policy of monitoring healthcare provider accesses to private information to ensure that abuse does not occur. This strategy reduces the risk of serious death or injury due to lack of access to critical healthcare information, at the increased risk of disclosure of private information. This is why the ITI Technical Committee created the Audit Trail and Node Authentication (ATNA) Integration profile, and furthermore, why that profile is a requirement of XDS and related profiles.

Another risk that must be resolved by an affinity domain is how to address the issues of sharing truly sensitive information in a registry (e.g., for VIP patients, or sensitive data). One strategy that might be recommended is that truly sensitive data not be shared within the XDS Affinity Domain, directed communications using XDR or XDM may be more appropriate.