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.