HIT Policy Committee - Encryption Mandate is either misguided or misunderstood

Last week the HIT Policy declared that Encryption was necessary in NHIN-Direct. This was reported in many forums: Government Health IT, Health Data Management, iHealthBeat, Federal Computer Week, etc. But in all of these cases there is little discussion of the potential unintended consequences of this 'policy' decision.

The following comes from the presentation given at that committee meeting (Slides 6 and 7)

1. We need specific policies, as well as technology requirements, to govern all forms of electronic health information exchange.
• Implement the Nationwide Privacy and Security Framework principles.
• Work should take place ideally before, or at least in conjunction with, technology standards work.
• Technology should implement policy and not make it
• Fill gaps in current law.
• Address “facilitator” access to identifiable information
• Constraints on collection, access, and use of identifiable data
• Constraints on data retention and re-use 
• Security requirements
  
2. One-to-one exchange from one provider to another for treatment purposes – even with no “facilitator” - must be governed by policies that at least include:
• Encryption (no ability for facilitator to access content) 
• Encryption ideally should be required when potential for transmitted data to be exposed (mandate through meaningful use/certification criteria or HIPAA security rule modification) 
• Limits on identifiable (or potentially identifiable) information in the message 
• Identification and authentication 
3. If strong policies such as the above are in place and enforced, we don’t think the above scenario needs any additional individual consent beyond what is already required by current law.

So, this has been taken by some inside the NHIN-Direct project as a mandate for end-to-end encryption and the forbidding of any intermediary. There is evidence on Slide 8 that the HIT Policy committee really is worried about intermediaries, as they continue on to explain that their is concern that regulations are not covering these Business Associates. I believe that this is not true anymore. The HITECH Act did update this.

More importantly the HIT Policy committee should be defining policies that bring the Health Information Exchange (HIE) 'into' control. They are rather telling the standards committees to make sure that the HIE is kept 'out' of the conversation. This is a miss-guided policy, even if it is the easy policy statement.

When this 'facilitator' is indeed only 'routing' the information it is surely possible that they only need to have access to the information necessary to 'route'.  Those that read my blog will recognize that when using Mutually-Authenticated-TLS with Encryption/Hashing; that all of the Internet IP-Routers will only have access to the necessary IP-Addresses to route the communications from the Source to the Destination. In this case one can surely understand that this meets the requirement.  I have been very careful to always indicate that in this case the 'routing' and 'Address' are at the IP level. When communicating in a point-to-point way between these two endpoints TLS works wonderful.

Some within NHIN-Direct are looking at what NHIN-Direct defined as a NHIN 'Address'. In this case an address includes more than the IP-Address, but also includes the target user/group/process. The NHIN Address looks very much like an e-Mail Address, and it is possible that it is indeed an e-Mail Address.

There some in NHIN-Direct that want to use e-Mail as the transport, and thus the whole NHIN-Direct Address would need to be 'known' by the e-Mail infrastructure (aka 'facilitator'). They could isolate their e-Mail infrastructure with TLS, but they would like to potentially use the 'Internet' e-Mail infrastructure. The advantage of using the 'Internet' e-Mail infrastructure is that it already exists and is very common and well understood by many. When they use the e-Mail infrastructure they thus are bringing in 'facilitators' that need to see the NHIN-Direct Address, but clearly don't need to see the contents. The e-Mail architects would logically use Message level security to satisfy the requirement. There is two solutions here: S/MIME and PGP. These two solutions have benefits and drawbacks that make them about equal but not compatible.

When using a point-to-point protocol, such as HTTP or SOAP, there is no need to expose this additional part of the NHIN 'Address' to the 'IP-Routing'. So, these architects are pushing this NHIN-Direct Address inside the TLS envelop. Note that in the case of SOAP there is the possibility to use WS-Security to enable message level security, but the community of architects recognize that message level security is today very immature and more burdensome. So for simplicity sake we start with TLS knowing that operationally message level security could be used as the technology and infrastructures mature.


All that said, there is an very large elephant in the room. That is that there is very legitimate reasons why a 'facilitator' might need to see the contents. This need would clearly need to be 'authorized' by the endpoints. This 'authorization' would be based on the fact that the 'facilitator' truly does need to see the content. It is this point that the HIE-Policy committee seems to have missed, or chosen to ignore. It is very possible that the HIT-Policy committee is explicitly recognizing this use-case and explicitly forbidding it. I hope that this is not the case as not all Providers or other NHIN-Direct endpoints are equally enabled. Some Providers really will need 'facilitators' to add value to the communications. This value might be in packaging, distribution, reformatting, archiving, etc.


The HIT-Policy committee needs to recognize that some 'facilitators' should be allowed to be 'authorized' to see the contents of the transactions because they explicitly do add value to the exchange.

IHE IT Infrastructure Technical Framework Supplements available for Public Comment

The Public Comment period is now open on the new set of supplements from IHE ITI. Please review and provide critical and constructive comments. The comments are due before June 24. 

The XUA profile has been updated with a few use-cases where we found mature standards and production interest in using these capabilities. There are a larger set of use-cases that we looked at satisfying, but found either no interest from production environments or not sufficiently mature standards. The hope is that over time there will be more demand for these use-cases and there will be more experimentation with the available standards. Once these use-cases mature we will address them. For those that are implementing these unaddressed use-cases now, please let us know. If we have sufficient evidence of a production need and mature standards then we can roll these use-cases into the post Public Comment phase.

The IHE IT Infrastructure (ITI) Technical Committee has published the following supplements to the ITI Technical Framework for Public Comment:

• Cross-Enterprise User Assertion - Attribute Extension (XUA++)
• Deferred Document and Dynamically Created Content (D3S)
• Healthcare Provider Directory (HPD)
• Query Enhancements to Sharing Value Sets

The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments should be submitted by June 24 to the online forums at http://forums.rsna.org/forumdisplay.php?f=198.

NHIN-Direct Focus and Scope Creep

Keith got lots of feathers ruffled today with his blog Governance, SDOs, PEOs and NHIN Direct , primary because he poked at how unlike a standard the current NHIN-Direct distraction is. My comment to his blog was that the intentions are good, but like all projects it is suffering from scope creep.

Glen put his finger on it. The project is unabashedly a prototype project. It makes no pretense of being a standards organization or a profiling organization. It is trying to re-use existing standards to solve a problem that the small provider has little time to focus on. We should view it more as a consulting gig to all the very small doctor offices, and less like a design-for-all project.

As long as the focus stays on helping the very little provider solve this problem, I believe that it will be useful. But as soon as use-cases that are not specific to the very small doctor office creep in, it will have 'jumped the shark'. (like CCHIT and HITSP before it) Scope-creep will eventually kill it as a useful thing. 

And like clock work an email storm today tries to expand the scope of NHIN-Direct to support individual patients sitting in their home using nothing but an email client. There was much discussion of patients being allowed to invent their own NHIN-Direct 'Addresses'. This 'Address' looks very much like an email address, and in a few months when NHIN-Direct is done prototyping and ultimately chooses the one or two specifications to go forward with it might just be an email address. But the discussion nonetheless continues to discuss the use-case exactly as a patient using a common email service.

At this point I couldn't take it anymore and respond with:

Reality check... We need to focus on the NHIN-Direct prioritized Use-cases and focus on solutions that best fit the very small doctor office with 5 or less doctors. We can't be blind to the other potential use-cases, but we also can't be blind to the other realities.

At the face-to-face meeting it was made very clear that:
a) There is no reason why a Healthcare Provider can't send email to a patient today.
b) There is no reason why a Healthcare Provider can't send attachments in the email today.
c) There is no legal reason to secure these communications as long as the Healthcare Provider has reasonable assurances that the address they are sending is the one the patient told them to send it to.

At least that is what I heard (I think from Devon McGraw ).

In addition: Consumer grade email services do NOT support S/MIME or PGP. Yes I know that there are some, but they are not the big guys. Yes I know that one can get add-on packages, or clients. But I assert that they are impossible for the 'common' patient to use, especially those most in need of healthcare. If a patient does know how to set it up, they are free to convince their Provider to use that system. But most importantly, see above. There is no need to confuse patients or providers on this topic.

Now back into the NHIN-Direct use-cases, where the patient is using a PHR like 'service' that is a common service with many other patients; There is a reason to bring in the NHIN-Direct pre-conditions, transaction requirements, and content packaging. The reason is that the PHR is a 'service' that is offered by an 'organization'.

And on this topic, our current specifications do not get in the way of the patient having one or thousands of addresses, or using individual or group endpoints, or even acting as their own organization. The limiting factor will be the willingness of their Healthcare Providing organizations to scale.

Once we are talking 'scale', we should really be discussing Health Exchanges with support for a longitudinal record (e.g. XDS, or NHIN-Exchange). This can be hosted by the patients' PHR or federated by all their providers or both. This is what HealthVault is already doing, providing a longitudinal exchange platform. This is what many HIE projects within the states are doing. See "Where in the World is CDA and XDS".
A full scale health exchange includes policies (See DURSA). A full scale health exchange includes support for policy bridging including handling of consent and authorization. A full scale health exchange includes organization/entity identification and authentication systems (CA and Revocation checking). A full scale health exchange includes support for security audit logging which can feed an accounting of disclosures report. A full scale health exchange has patient identification and patient discovery mechanisms. A full scale exchange includes methods of data segmentation (aka confidentiality coding). Etc... This scale is NOT the focus of NHIN-Direct.

Reality, NHIN-Direct has prioritized use-cases and a focus to support the small Provider office of 5 doctors or less. Yes this means that they will be talking to larger organizations, but the priority for the solution space preference should be "what is best for the small Provider Office".

Accountability using ATNA Audit Controls

As one of the small number of individuals involved in the creation of the IHE Audit Trail and Node Authentication (ATNA) Profile, I am excited to see a vision coming to life. There are those that see the Access Controls as being the tool used to control fine details, this is much harder to do in healthcare give the fluidity of workflows, variability of data, and critical to safety. Thus an Accountability model that leverages Audit Controls are more often used in healthcare. The Audit Controls model supports just as detailed of Policies, but they are enforced using professional ethics and audit log analysis. There are still course Access Controls that keep out those that should never be given access, but those that might need access are given access rights. Along with this is strong training on the policy informing the users that they are under. When using Audit Controls to enforce Accountability there is much more reliance on good behavior enforced through swift punishment as said in an article this week Train Employees Not To Snoop; Fire Those Who Do. This Audit Controls model is not critical to the success of ATNA, but the success of the ATNA audit log is critical to the success of an Audit Control model.

At the time we wrote ATNA we knew that the vendors involved in Healthcare software and medical-devices are experts in; healthcare software and medical devices; and were quite bad at security. This holds true today, although it is getting better. What we wanted to do was leverage existing security infrastructure and keep those developers focused on great healthcare software and medical-devices. This is shown through not just IHE ATNA, but alsoConsistent Time Profile, Document Digital Signature Content Profile, Enterprise User Authentication Profile, Personnel White Pages Profile, Cross-Enterprise User Assertion Profile and to a lesser extent Basic Patient Privacy Consents Profile. All of these profiles tried to invent as little as possible, tried to use as little specialization for healthcare, and use as much of existing and mature IT.


Even within IHE ATNA there are many threads that are exciting to see continue to be a strong force today (like: Mutually-Authenticated-TLS, and Federated Access Controls at the edges). The specific topic of this article is the Audit Logging functionality. As stated above, the healthcare software of the time was really good with algorithms but not good at all at figuring out how to make something useful out of a security event log. At the same time there was an IT industry that was getting quite good at analyzing firewall logs, intrusion-detection logs, database health logs, hard-drive failure logs, etc. We figured that by letting the healthcare software developers focus on developing great healthcare software, and letting audit-log analyzing developers spend their time analyzing audit logs; that we had the helped both groups out.

It was not a smooth path. We tried to find a standards organization that was interested in developing a security audit log message that would meet healthcare's needs for security-surveillance. The usual set of standards organizations for healthcare (HL7, DICOM, ISO, and ASTM) did not think that they were the right place to develop the standard. So, off we went to a neutral third party, IETF. At the time they would allow anyone with interested parties develop a standard. We started with ASTM-E2147-01 "Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems". Through much difficulty, mostly due to growing pains in IETF, we produced RFC-3881. The problem was that IETF rules forced us to keep it 'informative', ok we could have gone through the pain but we found that DICOM would make the schema normative as part of specializing it for DICOM purposes. We then could reference this normative specification in IHE and produce ATNA.


All we needed was a normative transport, which was many more years of struggle. We pointed to the BSD-SYSLOG specification that captured what most everyone was doing with UDP. We pointed to Reliable-SYSLOG, as a freshly minted IETF standard that seemed to have all the right characteristics. Well Reliable-SYSLOG failed in the market, it was too difficult and was not perceived as being worth the extra trouble. We pushed the SYSLOG community to please give us normative specifications and a specification for what most all systems were doing with TCP rather than UDP. Many years later we now have SYSLOG-Protocol, and a binding for UDP and TCP. Even that couldn't be easy as IETF rules forced some unfortunate things.

Along the way, NIST SP800-92 Guide to Computer Security Log Management would all but endorse our model even if they didn't know of IHE-ATNA.  All of the above specifications are really still moving ever so slightly, but are mostly well established. The most interesting development is one in HL7, where a 'service' is being defined specifically for 'accounting of disclosures'. As part of this project we are defining what a audit log event for a disclosure would look like if one knew all the possible attributes (who, what, when, where, why....). This might be an academic exercise, but will give us room to build audit log analysis on. The ATNA can inform an Accounting of Disclosures.

So through all of this growing pain we have tried hard to show at the HIMSS Interoperability Showcase what an audit log repository would look like. It has never really been too exciting, and mostly we must show off incomplete applications. However through much of this I am seeing at least two vendors fighting hard to make the audit log analysis a highly valuable tool. HIPAAT has been in the trenches with us for some time, and I have also encouraged FairWarning. Any others that are out there are welcome to post a comment to this article.

The good news is that we continue to see that audit log analysis does work to detect and convict those that would abuse their access rights against policy. It is important to not just have technology but to use the technology securely.

Much said lately about Security/Privacy, but really nothing new

There was lots of healthcare related privacy and security news last week, but ultimately not much new was said.

• OCR: We Want to See Contingency Plans - they are warning providers that a contingency plan is and has always been required.
• Expert: Make Cybersecurity Enterprisewide - indicating that using a risk based approach is the right solution.
• Survey: Half of IT professionals say health data is less secure than a year ago -  This survey shows up in many articles, not much really is new here either.
• Experts: Train Employees Not To Snoop; Fire Those Who Do - that simple.. the part that most fail on is the ‘fire those who snoop’. But there is good evidence when the patient is a VIP.
• N.M. Medicaid Breach Affects 9,600 - Loss of an ‘unencrypted’ laptop.
• Civil rights office steps up health privacy enforcement - The privacy complaints are arriving and will cause providers to make changes. Providers have had 7 years to react to HIPAA Security/Privacy, OCR is making it real now. (Note found 4 articles on this same topic by different people)
• More Security Guidance Needed - now that OCR is enforcing, the Providers want guidance.
• Watch for ‘Reasonably Anticipated’ Threats - blah blah
• Encrypt, Log and Audit -Yes a good thing to do, but not really the message in the article

All have the same theme. There is now a forcing function in OCR and their Breach Notification web site. It is time to dust off the Risk Assessment tools, Document what you do, and do what you document. To emphasize this, OCR released today Security Rule Draft Guidance

The Office for Civil Rights (OCR) is responsible for issuing periodic guidance on the provisions in the HIPAA Security Rule. (45 C.F.R. §§ 164.302 – 318.)  This series of guidance documents will assist organizations in identifying and implementing the most effective and appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information. The materials will be updated annually, as appropriate.

Yes, nothing new… Well, what is new is a market place realization that they just might need to take security and privacy seriously.

Re: Personal Health Records May Not Be So Personal

When I saw the "Personal Health Records May Not Be So Personal" article I had high hopes at the level of detail they went into. But I was simply disappointed at the lack of detail in the article. I guess and hope that the detail in their actual research is more complete. Their first failing is that they only looked at 'tethered-PHR', explicitly excluding standalone PHR. A tethered-PHR is when a patient is given some form of access into their doctors EHR. This is not the same as a standalone PHR that has multiple data sources and other value. A tethered-PHR has only access to the information that the one EHR provides. This is not a bad functionality, but when it comes to the topic they wanted to investigate it is too limiting.

Overall, the PHR concept itself needs some major maturity. Until more patients try it out and many iterations happen the concept of what a PHR should be is still very 'alpha'. I did like the list of PHR features that they identified. The very small number of people using a PHR (7%) are a vocal minority that are truly interested in participating in the management of their data. I have played around with my provider's Tethered-PHR, and the other standalone PHR. I am motivated to try these tools, but I must simply not be sick enough to get any value out of these tools (not that I am complaining).

Researchers assessed the following 10 PHR policies at each organization:

• Patient proxies enable PHR access;
• PHR access for minors;
• Patient views of electronic health record clinical notes;
• Patient views of EHR diagnosis list;
• Patient control of information access;
• Research using self-entered data;
• Third-party PHR Web advertising;
• Emergency, "break the glass" access;
• Normal lab results PHR availability; and
• Clinical response to patient e-mails.

I would like to respond to a specific thing that was said:

Reti [Shane Reti -- an author of the report and a physician at Beth Israel Deaconess Medical Center] noted that other commercial PHR products, such as Google Health and Microsoft HealthVault, actually lead the field when it comes to patient-centered functions. He said that because such firms are not considered covered entities under HIPAA, they are not bound by the same privacy and security regulations. Reti said that Google and Microsoft still comply with HIPAA regulations, but they "are able to be more creative and move quicker because they don't require the same sign offs and double checks of HIPAA." More

This is NOT so much because they are 'covered entities', as that they are a healthcare provider and are bound by 'Medical Records Regulations'.This does not change the rational that Google Health and Microsoft Healthvault can move faster because they likely don't have as many 'sign offs and double checks'. I am just pointing out that these sign offs and double checks are far more likely a reaction to medical records and torte law. Of course, the standalone PHR vendors will eventually do something stupid, and will over time add checks and double checks. They simply are less burdened by the costs of their mistakes.

FYI: NHIN University - The Trust Fabric of the NHIN

NHIN University to Discuss Issues of Trust in Nationwide Health Information Exchange

In February, the NHIN Workgroup of the HIT Policy Committee recommended to the National Coordinator for Health IT that it is the role of the government to "establish and maintain a framework of trust, including ensuring adequate privacy and security protections to enable electronic health information exchange."

On Monday, May 24, 2010, experts in the development of this and other trust frameworks will serve as faculty for NHIN University's NHIN 104 - The Trust Fabric of the NHIN: Making Exchange a Good Choice.  In this free 1.5 hour online class, students will have an opportunity to talk with these experts about how issues of trust between health information exchange participants are being addressed in the context of the Nationwide Health Information Network.  By participating in this class, students will become familiar with:

• Key components of trust and why they are important
• How the NHIN Exchange trust fabric maps to the key trust components
• Efforts to harmonize the NHIN Exchange trust components with the rest of the NHIN ecosystem, including state-level HIEs and the NHIN Direct program

Register Now for NHIN University!

---

NHIN 104 - The Trust Fabric of the NHIN: Making Exchange a Good Choice

DATE: Monday, May 24, 2010 (add to your calendar)           TIME: 1:00 - 2:30 pm ET
FACULTY: 

• Mariann Yeager - NHIN Policy & Governance Lead (Contractor), Office of the National Coordinator for Health IT (ONC)
• Steve Gravely, JD - Troutman Sanders LLP

WEBINAR:  https://nationalehealthevents.webex.com/nationalehealthevents/onstage/g.php?d=665403498&t=a

AUDIOCONFERENCE:  (866) 699-3239 or (408) 792-6300
(Please join the event with a computer system first and follow the audio instructions on the screen.)

ACCESS/EVENT CODE: 665 403 498

ATTENDEE ID: You will receive this number when you join the event first with a computer connection.

READ THE NHIN 104 COURSE DESCRIPTION AND LEARNING OBJECTIVES

---

 NHIN 105: The Future Landscape will be offered in mid-June.  Watch for details!

---

Review the full Spring Semester Course Catalog: www.NationaleHealth.org/NHIN-U

HIT Standards - Privacy & Security committee - Presentation of HL7 CDA Consent

This coming friday (May 14th), the HIT Standards - Privacy & Security committee will be hosting Ioana Singureanu who will be presenting the current HL7 balloted CDA Consent specification. This meeting is open to the public.

Updated the blog post: The presentation is available as well as the recorded audio.

NHIN-Direct Privacy and Security Simplifying Assumptions

There is an article Policymakers explore patient consent triggerpoint that is a good high-level summary of the discussion going on inside NHIN-Direct around the the Privacy/Security simplifying assumptions of the NHIN-Direct and the more complex situation in the longitudinal Health-Information-Exchange model (e.g. XDS and XCA -- aka NHIN-Exchange).

“We need to talk about data, access, use and retention policies, even when their functions are just transport and some minimal business operations,” McGraw said. More

The simplifying assumptions of the NHIN-Direct are very powerful yet very important to keep in mind. The NHIN-Direct model says that the Sender is responsible for doing a bunch of things before ever sending the data. These things are not unusual, they are needed today when using a FAX, which is the model for NHIN-Direct.  The following is the 'context' of the NHIN-Direct use-cases:

The Sender has made the determination that it is clinically and legally appropriate to send the content to the Addressee.

1. This means that the sender has made sure the address the are going to use is correct. Likely done through some out-of-band communications, once they build a directory they reuse addresses. Addresses might become something that is communicated readily, possibly printed on business cards. The format chosen for the address will look familiar as the format is that of an email address, this does not mean that the transports are all e-mail based (although e-mail is one solution for transport). Much like what is done today with FAX numbers.
2. This means that the Sender has determined that the patient has consented or given appropriate authorization to send the content to the Addressee for the specific purpose. Again, much like is done with FAX today. This means that there is no need for a consent-repository, as it is a sender decision is on a case-by-case basis. Essentially the Sender must have a consent 'on-file', but does not need to produce any electronic version of this.
3. To emphasize the Sender is sending the content to the Addressee for a specific purpose. This purpose might be encoded in the content or not. But it is this purpose that is specific to the transaction. Meaning that the Receiver of the data is not free to use the data for other purposes not authorized. This does not mean that the Receiver can't go through the paper work with the Patient/Consumer to get authorization. This is being pointed out only because the single purpose aspect is important to the simplifying assumptions of the NHIN-Direct.
4. The Receiver does have the right to use the data for the purpose it was sent, but no other purpose. This has a suitableness that is important. The content is sent to the domain of the addressee, and notice given to the human. Meaning that the domain of the addressee is their EHR or PHR. Once nicely tucked inside these systems it is expected to be managed according to the Receiving organization rules. This allows a Provider to know that the received content is now part of their medical-records. This also means that the Receiver takes on maintenance responsibilities for as long as they hold onto the data. This might be a few seconds while the Provider reviews it and they dismisses the content, or it might be the life of the patient chart.
5. The Communications between the Sender and Addressee organization/domain is cryptographically authenticated at the organization level in both directions. This means that the Sender is assured that they truly got connected to the right server, and the receiving server is assured that they are being connected to by a trustable sender. This authentication is mutual because both parties need to be sure they are talking to a authentic opposite. This keeps the bad guys out. This authentication should not be confused with authorization, that comes next.
• Note that with TLS, this exchange of certificates is automatic. There is no need to have the certificate of the opposite prior to connecting. BUT, once the certificate comes down the TLS pipe it must be fully validated including checking the expiration, signature, chain-of-trust (CA), and that the CA has not revoked the Cert. Good luck, this is totally automatic and built into TLS.
6. There is discussion of white-list and black-list. This is not your normal use of these terms but is close. The above step made sure that only authentic NHIN-Direct systems can be communicating. But not all Receivers will want to allow content from all Senders. For example, until a business relationship is formed, it might be very useful to not Authorize an Authenticated system to communicate. That is that one can be sure that the Sending system is authenticated as being a NHIN-Direct system, but because no business relationship is in place, they don't want to receive content. This is simply good defensive business. So, there is talk about having a system configured to reject all but those certificates on a 'white-list', or to accept all but those certificates on a 'black-list. I guess this is similar to the assistant that looks at the received FAXes and weeds out some of them.
7. TLS would also be encrypting using AES (or better) and SHA1 (or better). Lucky us, TLS does this negotiation automatically.
8. The Sender is responsible for any Accounting of Disclosures, as is the Receiver. Even if they are not Covered Entities, they should maintain a Security Surveillance Audit  (see ATNA)

These simplifying assumptions are very critical to allowing the NHIN-Direct solution to be very simple. These simplifying assumptions are not intended to remove responsibility, they are very explicitly stating the responsibility still exists but is cleanly pushed into Policy and Procedure space.

HHS/OCR Looking for input on Accounting of Disclosures

Fantastic news, someone in the government wanting to get information BEFORE they make rules. The Federal Register text is only 2 pages, so go and read it. This is not only great news but the information the are looking for is reasonable and will be useful to them.

HHS Releases Request for Information for Accounting of Disclosures Rulemaking

May 3, 2010

The U.S. Department of Health and Human Services Office for Civil Rights (OCR) published a request for information today seeking comments to better inform upcoming rulemaking that will expand an individual's right to receive an accounting of disclosures under the HIPAA Privacy Rule.  Currently, the HIPAA Privacy Rule provides an individual with the right to receive a listing – known as an accounting of disclosures – that provides information about when a HIPAA covered entity discloses the individual's information to others.  The current HIPAA Privacy Rule does not require a covered entity to list disclosures to carry out treatment, payment, and health care operations.

The Health Information Technology for Economic and Clinical Health (HITECH) Act, part of the American Recovery and Reinvestment Act of 2009, provides that an individual has a right to receive information about disclosures made through a covered entity's electronic health record for purposes of carrying out treatment, payment, and health care operations.  The HITECH Act requires the Secretary to balance the interests of individuals in learning about these disclosures with the administrative burden on HIPAA covered entities to track the disclosures.

This request for information seeks comments so that OCR can learn more about the interests of individuals and the burden on covered entities with respect to accounting for disclosures for purposes of treatment, payment, and health care operations.  The request for information will be followed by a proposed rule, providing further opportunity for comment.  The request for information is available at: http://edocket.access.gpo.gov/2010/pdf/2010-10054.pdf

The best part of this is found on page 2 . Here are just the first 5... there are far more... Really, go read the text.  The unfortunate part at this point is that the comments received will be made public, and thus no vendor or provider is actually going to put the truth into comments. 

II. Questions
1. What are the benefits to the individual of an accounting of disclosures, particularly of disclosures made for treatment, payment, and health care operations purposes?
2. Are individuals aware of their current right to receive an accounting of disclosures? On what do you base this assessment?
3. If you are a covered entity, how do you make clear to individuals their right to receive an accounting of disclosures? How many requests for an accounting have you received from individuals?
4. For individuals that have received an accounting of disclosures, did the accounting provide the individual with the information he or she was seeking? Are you aware of how individuals use this information once obtained?
5. With respect to treatment, payment, and health care operations disclosures, 45 CFR 170.210(e) currently provides the standard that an electronic health record system record the date, time, patient identification, user identification, and a description of the disclosure. In response to its interim final rule, the Office of the National Coordinator for Health Information Technology received comments on this standard and the corresponding certification criterion suggesting that the standard also include to whom a disclosure was made (i.e., recipient) and the reason or purpose for the disclosure. Should an accounting for treatment, payment, and health care operations disclosures include these or other elements and, if so, why? How important is it to individuals to know the specific purpose of a disclosure— i.e., would it be sufficient to describe the purpose generally (e.g., for ‘‘for treatment,’’ ‘‘for payment,’’ or ‘‘for health care operations purposes’’), or is more detail necessary for the accounting to be of value? To what extent are individuals familiar with the different activities that may constitute ‘‘health care operations?’’ On what do you base this assessment? 
.....

A Secure EMR Transition

This is a nice piece written by a security expert that is making wild assertions that are likely to be true but I think there are far easier fruit to grasp. What I mean by this is that the article is full of the typical security banter about policy, procedure, least-privilege, etc. These are all good things, what bothers me is that these are said without a evidence that these are actually causing harm. Where as we have lots of evidence that more simple things like turning off an account of someone that just got fired is causing harm. That defining what is allowed and what is not, so that you know if your security is in control or not. Or a host of other times when an EHR is not used securely. But, the point is that this article is sound generic IT security.

To implement EMRs securely, organizations will need to replace their trust-based security method with an approach based on processes and policies. These processes and policies should give employees only the required access to confidential information they need to do their job, while providing a highly automated and efficient process for granting privileges when needed. More

Prison for HIPAA Privacy Violator

There are so many strange aspects with this case that I am not sure I would draw such a tight headline to HIPAA. The main part of the story that I don't think is made clear is that this is yet another case of an employee getting FIRED and their account not being disabled for at least four weeks.

On Oct. 23, 2003, he received a notice of intent to dismiss him for performance reasons that did not include illegal access of medical records. That evening, he accessed medical records of his superior and co-workers, and during three other periods during the next four weeks accessed UCLA patient records, many of them involving celebrities, a total of 323 times, according to the FBI office in Los Angeles. More

Personal health records most likely to be used when doctors recommend them

As a patient myself I don't find the results of this survey too surprising. I surely would not be interested in a PHR from the insurance company. I am not interested in a PHR from my employer. Like many now days I am suspicious of the current models for independent PHR; Even Google's do-no-harm motto seems to be highly tarnished (I have to be careful saying that on a Google hosted blog).

58% said they might be interested in a PHR from a hospital or physician with whom they already have a relationship. Fifty-two percent said they might be persuaded to use a PHR if a doctor said it was safe, while 50% said they would use a PHR if a friend or family member said it was safe.  More

To have my healthcare provider offer a PHR seems useful. My healthcare provider does offer a PHR interface, but I question how useful this would be if I had to move. The tool doesn't seem to give me the ability to export my data so that I can carry it with me to my new town. It also doesn't give me an accounting-of-disclosures, something that seems logical given that the PHR is clearly just a module on their EHR.

The number of people using personal health records has doubled in the past year. But those users still account for only 7% of the American patient population, according to one recent survey. More

The good news is that PHR use is up, the bad news is that it is only up to 7%. I am not sure how much higher it will go, but I suspect that it won't ever be too high. I think that there are few people that (a) want to mess with their data, or (b) need to mess with their data. The (b) group is likely to be the larger.

HIT Policy - Patient/Consumer Engagement Hearing

I was not able to listen live to this testimony, so I downloaded the MP3 and listened to it on my drive to/from Chicago for the IHE meetings. This is 4 hours of passionate pleading to include the Patient/Consumer engagement into Meaningful Use. There is no questioning of the passion behind each and every individual giving testimony.

HIT Policy Committee Meaningful Use Workgroup
Tuesday, April 20, 2010, 9 a.m. to 3:30 p.m./Eastern Time
Panel 1:  Meaningful Use of HIT in the Real Lives of Patients & Families
    Moderator:  Christine Bechtel
    Scott Mackie, Health & Wellness, IDEO, Inc.
    Eric Dishman, Director, Health Innovation & Policy, Intel Corp.
    M. Chris Gibbons, Johns Hopkins University Urban Health Institute
    Neil Calman, MD, Institute for Family Health
    Regina Holliday, patient voice
Panel 2:  Incorporating Patient-Generated Data in Meaningful Use of HIT
    Moderator:  David Lansky
    James Ralston, Group Health Research Institute
    Patti Brennan, University of Wisconsin, Project Health Design
   Carol Raphael, Visiting Nurse Service, NY
    Dave DeBronkart, ePatient Dave
    David Whitlinger, NY eHealth Collaborative
    Hank Fanberg, Christus Health
Panel 3:  Policy Challenges & Infrastructure Requirements to Facilitate
Patient/Consumers’ Meaningful Use of HIT
  Moderator:  Deven McGraw
  Joy Pritts, Chief Privacy Officer, Office of the National Coordinator
  James Weinstein, Dartmouth Institute for Health Policy & Clinical Practice
  Carl Dvorak, Epic Corporation
  Cris Ross, MinuteClinic   

However I was very frustrated that the little nuggets of new information in the testimony was overshadowed by the passion of the message. I never once heard a question from the committee members that was on these nuggets. The questions were mostly on the parts that the healthcare community continues to hash over and over. I kept expecting the chairman to summarize these nuggets.

The main message I extracted out of testimony, that I think was more-or-less lost on the committee, is that there is a HUGE amount of miss-information around what the Law says. Over and over I heard people asking for access to their health record. This 'right' was very clearly given to the patient in the HIPAA rules, and was further given again in ARRA. If it was given to the patient yet again, I don't think anything would change. Clearly the problem here is that the healthcare community doesn't understand the clear text in the current text. This is a gap of training, not a gap of regulations. This lack of training was not unique to access to the health record, there were many other topics that boil down to the same problem.

I heard strong need for Consent to be fully informed. Healthcare Providers need help from somewhere to help them explain what their Privacy Policies mean to the patient. This is also a case of not communicating with the Patient, but is also related to the whole mess around the meaning of consent in the USA. This complexity in privacy policy is not helping anyone at this point. We need simplification in the Privacy Consent landscape.