-
Notifications
You must be signed in to change notification settings - Fork 9
/
privacy-security-faqs.html
113 lines (107 loc) · 14.1 KB
/
privacy-security-faqs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
<!DOCTYPE html>
<html>
<head>
<title>Blue Button Toolkit | FAQs on Privacy and Security</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<link rel="shortcut icon" href="favicon.ico">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/jquery-1.10.2.min.js">\x3C/script>')</script>
<link rel="stylesheet" href="css/bbtoolkit-combined.css">
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-23987631-4', 'auto');
ga('send', 'pageview');
$(document).on('click', 'a', function(evt) {
if (evt.isDefaultPrevented() || typeof ga !== "function") return;
var $self = $(this);
var href = $self.attr("href");
var target = $self.attr("target");
var text = $self.text();
// is this an outbound link?
if ((this.protocol === 'http:' || this.protocol === 'https:') && typeof href !== "undefined" && this.hostname !== "" && this.hostname.indexOf(document.location.hostname) === -1) {
evt.preventDefault();
window.waitingForGA = true;
setTimeout(loadPage, 1000);
ga('send', 'event', 'Outbound', this.hostname, this.pathname, 0, { hitCallback: loadPage });
} else { // internal link
ga('send', 'event', 'Links', 'Clicked', text);
}
function loadPage(){
if (window.waitingForGA) {
window.waitingForGA = false;
window.location = href; // ...and open the link as usual
}
}
});
</script>
</head>
<body>
<div class="section splash-section bg-white"><a href="index.html"><img src="img/bb-logo-depth.jpg" alt="Blue Button Logo" class="logo-big"></a>
<ul class="top-nav nav nav-pills pull-right">
<li><a href="index.html#faqs">Introduction</a></li>
<li><a href="privacy-security-faqs.html">Privacy and Security</a></li>
<li><a href="http://bluebuttonconnector.healthit.gov">Join the Movement</a></li>
</ul>
<div class="splash-title text-center">
<h1 class="fg-mblue">Blue Button<sup>®</sup> Toolkit</h1>
<h3 class="fg-mblue">Support Consumers in Getting <br>& Using Their Health Records</h3>
</div>
</div>
<div class="container readable-width"></div>
<div class="row">
<div class="col-md-offset-2 col-md-8">
<h1 class="fg-mblue">FAQs - Privacy and Security</h1>
<p>The U.S. Department of Health and Human Services’ Office for Civil Rights and Office of the National Coordinator have compiled the following document in response to questions related to the Automate Blue Button Initiative. This document will be periodically expanded upon, as more questions arise that we can address with existing guidance.</p>
<h3>Background</h3>
<p>Blue Button functionality provides data that follows Meaningful Use Stage 2’s requirements for sections and fields, formatted in Consolidated Clinical Document Architecture (Consolidated CDA). A Consolidated CDA contains a subset of protected health information (PHI) maintained in an individual’s medical records and therefore is a subset of a designated record set. Accordingly, under the HIPAA Privacy Rule, the individual who is the subject of the PHI has a right of access to the PHI in the Consolidated CDA. (We recognize that individuals continue to have the right to request and receive all their PHI in the medical records outside of the Consolidated CDA or Blue Button function.) For ease of reference, we will call the PHI in a Consolidated CDA “Blue Button health information” in our Use Cases and Questions and Answers below.</p>
<p>DIRECT is a set of technical specifications that allow providers and individuals to securely transmit PHI electronically. It is similar to e-mail, in that providers and patients each have “DIRECT addresses” that allow them to communicate with each other, but is more secure than regular e-mail. For example, a John Q. Public could have a Direct address (JohnQPublic@direct.somephr.org). Meaningful Use Stage 2 requires every certified Electronic Health Record system to be able to send messages to DIRECT addresses.</p>
<h3>Use cases
<ol>
<li> While interacting in person with his HIPAA-covered health care provider’s office the individual gives the provider either the individual’s e-mail address or a Direct address and requests the provider to electronically transmit the individual’s Blue Button health information to this e-mail or Direct address.</li>
<li>The individual has established an account with the portal of his HIPAA-covered health care provider and through that portal requests that the individual’s Blue Button health information be transmitted to the individual’s e-mail or Direct address.</li>
</ol>
</h3>
<h3>Preliminary Questions and Answers
<p class="fs-medium">1. What are HIPAA’s general requirements for verifying the individual’s identity when the individual requests that the health care provider furnish an electronic copy of the individual’s Blue Button health information?
<p>The Privacy Rule requires covered entities (including health care providers) to verify the identity and authority of a person requesting protected health information (PHI), if the identity or authority of the person is not already known to the provider. See 45 C.F.R. 164.514(h)(1). These verification requirements apply to individuals who request access to their PHI that is maintained in a designated record set, including PHI maintained by or for a covered entity that is available through the Blue Button function (Blue Button health information). The Privacy Rule does not include specific or technical verification requirements, largely allowing a covered entity’s professional judgment and industry standards to determine what is reasonable and appropriate under the circumstances.</p>
<p>In addition to the Privacy Rule’s verification requirements, where electronic access is being provided by or on behalf of a covered entity, the HIPAA Security Rule requires administrative safeguards be in place to authorize only appropriate persons to have access to the electronic protected health information (e-PHI) and technical safeguards be implemented to verify that a person seeking access to e-PHI is the one claimed. See 45 C.F.R. §§ 164.308(a)(4)(i) (information access management standard) and 164.312(d)) (person or entity authentication standard).</p>
<p class="fs-medium">a. What if the individual makes his or her request in person to have the health care provider electronically transmit the individual’s Blue Button health information to an e-mail or Direct address?</p>
<p>If the individual is not known to the covered entity, the covered entity (including a health care provider) is required to verify the identity of the individual requesting access before authorizing the access. Verification may be obtained either orally, or in writing. If the covered entity already knows the identity of the individual, it is not required to take additional steps to verify the individual’s identity.</p>
<p class="fs-medium">b. What if the individual’s identity was previously verified for purposes of establishing a web portal account with the health care provider and the individual requests their Blue Button health information from the provider through that portal?</p>
<p>Once the individual’s identity has been verified and the individual authorized to obtain electronic access to PHI through the web portal, the Security Rule also requires that a covered entity (including a health care provider) implement technical safeguards for verifying that when the individual seeks access through the portal, he or she is the one claimed (45 CFR 164.312(d)(1)). For example, a web portal could require the individual to enter a user name and password to access the individual’s health information.</p>
</p>
<p class="fs-medium">2. May a health care provider require individuals to submit in writing their requests that their Blue Button health information be transmitted to them?</p>
<p>Yes. The Privacy Rule allows covered entities (including health care providers) to require individuals to make requests for access in writing, provided that they inform the individual of such a requirement. See 45 C.F.R. § 164.524(b)(1). In addition, electronic documents qualify as written documents under the Privacy Rule. Thus, the Privacy Rule equally supports covered entities’ providing individuals with a means to request access to their Blue Button health information in paper (e.g., a note or a form) or through electronic means (e.g., e-mail, web portal).</p>
<p>As a practical matter, requiring that such requests be in writing may reduce errors and may serve as the covered entity’s record of the e-mail or Direct address to which the individual requested their information be sent.</p>
<p class="fs-medium">3. If an individual requests a machine-readable Consolidated CDA and the health care provider is able to readily furnish a copy in that format, must the provider furnish the copy of the data in this requested format?</p>
<p>Yes. The Privacy Rule requires covered entities (including health care providers) to provide access to the PHI in the form or format requested by the individual if it is readily producible in such form or format. See 45 C.F.R. § 164.524(c)(2).</p>
<p class="fs-medium">4. If an individual requests that a provider transmit their Blue Button health information via unencrypted e-mail, may the provider do so?</p>
<p>In e-mailing PHI to individuals, covered entities (including health care providers) are required to comply with the HIPAA Security Rule, which, among other requirements, requires implementation of technical security measures to guard against unauthorized access to e-PHI that is being transmitted over an electronic communications network. See 45 CFR 164.312(e). The Security Rule requires encryption when transmitting e- PHI where it is reasonable and appropriate to encrypt the information, and in general, encryption is a reasonable and appropriate measure to safeguard the e-PHI in e-mail transmissions. However, there may be instances where an individual may not want to receive his or her e-PHI encrypted. In these cases, covered entities are permitted to send e-PHI to individuals through unencrypted e-mails if they have advised the individual of the risk, and after doing so, the individual still requests that his or her e-PHI be sent through unencrypted e-mail.</p>
<p class="fs-medium">a. May a provider require written documentation that an individual has requested his or her Blue Button health information be sent via unencrypted e-mail, despite being advised of the risks of sending sensitive information through an unsecured transmission? For example, may a provider require an individual to sign a written request for access that includes provisions that 1) specify that the individual has requested to receive PHI via unencrypted e-mail versus in a more secure manner, 2) set out the potential security risks of sending unencrypted e-mail, and 3) state that the individual understands the risks and still wishes to receive PHI via unencrypted e-mail?</p>
<p>Yes. Covered entities (including health care providers) are permitted to require that individuals make access requests in writing, which may include documentation of an individual’s wish to receive his or her e-PHI via unencrypted e-mail even though the individual has been advised of the risks.</p>
<p class="fs-medium">5. Is a provider responsible for the security of Blue Button health information under the HIPAA Rules once it has been received by the individual?</p>
<p>A covered entity is not responsible for safeguarding e-PHI once it has been delivered to the destination designated by the individual.</p>
<p>Not in use case, but relevant for health plans: - Does an individual have a right of access to claims and other payment information about the individual maintained by a health plan?</p>
<p>An individual’s right of access applies to the PHI that is maintained in a covered entity’s designated record set(s). With respect to health plans, a designated record set includes the health plan’s enrollment, payment, claims adjudication, and case or medical management record systems, as well as any records used in whole or in part by or for the health plan to make decisions about the individual. A record is any item, collection, or grouping of information that includes PHI that is maintained, collected, used or disseminated by or for the covered entity. See 45 C.F.R. 164.501 (definition of “designated record set”).</p>
</h3>
</div>
</div>
<div class="section footer">
<div class="container">
<ul class="footer-links list-inline inline">
<li class="hidden-xs force-inline"><img src="img/bb-logo-depth-small-greybg.jpg" alt="small blue button logo" class="little-logo"></li>
<li><a href="mailto:bluebutton@hhs.gov?subject=Feedback%20on%20Blue%20Button%20Toolkit">Send feedback</a></li>
<li><a href="http://www.hhs.gov">Privacy Policy</a></li>
<li><a href="http://bluebuttonconnector.healthit.gov">Visit the Blue Button Connector</a></li>
</ul>
<p class="fs-xxsmall">The ‘Blue Button’ logo is a registered Service Mark of the U.S. Department of Health and Human Services.</p>
</div>
</div>
<script src="js/bbtoolkit-combined.min.js"></script>
</body>
</html>