Privacy Option: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Kboone (talk | contribs)
m New page: === Privacy Option === {{Note|Add the following to ITI TF-2:3.14.4.1.3.1 Register Document Set to explain the Privacy Option|Editor's Note}} ==== 3.14.4.1.3.1 Privacy Option ==== If the P...
 
Kboone (talk | contribs)
Line 1: Line 1:
=== Privacy Option ===
=== Privacy Option ===
The Privacy Option applies to Actors in the ITI Technical Framework.  Below are the proposed changes to that technical framework for implementing the BPPC Profile.


{{Note|Add the following to ITI TF-2:3.14.4.1.3.1 Register Document Set to explain the Privacy Option|Editor's Note}}
{{Note|Add the following to ITI TF-2:3.14.4.1.3.1 Register Document Set to explain the Privacy Option|Editor's Note}}

Revision as of 02:59, 19 June 2007

Privacy Option

The Privacy Option applies to Actors in the ITI Technical Framework. Below are the proposed changes to that technical framework for implementing the BPPC Profile.


Editor's Note Add the following to ITI TF-2:3.14.4.1.3.1 Register Document Set to explain the Privacy Option

3.14.4.1.3.1 Privacy Option

If the Privacy Option is implemented:

  1. The Registry actor shall verify that the confidentialityCode in the document metadata consists of OID values that match the Privacy Consent Policies that have been configured for this XDS Affinity Domain, and shall ensure that all documents submitted have confidentiality codes. The confidentiality codes for different documents in the same submission may be different.
  2. The Registry actor shall be able to be configured with the Privacy Consent Policies, Privacy Consent Policy Identifiers (OIDs) and associated information necessary to understand and enforce the XDS Affinity Domain Policy. The details of this are product specific and not specified by IHE.


Editor's Note Add the following to ITI TF-2:3.15.5.1 Provide and Register to explain the Privacy Option

3.15.5.1 Privacy Option

If the Privacy Option is implemented:

  1. The Document Source actor shall populate the confidentialityCode in the document metadata with the list of OID values that identify the Privacy Consent Policies that apply to the associated document. All documents submitted shall have confidentiality codes. The confidentiality codes for different documents in the same submission may be different.
  2. The Document Source actor shall be able to be configured with the Privacy Consent Policies, Privacy Consent Policy Identifiers (OIDs) and associated information necessary to understand and enforce the XDS Affinity Domain Policy. The details of this are product specific and not specified by IHE.
  3. The Document Source actor may have user interface or business rule capabilities to determine the appropriate confidentiality codes for each document. The details of this are product specific and not specified by IHE. However, the information about how confidentiality codes are assigned must be part of the published policy for the XDS Affinity Domain.


Note: For example, when publishing a document, the Document Consumer might show a list of checkboxes where a user can select which of the available consents a document is to be published.


Editor's Note Make the following changes to section ITI 3.16.4.1.3 Query Registry and ITI 3.18.4.1.3 Registry Stored Query to explain the Privacy option


3.16.4.1.3 Privacy Option

3.18.4.1.3 Privacy Option

If the Basic Patient Privacy Consents Option is implemented:

  1. The Document Consumer actor may populate the confidentialityCode in every query with the list of OID values that identify the Privacy Consent Policies that should apply to the documents that are returned in the query results. All documents submitted shall have confidentiality codes.
  2. The Document Consumer actor shall be able to be configured with the Privacy Consent Policies, Privacy Consent Policy Identifiers (OIDs and associated information necessary to understand and enforce the XDS Affinity Domain Policy. The details of this are product specific and not specified by IHE.
  3. The Document Consumer shall not allow access to documents for which the Document Consumer does not understand at least one of the confidentialityCode returned.
  4. The Document Consumer actor shall have user access controls or business rule capabilities to determine the details of how confidentiality codes apply to query results. For example, many EHR systems have complex role based access control (RBAC) systems that determine what information is displayed to a user. The RBAC configuration will need to know the user, the user’s role, the patient, and the confidentiality code to know whether all or only selected portions of the query results are visible to the user. The details of this are product specific and not specified by IHE. These rules shall reduce the query results to only those that are appropriate to the current situation for that actor and user.
  5. The Registry shall return only documents that match the requested confidentialityCode indicated in the query according to the following rules:
    1. If the query parameter confidentialityCode is empty, then it is not considered in the filter criteria, and thus the Registry may return all otherwise matching documents.
    2. If the query contains one or more confidentialityCode values, the Registry shall return only those documents for which there are active consents based on the set of confidentialityCode values submitted. An active consent is one for which there is a consent document that positively indicates patient consent to the policy, and for which the consent has not expired or been deprecated.


Note: This filtering may be provided, for example, by removing the confidentialityCode values for which there are no active consents from the initial query. An alternative is to filter the result set to remove the documents that have only confidentialityCode values that are not for active consents.



Editor's Note Add the following to ITI 3.17.4.2.3 Retrieve Document to explain the Privacy Option

3.17.4.2.3.1 Privacy Option

If the Privacy Option is implemented:

  1. The Document Consumer actor shall honor the confidentialityCode in the metadata associated with the document.
  2. The Document Consumer actor shall be able to be configured with Privacy Consent Policies, Privacy Consent Policy Identifiers (OIDs) and associated information necessary to understand and enforce the XDS Affinity Domain Policy. The details of this are product specific and not specified by IHE.
  3. The Document Consumer actor is expected to have user access controls or business rule capabilities to determine the details of how confidentiality codes apply to documents. For example, many EHR systems have complex role based access control (RBAC) systems that determine what information is displayed to a user. The RBAC configuration will need to know the user, the user’s role, the patient, and the confidentiality code to know whether all or only selected portions of the document are visible to the user. The details of this are product specific and not specified by IHE. These rules shall reduce the document display results to only those that are appropriate to the current situation for that actor and user.


Editor's Note Add the following to ITI TF-2:3.32.4.1.4 Distribute Document Set on Media

3.32.4.1.4.1 Privacy Option If the Privacy Option is implemented:

  1. The Portable Media Creator actor shall populate the confidentialityCode in the document metadata with the list of Privacy Consent Policy Identifiers (OID) values that identify the Patient Privacy Policies that apply to the associated document. All documents submitted shall have confidentiality codes. The confidentiality codes for different documents in the same submission may be different.
  2. The Portable Media Creator actor shall be able to be configured with the Privacy Consent Policies, Privacy Consent Policy Identifiers (OIDs) and associated information necessary to understand and enforce the policies. The details of this are product specific and not specified by IHE.
  3. The Portable Media Creator actor may have user interface or business rule capabilities to determine the appropriate confidentiality codes for each document. The details of this are product specific and not specified by IHE.
  4. The Portable Media Importer actor shall be able to be configured with the Privacy Consent Policies, Privacy Consent Policy Identifiers (OIDs) and associated information necessary to understand and enforce the policies. The meanings of the codes on the media must be provided out of band, e.g., by telephone, fax, or email. The detail of how this is done is product specific and not specified by IHE. If the documents are transferred internally within the organization or to other members of the recipient's affinity domain, appropriate internal confidentiality codes shall be applied.
  5. The Portable Media Creator actor shall be able to publish the consent documents and any applicable digital signatures that apply to the collection of content that it has created on portable media.
  6. The Portable Media Importer actor shall have the ability to coerce the confidentiality code in the metadata associated with the document from the codes used by the Exporter to the codes used by the Importer.
  7. The Portable Media Importer actor shall have user access control or business rule capabilities to determine the details of how confidentiality codes apply to query results. For example, many EHR systems have complex role based access control (RBAC) systems that determine what information is displayed to a user. The RBAC configuration will need to know the user, the user’s role, the patient, and the confidentiality code to know whether all or only selected portions of the document are visible to the user. The details of this are product specific and not specified by IHE. These rules shall reduce the document display results to only those that are appropriate to the current situation for that actor and user.