Saturday, August 29, 2015

Don't disassemble ATNA, what you are looking for is there.

I have been pulled into many discussions that are not taking 'all' of ATNA. They are either just taking the audit logging, or just taking the Secure Communications. Then there are the discussions that are taking the Secure Communications but don't want to take the Client authentication. All of these discussions are missing the point of ATNA, and/or are missing the configurability that is built into ATNA.

Let me explain:

1. ATNA is a grouping of three functions: Security Audit, Secure Communications, and local Access Controls. It is only when you are assured that ALL of these functions exist that you should administratively accept the node/application, and provision a certificate. When I see groups picking and choosing parts, I worry that they might not be understanding the overall. I don’t mind treating them independent as long as this overall design is understood.

2. ATNA Secure Communications (actually Authenticate Node). is not just mutual-authenticated-TLS, although this is the predominant form (The only form for point-to-point protocols like HL7 v2, and DICOM). It also includes SMTP end-to-end security used by Direct. It includes end-to-end security for SOAP using XML-Signature and XML-Encryption….

3. ATNA Secure Communications expects that you will do certificate management (PKI) properly, that is that authenticating a node is more than just proving that the claimed identity is the one authenticated. If you don’t manage your truststore, then you are just authenticating that the identity is the one claimed in the certificate. This is the kind of https used on the internet, one that only looks to prove that the server you connected to is 'most likely' the one you intended. When you don't manage your trust-store, all you can know is that the identity seems 'most likely' to be the one you intended to connect to. This is indeed not very helpful. This is why ATNA has a long discussion around certificate management. Managing the trust-store, usually through removing the hundreds of internet Certificate Authorities (CA), and leaving only CAs that you really trust.

4. Further there is an expectation that you don’t stop at authentication, but also check that the remote node is authorized. The ATNA Secure Communications is just the “Interoperability” way to get authentication done, you still must use that authenticated identity in an authorization decision. If you fail to do this then you will certainly fail to be secure. This fact is true about ALL authentication mechanisms.

5. ATNA Secure Communications can be grouped with a user authentication profile like EUA, XUA, or IUA. This is less clear in the ATNA profile and transaction, as the transaction doesn’t mention these (beyond EUA). So you can authenticate the user at the client, in addition to authenticating the client they are on.

6. ATNA Secure Communications does specify TLS 1.0 or better, and the use of TLS_RSA_WITH_AES_128_CBC_SHA; this is an “Interoperability” statement, not a security statement. Meaning it is there to set a low bar that assures interoperability can happen. Policy is expected to take over from there, where policy can push the security criteria up as high as the actors can handle. If you are in the space of Policy, you can certainly set the Policy higher. I emphasize that IHE is focused on assuring that products come with capability that will interoperate, it is NOT constraining on the top-end and can’t constrain on the top-end; that is policy space. The profile does recommend that all crypto algorithms, and key sizes be configurable. It only specifies one set, so that interoperabililty will work, as without this it is likely two systems choose non-overlapping crypto algorithms and key sizes.

7. IHE has further explained that for HTTP traffic, it is likely that policy will allow HTTPS with no client-authentication, where the client is authenticated using IUA (OAuth). This is the same recommendation you will find in FHIR, and SMART. OAuth is an acceptable standard, it “can” represent the application as being authorized by the User. In this way it meets the expectation of ATNA Secure Communications. So if you are focused on HTTP like things, FHIR, then stop worrying about the client certificate in ATNA Secure Communications, and start demanding OAuth for client; as this does meet the ATNA requirement and is far more easy to manage in HTTP like architectures (Mutual-Auth-TLS is very hard to deal with in web centric architectures).

8. That said, although OAuth can be used to authorize background tasks for authorized applications (e.g. Facebook app does this); OAuth doesn’t work as well for cases where the identity that needs to be claimed is NOT HUMAN. Meaning it works fine for Facebook, but doesn’t work all that well for “The XCA Gateway of Kaiser”. In these cases certificates work better as they are inherently more manageable as automaton identity, vs human identity.
 
Conclusion
So, keep ATNA together, it is an important set of capabilities that if not used together don't provide security. Recognize that ATNA is just one security profile, user authentication is done with IUA, XUA, and EUA. Lastly recognize that IHE is enabling default interoperability, it is not restricting the security to that level. 

Thursday, August 20, 2015

Where do I record the Reason that an auditable event happened?

I received a question about where to put the 'reason' that an ATNA auditable event has happened. The short answer is that Security is not interested in the reason; but Provenance is.
Hello John,

I have a question around ATNA logging. We are currently implementing the Metadata Update profile; ITI-57 "Update Document Set". [Specifically for deprecating a document without replacement.]
However, we cannot find a place to store a reason (free text), which the user can enter when deprecating the document. It does not really make sense to allow the user to enter a reason, but not log it as part of the audit trail.

The ATNA log is for Security purposes. It therefore is not interested in why. it is just interested in the fact that it happened. Security is interested in making sure that those that are not authorized to do things, are prevented from doing them. So the Security audit log is there to prove that only authorized acts are happening. If non-authorized acts are happening, then security is broken somewhere. If acts are happening that shouldn't be authorized, then the access control rules need to be changed.

This is not to say that it is not important to Medical-Records that there is a reason why the act happened. As with most information in medical records, they don’t really get removed but rather deprecated. In these transitions it is important to note why this happened. This kind of a record-keeping is Provenance, and is parallel to security/privacy audit.

The most important distinction between Audit and Provenance is the target audience (Security/Privacy vs Medical-Records); this is also recognized in the fact that the Audit is often only kept around for a few years. The Audit is only kept long enough to prove that the whole system is operating properly, that only authorized acts are happening.

There is some support for recording the reason the event happened. But they are both coded values to limit the potential unintended spilling of PII into the Audit log.
  1. ParticipantObject.ParticipantObjectDataLifeCycle -- indicates the lifecycle that the object is now in.
  2. Event.PurposeOfUse, (also being added through DICOM) -- indicate the purpose of use when the event happened.

Note that this use-case, deprecate without replacement, is explicitly troubling. The original design for XDS allowed only Replacement. In a Replacement transaction one can record in the new XDS entry why this entry is better than the old one. This transaction was intentionally  the only method, so that we always had a permanent  record of the deprecation. We even explained how to do a Replace with an empty document. The Metadata-Update supplement breaks this nice model, and thus leaves us with no way to record why the deprecation is happening. The XDS registry is the place where Provenance is recorded, the ATNA log is not permanent.

So it is important with ATNA to keep the log entry to as minimal information as possible, using coded values and identifiers (pointers) rather than textual descriptions. This keeps the risk that the audit log itself presents as minimal as possible, while still making the content useful for the Security and Privacy use-cases. As in those use-cases the codes and identifiers can be dereferenced, with authority and audit log entries.


Blog articles on Audit Control

Wednesday, July 15, 2015

How to set the ConfidentialityCode

I have been discussing the confidentialityCode, especially within the context of IHE-XD* (Document Sharing).  I was asked, by Keith, to give guidance on how the confidentialityCode should be set as without guidance he just tells everyone to use "N" (Normal confidentiality).

Some background articles:

Recommendation for setting confidentiatlityCode

So. I would continue to recommend that anyone or any-system publishing a CDA document should use "N", unless they have evidence to say that is the wrong value. Meaning it should be a specific effort to choose the other values:
  • "R", because there is specifically sensitive content – HIV, alcohol/drug abuse, etc.
  • "V", because the content should be seen only when reader is individually authorized -- psychology-notes, usually also used on all VIP patients (Not a best practice, but reality).
  • "M", because the content is less sensitive than normal, but still medical. authorized for wide distribution – like an emergency-data-set, or for dietary use-cases
  • "L", because the content is not medical, or has been de-identified
  • "U", because the content is not specific to an individual and is public

This is right out of the definition of the vocabulary values 2.16.840.1.113883.5.25 for "_confidentiality". Available from the FHIR specification for easy reading. https://www.hl7.org/fhir/v3/Confidentiality/index.html

How to determine what the value should be?

I don't disagree that this is a hard thing to determine.
  • It might be determined by workflow, psychology notes clearly are coming from a psychology workflow. 
  • Clearly de-identification is a specific workflow. 
  • It might be an explicit act, where the user is specifically trying to make a less-sensitive document for broad use such as a emergency-dataset, or 
  • for export to the dietician. 
  •  It might be a specific request, where the clinician decides that the data is very sensitive, or 
  • where the patient decides that the data is very sensitive. 
This is different than a patient choice in consent regarding rules applied to these different codes, meaning where a patient chooses a restrictive consent for their data accessibility. See http://healthcaresecprivacy.blogspot.com/p/topics.html#Privacy

The VHA has shown some success in demonstration projects with passing the data through a CDS (Clinical Decision Support) to tag sensitive clinical concepts. See FHIR Demonstration of DS4P. If none are found then the data is "N", if some are found then the data is "R", if specific types are found the data is "V"… This automated method has me somewhat worried as the social norms of what is sensitive, change often. So using this automated form on publication time might produce wrong evaluation overtime. In the case of the VHA demonstration, they applied it upon 'use' of the data, so it was using the social norms rules at the time of reading. Likely better social norm rules, but not sure this is better behavior. Note that the intermediate step is tagged sensitivity category, which might be given to the access control system as information to be used in the access control decision or enforcement

Is there more?

All the other security-tags are not likely to be set upon publication. IHE has brought in the whole of  the "Healthcare Privacy/Security Classification System"
  • IHE specifically recommends against using the sensitivity category, as the value itself is sensitive. They are useful for internal use, like the VHA demonstration.
  • Compartment is mostly undefined, but would likely be a local value-set. Unlikely to be understood at publication time. Interesting place to play, as it might be used to define compartments like Radiology, Cardiology, Psychology, etc... but it is untested grounds.
  • Integrity could be equally set by the publisher, although it is not well enough defined. But this would be a way to tag data that was generated by the patient, vs data generated by a licensed clinician.
  • Handling caveats might be set on publication. The only cases I can think of are similar to the "V" cases, in that the author explicitly knows something about the data and thus needs to add a caveat.
    • One specific example is 42CFR Part 2 – SAMSA covered treatment- that must be explicitly marked with a 'do not disclose without explicit authorization by the patient'. NOAUTH
    • Second specific example is an obligation to delete after use, which specifically forbids persistence (including printing) DELAU

Conclusion

So, simple guidance. You need all of the _confidentiality vocabulary, and two more from the handling caveats. -- [U, L, M, N, V, R] + NOAUTH + DELAU  

Blog articles by Topic



Friday, June 12, 2015

FHIR does not need a deidentify=true parameter

There has been a very short discussion of this topic on the FHIR Implementers skype. The question was asked if there was a need for FHIR to explicitly support de-identification. Fortunately Grahame is smart enough to say NO. I then added this detail.

What everyone keeps forgetting to recognize is just how hard it is to de-identify, and how easy it is to mess it up.

There is nothing preventing someone from creating an intermediary that looks like FHIR, and talks FHIR to the backend, while de-identifying the data according to some algorithm. However the algorithm is very use-case and risk specific.  This is the model IHE proposes, with a handbook to help with the algorithm selection, backed by ISO standard. De-Identification: process reduce risk of identification of entries in a data-set.

There is no need for a parameter  deidentify=true.... as you are already indicating WHO (OAuth) is making the query and why. This is information used by the Access Control Service, in keeping with enforcing RBAC, ABAC, Consents, and laws/regulations. This access control decision can determine that 'less' information shall be returned. Where 'less' is specific to the request, authentication, etc. Where 'less' might be a de-identification algorithm, or might be to return '200 zero results found'.

Unless one comes up with a NULL-set, you are leaving RISK in the de-identified data-set.

Other articles:


Wednesday, May 27, 2015

In Wisconsin we have Interoperability

There is much talk on the blogs about the USA government trepidation around Health Information Exchange interoperability. Some samples:
I live in Wisconsin, and it seems I live in one of the few areas where Health Information Exchange is alive and well. See below an interesting monthly report I get from the Wisconsin HIE. It shows the health of this system. A very healthy and Quality producing HIE: 2.6 Million Patients, Almost 15 Million Lab transactions, and Almost 200 Thousand Radiology transactions.
 
I am on the Technical Advisory Committee for WISHIN.

This is a Standards based HIE, based on IHE-XDS and XCA. Fully federated.

I also find it interesting that opt-out has only happened 33 times, total, out of 2.6 million patients. Yes, this is an 'implied consent' state. There are many ways offered for patients to opt-out. Note, one patient has chosen to opt back in...

John

From: Wisconsin Statewide Health Information Network [mailto:wishin@wishin.org]
Subject: WISHIN Connections - May 2015

WISHIN Banner

May 2015

Welcome to WISHIN Connections, the monthly e-Newsletter from the Wisconsin Statewide Health Information Network (WISHIN).  We will keep you up to date with WISHIN activities, news on health information exchange (HIE) and new product developments.

WISHIN Pulse Dashboard

Data through
April 30, 2015

Pulse Transaction Statistics

ADT Transactions: 65,635,193 

Lab/Pathology Reports: 14,710,937

Radiology Reports: 196,700

Transcribed Reports: 144,121

Public Health Syndromic 
Surveillance: 55,350,072

Pulse Patient Statistics

# of unique patients: 2,609,548

# of patients opted out: 33

# of patients opted back in: 1
   

Pulse User Statistics

# of Pulse Users: 1,018

Users Who Logged in 1+ Times in Month: 322

# of Chart Accesses in Month: 5,964

# of Unique Patients Queried in Month: 1,176





EKG Results Now Available Through WISHIN Pulse

<![if !vml]><![endif]>Earlier this month Ministry Health and Affinity Health System
became the first WISHIN clients to share EKG reports via WISHIN Pulse. This marks the first instance of adding attachments to Pulse messages. By adding a PDF of the EKG report, connected physicians are able to view EKG wave form images along with a cardiologist's interpretation of the results. Receiving both the wave form images and interpretations allow providers to make even more informed decisions about their patients' care plans. 

EHR Vendors Eliminate Fees; Ease Path to Interoperability

The path to statewide interoperability has become a bit easier with the announcement by several electronic health record (EHR) vendors that they would eliminate fees that caused concern for some health care organizations seeking to participate in health information exchange (HIE).

In April, the Office of the National Coordinator for Health Information Technology sent a report to Congress, criticizing information technology developers as well as health care organizations for "blocking" state and federal efforts at HIE.  Later in the month, Epic Systems, Athenahealth, and other EHR vendors announced plans to halt charges for interfaces and transactions related to HIE.

In its April 27th edition, Wisconsin Health News reported that Epic, the largest EHR vendor in Wisconsin, previously charged providers 20 cents for each clinical message sent to a health information exchange with inbound messages charged at a rate of $2.35 per patient per year. The vendor eliminated the fees retroactively to April 1 and plans to continue with no-charge data sharing until 2020.

Elimination of HIE-related fees is just one piece of the puzzle for interoperability. As Jitin Asnaanii, Executive Director of CommonWell Health Alliance points out, free exchange doesn't necessarily equal effective exchange. "There are two key factors that will drive real-world exchange and usage of health information," Asnaanii told Healthcare Dive, "(a) availability of functioning interoperability services to those who need them; and (b) access to the data when and where it is needed."

So while many EHR vendor fees have been eliminated for the moment, it remains to be seen if the vendors will also remove technical and practical barriers to exchange with other EHR vendors' products.

WISHIN's vendor-agnostic, one-to-many architecture advances true interoperability. One connection with WISHIN circumvents the complexity of multiple point-to-point connections between providers and delivers access to information from all other participating organizations. With clinical information for more than 2.6 million unique patients (and growing) WISHIN is a critical tool for advancing interoperability for seamless, complete and improved patient care statewide.
 



EHR Adoption Rates Help Wisconsin Rank Second in Nation for Health Care Quality

<![if !vml]><![endif]>In a report released early this month by the federal Agency for Healthcare Research and Quality (AHRQ) Wisconsin placed second among the 50 states in quality of health care. The report, which ranks states on more than 200 criteria, produces a score based on a state's achievements in relation to "achievable benchmarks in health care quality."

A number of Wisconsin's highest-scoring measures were related to electronic health record (EHR) use and capabilities in hospitals. In Wisconsin many hospitals were early adopters of EHR systems and the state scored 44% better than the national benchmark in "hospitals with computerized system that allows for electronic clinical documentation including physician notes." 

A high rate of EHR adoption is one of the factors that make Wisconsin poised to lead in development of successful statewide health information exchange (HIE) and achieve widespread interoperability.

HIE is positioned to thrive in Wisconsin because so many hospitals and providers have already digitized their health care information. As an independent, EHR-agnostic HIE utility, WISHIN is able to connect to any EHR system including those created by popular vendors such as Cerner, MEDITECH and Epic as well as those of smaller organizations or custom-built EHRs. One connection with WISHIN provides access to exchange and use information from all other participating organizations.

WISHIN can play a key role in continuing to advance health care quality in Wisconsin. WISHIN Pulse makes information available to those who need it, when they need it. Enabling vital information to follow patients wherever they seek care can mean better outcomes, fewer preventable readmissions, and lower administrative costs. 

HIT & HIE News


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: