<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Privacy &amp; Security Tiger Team Seeks Feedback on Framework for Electronic Health Information Exchange</title>
	<atom:link href="http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/feed/" rel="self" type="application/rss+xml" />
	<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/</link>
	<description>Federal Advisory Committee Act</description>
	<lastBuildDate>Mon, 16 Apr 2012 01:53:05 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dan Rode</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-2/#comment-3161</link>
		<dc:creator>Dan Rode</dc:creator>
		<pubDate>Thu, 12 May 2011 00:09:31 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3161</guid>
		<description>May 11, 2011

Paul Egerman, Co-Chair
Deven McGraw, Co-Chair
C/O HIT Policy Privacy and Security Tiger Team Blog

RE:  Comment on Policy and Technology Framework for Health Information Exchange

Ms. McGraw and Mr. Egerman:

The purpose of this letter is to respond to the Framework from the Tiger Team as requested.  The American Health Information Management Association (AHIMA) is a non-profit professional association made up of more than 62,000 individuals who are educated and certified in health information management (HIM) and have been engaged in the confidentiality and security of health information for over 83 years.  

Since AHIMA members are very interested in the use of electronic health information exchange (HIE), we have standing policy councils focused both on HIE as well as privacy and security.  Members of these councils have been involved in the development of this response.  Members of the councils as well as technical staff have reviewed the proposed Framework.  

Page 1 of 14:  Comments on Policy Principles:
•	Correction: While the term “correction” may have public meaning, changes to the content of a health record is usually referred to “amendment” in the healthcare industry.  When a record is amended, the information in error is identified as such but left in the record for a number of purposes.  The correct information is added to the record.  AHIMA recommends that when referring to this issue you use the term Correction/Amendment or note the use of the term “amendment” for better understanding. 
•	Individual choice:   HIPAA addresses the use and disclosure of health information.  There is limited if any ability for a provider to modify the collection of information – information is either collected or not collected.  Where it is stored and the use of the information is a different issue.  Record collection is important in the provider’s ability to render care. The health record is also a legal and business record for the provider. To withhold information from the record could result in harm to the individual or an accusation of fraud made against the provider.  We recommend that the term “collection” not be included in this section.   

Page 4 or 14:  “Correction”
•	See comment on Correction above.
•	The discussion under Policy-Current Law/Regulation: the Team needs to define:
o	When it is referring to paper versus electronic.
o	How a provider (record holder) would notify “persons” identified by the patient of an amendment.  Normally the provider would notify those to whom the amended information had been sent, by the provider not the patient. 

•	The Team needs to consider education and training regarding the notification of amendments. AHIMA members have no direct evidence, but given the current hybrid nature of healthcare we believe that amendments are not always conveyed as they should be.
•	There needs to be a consideration of where amendments should be considered and adjudicated.  AHIMA believes they should not take place in the network: rather, the amendment should be handled at the originator (provider) location.  This then presumes a tagging of data for origination and an accompanying nomenclature for such tags.   
•	Under Notes/Considerations – Bullet #2:
o	It should be clearly stated that total obliteration of a health record entry is not appropriate. The health record is a business record and falls under the Business Record Rule of the Rules of Evidence. Consumers often have the false expectation that an amended or corrected health record entry can be totally obliterated. HL7 and ASTM standards provide guidance on how to establish directories for the original incorrect entry, with flagging models for amended or corrected entries.
o	When an entry belongs to a different patient and is removed before any action is taken based on that entry, documentation of such an event should exist but should not be part of the patient&#039;s record and should not be visible except in the audit trail. To leave such an entry visible but labeled as an error:
	Puts the patient at risk if the provider misses the notation that it is an error
	Creates potential problems for the patient particularly with insurance carriers that often believe that &quot;where there is smoke there is fire.&quot;

Page 5 of 14: Openness and Transparency-Current Law/Regulation
•	Currently, accounting of disclosures is rarely requested and in general tracking for TPO is not a HIPAA requirement.  Accordingly, very few EHR systems have such capability for all disclosures.  ARRA-HITECH proposed rules have not been released and there has been little industry discussion regarding how disclosures can be tracked especially in larger organizations where disclosure may occur for TPO from a number of locations and different HIPAA entities.  This is both a policy and a technology issue.

Page 5 of 14: Openness and Transparency- Recommendations
•	Bullet #1:  AHIMA recommends provider and consumer education on definition and use of de-identified data.  The concepts are not understood by a number of healthcare providers let alone patients and third party service organizations.  
•	Bullet#2:  AHIMA suggests that it is time to extend HIPAA requirements to all holders of protected health information if consumer trust is to be met.  There should be no category of healthcare provider that is not covered by the HIPAA privacy and security rules. 
•	Bullet #3:  Define “indirect exchange model.” 
•	Bullet #3:   Purposes for which exchange can occur are being changed constantly, as are exchange participants and technology partners, a definite issue in keeping hard copy information available – web site info with the ability for the patient to print should cover it, and maybe an annual signoff indicating they know where to find it if they want it. There is no way that a NwHIN participant can reasonably keep a listing of all the potential indirect participants.  If the level of HIEs gets to 225-250-plus keeping a list of the possible exchange partners becomes illogical and probably complicated for the individual to understand. 
•	Bullet #4:  AHIMA suggests changing “anticipate exchange activities” to “reasonably anticipated exchange activities.” 
•	Bullet #6:  This item needs to be expanded in some way to cover other entities such as OCAs and Medical Homes.  Given that there could be even more entities in the not too distant future OHCA may be too narrow an approach.

Page 8 of 14: Individual Choice – Notes/Considerations
•	Bullet #2:  
o	Define “independent consent.”
o	There should be a defined list of “common” exchanges so that the provider can better communicate with the individual. 
o	Is there a potential for a third party – say Medicare or Medicaid – to require consent?  

Page 10 of 14: Notes/Considerations
•	General Comment: Presuming that data can be de-identified then data collection could change over time especially if one of the goals of electronic health records and interoperable health terminologies and classifications is to improve population health and gaining a body of knowledge to improve treatment, patient safety, etc.  These types of secondary data use are different than that associated, perhaps, with treatment, payment, or operations.  Programs like genomics and organizations of data like ACOs are moving so rapidly that being able to define all the purposes (to what degree) becomes almost impossible, especially if science is going to be able to look at legacy data.  There needs to be some flexibility in the approach to specification and there needs to be a reduction in the silos that surround public health and medical studies that are necessary to address health and treatment improvement and outcomes.  

Page 13 of 14: Safeguards – Recommendations
•	Bullet #2:  How will a provider attest to their relationship with a patient? Each time the provider makes a request?  Will this vary with emergency department physicians?   Will this vary in an ACO network or within an HIEO (but not for requests outside of that HIEO)?  

AHIMA and its members appreciate this opportunity to comment on the Policy and Technology Framework for Health Information Exchange and the efforts of the Tiger Team to address this complicated and changing subject.  We hope these comments are helpful.  If you have further questions on these comments or on the subject of privacy and security in HIEs, please contact me (dan.rode@ahima.org), or in my absence either Harry Rhodes, AHIMA’s director for practice leadership at harry.rhodes@ahima.org, or Allison Viola, AHIMA’s director for federal affairs at allison.viola@ahima.org.  

Thank you for your review and consideration of these comments.

Sincerely,


Dan Rode, MBA, CHPS, FHFMA
Vice President, Policy and Government Relations

Cc:  Harry Rhodes, MBA, RHIA, CHPS, CPHIMS, FAHIMA
        Allison Viola, MBA, RHIA</description>
		<content:encoded><![CDATA[<p>May 11, 2011</p>
<p>Paul Egerman, Co-Chair<br />
Deven McGraw, Co-Chair<br />
C/O HIT Policy Privacy and Security Tiger Team Blog</p>
<p>RE:  Comment on Policy and Technology Framework for Health Information Exchange</p>
<p>Ms. McGraw and Mr. Egerman:</p>
<p>The purpose of this letter is to respond to the Framework from the Tiger Team as requested.  The American Health Information Management Association (AHIMA) is a non-profit professional association made up of more than 62,000 individuals who are educated and certified in health information management (HIM) and have been engaged in the confidentiality and security of health information for over 83 years.  </p>
<p>Since AHIMA members are very interested in the use of electronic health information exchange (HIE), we have standing policy councils focused both on HIE as well as privacy and security.  Members of these councils have been involved in the development of this response.  Members of the councils as well as technical staff have reviewed the proposed Framework.  </p>
<p>Page 1 of 14:  Comments on Policy Principles:<br />
•	Correction: While the term “correction” may have public meaning, changes to the content of a health record is usually referred to “amendment” in the healthcare industry.  When a record is amended, the information in error is identified as such but left in the record for a number of purposes.  The correct information is added to the record.  AHIMA recommends that when referring to this issue you use the term Correction/Amendment or note the use of the term “amendment” for better understanding.<br />
•	Individual choice:   HIPAA addresses the use and disclosure of health information.  There is limited if any ability for a provider to modify the collection of information – information is either collected or not collected.  Where it is stored and the use of the information is a different issue.  Record collection is important in the provider’s ability to render care. The health record is also a legal and business record for the provider. To withhold information from the record could result in harm to the individual or an accusation of fraud made against the provider.  We recommend that the term “collection” not be included in this section.   </p>
<p>Page 4 or 14:  “Correction”<br />
•	See comment on Correction above.<br />
•	The discussion under Policy-Current Law/Regulation: the Team needs to define:<br />
o	When it is referring to paper versus electronic.<br />
o	How a provider (record holder) would notify “persons” identified by the patient of an amendment.  Normally the provider would notify those to whom the amended information had been sent, by the provider not the patient. </p>
<p>•	The Team needs to consider education and training regarding the notification of amendments. AHIMA members have no direct evidence, but given the current hybrid nature of healthcare we believe that amendments are not always conveyed as they should be.<br />
•	There needs to be a consideration of where amendments should be considered and adjudicated.  AHIMA believes they should not take place in the network: rather, the amendment should be handled at the originator (provider) location.  This then presumes a tagging of data for origination and an accompanying nomenclature for such tags.<br />
•	Under Notes/Considerations – Bullet #2:<br />
o	It should be clearly stated that total obliteration of a health record entry is not appropriate. The health record is a business record and falls under the Business Record Rule of the Rules of Evidence. Consumers often have the false expectation that an amended or corrected health record entry can be totally obliterated. HL7 and ASTM standards provide guidance on how to establish directories for the original incorrect entry, with flagging models for amended or corrected entries.<br />
o	When an entry belongs to a different patient and is removed before any action is taken based on that entry, documentation of such an event should exist but should not be part of the patient&#8217;s record and should not be visible except in the audit trail. To leave such an entry visible but labeled as an error:<br />
	Puts the patient at risk if the provider misses the notation that it is an error<br />
	Creates potential problems for the patient particularly with insurance carriers that often believe that &#8220;where there is smoke there is fire.&#8221;</p>
<p>Page 5 of 14: Openness and Transparency-Current Law/Regulation<br />
•	Currently, accounting of disclosures is rarely requested and in general tracking for TPO is not a HIPAA requirement.  Accordingly, very few EHR systems have such capability for all disclosures.  ARRA-HITECH proposed rules have not been released and there has been little industry discussion regarding how disclosures can be tracked especially in larger organizations where disclosure may occur for TPO from a number of locations and different HIPAA entities.  This is both a policy and a technology issue.</p>
<p>Page 5 of 14: Openness and Transparency- Recommendations<br />
•	Bullet #1:  AHIMA recommends provider and consumer education on definition and use of de-identified data.  The concepts are not understood by a number of healthcare providers let alone patients and third party service organizations.<br />
•	Bullet#2:  AHIMA suggests that it is time to extend HIPAA requirements to all holders of protected health information if consumer trust is to be met.  There should be no category of healthcare provider that is not covered by the HIPAA privacy and security rules.<br />
•	Bullet #3:  Define “indirect exchange model.”<br />
•	Bullet #3:   Purposes for which exchange can occur are being changed constantly, as are exchange participants and technology partners, a definite issue in keeping hard copy information available – web site info with the ability for the patient to print should cover it, and maybe an annual signoff indicating they know where to find it if they want it. There is no way that a NwHIN participant can reasonably keep a listing of all the potential indirect participants.  If the level of HIEs gets to 225-250-plus keeping a list of the possible exchange partners becomes illogical and probably complicated for the individual to understand.<br />
•	Bullet #4:  AHIMA suggests changing “anticipate exchange activities” to “reasonably anticipated exchange activities.”<br />
•	Bullet #6:  This item needs to be expanded in some way to cover other entities such as OCAs and Medical Homes.  Given that there could be even more entities in the not too distant future OHCA may be too narrow an approach.</p>
<p>Page 8 of 14: Individual Choice – Notes/Considerations<br />
•	Bullet #2:<br />
o	Define “independent consent.”<br />
o	There should be a defined list of “common” exchanges so that the provider can better communicate with the individual.<br />
o	Is there a potential for a third party – say Medicare or Medicaid – to require consent?  </p>
<p>Page 10 of 14: Notes/Considerations<br />
•	General Comment: Presuming that data can be de-identified then data collection could change over time especially if one of the goals of electronic health records and interoperable health terminologies and classifications is to improve population health and gaining a body of knowledge to improve treatment, patient safety, etc.  These types of secondary data use are different than that associated, perhaps, with treatment, payment, or operations.  Programs like genomics and organizations of data like ACOs are moving so rapidly that being able to define all the purposes (to what degree) becomes almost impossible, especially if science is going to be able to look at legacy data.  There needs to be some flexibility in the approach to specification and there needs to be a reduction in the silos that surround public health and medical studies that are necessary to address health and treatment improvement and outcomes.  </p>
<p>Page 13 of 14: Safeguards – Recommendations<br />
•	Bullet #2:  How will a provider attest to their relationship with a patient? Each time the provider makes a request?  Will this vary with emergency department physicians?   Will this vary in an ACO network or within an HIEO (but not for requests outside of that HIEO)?  </p>
<p>AHIMA and its members appreciate this opportunity to comment on the Policy and Technology Framework for Health Information Exchange and the efforts of the Tiger Team to address this complicated and changing subject.  We hope these comments are helpful.  If you have further questions on these comments or on the subject of privacy and security in HIEs, please contact me (dan.rode@ahima.org), or in my absence either Harry Rhodes, AHIMA’s director for practice leadership at <a href="mailto:harry.rhodes@ahima.org">harry.rhodes@ahima.org</a>, or Allison Viola, AHIMA’s director for federal affairs at <a href="mailto:allison.viola@ahima.org">allison.viola@ahima.org</a>.  </p>
<p>Thank you for your review and consideration of these comments.</p>
<p>Sincerely,</p>
<p>Dan Rode, MBA, CHPS, FHFMA<br />
Vice President, Policy and Government Relations</p>
<p>Cc:  Harry Rhodes, MBA, RHIA, CHPS, CPHIMS, FAHIMA<br />
        Allison Viola, MBA, RHIA</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3161" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3161-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3161" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3161-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3161-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Jack Campbell</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-2/#comment-3159</link>
		<dc:creator>Jack Campbell</dc:creator>
		<pubDate>Wed, 11 May 2011 23:53:57 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3159</guid>
		<description>1. The “Don’t let ‘perfect’ be the enemy of ‘good enough’” principle:
Request that the TT add “procedures” in the list: “(meds, procedures, problems, allergies, labs)”.

 We would reword this to “Go for 80% of the feature set…”. Eighty percent of a “full” HIE may be acceptable, but eighty percent of a trust model, or eighty percent of the patient records being matched correctly, are insufficient.

Where alternative solution designs exist, interoperability between solutions should be a requirement.

2. “Separate content and transmission standards” principle: While we agree with this separation, it is essential that the government leverage their role and specify sufficient content standards to achieve semantic interoperability.

3. “Create publicly available vocabularies &amp; code sets” principle:
Where appropriate, we should leverage existing, publically and readily available vocabularies and codes sets and avoid proprietary and expensive code sets (e.g., CPT4), which will add a significant burden to participation.

Recommend renaming the principle to “Adopt publicly available vocabularies and code sets”.

4. “Position quality measures so they motivate standards adoption” principle:
We agree that the ability to measure and report quality should be an automated by-product of certified technologies. To that end, the quality measures used in current technologies do not use all available code sets and vocabularies to support the reporting of these measures.

For example, numerators that can only be satisfied by SNOMED codes will result in underreporting or increase the burden for providers and vendors to support since most of current technologies do not currently use SNOMED codes.

Revisit existing quality measures and ensure they are viable to capture. For example, most hospices don’t have an EMR.

5. “Individual Access” principle:
Agree with the principle, but “Readable form and format”, as an objective doesn’t go far enough. The industry should adopt semantically interoperable standards, such as C32 (or CDA “level 3”) documents.

We urge the TT to include in its Policy column “Adopt semantically interoperable standards” and to recommend specific standards, thus making interoperability a strategy for standardization.
Recommend the TT amend the description to be “human readable form and format”.

6. Correction principle:
We agree with the need for the ability of individuals to dispute the accuracy or integrity of PHR. The larger issue is the downstream implication of reporting or notifying others who need to be aware of the correction. How do we envision that technologies should facilitate the downstream propagation of the correction?

Such a system may require attribution of the authoritative source of the IIHI. The question is whether the Privacy-Security Framework would, could, or should enable such a potentially massive record-lookup system. We would like to see TT list their choice of alternatives in their recommendations.

7. Openness and Transparency principle:
We agree with the principle, but don’t agree that the ‘technologies’ should be included in the list, due to security reasons – transparency in which technologies are used may be divulging too much – putting IT systems at risk.

In Openness and Transparency &gt; Tiger Team Recommendations page &gt; Policy &gt; bullet 2: “Requesting providers who are not covered…should disclose this…”: Instead of having the non-covered entity disclose itself as “non-covered”, has the TT considered a selection of valid recipient roles (e.g. Covered Entity / Business Associate / Law Enforcement / etc.) for status attestation to occur before the exchange?

In Openness and Transparency &gt; Tiger Team Recommendations page &gt; Policy: In bullet 6, “Patients…ability to obtain more detailed information…including a list of other entities in the OHCA that “have access to” their information” (a priori). Those that already have accessed their information (a posteriori) is the “ideal” that is specified in bullet 4. 

It would be best to describe the objective here. These are potentially enormously expensive to retrofit and coordinate. Is the objective only to identify who has access in the OHCA only? Or is the ideal to have complete traceability through the chain of access? We would like to see scope clarification, and a Technology Implementation listed for a priori and a posteriori access.

8. Collection, Use and Disclosure Limitation: This topic, like many of the topics covered herein, should be regarded as a “living topic” that should evolve over time to reflect new requirements, not as a one-time, static, issue. Organizations change the way data is used on a regular basis and those new uses should be tied back to the disclosure agreements. For example, the use of existing data for ACOs is a new use for many organizations and should trigger a review of the adequacy of existing consent processes. Our concern is the lack of consistent state and federal law related to collection, use and disclosure

9. Data Quality and Integrity: Agreed. Suggest that data integrity should be defined as including “completeness of the medical record”. The data integrity and quality principal seems at odds with the current fundamental design of the Direct Project, but is a primary use case of the NHIN/NwHIN Exchange.

The TT Recommendations list “Five categories of recommendations for patient matching” but provide no technologies or enforcement levers. Given the level of fraud and the complex nature of human identity, the “Technology Implications” and the “Accountability and Oversight” columns should include those standards that address patient/identity matching. One possible candidate is the National Strategy for Trusted Identities in Cyberspace (NSTIC).

10. Safeguards principle:
Agreed. Some small physician offices have a critical lack of IT support, and an associated lack of awareness of proper risk assessments, mitigation, etc. See the State of California CalOHii for a template of what can be done in this regard (where they’ve created a state-wide template for all participants in HIE to follow related to basic risk mitigation).

11. Accountability Policy Principle:
Agreed. Suggest that IHE standards such as ATNA be leveraged as they are globally accepted and implemented widely.

The Accountability principle’s description isn’t very clear. It could say something like “Perform appropriate oversight, logging, monitoring, and detection (automated or manual) of non-adherence and breaches, to enable triggering a mitigation response”, or something similar. Consider adding TT Recommendations for Accountability specifying the as minimum floor requirements that enable breach forensics: logging to capture the requesting identity, date, system accessed, subject, etc.</description>
		<content:encoded><![CDATA[<p>1. The “Don’t let ‘perfect’ be the enemy of ‘good enough’” principle:<br />
Request that the TT add “procedures” in the list: “(meds, procedures, problems, allergies, labs)”.</p>
<p> We would reword this to “Go for 80% of the feature set…”. Eighty percent of a “full” HIE may be acceptable, but eighty percent of a trust model, or eighty percent of the patient records being matched correctly, are insufficient.</p>
<p>Where alternative solution designs exist, interoperability between solutions should be a requirement.</p>
<p>2. “Separate content and transmission standards” principle: While we agree with this separation, it is essential that the government leverage their role and specify sufficient content standards to achieve semantic interoperability.</p>
<p>3. “Create publicly available vocabularies &amp; code sets” principle:<br />
Where appropriate, we should leverage existing, publically and readily available vocabularies and codes sets and avoid proprietary and expensive code sets (e.g., CPT4), which will add a significant burden to participation.</p>
<p>Recommend renaming the principle to “Adopt publicly available vocabularies and code sets”.</p>
<p>4. “Position quality measures so they motivate standards adoption” principle:<br />
We agree that the ability to measure and report quality should be an automated by-product of certified technologies. To that end, the quality measures used in current technologies do not use all available code sets and vocabularies to support the reporting of these measures.</p>
<p>For example, numerators that can only be satisfied by SNOMED codes will result in underreporting or increase the burden for providers and vendors to support since most of current technologies do not currently use SNOMED codes.</p>
<p>Revisit existing quality measures and ensure they are viable to capture. For example, most hospices don’t have an EMR.</p>
<p>5. “Individual Access” principle:<br />
Agree with the principle, but “Readable form and format”, as an objective doesn’t go far enough. The industry should adopt semantically interoperable standards, such as C32 (or CDA “level 3”) documents.</p>
<p>We urge the TT to include in its Policy column “Adopt semantically interoperable standards” and to recommend specific standards, thus making interoperability a strategy for standardization.<br />
Recommend the TT amend the description to be “human readable form and format”.</p>
<p>6. Correction principle:<br />
We agree with the need for the ability of individuals to dispute the accuracy or integrity of PHR. The larger issue is the downstream implication of reporting or notifying others who need to be aware of the correction. How do we envision that technologies should facilitate the downstream propagation of the correction?</p>
<p>Such a system may require attribution of the authoritative source of the IIHI. The question is whether the Privacy-Security Framework would, could, or should enable such a potentially massive record-lookup system. We would like to see TT list their choice of alternatives in their recommendations.</p>
<p>7. Openness and Transparency principle:<br />
We agree with the principle, but don’t agree that the ‘technologies’ should be included in the list, due to security reasons – transparency in which technologies are used may be divulging too much – putting IT systems at risk.</p>
<p>In Openness and Transparency &gt; Tiger Team Recommendations page &gt; Policy &gt; bullet 2: “Requesting providers who are not covered…should disclose this…”: Instead of having the non-covered entity disclose itself as “non-covered”, has the TT considered a selection of valid recipient roles (e.g. Covered Entity / Business Associate / Law Enforcement / etc.) for status attestation to occur before the exchange?</p>
<p>In Openness and Transparency &gt; Tiger Team Recommendations page &gt; Policy: In bullet 6, “Patients…ability to obtain more detailed information…including a list of other entities in the OHCA that “have access to” their information” (a priori). Those that already have accessed their information (a posteriori) is the “ideal” that is specified in bullet 4. </p>
<p>It would be best to describe the objective here. These are potentially enormously expensive to retrofit and coordinate. Is the objective only to identify who has access in the OHCA only? Or is the ideal to have complete traceability through the chain of access? We would like to see scope clarification, and a Technology Implementation listed for a priori and a posteriori access.</p>
<p>8. Collection, Use and Disclosure Limitation: This topic, like many of the topics covered herein, should be regarded as a “living topic” that should evolve over time to reflect new requirements, not as a one-time, static, issue. Organizations change the way data is used on a regular basis and those new uses should be tied back to the disclosure agreements. For example, the use of existing data for ACOs is a new use for many organizations and should trigger a review of the adequacy of existing consent processes. Our concern is the lack of consistent state and federal law related to collection, use and disclosure</p>
<p>9. Data Quality and Integrity: Agreed. Suggest that data integrity should be defined as including “completeness of the medical record”. The data integrity and quality principal seems at odds with the current fundamental design of the Direct Project, but is a primary use case of the NHIN/NwHIN Exchange.</p>
<p>The TT Recommendations list “Five categories of recommendations for patient matching” but provide no technologies or enforcement levers. Given the level of fraud and the complex nature of human identity, the “Technology Implications” and the “Accountability and Oversight” columns should include those standards that address patient/identity matching. One possible candidate is the National Strategy for Trusted Identities in Cyberspace (NSTIC).</p>
<p>10. Safeguards principle:<br />
Agreed. Some small physician offices have a critical lack of IT support, and an associated lack of awareness of proper risk assessments, mitigation, etc. See the State of California CalOHii for a template of what can be done in this regard (where they’ve created a state-wide template for all participants in HIE to follow related to basic risk mitigation).</p>
<p>11. Accountability Policy Principle:<br />
Agreed. Suggest that IHE standards such as ATNA be leveraged as they are globally accepted and implemented widely.</p>
<p>The Accountability principle’s description isn’t very clear. It could say something like “Perform appropriate oversight, logging, monitoring, and detection (automated or manual) of non-adherence and breaches, to enable triggering a mitigation response”, or something similar. Consider adding TT Recommendations for Accountability specifying the as minimum floor requirements that enable breach forensics: logging to capture the requesting identity, date, system accessed, subject, etc.</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3159" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3159-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3159" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3159-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3159-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: The Statewide HIE Coalition</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3155</link>
		<dc:creator>The Statewide HIE Coalition</dc:creator>
		<pubDate>Wed, 11 May 2011 22:09:01 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3155</guid>
		<description>Dear Ms. McGraw and Mr. Egerman,

The Statewide HIE Coalition appreciates the opportunity to comment on gaps in the Privacy and Security Tiger Team’s privacy and security framework for electronic health information exchange (the “framework”).

The Statewide HIE Coalition (the “Coalition”) is a coalition of states and state-designated entities (“SDEs”) with advanced health information exchange (“HIE”) plans or capacity that are working to build the infrastructure necessary for nationwide adoption and meaningful use of health information technology (“health IT”).  The HIE networks being developed and operated by Coalition members provide integral infrastructure for health care providers to reach outside of their clinical practice sites and connect with other points of care.  

Ensuring the privacy and security of electronic HIE is an important aim that we all share, and it is one on which the success of nationwide electronic HIE hinges.  Differences in privacy and security practices – often driven by differences in state laws governing medical record disclosure – create one of the biggest obstacles to widespread, interoperable HIE.  We applaud the Tiger Team for working toward a solution to this challenge.

The Tiger Team has covered a significant amount of ground, having issued recommendations to the Health IT Policy Committee on issues related to patient consent, transparency about health care provider participation in HIE, and individual user and organization-level authentication, among the many others included in the framework.  In evaluating where there are gaps that still need to be filled, we need to better understand the context in which the framework is being developed.  

We understand that the framework may be incorporated into a set of initial “conditions of trust and interoperability” or “COTIs” for the Nationwide Health Information Network (“Nw-HIN”).  According to the Governance Workgroup of the Health IT Policy Committee, which recommended the creation of COTIs as part of a larger Nw-HIN governance strategy, Nw-HIN is “a set of policies, standards, and services that enable the Internet to be used for secure and meaningful exchange of health information to improve health and health care.”  The Governance Workgroup has further indicated that “any entity, large or small, or aggregation of entities, large or small, that engages in the exchange of health information, asserts itself as being Nw-HIN compliant and is recognized to have met Nw-HIN COTIs” would be considered “part of Nw-HIN.”  

Thus, we understand that to the extent electronic HIE that is performed through statewide, regional and local HIE networks, such as those funded under the State HIE Cooperative Agreement Program, is asserted to be Nw-HIN compliant, the framework will apply to it.  But how will ONC enforce compliance?  For participants in NHIN Exchange who are also “part of Nw-HIN,” how will the COTIs relate to the requirements of the Data Use and Reciprocal Support Agreement (the “DURSA”)?  Will one trump the other in instances of overlap?  Answers to these fundamental questions will go a long way toward helping us identify additional areas for policy development.

These contextual questions aside, we provide the following suggestions to fill existing gaps in the framework:

1.  Consider whether the Tiger Team’s recommendations can be operationalized by HIE networks funded under the State HIE Cooperative Agreement Program:  We appreciate that the Tiger Team’s charge is to issue policy recommendations, but, as the Tiger Team knows, policy is often inextricably linked to operations. We therefore ask the Tiger Team to develop a mechanism to consider how its recommendations can be operationalized by HIE networks funded under the State HIE Cooperative Agreement Program before they are finalized.  For example, the Tiger Team has recommended that “requesting providers who are not covered under the [Health Insurance Portability and Accountability Act] should disclose this to the disclosing provider before patient information is exchanged.”  We would like to have a formal mechanism to work with the Tiger Team to determine exactly how a recommendation like this could be accomplished in a pull-model exchange environment before it is adopted by the Health IT Policy Committee.

2.  Focus on enabling HIE across state boundaries:  While we appreciate that HIE is local, and our members have been adopting policies that apply within the boundaries of our states, we aspire to exchange information across state borders. We believe that nationwide COTIs are a good first step but harmonization of state privacy and security law variation will be needed to truly achieve this goal.  Therefore, we ask the Tiger Team to ask ONC to consider developing strategies, such as model legislation, interstate compacts, and/or model data sharing agreements, to begin to address differences in state medical record disclosure and other laws, which stand as a formidable barrier to truly nationwide HIE.

Thank you for the opportunity to submit these comments, the signatories to which are listed below.  We hope that this feedback is useful, and would be happy to discuss it in more detail.  Please do not hesitate to contact us if we may be of any assistance.

Sincerely,

Hawai&#039;i Health Information Exchange
HealthInfoNet
Department of Vermont Health Access
Florida Agency for Health Care Administration
Maryland Health Care Commission
Minnesota Department of Health
Minnesota Department of Human Services
Missouri Health Connection
Nebraska Health Information Initiative
New York Office of Health Information Technology Transformation
Office of Health IT, Oregon Health Authority
Utah Department of Health
Utah Health Information Network</description>
		<content:encoded><![CDATA[<p>Dear Ms. McGraw and Mr. Egerman,</p>
<p>The Statewide HIE Coalition appreciates the opportunity to comment on gaps in the Privacy and Security Tiger Team’s privacy and security framework for electronic health information exchange (the “framework”).</p>
<p>The Statewide HIE Coalition (the “Coalition”) is a coalition of states and state-designated entities (“SDEs”) with advanced health information exchange (“HIE”) plans or capacity that are working to build the infrastructure necessary for nationwide adoption and meaningful use of health information technology (“health IT”).  The HIE networks being developed and operated by Coalition members provide integral infrastructure for health care providers to reach outside of their clinical practice sites and connect with other points of care.  </p>
<p>Ensuring the privacy and security of electronic HIE is an important aim that we all share, and it is one on which the success of nationwide electronic HIE hinges.  Differences in privacy and security practices – often driven by differences in state laws governing medical record disclosure – create one of the biggest obstacles to widespread, interoperable HIE.  We applaud the Tiger Team for working toward a solution to this challenge.</p>
<p>The Tiger Team has covered a significant amount of ground, having issued recommendations to the Health IT Policy Committee on issues related to patient consent, transparency about health care provider participation in HIE, and individual user and organization-level authentication, among the many others included in the framework.  In evaluating where there are gaps that still need to be filled, we need to better understand the context in which the framework is being developed.  </p>
<p>We understand that the framework may be incorporated into a set of initial “conditions of trust and interoperability” or “COTIs” for the Nationwide Health Information Network (“Nw-HIN”).  According to the Governance Workgroup of the Health IT Policy Committee, which recommended the creation of COTIs as part of a larger Nw-HIN governance strategy, Nw-HIN is “a set of policies, standards, and services that enable the Internet to be used for secure and meaningful exchange of health information to improve health and health care.”  The Governance Workgroup has further indicated that “any entity, large or small, or aggregation of entities, large or small, that engages in the exchange of health information, asserts itself as being Nw-HIN compliant and is recognized to have met Nw-HIN COTIs” would be considered “part of Nw-HIN.”  </p>
<p>Thus, we understand that to the extent electronic HIE that is performed through statewide, regional and local HIE networks, such as those funded under the State HIE Cooperative Agreement Program, is asserted to be Nw-HIN compliant, the framework will apply to it.  But how will ONC enforce compliance?  For participants in NHIN Exchange who are also “part of Nw-HIN,” how will the COTIs relate to the requirements of the Data Use and Reciprocal Support Agreement (the “DURSA”)?  Will one trump the other in instances of overlap?  Answers to these fundamental questions will go a long way toward helping us identify additional areas for policy development.</p>
<p>These contextual questions aside, we provide the following suggestions to fill existing gaps in the framework:</p>
<p>1.  Consider whether the Tiger Team’s recommendations can be operationalized by HIE networks funded under the State HIE Cooperative Agreement Program:  We appreciate that the Tiger Team’s charge is to issue policy recommendations, but, as the Tiger Team knows, policy is often inextricably linked to operations. We therefore ask the Tiger Team to develop a mechanism to consider how its recommendations can be operationalized by HIE networks funded under the State HIE Cooperative Agreement Program before they are finalized.  For example, the Tiger Team has recommended that “requesting providers who are not covered under the [Health Insurance Portability and Accountability Act] should disclose this to the disclosing provider before patient information is exchanged.”  We would like to have a formal mechanism to work with the Tiger Team to determine exactly how a recommendation like this could be accomplished in a pull-model exchange environment before it is adopted by the Health IT Policy Committee.</p>
<p>2.  Focus on enabling HIE across state boundaries:  While we appreciate that HIE is local, and our members have been adopting policies that apply within the boundaries of our states, we aspire to exchange information across state borders. We believe that nationwide COTIs are a good first step but harmonization of state privacy and security law variation will be needed to truly achieve this goal.  Therefore, we ask the Tiger Team to ask ONC to consider developing strategies, such as model legislation, interstate compacts, and/or model data sharing agreements, to begin to address differences in state medical record disclosure and other laws, which stand as a formidable barrier to truly nationwide HIE.</p>
<p>Thank you for the opportunity to submit these comments, the signatories to which are listed below.  We hope that this feedback is useful, and would be happy to discuss it in more detail.  Please do not hesitate to contact us if we may be of any assistance.</p>
<p>Sincerely,</p>
<p>Hawai&#8217;i Health Information Exchange<br />
HealthInfoNet<br />
Department of Vermont Health Access<br />
Florida Agency for Health Care Administration<br />
Maryland Health Care Commission<br />
Minnesota Department of Health<br />
Minnesota Department of Human Services<br />
Missouri Health Connection<br />
Nebraska Health Information Initiative<br />
New York Office of Health Information Technology Transformation<br />
Office of Health IT, Oregon Health Authority<br />
Utah Department of Health<br />
Utah Health Information Network</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3155" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3155-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3155" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3155-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3155-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Sadie Peterson</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3154</link>
		<dc:creator>Sadie Peterson</dc:creator>
		<pubDate>Wed, 11 May 2011 21:04:05 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3154</guid>
		<description>Ted Boyle, formerly Data Protection and IT Security Officer with NHS Scotland, has recently written a piece entitled “Privacy Lessons Learned from an Operational Health Information Exchange.”  The goal is to help providers investing in health information exchanges and electronic health records to fully understand the privacy implications of broad-scale electronic access to protected patient information. Lessons learned from NHS Scotland’s fully operational HIE deployment could save the healthcare industry time, money and reputation.

As the Privacy and Security Tiger Team fleshes out the privacy and security policies, Ted’s experiences may prove valuable.  To download the full paper, please visit http://www.fairwarningaudit.com/documents/2011-WHITEPAPER-HIE-NHS-SCOTLAND.pdf&lt;/a&gt; &lt;img src=&quot;http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true&quot; border=&quot;0&quot; alt=&quot;Exit Disclaimer&quot; /&gt;  
</description>
		<content:encoded><![CDATA[<p>Ted Boyle, formerly Data Protection and IT Security Officer with NHS Scotland, has recently written a piece entitled “Privacy Lessons Learned from an Operational Health Information Exchange.”  The goal is to help providers investing in health information exchanges and electronic health records to fully understand the privacy implications of broad-scale electronic access to protected patient information. Lessons learned from NHS Scotland’s fully operational HIE deployment could save the healthcare industry time, money and reputation.</p>
<p>As the Privacy and Security Tiger Team fleshes out the privacy and security policies, Ted’s experiences may prove valuable.  To download the full paper, please visit <a href="http://www.fairwarningaudit.com/documents/2011-WHITEPAPER-HIE-NHS-SCOTLAND.pdf" rel="nofollow">http://www.fairwarningaudit.com/documents/2011-WHITEPAPER-HIE-NHS-SCOTLAND.pdf</a> <img src="http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true" border="0" alt="Exit Disclaimer" /></p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3154" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3154-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3154" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3154-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3154-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Beki Marshall for the American Academy of Pediatrics</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3153</link>
		<dc:creator>Beki Marshall for the American Academy of Pediatrics</dc:creator>
		<pubDate>Wed, 11 May 2011 20:24:27 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3153</guid>
		<description>On behalf of the 60,000 primary care pediatricians, pediatric medical subspecialists, and surgical specialists of the American Academy of Pediatrics who are committed to the attainment of optimal physical, mental and social health and well-being for all infants, children, adolescents, and young adults, thank you for the opportunity to comment on the draft Framework for Electronic Health Information Exchange. The Academy is committed to the meaningful adoption of Health Information Technology (HIT) with the goal of improved quality and safety of care for children. 

While the Framework proposed is a good overview and initial step, the implementation of such a Framework poses special risks to patients younger than 18 years of age and to adults who may not be competent to make their own healthcare decisions. For adolescent patients in particular, the following issues must be addressed to allow for all the benefits that health information technology can provide.

Key Issues
• Confidentiality is crucial to reducing barriers to care for adolescents. It has long been recognized that if adolescents do not believe their information will be kept private, they will avoid seeking care.
• Laws governing the conditions under which a minor may seek and consent to healthcare without permission from a parent or guardian vary from state to state. The HIPAA Privacy Rule mostly defers to these states laws.
• Dual (or plural) consent must be available to allow for teens and their parents to access different portions of electronic health information.
• Current technologies do not allow adolescents to provide consent for their information to be included in a health information exchange (HIE).
• Insurance laws require that a policy owner receive notice of any charges billed to the policy. As a result, adolescents must either pay for their own care or seek care from publicly-funded clinics if the adolescent wishes to keep that care confidential. Pediatricians can be put in the uncomfortable position of choosing whether to refer their adolescent patients to public clinics or providing care free of charge.
• Privacy standards must protect diagnoses; laboratory orders and results; prescriptions; problem lists; personal health record access; and ultimately, any documentation.
• Certified electronic health record systems should be required to meet applicable state laws/regulations. While this is certainly a complex and complicated issue, physicians cannot be expected to comply with these laws if the systems on which they rely do not.

The following issues should also be addressed:
• Children in foster care or kinship care have additional unique privacy and consent issues, including the need for multiple and changing guardianship information and access rights.
• Related to the Data Quality and Integrity Principle, when information is shared through an HIE, the original source and date of each piece of information should be transparent to reduce the potential for proliferating bad information. 

References
• Council on Clinical Information Technology. “Using Personal Health Records to Improve the Quality of Health Care For Children.” PEDIATRICS Vol. 124 No. 1 July 2009, pp. 403-409
• Spooner SA and the Council on Clinical Information Technology. “Special Requirements of Electronic Health Records Systems in Pediatrics.” PEDIATRICS Vol. 119 No. 3 March 2007, pp. 631-637 (doi:10.1542/peds.2006-3527)
• Pediatric Data Standards Special Interest Group. Functional profile: child health functional profile for EHR systems. Available at: http://xreg2.nist.gov:8080/ehrsRegistry &lt;/a&gt; &lt;img src=&quot;http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true&quot; border=&quot;0&quot; alt=&quot;Exit Disclaimer&quot; /&gt; Accessed 4/27/11.
• NYeHealth Collaborative Privacy and Security Minor Consent Tiger Team. “Barriers to the Exchange of Pediatric Health Information.” Produced July 2010.</description>
		<content:encoded><![CDATA[<p>On behalf of the 60,000 primary care pediatricians, pediatric medical subspecialists, and surgical specialists of the American Academy of Pediatrics who are committed to the attainment of optimal physical, mental and social health and well-being for all infants, children, adolescents, and young adults, thank you for the opportunity to comment on the draft Framework for Electronic Health Information Exchange. The Academy is committed to the meaningful adoption of Health Information Technology (HIT) with the goal of improved quality and safety of care for children. </p>
<p>While the Framework proposed is a good overview and initial step, the implementation of such a Framework poses special risks to patients younger than 18 years of age and to adults who may not be competent to make their own healthcare decisions. For adolescent patients in particular, the following issues must be addressed to allow for all the benefits that health information technology can provide.</p>
<p>Key Issues<br />
• Confidentiality is crucial to reducing barriers to care for adolescents. It has long been recognized that if adolescents do not believe their information will be kept private, they will avoid seeking care.<br />
• Laws governing the conditions under which a minor may seek and consent to healthcare without permission from a parent or guardian vary from state to state. The HIPAA Privacy Rule mostly defers to these states laws.<br />
• Dual (or plural) consent must be available to allow for teens and their parents to access different portions of electronic health information.<br />
• Current technologies do not allow adolescents to provide consent for their information to be included in a health information exchange (HIE).<br />
• Insurance laws require that a policy owner receive notice of any charges billed to the policy. As a result, adolescents must either pay for their own care or seek care from publicly-funded clinics if the adolescent wishes to keep that care confidential. Pediatricians can be put in the uncomfortable position of choosing whether to refer their adolescent patients to public clinics or providing care free of charge.<br />
• Privacy standards must protect diagnoses; laboratory orders and results; prescriptions; problem lists; personal health record access; and ultimately, any documentation.<br />
• Certified electronic health record systems should be required to meet applicable state laws/regulations. While this is certainly a complex and complicated issue, physicians cannot be expected to comply with these laws if the systems on which they rely do not.</p>
<p>The following issues should also be addressed:<br />
• Children in foster care or kinship care have additional unique privacy and consent issues, including the need for multiple and changing guardianship information and access rights.<br />
• Related to the Data Quality and Integrity Principle, when information is shared through an HIE, the original source and date of each piece of information should be transparent to reduce the potential for proliferating bad information. </p>
<p>References<br />
• Council on Clinical Information Technology. “Using Personal Health Records to Improve the Quality of Health Care For Children.” PEDIATRICS Vol. 124 No. 1 July 2009, pp. 403-409<br />
• Spooner SA and the Council on Clinical Information Technology. “Special Requirements of Electronic Health Records Systems in Pediatrics.” PEDIATRICS Vol. 119 No. 3 March 2007, pp. 631-637 (doi:10.1542/peds.2006-3527)<br />
• Pediatric Data Standards Special Interest Group. Functional profile: child health functional profile for EHR systems. Available at: <a href="http://xreg2.nist.gov:8080/ehrsRegistry" rel="nofollow">http://xreg2.nist.gov:8080/ehrsRegistry</a>  <img src="http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true" border="0" alt="Exit Disclaimer" /> Accessed 4/27/11.<br />
• NYeHealth Collaborative Privacy and Security Minor Consent Tiger Team. “Barriers to the Exchange of Pediatric Health Information.” Produced July 2010.</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3153" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3153-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3153" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3153-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3153-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Gaye Adams Massey &#38; Ann Tobin</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3152</link>
		<dc:creator>Gaye Adams Massey &#38; Ann Tobin</dc:creator>
		<pubDate>Wed, 11 May 2011 19:48:09 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3152</guid>
		<description>May 11, 2011

Deven McGraw and Paul Egerman, Co-Chairs
Privacy and Security Tiger Team
Health IT Policy Committee

VIA the Federal Advisory Committee Blog

	UnitedHealth Group is pleased to provide the Health IT Policy Committee’s Privacy and Security Tiger Team with our comments on the “Policy and Technology Framework for Health Information Exchange” (the “Proposed Framework”).  UnitedHealth Group is dedicated to making our nation’s health care system work better.  Recognized as America’s most innovative health care company in Fortune magazine’s 2010 Most Admired Companies in America survey, our highly-diversified and comprehensive array of health and well-being products and services empowers individuals, expands consumer choice, and strengthens patient-provider relationships.  Our more than 80,000 employees serve the health care needs of more than 75 million individuals, develop and advance new health technologies and enhance financial and operational connectivity across the health care system.  Our role as a national leader in both private and public health benefits programs and services enables us to continuously foster innovative health solutions aimed at creating a modern health care system that is more accessible, affordable and personalized for all Americans.  We offer these comments based on our experience in developing and delivering innovative solutions through our electronic health record (EHR) and health information exchange technologies, as well as our health plan offerings in the commercial, Medicare, and Medicaid markets across the country.  

	We believe that a strong privacy framework is important for protecting consumer trust as well as for promoting successful Health Information Exchange (HIE).  UnitedHealth Group supports the development of HIE that is compatible with the goals of improving the quality and affordability of health care, promoting patient trust in the health care system, and safeguarding public health.  Information technology has the potential to dramatically and positively affect the delivery of health care in the United States, and HIE is a fundamental component of the ability of HIT to improve care delivery and quality. Broad adoption and use of comprehensive HIT could significantly improve health care as well as care coordination among health care providers, while reducing medical errors and redundant services as well as enabling better health research.  With these goals in mind, UnitedHealth Group supports the following principles for development of state HIE efforts.  We have described some specific recommendations and concerns related to the Tiger Team’s Proposed Framework below. 

I.	Fair Information Principles.  We support the Tiger Team’s recommendation that all entities involved in health information exchange should follow the full complement of fair information practices, as described in the Proposed Framework, when handling personally identifiable health information.  We also support the core values set forth in the Proposed Framework.  In particular, we agree that successful health information exchange depends on the trust of both consumers and physicians.  

II.	Individual Choice.  It is important that the development of a privacy and security framework for HIE build upon HIPAA and not unnecessarily constrain the exchange of information that would otherwise be permitted under HIPAA.  The exchange of information must be structured to safeguard patient information without unduly burdening the effective delivery of care, payment for care, or quality improvement activities.  All of these functions occur as a normal part of HIPAA-regulated health care operations.  Therefore, it is important that a framework for HIE include patient choice, as the Tiger Team has written, but also that the framework not undermine necessary use of patient identifiable data today that is regulated by HIPAA. With this principle in mind, we have the following additional comments:

	Consent and Directed Exchange.  We agree with the Tiger Team that for the purposes of Health Information Exchange, “individuals should be provided a reasonable opportunity and capability to make informed decisions about the collection, use and disclosure of their individually identifiable health information.”  As with existing exchange of health information, it is important that patients are provided with proper notice and are fully informed about their choices with regard to uses and disclosures of their information.  This will be particularly important in the context of health information exchange, as part of establishing trust in HIE among patients and providers.  As the Tiger Team notes in Recommendation 3.1 on Consent and Directed Exchange, this consent process  includes ensuring “that the patient understands the information the receiving provider or clinician will likely need in order to provide safe, effective care.”  As described above, in order for HIE to be widely used, reliable and robust patient data must be available.  This will only be possible with a workable patient consent policy that ensures that patients receive the information they need and that, as described below, the choices given to patients ensure that data flows smoothly and securely for core activities, such as the provision of care.  

	We are concerned about the effect that a granular system of consent may have on the availability of information for health care providers.  We appreciate the Tiger Team’s recognition that the technology for granular consent is still in the early stages of development and that models for a granular approach should be carefully evaluated, taking into consideration factors such as patient educational needs, operational considerations, and health care quality. In particular, we are concerned that the ability to limit large segments of health care information from inclusion in HIE will greatly diminish the usability of the data that is available, and therefore adoption of health information exchange.  If physicians cannot rely on the information available in HIE to provide quality care, they are not likely to engage in HIE.

Instead, we propose that patients should be able to decline to participate in HIE altogether.  This approach would address the concerns of patients who prefer not to have their information shared via HIE, while at the same time ensuring, for those patients who do participate, that health care providers will have access to information necessary to provide quality care.  If at the end of Meaningful Use Stage III, physicians are widely exchanging health information, and have widely adopted health information technology, and if at that time the technology for more granular consent is robust and reliable, stakeholders can then consider whether consent rules should evolve. 

	Directed exchange.  UHG supports the Tiger Team’s observation that “[d]irected exchange for treatment does not require patient consent beyond what is required in current law or what has been customary practice.”  In fact, UnitedHealth Group recognized this principle in its December 2009 comments to the California Office of Health Information Integrity noting that California Law already permits media-agnostic exchange among physicians concerning a shared patient—in essence what the Tiger Team calls “directed exchange.”  (See Cal Civil Code sec. 56.10(c)(4)).  

	Moreover, it is critical that the principles for health information exchange not restrict existing rules for disclosure of health information for purposes that already are permitted under law.  Examples include treatment, payment, quality analysis and improvement efforts, and care management by payers and providers.  We agree that in order to facilitate successful adoption of HIE it may be appropriate to give patients the option to opt out of HIE.  But we also recognize, and urge the Tiger Team’s final recommendations to recognize, that protected health information that exists outside an HIE (including data that is properly accessed via HIE) should be subject to the HIPAA rules governing the use and disclosure of PHI, not any consent rules specific to HIE.    

	A national framework. We share the concern of many well-informed and well-respected commentators, from HISPC to the National eHealth Collaborative, that without uniform HIE privacy rules across states, information will not flow in a manner that will facilitate the development of a successful nationwide health information network.  A national framework will provide an effective solution to the issue of consent that protects patient privacy while making data accessible.  

We urge the Tiger Team to recommend to ONC that HHS develop a model rule states could use in building HIE infrastructure and to direct states to work within these uniform rules.  We believe the recommendation should contain two concepts, namely:

•	ONC adopt a timeframe and strategy to coordinate efforts with the Office for Civil Rights to ensure a privacy and security framework for electronic HIE that promotes consistent standards.

•	ONC recommend an approach, grounded in a model law for patient consent for HIE, that makes HIE a meaningful tool to improve care and care delivery, and to moderate health costs.

III.	Third Party Service Organizations.   With respect to the Tiger Team’s recommendations regarding third party service organizations “that offer valuable services to providers that often facilitate the effective exchange of identifiable health information” – such as Health Information Organizations – we are concerned that these recommendations fail to recognize the changes to HIPAA set forth in the HITECH Act.  The Proposed Framework suggests that business associate agreements have not “historically been sufficiently effective in limiting a third-party’s use or disclosure of identifiable information.”  Under the HITECH Act, business associates are now directly obligated to comply with virtually all of the Security Rule requirements and most of the Privacy Rule requirements and are directly liable for failure to do so.  The HIPAA rules set forth detailed requirements for business associate agreements, and the final rule implementing the HITECH Act changes to the business associate requirements are expected to provide the detail necessary for business associates to fully carry out their obligations under HIPAA.  The HIPAA rules contemplate the issues raised by the Proposed Framework, such as retention, destruction and de-identification of information.  The HITECH Act specifically contemplates the role of Health Information Organizations (HIOs) and requires that such entities are “business associates.”  We believe that these revised rules address the oversight, accountability and enforcement concerns raised by the Proposed Framework.  To the extent that the Tiger Team believes that additional requirements are necessary, we urge it to work closely with the Office for Civil Rights to address any additional business associate issues specific to HIOs in order to provide an efficient and seamless framework for such entities.  

			*			*			*
	We appreciate the opportunity to submit comments on the Proposed Framework.  Should you have any questions regarding our suggestions, please do not hesitate to contact us.

Sincerely,

Gaye Adams Massey
Senior Deputy General Counsel
and Acting Chief Privacy Officer
Unitedhealth Group

Ann Tobin
Senior Privacy Counsel
Unitedhealth Group</description>
		<content:encoded><![CDATA[<p>May 11, 2011</p>
<p>Deven McGraw and Paul Egerman, Co-Chairs<br />
Privacy and Security Tiger Team<br />
Health IT Policy Committee</p>
<p>VIA the Federal Advisory Committee Blog</p>
<p>	UnitedHealth Group is pleased to provide the Health IT Policy Committee’s Privacy and Security Tiger Team with our comments on the “Policy and Technology Framework for Health Information Exchange” (the “Proposed Framework”).  UnitedHealth Group is dedicated to making our nation’s health care system work better.  Recognized as America’s most innovative health care company in Fortune magazine’s 2010 Most Admired Companies in America survey, our highly-diversified and comprehensive array of health and well-being products and services empowers individuals, expands consumer choice, and strengthens patient-provider relationships.  Our more than 80,000 employees serve the health care needs of more than 75 million individuals, develop and advance new health technologies and enhance financial and operational connectivity across the health care system.  Our role as a national leader in both private and public health benefits programs and services enables us to continuously foster innovative health solutions aimed at creating a modern health care system that is more accessible, affordable and personalized for all Americans.  We offer these comments based on our experience in developing and delivering innovative solutions through our electronic health record (EHR) and health information exchange technologies, as well as our health plan offerings in the commercial, Medicare, and Medicaid markets across the country.  </p>
<p>	We believe that a strong privacy framework is important for protecting consumer trust as well as for promoting successful Health Information Exchange (HIE).  UnitedHealth Group supports the development of HIE that is compatible with the goals of improving the quality and affordability of health care, promoting patient trust in the health care system, and safeguarding public health.  Information technology has the potential to dramatically and positively affect the delivery of health care in the United States, and HIE is a fundamental component of the ability of HIT to improve care delivery and quality. Broad adoption and use of comprehensive HIT could significantly improve health care as well as care coordination among health care providers, while reducing medical errors and redundant services as well as enabling better health research.  With these goals in mind, UnitedHealth Group supports the following principles for development of state HIE efforts.  We have described some specific recommendations and concerns related to the Tiger Team’s Proposed Framework below. </p>
<p>I.	Fair Information Principles.  We support the Tiger Team’s recommendation that all entities involved in health information exchange should follow the full complement of fair information practices, as described in the Proposed Framework, when handling personally identifiable health information.  We also support the core values set forth in the Proposed Framework.  In particular, we agree that successful health information exchange depends on the trust of both consumers and physicians.  </p>
<p>II.	Individual Choice.  It is important that the development of a privacy and security framework for HIE build upon HIPAA and not unnecessarily constrain the exchange of information that would otherwise be permitted under HIPAA.  The exchange of information must be structured to safeguard patient information without unduly burdening the effective delivery of care, payment for care, or quality improvement activities.  All of these functions occur as a normal part of HIPAA-regulated health care operations.  Therefore, it is important that a framework for HIE include patient choice, as the Tiger Team has written, but also that the framework not undermine necessary use of patient identifiable data today that is regulated by HIPAA. With this principle in mind, we have the following additional comments:</p>
<p>	Consent and Directed Exchange.  We agree with the Tiger Team that for the purposes of Health Information Exchange, “individuals should be provided a reasonable opportunity and capability to make informed decisions about the collection, use and disclosure of their individually identifiable health information.”  As with existing exchange of health information, it is important that patients are provided with proper notice and are fully informed about their choices with regard to uses and disclosures of their information.  This will be particularly important in the context of health information exchange, as part of establishing trust in HIE among patients and providers.  As the Tiger Team notes in Recommendation 3.1 on Consent and Directed Exchange, this consent process  includes ensuring “that the patient understands the information the receiving provider or clinician will likely need in order to provide safe, effective care.”  As described above, in order for HIE to be widely used, reliable and robust patient data must be available.  This will only be possible with a workable patient consent policy that ensures that patients receive the information they need and that, as described below, the choices given to patients ensure that data flows smoothly and securely for core activities, such as the provision of care.  </p>
<p>	We are concerned about the effect that a granular system of consent may have on the availability of information for health care providers.  We appreciate the Tiger Team’s recognition that the technology for granular consent is still in the early stages of development and that models for a granular approach should be carefully evaluated, taking into consideration factors such as patient educational needs, operational considerations, and health care quality. In particular, we are concerned that the ability to limit large segments of health care information from inclusion in HIE will greatly diminish the usability of the data that is available, and therefore adoption of health information exchange.  If physicians cannot rely on the information available in HIE to provide quality care, they are not likely to engage in HIE.</p>
<p>Instead, we propose that patients should be able to decline to participate in HIE altogether.  This approach would address the concerns of patients who prefer not to have their information shared via HIE, while at the same time ensuring, for those patients who do participate, that health care providers will have access to information necessary to provide quality care.  If at the end of Meaningful Use Stage III, physicians are widely exchanging health information, and have widely adopted health information technology, and if at that time the technology for more granular consent is robust and reliable, stakeholders can then consider whether consent rules should evolve. </p>
<p>	Directed exchange.  UHG supports the Tiger Team’s observation that “[d]irected exchange for treatment does not require patient consent beyond what is required in current law or what has been customary practice.”  In fact, UnitedHealth Group recognized this principle in its December 2009 comments to the California Office of Health Information Integrity noting that California Law already permits media-agnostic exchange among physicians concerning a shared patient—in essence what the Tiger Team calls “directed exchange.”  (See Cal Civil Code sec. 56.10(c)(4)).  </p>
<p>	Moreover, it is critical that the principles for health information exchange not restrict existing rules for disclosure of health information for purposes that already are permitted under law.  Examples include treatment, payment, quality analysis and improvement efforts, and care management by payers and providers.  We agree that in order to facilitate successful adoption of HIE it may be appropriate to give patients the option to opt out of HIE.  But we also recognize, and urge the Tiger Team’s final recommendations to recognize, that protected health information that exists outside an HIE (including data that is properly accessed via HIE) should be subject to the HIPAA rules governing the use and disclosure of PHI, not any consent rules specific to HIE.    </p>
<p>	A national framework. We share the concern of many well-informed and well-respected commentators, from HISPC to the National eHealth Collaborative, that without uniform HIE privacy rules across states, information will not flow in a manner that will facilitate the development of a successful nationwide health information network.  A national framework will provide an effective solution to the issue of consent that protects patient privacy while making data accessible.  </p>
<p>We urge the Tiger Team to recommend to ONC that HHS develop a model rule states could use in building HIE infrastructure and to direct states to work within these uniform rules.  We believe the recommendation should contain two concepts, namely:</p>
<p>•	ONC adopt a timeframe and strategy to coordinate efforts with the Office for Civil Rights to ensure a privacy and security framework for electronic HIE that promotes consistent standards.</p>
<p>•	ONC recommend an approach, grounded in a model law for patient consent for HIE, that makes HIE a meaningful tool to improve care and care delivery, and to moderate health costs.</p>
<p>III.	Third Party Service Organizations.   With respect to the Tiger Team’s recommendations regarding third party service organizations “that offer valuable services to providers that often facilitate the effective exchange of identifiable health information” – such as Health Information Organizations – we are concerned that these recommendations fail to recognize the changes to HIPAA set forth in the HITECH Act.  The Proposed Framework suggests that business associate agreements have not “historically been sufficiently effective in limiting a third-party’s use or disclosure of identifiable information.”  Under the HITECH Act, business associates are now directly obligated to comply with virtually all of the Security Rule requirements and most of the Privacy Rule requirements and are directly liable for failure to do so.  The HIPAA rules set forth detailed requirements for business associate agreements, and the final rule implementing the HITECH Act changes to the business associate requirements are expected to provide the detail necessary for business associates to fully carry out their obligations under HIPAA.  The HIPAA rules contemplate the issues raised by the Proposed Framework, such as retention, destruction and de-identification of information.  The HITECH Act specifically contemplates the role of Health Information Organizations (HIOs) and requires that such entities are “business associates.”  We believe that these revised rules address the oversight, accountability and enforcement concerns raised by the Proposed Framework.  To the extent that the Tiger Team believes that additional requirements are necessary, we urge it to work closely with the Office for Civil Rights to address any additional business associate issues specific to HIOs in order to provide an efficient and seamless framework for such entities.  </p>
<p>			*			*			*<br />
	We appreciate the opportunity to submit comments on the Proposed Framework.  Should you have any questions regarding our suggestions, please do not hesitate to contact us.</p>
<p>Sincerely,</p>
<p>Gaye Adams Massey<br />
Senior Deputy General Counsel<br />
and Acting Chief Privacy Officer<br />
Unitedhealth Group</p>
<p>Ann Tobin<br />
Senior Privacy Counsel<br />
Unitedhealth Group</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3152" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3152-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3152" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3152-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3152-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Steinberg</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3148</link>
		<dc:creator>Dan Steinberg</dc:creator>
		<pubDate>Wed, 11 May 2011 05:15:44 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3148</guid>
		<description>Thank you for a well-thought out and detailed framework, and for the opportunity to comment.  Please note that my comments below are my own, and not those of my employer or clients.

1. Technology principles.  I note that all the technology principles focus on what is convenient and usable for the adopters, and does not mention or consider the consumers.  Perhaps your intention was to reflect the adopters’ interests here, and the consumers’ interests in the sections that follow.  If not, however, I suggest that there are two concepts—well-reflected elsewhere in the document—that may be appropriate here, as well: “Ensure that technologies do not preempt the possibility of providing access to consumers” and “Ensure that technologies are able to be implemented in a manner that allows reasonably user-friendly end use by consumers.”

2. One Tiger Team recommendation on Openness and Transparency is to provide a “layered notice” to consumers.  Later, however, one of the “Notes and Consideration” under the category “Individual Choice (Individual Participation and Control)” indicates the Tiger Team is still thinking through some of the consequence of opt-in/opt-out models.  The “layered choice” option seems wise, considering that the vast majority of consumers decline to read even reasonably short NOPPs, and through the fault of no party, they become similar to adhesion contracts. However, the &quot;top layer&quot; could conceivably mask any &quot;opt-out&quot; choices provided to the consumer in the foundational NOPP.

Therefore, the Tiger Team may wish to make explicit that uses of individually identifiable health information, except for those for treatment, payment and operations, should require either an authorization; waiver of authorization; or compelling social need. While many of these principles are already reflected in the HIPAA Privacy Rule, you have chosen, appropriately (a) to extend many of these principles to non-HIPAA covered entities and (b) to make such requirements explicit elsewhere in the document. Requiring an explicit opt-in approach seems to balance the goals of overburdening neither the adopters of technology nor the consumers, while also ensuring that data is used only within the consumers’ rights, expectations, and best interests.

3. Under “Data Integrity”—an often minimized or overlooked element of privacy--two of the Tiger Team recommendations are intriguing: ”Internally evaluating matching accuracy, including individual providers and institutions as well as HIEs in the evaluations, make use of performance improvement metrics” and “Accountability, implement and enforce governance policies and levels of accuracy model.”  While not entirely clear in this context, I assume that the former is suggesting that individual users of technology test their own data matching capabilities, and update or revise their data matching algorithms accordingly, and the latter refers to a governance model that considers whether adopters have an effective matching algorithm in use.  I would request that the Tiger Team either clarify these points or indicate where further clarification can be found.  I also wonder whether the Tiger Team has considered whether integrity can also be confirmed by collecting data directly from the patient; periodically reviewing the accuracy of patient data as part of service delivery; preventing and detecting medical identity theft (for example by requesting patients to periodically authenticate themselves to the information in their records); and supporting education, training and awareness for data integrity, including the detection and elimination of medical identity theft and medical errors.  It is possible the Tiger Team considers these beyond the scope of this document, but if not there is an opportunity here to address issues that affect not only patient trust, but to directly improve quality of care.

4. Under “Safeguards” I note the Tiger Team did not feel it necessary to reiterate all of the standards and implementation specifications of the Security Rule.  I assume the Tiger Team considered whether to, at minimum, discuss the need to explicitly mention the Risk Analysis standard (§ 164.308(a)(1)(ii)(A)).  As I’m sure the Tiger Team is aware, risk analysis is not only HIPAA standard, but explicitly called out in the Meaningful Use criteria, and OCR has rightly called risk analysis “foundational.” If the Tiger Team were to call out just one security control in this document, risk analysis seems to be the obvious choice.

Thank you for providing the opportunity to comment. If any of these comments is unclear, I would be happy to discuss further, either via e-mail (provided when leaving these comments) or in another appropriate forum.</description>
		<content:encoded><![CDATA[<p>Thank you for a well-thought out and detailed framework, and for the opportunity to comment.  Please note that my comments below are my own, and not those of my employer or clients.</p>
<p>1. Technology principles.  I note that all the technology principles focus on what is convenient and usable for the adopters, and does not mention or consider the consumers.  Perhaps your intention was to reflect the adopters’ interests here, and the consumers’ interests in the sections that follow.  If not, however, I suggest that there are two concepts—well-reflected elsewhere in the document—that may be appropriate here, as well: “Ensure that technologies do not preempt the possibility of providing access to consumers” and “Ensure that technologies are able to be implemented in a manner that allows reasonably user-friendly end use by consumers.”</p>
<p>2. One Tiger Team recommendation on Openness and Transparency is to provide a “layered notice” to consumers.  Later, however, one of the “Notes and Consideration” under the category “Individual Choice (Individual Participation and Control)” indicates the Tiger Team is still thinking through some of the consequence of opt-in/opt-out models.  The “layered choice” option seems wise, considering that the vast majority of consumers decline to read even reasonably short NOPPs, and through the fault of no party, they become similar to adhesion contracts. However, the &#8220;top layer&#8221; could conceivably mask any &#8220;opt-out&#8221; choices provided to the consumer in the foundational NOPP.</p>
<p>Therefore, the Tiger Team may wish to make explicit that uses of individually identifiable health information, except for those for treatment, payment and operations, should require either an authorization; waiver of authorization; or compelling social need. While many of these principles are already reflected in the HIPAA Privacy Rule, you have chosen, appropriately (a) to extend many of these principles to non-HIPAA covered entities and (b) to make such requirements explicit elsewhere in the document. Requiring an explicit opt-in approach seems to balance the goals of overburdening neither the adopters of technology nor the consumers, while also ensuring that data is used only within the consumers’ rights, expectations, and best interests.</p>
<p>3. Under “Data Integrity”—an often minimized or overlooked element of privacy&#8211;two of the Tiger Team recommendations are intriguing: ”Internally evaluating matching accuracy, including individual providers and institutions as well as HIEs in the evaluations, make use of performance improvement metrics” and “Accountability, implement and enforce governance policies and levels of accuracy model.”  While not entirely clear in this context, I assume that the former is suggesting that individual users of technology test their own data matching capabilities, and update or revise their data matching algorithms accordingly, and the latter refers to a governance model that considers whether adopters have an effective matching algorithm in use.  I would request that the Tiger Team either clarify these points or indicate where further clarification can be found.  I also wonder whether the Tiger Team has considered whether integrity can also be confirmed by collecting data directly from the patient; periodically reviewing the accuracy of patient data as part of service delivery; preventing and detecting medical identity theft (for example by requesting patients to periodically authenticate themselves to the information in their records); and supporting education, training and awareness for data integrity, including the detection and elimination of medical identity theft and medical errors.  It is possible the Tiger Team considers these beyond the scope of this document, but if not there is an opportunity here to address issues that affect not only patient trust, but to directly improve quality of care.</p>
<p>4. Under “Safeguards” I note the Tiger Team did not feel it necessary to reiterate all of the standards and implementation specifications of the Security Rule.  I assume the Tiger Team considered whether to, at minimum, discuss the need to explicitly mention the Risk Analysis standard (§ 164.308(a)(1)(ii)(A)).  As I’m sure the Tiger Team is aware, risk analysis is not only HIPAA standard, but explicitly called out in the Meaningful Use criteria, and OCR has rightly called risk analysis “foundational.” If the Tiger Team were to call out just one security control in this document, risk analysis seems to be the obvious choice.</p>
<p>Thank you for providing the opportunity to comment. If any of these comments is unclear, I would be happy to discuss further, either via e-mail (provided when leaving these comments) or in another appropriate forum.</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3148" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3148-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3148" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3148-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3148-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Shelly Spiro - Director Pharmacy e-HIT Collaborative</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3139</link>
		<dc:creator>Shelly Spiro - Director Pharmacy e-HIT Collaborative</dc:creator>
		<pubDate>Tue, 10 May 2011 02:45:41 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3139</guid>
		<description>On behalf of the membership of the Pharmacy e-Health Information Technology Collaborative (Collaborative), we are pleased to submit brief comments in response to the Policy and Technology Framework for HIE released by the Office of the Nation Coordinator’s (ONC) Tiger Team on April 19, 2011. The Collaborative supports technological developments and policy actions related to the privacy and security of health data as long as pharmacists are recognized as providers of patient care services and are not limited by any provision exclusion, such as minimum necessary requirements.  More detailed comments are found at http://pharmacye-hit.org/20110509PharmacyeHITCollaborativePrivacySecurityFrameworkComments.pdf&lt;/a&gt; &lt;img src=&quot;http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true&quot; border=&quot;0&quot; alt=&quot;Exit Disclaimer&quot; /&gt;  

These comments focus on the need to recognize pharmacists as providers that may receive health information through HIEs consistent with accepted privacy and security standards. Formed in the fall of 2010, the Collaborative’s focus is to assure the meaningful use (MU) of standardized electronic health records (EHRs) supports safe, efficient, and effective medication use, continuity of care, and provides access to the patient-care services provided by pharmacists with other members of the interdisciplinary patient-care team.  The Collaborative’s goal is to assure that the pharmacist’s role of providing patient-care services is integrated into the National HIT interoperable framework.  The group is pursuing EHR standards that effectively support the delivery, documentation of, and billing for pharmacist-provided patient care services across all care settings. 

The Collaborative seeks to ensure that pharmacist-provided patient care services in all practice settings are represented in the MU of EHRs. The Collaborative’s founding organizations represent pharmacists in all patient care settings and other facets of pharmacy, including pharmacy education and pharmacy education accreditation. The Collaborative’s Associate Members represent e-prescribing networks, a standards development organization, and a transaction processing network. The Collaborative was founded by nine pharmacy professional associations representing over 250,000 members and includes three associate members from other pharmacy related organizations. For additional information, visit www.pharmacye-hit.org.&lt;/a&gt; &lt;img src=&quot;http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true&quot; border=&quot;0&quot; alt=&quot;Exit Disclaimer&quot; /&gt; 

The Collaborative believes that the inclusion of pharmacists’ clinical services is critical to achieving the new focus areas identified by ONC in its Federal Health IT Strategic Plan 2011-2015 (Strategic Plan) updated on March 25, 2011 and other objectives. The current federal HIT infrastructure limits pharmacists’ exchange of information to electronic prescribing. Data elements exchanged through electronic prescribing systems are generally limited to minimal patient and provider information in addition to the information on the medications prescribed. Much more extensive clinical information is necessary for pharmacists to implement patient-care recommendations, including in the exchange of information among HIEs.  To fully achieve the desired health outcomes of a fully integrated interoperable HIT environment, ONC must consider the inclusion of pharmacists as a component of the EHR information exchange, which currently is not the case.

On behalf of the Pharmacy e-HIT Collaborative, thank you again for the opportunity to comment on the Policy and Technology Framework for HIE:  Privacy and Security Issues and the work of ONC to establish the nationwide HIT infrastructure.</description>
		<content:encoded><![CDATA[<p>On behalf of the membership of the Pharmacy e-Health Information Technology Collaborative (Collaborative), we are pleased to submit brief comments in response to the Policy and Technology Framework for HIE released by the Office of the Nation Coordinator’s (ONC) Tiger Team on April 19, 2011. The Collaborative supports technological developments and policy actions related to the privacy and security of health data as long as pharmacists are recognized as providers of patient care services and are not limited by any provision exclusion, such as minimum necessary requirements.  More detailed comments are found at <a href="http://pharmacye-hit.org/20110509PharmacyeHITCollaborativePrivacySecurityFrameworkComments.pdf" rel="nofollow">http://pharmacye-hit.org/20110509PharmacyeHITCollaborativePrivacySecurityFrameworkComments.pdf</a> <img src="http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true" border="0" alt="Exit Disclaimer" />  </p>
<p>These comments focus on the need to recognize pharmacists as providers that may receive health information through HIEs consistent with accepted privacy and security standards. Formed in the fall of 2010, the Collaborative’s focus is to assure the meaningful use (MU) of standardized electronic health records (EHRs) supports safe, efficient, and effective medication use, continuity of care, and provides access to the patient-care services provided by pharmacists with other members of the interdisciplinary patient-care team.  The Collaborative’s goal is to assure that the pharmacist’s role of providing patient-care services is integrated into the National HIT interoperable framework.  The group is pursuing EHR standards that effectively support the delivery, documentation of, and billing for pharmacist-provided patient care services across all care settings. </p>
<p>The Collaborative seeks to ensure that pharmacist-provided patient care services in all practice settings are represented in the MU of EHRs. The Collaborative’s founding organizations represent pharmacists in all patient care settings and other facets of pharmacy, including pharmacy education and pharmacy education accreditation. The Collaborative’s Associate Members represent e-prescribing networks, a standards development organization, and a transaction processing network. The Collaborative was founded by nine pharmacy professional associations representing over 250,000 members and includes three associate members from other pharmacy related organizations. For additional information, visit <a href="http://www.pharmacye-hit.org" rel="nofollow">http://www.pharmacye-hit.org</a>. <img src="http://healthit.hhs.gov/portal/server.pt?open=18&amp;objID=911201&amp;parentname=CommunityPage&amp;parentid=7&amp;mode=2&amp;in_hi_userid=11113&amp;cached=true" border="0" alt="Exit Disclaimer" /> </p>
<p>The Collaborative believes that the inclusion of pharmacists’ clinical services is critical to achieving the new focus areas identified by ONC in its Federal Health IT Strategic Plan 2011-2015 (Strategic Plan) updated on March 25, 2011 and other objectives. The current federal HIT infrastructure limits pharmacists’ exchange of information to electronic prescribing. Data elements exchanged through electronic prescribing systems are generally limited to minimal patient and provider information in addition to the information on the medications prescribed. Much more extensive clinical information is necessary for pharmacists to implement patient-care recommendations, including in the exchange of information among HIEs.  To fully achieve the desired health outcomes of a fully integrated interoperable HIT environment, ONC must consider the inclusion of pharmacists as a component of the EHR information exchange, which currently is not the case.</p>
<p>On behalf of the Pharmacy e-HIT Collaborative, thank you again for the opportunity to comment on the Policy and Technology Framework for HIE:  Privacy and Security Issues and the work of ONC to establish the nationwide HIT infrastructure.</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3139" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3139-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3139" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3139-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3139-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Susan Limoncelli</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3108</link>
		<dc:creator>Susan Limoncelli</dc:creator>
		<pubDate>Fri, 06 May 2011 21:08:33 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3108</guid>
		<description>Thus far, security measures have primarily focused on getting PHI from place A to place B in a secure manner; this is fundamental.  But what happens next? Once of the greatest potentials for a security breach is due to unauthorized and/or unsecure USE of that information, after it has been securely transmitted. 

No one seems to be talking about this huge, potential GAP in the secuirty ecosystem; one with significant consequences.  Think, for example, of a typical scenario of a physican&#039;s office (securely) receiving a patient&#039;s EMR from an authorized HIE. All is well and in compliance.  Then, a well-intentioned employee prints, faxes or forwards a copy of the patient&#039;s record to another provider.  The PHI is no longer secure.  

How is the USE of PHI being secured once it is delivered?  This is the natural next question; one we should be thinking about, and planning for now, not later!</description>
		<content:encoded><![CDATA[<p>Thus far, security measures have primarily focused on getting PHI from place A to place B in a secure manner; this is fundamental.  But what happens next? Once of the greatest potentials for a security breach is due to unauthorized and/or unsecure USE of that information, after it has been securely transmitted. </p>
<p>No one seems to be talking about this huge, potential GAP in the secuirty ecosystem; one with significant consequences.  Think, for example, of a typical scenario of a physican&#8217;s office (securely) receiving a patient&#8217;s EMR from an authorized HIE. All is well and in compliance.  Then, a well-intentioned employee prints, faxes or forwards a copy of the patient&#8217;s record to another provider.  The PHI is no longer secure.  </p>
<p>How is the USE of PHI being secured once it is delivered?  This is the natural next question; one we should be thinking about, and planning for now, not later!</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3108" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3108-up" style="font-size:12px; color:#009933;">1</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3108" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3108-down" style="font-size:12px; color:#990033;">1</span> (<span id="karma-3108-total" >0</span>)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Pingala</title>
		<link>http://healthit.hhs.gov/blog/faca/index.php/2011/04/19/privacy-security-tiger-team-seeks-feedback-on-framework-for-electronic-health-information-exchange/comment-page-1/#comment-3105</link>
		<dc:creator>Pingala</dc:creator>
		<pubDate>Thu, 05 May 2011 18:35:37 +0000</pubDate>
		<guid isPermaLink="false">http://healthit.hhs.gov/blog/faca/?p=440#comment-3105</guid>
		<description>The costs to maintain (change control, legal audits, etc) and support of a granular consent management seem to be so high that the states may not be able to spend the tax-payers&#039; money at the very out-front. It is difficult to visualize how to make it as an incremental model based on multi-year investment. Are there any guidelines for implementation?</description>
		<content:encoded><![CDATA[<p>The costs to maintain (change control, legal audits, etc) and support of a granular consent management seem to be so high that the states may not be able to spend the tax-payers&#8217; money at the very out-front. It is difficult to visualize how to make it as an incremental model based on multi-year investment. Are there any guidelines for implementation?</p>
<p>Like or Dislike: <img style="padding: 0px; margin: 0px; border: none;" id="up-3105" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_up.png" alt="Thumb up"  /> <span id="karma-3105-up" style="font-size:12px; color:#009933;">2</span>&nbsp;<img style="padding: 0px; margin: 0px; border: none;" id="down-3105" src="http://healthit.hhs.gov/blog/faca/wp-content/plugins/comment-rating/images/1_14_gray_down.png" alt="Thumb down"  /> <span id="karma-3105-down" style="font-size:12px; color:#990033;">0</span> (<span id="karma-3105-total" style="font-size:12px; color:#009933;">+2</span>)</p>]]></content:encoded>
	</item>
</channel>
</rss>

