Sunday, May 3, 2015

Strawman on Consent Directive

The Healthcare community continue to struggle with Patient Consent Directives. I assert it is because we have two very different forces:
  1. Healthcare Business -- that are under many regulatory, ethical, and business forces. This makes it very hard to change, especially hard to make radical changes. So this community needs very small realistic changes suggested that eventually produce the result desired.
  2. Patient Advocates -- that want a very different User Experience. This community wants all of the Privacy Principles implemented. They accept nothing less, likely because of the limited movement so far.
I support both views! But we can't go from one view to the other without taking some small steps.

We can't change Healthcare by writing very complex standards like the current FHIR ConsentDirective, which is fundamentally a "Contract" resource. And the CDA ConsentDirective is even less realistic. First I recommend that FHIR make ConsentDirective a resource rather than just profiles of Contract. I have defended this model so far, but the negatives are more powerful. People simply want a ConsentDirective resource.

Might I suggest that the ConsentDirective project include a "Basic-ConsentDirective" that supports blanket consents without exceptions. Essentially the common HIE policies from BPPC. These would be scoped to sharing beyond the original organization and purpose for which the health information was created. This form of a Consent Directive would need only (identifier, issued, applies, subject, authority, domain, type=consent, subtype=<some vocabulary>, and possibly friendly and legal). This Basic Consent Directive would support the following HIE subtypes:
  • Opt-In -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment". No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
  • Opt-Out allowing break-glass -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a Treatment organization for specifically "Emergency Treatment" PurpoeOfUse, and Payment of those treatment. This agreement does not authorize other accesses.
  • Opt-In summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment"; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
  • Opt-In break-glass summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" organization "For the Purpose" of "Emergency Treatment" and Payment of those treatment; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
  • Opt-Out no break-glass -- Agree to publish "All" healthcare information. This agreement does not authorize any accesses.
  • Opt-Out completely -- Agree to publish "No" healthcare information beyond originating organization intended use.
I will also note that I think we should look to ‘Creative Commons’, which I explain on my blog.

More advanced consents can be made once we have this basic vocabulary in place. For example we an then add exceptions, which can be computable rules. For example an "Opt-In" but not to Doctor Bob. All of the Opt-In logic is understood from the reference to Opt-In, the only thing that needs to be added is the exception for Doctor Bob. No need to duplicate the logic of Opt-In in each patient chart.

References:

Tuesday, April 28, 2015

Privacy Principles

Privacy definition is far more than just 'confidentiality' or 'consent'.

Defining Privacy


Privacy is a very important Human Right, yet very hard to define. I am very encouraged by all the efforts in Healthcare on Privacy. These efforts are caused by the interest, yet made complex by the lack of a simple definition for Privacy. The problem with defining Privacy, even in Healthcare, is that there really isn't a single definition of Privacy. The reason is that Privacy has multiple dimensions. Controllership, Confidentiality, Accountability, Accounting, Correctness, Transparency, Disclosure, Consent/Authorization, etc. This is why Privacy is often described in terms of Privacy Principles. As the concept of Privacy is made up of all these various dimensions.

There are some standards that have definitions for Privacy
  • ISO/IEC 2382-8:1998 -- Freedom from intrusion into the private life or affairs of an individual when that intrusion results from undue or illegal gathering and use of data about that individual.
  • ISO 7482-2:1989 -- The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.
  • AHIMA -- The quality or state of being hidden from, or undisturbed by, the observation or activities of other persons, or freedom from unauthorized intrusion; in healthcare-related contexts, the right of a patient to control disclosure of protected health information.
  • Countries like Canada -- (1) The claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others. [Defined by uses this definition from A.F. Westin, Privacy and Freedom (1968). Basis for Privacy Act of 1974 (P.L. 93579; 5 U.S.C. § 552a).] (2) The right of an individual to live free of intrusive monitoring of their personal affairs by third parties not of their choosing.
I find that it is better to understand the Privacy Principles in order to understand what the term Privacy really means. See some of the foundational Privacy Principles. 
The OECD  Privacy Principles are as good as any to review
  1. Collection Limitation Principle --  There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
  2. Data Quality Principle -- Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
  3. Purpose Specification Principle -- The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
  4. Use Limitation Principle -- Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except: a) with the consent of the data subject; or b) by the authority of law.
  5. Security Safeguards Principle -- Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.
  6. Openness Principle -- There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
  7. Individual Participation Principle -- An individual should have the right:a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.
  8. Accountability Principle -- A data controller should be accountable for complying with measures which give effect to the principles stated above.
It isn't even as simple as these 8 Privacy Principles. There are regional nuances, personal decisions, concerns for safety/health, etc. Often times there is complaints that these Privacy Principles get in the way of Medical Ethics  the actual cases of conflict are few and usually well understood by those affected.
So, you can see there isn’t one concept that makes up “Privacy”. Even Wikipedia has trouble simplifying it http://en.wikipedia.org/wiki/Privacy

Privacy Principle Cross-Reference 


The following is a table that cross-references these 6 references on Privacy. Note that the identifier in parentheses (e.g. "(WH1)") is simply an indicator of the Privacy Principle as indicated. I expect the reader can find these. The Rows are grouping similar Principles. This is just one way to group these Principles.


White House Privacy PrinciplesPrivacy by DesignOECDSafe HarborHIPAANIST 800-53
(WH1) [Capability to support] Individual Control -Consumers have a right to exercise control over what personal data organizations collect from them and how they use it.(PbD1) Proactive not Reactive; Preventative not Remedial [implementation of controls to support customer obligations](OECD1) [Capability to support] Collection Limitation - There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.(SH1) [Capability to support] Choice - Individuals must have the ability to opt out of the collection and forward transfer of the data to third parties.(HIP1) [Capability to support] Request for Access - The Privacy Rule allows covered entities to require that individuals make requests for access in writing, provided they inform individuals of such a requirement. See 45 C.F.R. § 164.524(b)(1). In addition, the Privacy Rule has always considered electronic documents to qualify as written documents. Thus, the Privacy Rule supports covered entities’ offering individuals the option of using electronic means (e.g. e-mail, web portal) to make requests for access - The Privacy Rule allows covered entities to require that individuals make requests for access in writing, provided they inform individuals of such a requirement.(NIST1) [Capability to support] Security - This family supplements the security controls in Appendix F to ensure administrative, technical, and physical safeguards are in place to protect PII collected or maintained by organizations against loss, unauthorized access, or disclosure, as required by the Privacy Act, and to ensure that organizational planning and responses to privacy incidents comply with OMB policies and guidance. The controls in this family are implemented in coordination with information security personnel and in accordance with the existing NIST Risk Management Framework.
(WH2) [Capability to support] Focused Collection - Consumers have a right to reasonable limits on the personal data that companies collect and retain.(PbD2) Privacy as the Default [configuration](OECD2) [Capability to support] Data Quality - Personal data should be relevant to the purposes for which they are to be used and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.(SH2) [Capability to support] Onward Transfer - Transfers of data to third parties may only occur to other organizations that follow adequate data protection principles.(HIP2) [Capability to support] Limited Data Set - A limited data set is protected health information from which certain specified direct identifiers of individuals and their relatives, household members, and employers have been removed.43 A limited data set may be used and disclosed for research, health care operations, and public health purposes, provided the recipient enters into a data use agreement promising specified safeguards for the protected health information within the limited data set.(NIST2) [Capability to support] Authority and Purpose - This family furthers compliance with the Privacy Act by ensuring that organizations: (i) identify the legal bases that authorize a particular PII collection or activity that impacts privacy; and (ii) specify in their notices, the purpose(s) for which PII is collected.
(WH3) [Capability to support] Respect for Context – Consumers have a right to expect that organizations will collect, use, and disclose personal data in ways that are consistent with the context in which consumers provide the data.(PbD3) Full Functionality - Positive Sum, not Zero Sum [Privacy Design] - Privacy by Design seeks to accommodate all legitimate interests and objectives in a positive-sum “win-win” manner, not through a dated, zero-sum approach, where unnecessary trade-offs are made. Privacy by Design avoids the pretense of false dichotomies, such as privacy vs. security, demonstrating that it is possible to have both.(OECD3) [Capability to support] Purpose Specification - The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfillment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.(SH3) [Capability to support] Access - Individuals must be able to access information held about them, and correct or delete it if it is inaccurate.(HIP3) [Capability to support] Authorization - A covered entity must obtain the individual’s written authorization for any use or disclosure of protected health information that is not for treatment, payment or health care operations or otherwise permitted or required by the Privacy Rule.44 A covered entity may not condition treatment, payment, enrollment, or benefits eligibility on an individual granting an authorization, except in limited circumstances.45 An authorization must be written in specific terms. It may allow use and disclosure of protected health information by the covered entity seeking the authorization, or by a third party. Examples of disclosures that would require an individual’s authorization include disclosures to a life insurer for coverage purposes, disclosures to an employer of the results of a pre-employment physical or lab test, or disclosures to a pharmaceutical firm for their own marketing purposes.(NIST3) [Capability to support] Data Quality and Integrity - This family ensures compliance with Section 552a (e)(2) of the Privacy Act of 1974 and enhances public confidence that any PII collected and maintained by organizations is accurate, relevant, timely, and complete for the purpose for which it is to be used, as specified in public notices.
(WH4) [Capability to support] Access and Accuracy - Consumers have a right to access and correct personal data in usable formats, in a manner that is appropriate to the sensitivity of the data and the risk of adverse consequences to consumers if the data are inaccurate.(PbD4) Privacy Embedded into Design - Privacy is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on, after the fact. The result is that it becomes an essential component of the core functionality being delivered. Privacy is integral to the system, without diminishing functionality.(OECD4) [Capability to support] Use Limitation - Personal data should not be disclosed, made available or otherwise used for purposes other than those specified except: a) with the consent of the data subject; or b) by the authority of law.(SH4) [Capability to support] Enforcement - There must be effective means of enforcing these rules.(HIP4) [Capability to support] Accounting of Disclosures - Individuals have a right to an accounting of the disclosures of their protected health information by a covered entity or the covered entity’s business associates.60 The maximum disclosure accounting period is the six years immediately preceding the accounting request, except a covered entity is not obligated to account for any disclosure made before its Privacy Rule compliance date.(NIST4) [Capability to support] Use Limitation - This family helps organizations comply with the Privacy Act, which prohibits the use of PII that is either not specified in notices, incompatible with the specified purposes, or not otherwise permitted by law.
(WH5) [Capability to support] Accountability -Consumers have a right to have personal data handled by companies with appropriate measures in place to assure they adhere to the Consumer Privacy Bill of Rights.
(OECD5) [Capability to support] Openness - There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
(HIP5) [Capability to support] Amendments - This rule gives individuals the right to have covered entities amend their protected health information in a designated record set when that information is inaccurate or incomplete. 58 If a covered entity accepts an amendment request, it must make reasonable efforts to provide the amendment to persons that the individual has identified as needing it, and to persons that the covered entity knows might rely on the information to the individual’s detriment.59 If the request is denied, covered entities must provide the individual with a written denial and allow the individual to submit a statement of disagreement for inclusion in the record. The Rule specifies processes for requesting and responding to a request for amendment. A covered entity must amend protected health information in its designated record set upon receipt of notice to amend from another covered entity.(NIST5) [Capability to support] Individual Participation and Redress - This family addresses the need to make individuals active participants in the decision-making process regarding the collection and use of their PII, as required by the Privacy Act. By providing individuals with access to PII and the ability to have their PII corrected or amended, as appropriate, the controls in this family enhance public confidence in organizational decisions made based on the PII.




(HIP6) [Capability to support] Confidential communication with the patient - i.e. configurability of displays to not display personal information upon request of the patient.(NIST6) [Capability to support] Data Minimization and Retention - This family helps organizations implement the data minimization and retention elements of the Privacy Act, which requires organizations to collect, use, and retain only PII that is relevant and necessary for the specified purpose for which it was originally collected. Organizations retain PII for only as long as necessary to fulfill the specified purpose(s) and in accordance with a National Archives and Records Administration (NARA) -approved record retention schedule.
(WH6) Security - Consumers have a right to secure and responsible handling of personal data.(PbD5) Lifecycle Protection - Privacy by Design, having been embedded into the system prior to the first element of information being collected, extends throughout the entire lifecycle of the data involved, from start to finish. This ensures that at the end of the process, all data are securely destroyed, in a timely fashion. Thus, Privacy by Design ensures cradle to grave, lifecycle management of information, end-to-end.(OECD6) Security Safeguards - Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data.(SH2) Onward Transfer - Transfers of data to third parties may only occur to other organizations that follow adequate data protection principles.(HIP7) Confidential Communications Requirement - Health plans and covered health care providers must permit individuals to request an alternative means or location for receiving communications of protected health information by means other than those that the covered entity typically employs.63 For example, an individual may request that the provider communicate with the individual through a designated address or phone number. Similarly, an individual may request that the provider send communications in a closed envelope rather than a post card.
Health plans must accommodate reasonable requests if the individual indicates that the disclosure of all or part of the protected health information could endanger the individual.
(NIST1) Security - This family supplements the security controls in Appendix F to ensure administrative, technical, and physical safeguards are in place to protect PII collected or maintained by organizations against loss, unauthorized access, or disclosure, as required by the Privacy Act, and to ensure that organizational planning and responses to privacy incidents comply with OMB policies and guidance. The controls in this family are implemented in coordination with information security personnel and in accordance with the existing NIST Risk Management Framework.



(SH6) Security - Reasonable efforts must be made to prevent loss of collected information(HIP8) Data Safeguards - A covered entity must maintain reasonable and appropriate administrative, technical, and physical safeguards to prevent intentional or unintentional use or disclosure of protected health information in violation of the Privacy Rule and to limit its incidental use and disclosure pursuant to otherwise permitted or required use or disclosure. For example, such safeguards might include shredding documents containing protected health information before discarding them, securing medical records with lock and key or passcode, and limiting access to keys or pass codes.



(SH7) Data Integrity - Data must be relevant and reliable for the purpose it was collected for.

(WH1) Individual Control - Consumers have a right to exercise control over what personal data organizations collect from them and how they use it.(PbD1) Proactive not Reactive - Preventative not Remedial - The Privacy by Design (PbD) approach is characterized by proactive rather than reactive measures. It anticipates and prevents privacy invasive events before they happen. PbD does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred — it aims to prevent them from occurring. In short, Privacy by Design comes before-the-fact, not after.(OECD3) Purpose Specification - The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfillment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose(SH1) Choice - Individuals must have the ability to opt out of the collection and forward transfer of the data to third parties.(HIP3) Authorization - A covered entity must obtain the individual’s written authorization for any use or disclosure of protected health information that is not for treatment, payment or health care operations or otherwise permitted or required by the Privacy Rule.44 A covered entity may not condition treatment, payment, enrollment, or benefits eligibility on an individual granting an authorization, except in limited circumstances. (NIST2) Authority and Purpose - This family furthers compliance with the Privacy Act by ensuring that organizations: (i) identify the legal bases that authorize a particular PII collection or activity that impacts privacy; and (ii) specify in their notices, the purpose(s) for which PII is collected.
(WH2) Focused Collection - Consumers have a right to reasonable limits on the personal data that companies collect and retain.(PbD2) Privacy as the Default - We can all be certain of one thing — the default rules! Privacy by Design seeks to deliver the maximum degree of privacy by ensuring that personal data are automatically protected in any given IT system or business practice. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy — it is built into the system, by default.(OECD4) Use Limitation - Personal data should not be disclosed, made available or otherwise used for purposes other than those specified except: a) with the consent of the data subject; or b) by the authority of law.(SH4) Enforcement - There must be effective means of enforcing these rules.(HIP9) Restriction Requests - Individuals have the right to request that a covered entity restrict use or disclosure of protected health information for treatment, payment or health care operations, disclosure to persons involved in the individual’s health care or payment for health care, or disclosure to notify family members or others about the individual’s general condition, location, or death.(NIST3) Data Quality and Integrity - This family ensures compliance with Section 552a (e)(2) of the Privacy Act of 1974 and enhances public confidence that any PII collected and maintained by organizations is accurate, relevant, timely, and complete for the purpose for which it is to be used, as specified in public notices.
(WH4) Access and Accuracy - Consumers have a right to access and correct personal data in usable formats, in a manner that is appropriate to the sensitivity of the data and the risk of adverse consequences to consumers if the data are inaccurate.(PbD6) Respect for User Privacy - Above all, Privacy by Design requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric(OECD1) Collection Limitation - There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.(SH7) Data Integrity - Data must be relevant and reliable for the purpose it was collected for(HIP2) Limited Data Set - A limited data set is protected health information from which certain specified direct identifiers of individuals and their relatives, household members, and employers have been removed. A limited data set may be used and disclosed for research, health care operations, and public health purposes, provided the recipient enters into a data use agreement promising specified safeguards for the protected health information within the limited data set.(NIST4) Use Limitation - This family helps organizations comply with the Privacy Act, which prohibits the use of PII that is either not specified in notices, incompatible with the specified purposes, or not otherwise permitted by law.
(WH3) Respect for Context – Consumers have a right to expect that organizations will collect, use, and disclose personal data in ways that are consistent with the context in which consumers provide the data.
(OECD2) Data Quality - Personal data should be relevant to the purposes for which they are to be used and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.(SH3) Access - Individuals must be able to access information held about them, and correct or delete it if it is inaccurate.(HIP5) Amendments - The Rule gives individuals the right to have covered entities amend their protected health information in a designated record set when that information is inaccurate or incomplete. 58 If a covered entity accepts an amendment request, it must make reasonable efforts to provide the amendment to persons that the individual has identified as needing it, and to persons that the covered entity knows might rely on the information to the individual’s detriment.59 If the request is denied, covered entities must provide the individual with a written denial and allow the individual to submit a statement of disagreement for inclusion in the record. The Rule specifies processes for requesting and responding to a request for amendment. A covered entity must amend protected health information in its designated record set upon receipt of notice to amend from another covered entity.


(OECD7) Individual Participation - An individual should have the right: a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.(SH2) Onward Transfer - Transfers of data to third parties may only occur to other organizations that follow adequate data protection principles.(HIP1) Request for Access - The Privacy Rule allows covered entities to require that individuals make requests for access in writing, provided they inform individuals of such a requirement. See 45 C.F.R. § 164.524(b)(1). In addition, the Privacy Rule has always considered electronic documents to qualify as written documents. Thus, the Privacy Rule supports covered entities’ offering individuals the option of using electronic means (e.g., e-mail, web portal) to make requests for access.(NIST6) Data Minimization and Retention - This family helps organizations implement the data minimization and retention elements of the Privacy Act, which requires organizations to collect, use, and retain only PII that is relevant and necessary for the specified purpose for which it was originally collected. Organizations retain PII for only as long as necessary to fulfill the specified purpose(s) and in accordance with a National Archives and Records Administration (NARA)-approved record retention schedule.




(HIP10) Timely Action - The Privacy Rule requires covered entities to respond to requests for access in a timely manner. Except as otherwise specified, the Privacy Rule requires the individual be notified of the decision within 30 days of the covered entity’s receipt of the request.
(WH7) Transparency - Consumers have a right to easily understandable information about privacy and security practices.(PbD7) Visibility / Transparency - Keep it Open — Privacy by Design seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact, operating according to the stated promises and objectives, subject to independent verification. Its component parts and operations remain visible and transparent, to users and providers alike. Remember, trust but verify.(OECD5) Openness - There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.(SH5) Notice - Individuals must be informed that their data is being collected and about how it will be used.(HIP11) Notice - Each covered entity, with certain exceptions, must provide a notice of its privacy practices.51 The Privacy Rule requires that the notice contain certain elements. The notice must describe the ways in which the covered entity may use and disclose protected health information. The notice must state the covered entity’s duties to protect privacy, provide a notice of privacy practices, and abide by the terms of the current notice. The notice must describe individuals’ rights, including the right to complain to HHS and to the covered entity if they believe their privacy rights have been violated. The notice must include a point of contact for further information and for making complaints to the covered entity. Covered entities must act in accordance with their notices. The Rule also contains specific distribution requirements for direct treatment providers, all other health care providers, and health plans.(NIST7) Transparency - This family implements Sections 552a (e)(3) and (e)(4) of the Privacy Act and Section 208 of the EGovernment Act, which require public notice of an organization’s information practices and the privacy impact of government programs and activities.
(WH5) Accountability - Consumers have a right to have personal data handled by companies with appropriate measures in place to assure they adhere to the Consumer Privacy Bill of Rights.
(OECD8) Accountability - A data controller should be accountable for complying with measures which give effect to the principles stated above.
(HIP4) Accounting of Disclosures - Individuals have a right to an accounting of the disclosures of their protected health information by a covered entity or the covered entity’s business associates.60 The maximum disclosure accounting period is the six years immediately preceding the accounting request, except a covered entity is not obligated to account for any disclosure made before its Privacy Rule compliance date.
The Privacy Rule does not require accounting for disclosures: (a) for treatment, payment, or health care operations; (b) to the individual or the individual’s personal representative; (c) for notification of or to persons involved in an individual’s health care or payment for health care, for disaster relief, or for facility directories; (d) pursuant to an authorization; (e) of a limited data set; (f) for national security or intelligence purposes; (g) to correctional institutions or law enforcement officials for certain purposes regarding inmates or individuals in lawful custody; or (h) incident to otherwise permitted or required uses or disclosures. Accounting for disclosures to health oversight agencies and law enforcement officials must be temporarily suspended on their written representation that an accounting would likely impede their activities.(NIST8) Accountability, Audit and Risk Management - This family enhances public confidence through effective controls for governance, monitoring, risk management, and assessment to demonstrate that organizations are complying with applicable privacy protection requirements and minimizing overall privacy risk.7.4.2 If a patient contacts GEHC-HCIT for access, record amendment, accounting of disclosure, or restricted use or disclosure, have them contact their healthcare provider to assist them with the request or immediately contact the customer informing them of patient request.



The front material of this blog post is a restatement of a 2013 article Defining Privacy

Reference Blog Posts:



Sunday, April 26, 2015

Why Mutual-Authorized-TLS?

The IHE-ATNA Profile only calls for "Mutual-Authenticated-TLS", where I have asserted that you really need Mutual-Authorized-TLS. I am not changing the IHE-ATNA perspective. From an Interoperability perspective one is using the TLS to Mutually Authenticate. This is the concern that is addressed through Interoperability Profiling. This is all that Profiling can address, in that the Interoperability layer defines how the two sides authenticate each other. This is enough from an Interoperability perspective, but is not the end of the story.

Updated: To be clear, I am not recommending a change to IHE-ATNA, it is fine the way it is and what it provides is foundational to what I am describing. What I am describing is that use of IHE-ATNA Secure Communications is not sufficient, as a 'bad-guy' could potentially be authenticated but not authorized. This is especially true if one uses a truststore like the ones found in Browsers. So what I am describing is that each endpoint must also functionally do Access Control decisions, aka Authorization.

The reason one Authenticates something is to prove that the Identity claimed is indeed the Identity of the one claiming that Identity. But knowing an Identity is just part of the story.

 

Why does the Server need to check if the Client is Authorized?

An Authorized Client is one that is allowed to do the task that it is asking to do. This authorization is based on an Identity that has been Authenticated. An Identity that is not Authenticated is one that can be spoofed easily. So you see that the Authorization is dependent on the Authentication which is dependent on the Identity.

Servers need to differentiate communications from partners that they should talk to, from all the attackers that they should not talk to. This is rather obvious in the context of a Cloud hosted Server. As that Server is on the internet, and thus every attacker on the internet could be attacking. There are many proofs that any machine placed on the internet will be attacked within a few minutes.

The Server is often 'serving' up data or functions for Clients to use. Thus the Server is protecting that data from improper access. Cat videos need not be protected, but healthcare information and healthcare functionality really do need to be protected from improper access. Often times the server will use the identity in a simple Role-Based-Access-Control decision: Does this user possess roles that possess Permissions to this kind of access to this specific resource?

The basics are that the Server needs to protect itself, and this is done with Authorization decisions based on client identity authentication.

 

Why does the Client need to check if the Server is Authorized?

The Client must be sure that it has actually gotten connected to the Server it intended to get connected to. So the risk is that the Client will get attached to the wrong Server. Worst case is that the Client gets connected to a malicious Server. In this case the Client may be controlled to expose healthcare information to the attacker, or to falsify information into the hospital environment. This happens in the environment where a human is using a Browser, as the human is expected to do the authorization of the server step themselves. This however fails quite often, see phishing.

These attacks are harder to achieve. The vulnerability is that the client attaches to a Server that is not the right server (spoofing, tampering, repudiation, disclosure, and denial-of-service). The attacker would likely be a skilled and motivated attacker.  But the attacks are not that hard to achieve, and we have seen examples where this kind of attack has happened.

For example the attacker could 'spoof' the DNS, thus giving the Client a wrong IP address to connect to; thus causing the Client to connect to their malicious Server. The attacker could cause routers to route the communications to their malicious Server.

Where node-to-node Authentication is Authorization

There is a degenerate form where the truststore on both ends of the communications contain only identities that are Authorized. Thus the Authentication step, accomplished by the TLS layer, is sufficient. This is not a violation of the above assessment. It is simply moving the Authorization step to the configuration of the truststore, rather than leaving it in real-time as part of the communications channel establishment. This degenerate form simply is not scalable, and is much harder to manage.

 

Authorization as an Interoperability Concern

Yes, there are some protocols that cover Authorization. This can be done using SAML, a claim of authorization can be communicated within a SAML assertion. More directly OAuth, is 'Authorization', and not authentication, although one gets authentication by way of the authorization claims. I am not trying to downplay these, but rather focus on the IHE-ATNA model. This does not mean one model is better than the others, just different. I am simply not covering anything but IHE-ATNA in this blog article. See other articles for other topics.

 

Blog Articles on  Secure Communications

 


Tuesday, April 7, 2015

NIST seeks comments on De-Identification

NIST is seeking comment on De-Identification. The good news is that they have used the Healthcare ISO 25237 specification. The bad news is that they didn't reference the IHE De-Identification Handbook-. Guess I have my first comment ready. De-Identification is a Process used to lower 'risk' of re-identification.

NIST IR 8053
DRAFT De-Identification of Personally Identifiable Information
NIST requests comments on an initial public draft report on NISTIR 8053, De-identification of personally Identifiable Information. This document describes terminology, process and procedures for the removal of personally identifiable information (PII) from a variety of electronic document types.

Background:
This draft results from a NIST-initiated review of techniques that have been developed for the removal of personally identifiable information from digital documents. De-identification techniques are widely used to removal of personal information from data sets to protect the privacy of the individual data subjects. In recent years many concerns have been raised that de-identification techniques are themselves not sufficient to protect personal privacy, because information remains in the data set that makes it possible to re-identify data subjects.

We are soliciting public comment for this initial draft to obtain feedback from experts in industry, academia and government that are familiar with de-identification techniques and their limitations.

Comments will be reviewed and posted on the CSRC website. We expect to publish a final report based on this round of feedback. The publication will serve as a basis for future work in de-identification and privacy in general.

Note to Reviewers:
NIST requests comments especially on the following:

    • Is the terminology that is provided consistent with current usage?
    • Since this document is about de-identification techniques, to what extent should it discuss differential privacy?
    • To what extent should this document be broadened to include a discussion of statistical disclosure limitation techniques?
    • Should the glossary be expanded? If so, please suggest words, definitions, and appropriate citations?

Please send comments to draft-nistir-deidentify@nist.gov by May 15, 2015.
Draft NISTIR 8053
Comment Template Form for Draft NISTIR 8053


References to articles I have written on De-Identification
 

Monday, March 16, 2015

What is MHD beyond XDS-on-FHIR?

I have been working on a Profile in IHE now for three years. It normally doesn’t take this long, but in my case I had the good luck of being the in the right place at the right time. I saw the tidal wave of “HTTP RESTful” coming, felt it strongly back when I was on “The Direct Project” creating a sub-optimal solution. At that time, IHE only had the XDS solution, which is based on Web-Services using SOAP, SAML, and ebRegistry. This XDS solution was and is still the best solution for business-to-business. However this solution is very hard to use if one is using programming tools more common on lightweight systems such as Mobile.

So back in 2011 I wrote the first profile in IHE that was targeting ‘ease of use by lightweight application platforms such as Mobile Health Applications”. Thus it targeted use of HTTP RESTful, using JSON encoding. The Mobile Health Documents (MHD) profile was born to provide a more simple API to an XDS environment. This happened to be the same timeframe that Grahame was fanning the FHIR flames. So we joined forces and brought the concepts needed for XDS into FHIR®. So now, I take those FHIR based Resources and re-write the profile.

Note there will be yet-another re-write (hopefully just tweaks) this summer after HL7 completes their DSTU2 ballot process. There are a set of gaps identified this winter that we have fixed in the proposed content for DSTU2.

The Mobile Health Documents (MHD) is the result.
I am not going to go into deep details, but take the perspective here that the reader is a FHIR expert, and wants to understand this MHD profile. I will assume you also have some understanding of XDS, but only as an overall concept.

The basics are shown here.

The MHD abstract actors are:

  • Document Source - the  producer and publisher of documents and metadata
  • Document Recipient - receives documents and metadata
  • Document Consumer - queries for documents metadata, and requests to retrieve documents
  • Document Responder - responds to requests for document metadata entries and documents.

The MHD abstract transactions are:

  • Provide Document Bundle - This transaction is used to transfer documents and metadata, and is analogous to a Provide and Register Document Set-b transaction.
  • Find Document Manifests – This transaction is used to provide parameterized queries that result in a list of Document Manifest resources.
  • Find Document References – This transaction is used to provide parameterized queries that result in a list of Document Reference resources.
  • Retrieve Document – This transaction is used to get documents.

MHD uses few FHIR Resources:

and

The MHD Profile enables many deployment models:

As and API to XDS environment

This is what is mostly talked about, but this was just the master pattern. The functionality provided is a more simplified API to a backbone that is fundamentally based on XDS. This simplified API is based on the HL7 FHIR RESTful API. It is therefore available in simple XML, or JSON. The elements of the metadata are thus more accessible to a Java Script application.

As an API to XCA environment

Just like with XDS, this is a more simplified API to a federated set of Document Sharing infrastructure. The interactions of the Document Source and Document Consumer MHD actors are just the same as with XDS. The implementation of the Document Recipient and Document Responder MHD actors might be more specialized.

As a standalone Document Sharing infrastructure

Similar to XDS or XCA, but without the need for XDS or XCA on the backend.

As an API to XDR environment

Either end of an XDR could be implemented

As a standalone PUSH environment 

Similar to XDR without XDR. Use your imagination that everywhere XDR might be used, the MHD Document Source to Document Recipient could be used.

As an API to the Direct Project HISP  

Either as PUSH based API, or including support for Query side interaction. The Direct Project is a secure email protocol for pushing documents from one place to another. There are value-add service providers that provide a hosted environment for this. They offer a few different APIs to their hosted service. Some are the secure email, some are based on XDR, some have their own HTTP REST API. These could be augmented through the addition of the MHD API as the front-end of the HISP. 

As an API to any document based system

The backend just needs to have a document concept

As simply a profiled FHIR service 

At the IHE Connectathon we showed that Document Sources and Document Consumers could just direct their API toward FHIR Servers and it would simply work.

Security and Privacy 

As with any Interoperability API dealing with Healthcare information, Security and Privacy
are important. IHE doesn’t mandate a specific Security or Privacy model, as that would be Policy. But IHE does encourage the use of ATNA, and IUA.This also described on the FHIR Site on the Security page.

For More information

  • User Identity and Authentication
  • Patient Privacy Controls
  • Access Control (including Consent Enforcement)
  • Audit Control
  • Secure Communications
  • Document Sharing Management (Health Information Exchange - HIE)
  • Patient Identity
  • mHealth
  • Meaningful Use
  • The Direct Project