Three sentenced for privacy violations in Pressly case

HIPAA violations do actually get convictions...

Arkansas News Bureau — A federal judge sentenced a doctor and two former hospital employees to a year’s probation each today after they admitted to violating federal privacy laws by looking at the medical records of slain TV reporter Anne Pressly.
Dr. Jay Holland of Little Rock also was fined $5,000 and ordered to perform 50 hours of community service educating professionals on the importance of patient privacy under the federal Health Insurance Portability and Accountability Act, also known as HIPAA.
Sarah Elizabeth Miller of England, a former account representative at the St. Vincent Medical Center in Sherwood, was fined $2,500 and Candida Griffin, a former emergency room unit coordinator at St. Vincent’s main hospital in Little Rock, was fined $1,500.
The three pleaded guilty in July to misdemeanor violations of the health information privacy provisions of HIPAA for accessing Pressly’s medical records without any legitimate purpose. More

Groups: Genetic Data Rule Flawed

I find this article and statement somewhat tragically ironic. It shows that although the updates to GINA, a genetic privacy rule, are being seen as going too far. This group would like genetic information to be used to receive discounts, event hough they likely still would be against genetic information being used for increased fees. This is likely a case of a policy going too far. One solution would simply allow a patient to authorize any use of their genetic information including for the purpose of getting a discount.

"As noted, GINA's intent was to prohibit group health plans and insurers from collecting genetic information 1) prior to or in connection with enrollment; and 2) for underwriting purposes," according to the letter. "The final interim regulations broadly define 'underwriting purposes' to mean rules for determining eligibility (including enrollment and continued eligibility), computation of premium or contribution amounts, and application of pre-existing condition exclusions. This definition includes changing deductibles or other cost sharing mechanisms, or providing discounts, rebates, payments in kind, or other premium differential mechanisms in return for activities such as completing a health risk assessment (HRA) or participating in wellness programs. The new regulations clarify that offering reduced premiums or other reward for providing genetic information is an impermissible 'underwriting' activity. More

HIT Standards - Implementation Workgroup hearing

This workgroup/hearing will be very interesting to help expose the separation between desired capabilities, practicle capabilities, future capabilities, and how that relates to standards selection.

A G E N D A
HIT Standards Committee
Implementation Workgroup
Thursday, October 29, 2009, 9 a.m. to 4 p.m./Eastern
OMNI Shoreham Hotel, 2500 Calvert Street, NW, Washington, DC

 Note about this meeting:The HIT Standards Committee has inaugurated an Implementation Workgroup which is charged with bringing forward “real-world” implementation experience into the HIT Standards Committee recommendations, with special emphasis on strategies to accelerate the adoption of proposed standards, or mitigate barriers, if any. The Implementation Workgroup is holding a public hearing on the topic of Adoption Experiences on Thursday, October 29, 2009, in Washington, DC. We have organized a series of panels to address the issue.

9:00 a.m. Call to Order/Roll Call – Judy Sparrow, Office of the National Coordinator

9:05 a.m. Welcome and Introduction – Aneesh Chopra, Chair, Implementation Workgroup

9:15 a.m. Non‐Healthcare Industries Panel – Moderator:  John Halamka, HIT Standards Committee Co‐Chair

10:30 a.m. Providers Panel ‐ Moderator:  Judy Murphy, HIT Standards Committee member

•  Andy Wiesenthal, Kaiser Permanente (IDN)
•  Dick Taylor, CMIO, Providence Health, Portland, OR (IDN)
•  Rick Warren, VP/CIO, Allegiance Health, MI (Community Hospital)
• Lisa Bewley, VP/CIO, Regional West Medical Center, Scotts Bluff, NE (Community Hospital)
• Louis Spikol, MD, from Allentown PA (Small Practice)
• Roland Goertz, MD/Waco, Texas (Small Practice)[invited]
  

12:00 p.m. BREAK

12:45 p.m. Vendors Panel – Moderator:  Cris Ross, HIT Standards Committee member

•  Rick Ratliff, SureScripts
•  Arien Malec, Relay Health
•  Sean Nolan, MicroSoft
• Girish Kumar, eClinical Works
•  Ian McCrae, Orion Health [invited] 
  

2:00 p.m. Quality Measures Panel – Moderator: David McCallie, HIT Standards Committee member

•  Ralph Brindis, American College of Cardiology
•  Richard Gliklich, CEO, Outcome Sciences
•  Kepa Zubeldia, Ingenix [invited]
•  Jesse Singer, NYC Health [invited]
  

3:00 p.m. Meeting Summary – Aneesh Chopra, Chair

3:30 p.m. Public Comment

4:00 p.m. Adjourn

Feds crack down on medical ID theft and Medicare fraud

Security technology can do only so much, but it is still important.

Health and Human Services Secretary Kathleen Sebelius and Assistant Attorney General Tony West are urging seniors to take steps to avoid medical identification theft and Medicare fraud. As part of the Obama administration's ongoing effort to fight Medicare fraud, Sebelius and West unveiled at a Thursday press conference new information designed to help seniors and Medicare beneficiaries "deter, detect and defend" against medical identity theft.More

ONC revisits linking consumer preferences to EHRs

This article has some nice content, but fails to explain what they mean in their title about ONC revisiting the linking of consumer preferences to the EHR. I was intrigued by this statement as I had not heard anything like it.
I have posted a blog entry where I request that HHS/ONC/HIT leadership recognize that the current TP30 (BPPC) as meeting some simple needs, while continuing to push for continued developments.

The Office of the National Coordinator is weighing proposed requirements for how consumers’ preferences about their healthcare and personal health information could be made inseparable from their electronic health record.
According to a consumer preferences draft document, for which public comments were due Friday, standards built around the requirements would enable patient preferences about the use of their health information to be “interoperable” among those authorized to handle the record. More

Consumer Preferences and the Consumer

John Halamka posted a blog entry this morning where he discusses the current state of Consumer Preferences for data use (aka Consent to Privacy-Policy). He does a good job of explaining that this is critical to the success of Healthcare IT, and gives his views .

In my experience, something simple such as opt-in consent for data sharing at the institution level, will result in much more privacy because the security technologies required to support it are simple and easy to understand.

Including his vision of requirements (bold emphasis added by me):

My ideal plan for consumer preferences would be

1. We develop national policy which clearly delineates the types of consents we need to support. Ideally, this will be a short list. I prefer consumer opt-in at the institution level. To be compliant with ARRA and state laws I can imagine this being expanded a bit to include very basic segmentation of the record into mental health, HIV results, and everything else.

2. This consent will be recorded electronically and made available via a health information exchange, the PHR of the patient's choice, or via a mobile storage device such as a USB drive. When a patient presents for care, the consent is queried, and all data exchanges follow this declaration of confidentiality preferences.

3. The standard for recording consent would be XML-based and not require a "wet signature" or an image of a signature. I realize that some state laws still require handwritten consents, so policy work is needed here.

Given all this activity regarding consumer preferences, control, and empowerment, let's hope the policymaking gets done by 2011 and the standards to support the policy can be simple to deploy and manage. The more complex meaningful use data exchanges in 2013 and 2015 depend upon it.

I commented that what he is asking for is supportable with TP30 today. I want to explain a little more detail here. He does leave out some of the details, so I will have to invent some details for him. I assume that he is indicating that a consumer would register a consent with every institution that they want to share data with, and only if there is a specific OPT-IN registered with that institution would information be allowed to flow into that institution. Which unfortunately means that any sourcing institution would somehow need to be able to recognize an OPT-IN policy that was agreed to by the patient at that target institution.

This is not a problem for TP30 (BPPC) today, but is a complexity that may not be as obvious to all readers. Because of this complexity, we would need to have a 'template' OPT-IN policy, where the language is clear as to what can and can-not be done. Given that we are trying for a simple system, lets assume we can say that this OPT-IN policy allows the receiving organization to use the data only for treatment purposes and allows them to archive a copy in their medical-record only for treatment purposes. This forbids secondary use of the data transferred (It says nothing about their own secondary-use of their own created data). We now have the precondition for TP30 complete, a defined policy written in human readable form. I would argue that the policy needs to cover an agreed list of data segments, user roles, and treatment uses including break-glass. TP30 does not require that we now convert this policy into an XML form, a key question I had on John's requirements. But it does require that we globally identify this policy with an OID, lets say 1.2.3.4.5.6 (the standard example OID).

So, a patient would go into an agreement with a receiving institution, possibly signing a copy of the policy on paper with a pen. The institution would create a TP30 document, which is a CDA document that encapsulates the 'Act' of the patient agreeing to the specific privacy policy. Thus we have the patient identity, receiving institution identity, and the policy agreed to identified (OID). This CDA document is registered in the local HIE announcing to the rest of the NHIN that this receiving institution does have an agreement with the patient for this OPT-IN policy. This receiving institution now attempts to query across the NHIN and/or receive documents from other sourcing institutions. The sourcing institutions will not return results unless they can see evidence that the patient has agreed with the OPT-IN policy with that receiving institution, they can in this case so they return the results requested.

This is exactly what the NHIN did with TP30, and they actually went one step further and did this type of enforcement in the NHIN backbone. They can do this because they can see that the receiving institution is authorized by the existence of the CDA document being registered.

The hard part is getting someone to write the policy language. TP30 even envisions that there could be a small set of policies, including those postulated by John (bold added by me)

2. Policymaking can constrain technological complexity. If every possible permutation of consent (opt in, opt out, segmentation of the record, approval for sharing at the institution level, approval for sharing at the provider level, approval based on the situation - emergent care or not, etc.) needs to be supported by every stakeholder exchanging data, then the number of standards needed will be significant. Ensuring comformance with a large number of standards at every point of data exchange will be challenging. In my experience, something simple such as opt-in consent for data sharing at the institution level, will result in much more privacy because the security technologies required to support it are simple and easy to understand.

So you see, I think that TP30 as it is currently specified, using IHE-BPPC, can and should be used right NOW to give consumers choice, while we continue to develop a privacy/security policy schema and vocabulary that will give them more expressive ability in the future.

How Private can Electronic Information Ever Be?

This article is yet another article that is discussing how a university researcher took some de-identified data, netflix in this case, and claim they have re-identified some of the customers.

By comparing the film preferences of some anonymous Netflix customers with personal profiles on imdb.com, the Internet movie database, the researchers said they easily re-identified some people because they had posted their e-mail addresses or other distinguishing information online. More

Their claim is only that they were able to identify some of the customers, customers who had them-selves posted public reviews of the movies they watched. Thus I am not sure this is really a good example of re-identification as the customer had already identified them-selves.

But it does point out that de-identified data can sometimes be re-identified with some effort, something I have already blogged about De-Identification is highly contextual. Thus any de-identified data set must still be considered sensitive, it is just less sensitive than it was before. How much effort it takes is dependent on how much data is left in the data set, and how public the individuals of interest are.

The tie to healthcare is that this article then draws a line between movies-watched to health-information, and some of the typical discussions around the sale of de-identified health-information.  There is some discussion of this, but it is clear this section of the article was intended to be google friendly, making sure they used every keyword they could come up with. The article even concludes with a quote from Deborah Peel, a rather interesting point that there is a lack of laws against the act of re-identification. It might be useful to have a law like this.

What has HITSP done to protect confidentiality with a suite of implementable security standards

I have been asked this question quite a few times lately. As with any segment of technology can be shown to follow the Gartner Hype Curve, so I will show how the HITSP Security and Privacy solutions map. Some have expected to find this kind of an answer in TN900 but it is focused on explaining the preconditions to a Privacy and Security program.

Plateau of Productivity -- The core of the security is well mature and successful

SC109 – Security Audit

T14 – Consistent Time – NTP or SNTP

Something built into EVERY operating system since 1995

T15 – Secure Audit Log – ATNA

A healthcare specific audit logging schema that has been adopted by DICOM, IHE, and now ISO

T17 – Secure Communications Channel –

TLS -- Something built into every Browser, Web-Server, and Application Server – EVER

Web-Services Security – very immature but in there to satisfy academics that think it is critical

Slope of Enlightenment.

C19 – Entity Identity Assertions

This technology is in a good place on the Gartner curve. It is well implemented in platforms. GE has been using this for 3 years as the way they hook to 3^rd party services like travel reservations through Sabre. This is in the Slope of Enlightenment because of slow roll-out. The technology is very stable and plentiful. But until people get off of proprietary authentication systems that have been built into their EHR/EMR it will not take off.  The reason why proprietary user authentication is the rule today in healthcare is because the workflow in healthcare is NOT desk based. It is patient centric, as users (Doctors, Nurses, etc) move from workstation to workstation and log into a ‘session’ that is already in process. This ‘session’ is locked onto the patient. Because of this workflow it is very hard to re-use user authentication systems that are used in workstations and other industries.

SAML can help here, it can provide a way to support the green-fields of HIE interaction leveraging the existing authentication. I wrote a White Paper for IHE that discussed this XUA Implementation Demo 2005 Guide, this was in August of 2005. This is not the ultimate solution, the ultimate solution is that an enterprise class authentication must be built into the EHR and something WS-Trust is used to convert that enterprise class authentication into a SAML assertion.

So, much needs to change in healthcare before this takes off. But there really are no alternatives, and certainly none that support this environment better.

Peak of Inflated Expectations

TP20 -   Access Control

Pie in the sky, stuff we are pushing the innovation envelope (See Jacks 4^th bullet)

IHE access control is the third part of ATNA. A part HITSP choose not to recognize but rather push innovation and see if we can inspire some standards development. We have succeeded on that point.

When the concepts of TP20 was presented to IHE, they turned it down as having too little interest to implement and that the standards were too immature.

TP30 – Management of Consents

I am happy with where this is today, and very happy with where it is going. This is far more balanced than many view

a) BPPC – Today’s solution. Satisfies the ‘good enough’ clause for Opt-IN, Opt-OUT, Opt-OUT-with-BreakGlass

b) Pushing the innovation front such that HL7 is building a privacy Domain Analysis Model, and Services

I am disappointed that BPPC isn’t pushed to at least get Opt-IN/OUT support. It will be close to a decade before true dynamic policies and enforcement happen.

The other things that we call Security/Privacy are really very specific tools and therefore are really hard to put on the Hype Curve with these other things.

Document Integrity –

This is actually just leveraging a normal capability in TP13, T33, and T31. Nothing new here

Non-Repudiation of Origin –

This is XML-Digital Signatures. The technology is well mature. The missing part is a good reason to fund implementation of all the infrastructural parts that are preconditions. The federal government has chosen to fund PKI through the PIV card rollout. So, I expect they will start using this technology. Will they bother bringing their implementations to Connectathon? I don’t think they will care to or be compelled to.

This technology is very common now days in the ‘Clinical Trials’ space, especially on Drug-Trials. The FDA accepts the paperwork signed using Digital Signatures today.

Anonymization and Pseudonymization

This is the most niche constructs we have. More so than the Components that they operate on, and less re-useable. This puts them into the space of being close to unrankable and untrackable.

However they are very easy to implement

T24 is just TP22 with some management of a special configuration to make a standalone server for each study.

The anonymization constructs can be implemented with simple XSLT (ok I don’t have proof, but do have good theory)

           

This is not just my view. Here are a couple of others

NIST wrote an IR that all but endorsing everything HITSP did:

            NIST IR 7497, Jan. 13, 2009, DRAFT Security Architecture Design Process for Health Information Exchanges (HIEs)

All of our Privacy and Security constructs, including TP20 and TP30 are built into the FHA CONNECT platform.

I like the sage advice that John Halamka gives after final seeing the light “My Privacy and Security Lessons Learned”

update to HIT-Standards Privacy and Security selections

This week HIT-Standards meet again and there was some updates.
The Privacy and Security updates were fixes. They consisted of two items:
1) SOAP version now fixed at 1.2. There was a misunderstanding before that SOAP 1.1 was needed, but reality is that the marketplace using the selected healthcare standards isn't actually using any SOAP 1.1
2) Kerberos. This was a misunderstanding as well that I outlined on my blog

A big question came up after the meeting when Keith was looking at the whole specifications again. From the selections it is not clear what Topology is required in 2011. It is clear that SC112 is required, but this include multiple Topologies that use XDS(XCA), XDR, and XDM. I have been told that the answer is as Keith has stated. Pick at least one. Anyone will do. What is not as clear is that when you pick one, you need to pick both-sides of that one. That is you must pick a way to send and receive. For Example: If you pick XDM, then you must be able to publish to XDM and consume XDM. Ill be interested to hear Keith's perspective on consumption, does this mean just 'view' or does it mean 'import in full fidelity with complete attribution of source'?

Connect update improves health data security

The Connect project has included some of the leading edge standards and technologies in it's latest release. Some of it is the kind of baseline I have been recommending for years (IHE ATNA). Some of this is testing some new concepts, such as consumer preferences and authorizations.

The latest Connect version of Connect also strengthens security by using the same protocols in the interface between the healthcare organization and the Connect gateway that have been used between Connect and the NHIN, Westberg said. These include two-way Secure Sockets Layer (SSL), digital signature, and Security Assertion Mark-up Language (SAML), a standard for exchanging authentication and authorization data.More

IHE ITI Planning Committee - Announces 8 candidate proposals moved forward

There are a few proposals interesting to Healthcare Security/Privacy, although they all will need to answer the security/privacy risk assessment. I will be driving an update to the XUA profile to add common attributes about the user context that would be used to support Access Control decision making. This supplement will utilize the OASIS XSPA work, HITSP TP30/TP20/C19, and the IHE Access Control white paper. There is strong pledges of support from the international members, so I expect this to be a global effort.

The IT Infrastructure Planning Committee is pleased to announced the final slate of Profile and White Paper proposals that will advance to review by the Technical Committee.  Eight proposals were selected and ranked in order of Planning Committee criteria (market support, relevance, etc.), and documented on the spreadsheet found at this link.  Thanks to all proposal authors for their excellent preparatory work, and congratulations to those proposers/editors that have proposals going to the next stage.

Next steps are:

• Detailed proposals are required to be submitted by COB November 2^nd, 2009.  The detailed proposal template can be found here.  Authors should send their detailed proposals to ITI Technical Committee Co-Chairs Karen Witting (witting@us.ibm.com) and Rob Horn (robert.horn@agfa.com), with copies to Celina (croth@himss.org) and Lisa (lspelling@himss.org).
• The ITI Technical Committee will meet face-to-face in Oak Brook IL on November 10-11, 2009, in order to evaluate the proposals and formulate a recommendation.
• The ITI Planning and Technical Committees will meet jointly on a tcon in December (date tba) to finalize the slate of work items for the 2009-2010 planning cycle.

Thanks also to our host in Paris (Manuel Metz), and to all who participated in leading us to our selected proposals.

Cheers,

Mike Nusbaum

Charles Parisot

--------------------------------------

Co-Chairs

HITSP Webinar anounced - Security, Privacy and Infrastructure

I will be presenting the current state of HITSP Security, Privacy and Infrastructure.

November 12 – Security, Privacy and Infrastructure 2-3:30 p.m. Eastern

Look for more webinar information on the registration page on the HITSP Web site. Participation in any of the HITSP webinars is complimentary, but advance registration is required.

Check the HITSP website to register for these webinars.

View the webinar schedule

Listen to previous HITSP webinars

Stolen Laptop Holds Unencrypted Data of 850,000 Doctors

This is not Patient data, but then again maybe Doctors will care more about privacy in general now that their privacy has been breached.

A laptop computer stolen from the car of a BlueCross BlueShield employee contains unencrypted personal data of 850,000 physicians.  The data include names, addresses, tax ID numbers and national provider identification numbers.  About 187,000 of the physicians use their Social Security numbers (SSNs) as their tax ID or national provider numbers.  Company policy dictates that the data be encrypted, but the unidentified employee downloaded unencrypted data to work on at home; BlueCross BlueShield is reviewing its security policy in light of the incident.  The theft occurred on August 27, 2009. More and More

Opt-In, Opt-Out.... Don't publish THAT!

The standards for Privacy-Policies including Consent and Authorizations is being feverishly developed right now. These efforts are trying to fill all the gaps that exist today, and there are many. In the mean time we have a very Basic solution that can support very basic privacy-policies including Opt-In and Opt-Out (aka. HITSP/TP30 - Manage Consent Directives (IHE-BPPC profile)) This might support %80 of patients or might be only %20, I suspect it is closer to %80. But no matter what, there is some fragment of the population that will not be happy with these options. For these patients time will bring the solution, but today they can withhold information, a time tested solution.

People Can Opt Out of Listing STDs, Abortions in Gov't-Mandated Electronic Health Records, Patrick Kennedy Says

(CNSNews.com) - Rep. Patrick Kennedy (D.-R.I.) says people will be able to stop doctors from including records of sexually transmitted diseases and abortions in the new national system of Electronic Health Records that was mandated by the stimulus law enacted in February.

The law says that doctors, hospitals and other health care providers must create an Electronic Health Record (EHR) for every American by 2014 or else face deductions in their Medicare payments. The EHRs are supposed to be integrated into a national health care IT system where health-care providers nationwide as well as the government would have the ability to access them when authorized.

“This is totally going to be up to the individual,” Kennedy told CNSNews.com when specifically asked if these EHRs would include any STDs or abortions in a person's medical history. More

De-Identification is highly contextual

De-Identification is a process that is used to lower risks. It is is not an appropriate tool for 'treatment' uses as one must be able to positively identify the patient with the data in order to properly and safely treat the patient. But it is a very useful tool for secondary-uses of the data. The first step is to define the specific secondary-use. It will become more clear why this is true as we go through the de-identification process. The basics are that security/privacy wants to remove all the data elements as that is the only to be truly secure with zero risk, yet the secondary-use needs some data to be successful. So there is a trade-off of removal, keeping, and fuzzing.


There are some data elements that are direct identifiers (e.g. Name, Address, Phone Number, SSN) and these are simply removed. There are some data elements that are identifiers (e.g. insurance, payment) that are completely unimportant to the specific secondary-use and are simply removed. Sometimes the secondary-use needs to be able to have some way to link data over time (For example to determine if a treatment given one year is still effective years later). If this is needed then a pseudonym can be applied to the data, but applying a pseudonym brings in risk so must be done selectively and with purpose. A pseudonym is an identifier that is assigned consistently to the data, but has no apparent relationship to the original patient. Sometimes these pseudonyms can be assigned in a non-reversible way, yet other times the secondary-use have potential benefits to the patient that the risk of a reversible pseudonym is acceptable (e.g. after a clinical trial the patient is often informed of their previously blinded treatment and given recommendations). The pseudonym is often a randomly assigned value that is kept in a secured lookup table (See HITSP T24) that is very carefully protected (e.g. only the direct-care provider has access).


There are health data elements that are structured and coded and if these are needed by the secondary-use then these are generally left in place. Even with structured and coded values there needs to be a reason why the secondary-use requires the data as some structured and coded values can also be used to identify populations. The best case is to have the resulting data-set with multiple subjects statistically examined to identify if there is any segmentation that is too small in the data set. There are data elements that are NOT structured or coded (e.g. text comments) these are always simply removed as there is no way to be sure the data doesn't include identifiers.

This leaves a set of data elements that are 'Indirect Identifiers', that is they can be used by someone that is motivated and has the funds to re-identify the data. A great example of this was shown by Latanya Sweeney from CMU using simply: Date-of-Birth, Current ZIP Code, and Sex. (see below). So, for these data elements we go into a negotiation between the security/privacy folk that want to simply remove these elements and the secondary-use that possibly want them. In many cases we find that we can delete these elements as they are not critical to the secondary-use. In other cases we use some form of fuzziness algorithm to change them a little but within tolerance of the secondary-use. For things like ZIP Code, this can be done by removing the last two digits. This generally keeps the data as identified to a specific region but doesn’t point at a community. Dates (e.g. Date-of-onset, date-of-examination, date-of-treatment, etc) are an important part of this. For dates we have many algorithms we can use but each one has a drawback so it is important to pick the best one for the secondary-use: we can drop the day-of-the-month, we can adjust to days-since-birth, we can adjust-all-dates-by-a-random-but-consistent-to-the-patient, etc… The algorithm used is very specific to the secondary-use, for example a secondary-use that is trying to determine the outcome of a natural disaster needs to be able to associate the onset of a problem with time since the disaster.

So, what works for one secondary-use, will most likely be useless to another secondary-use.This is why HITSP has multiple ‘anonymization’ constructs (i.e. C25 - Anonymize (for Biosurveillance and Quality), C87 - Anonymize Public Health Case Reporting Data, C88 - Anonymize Immunizations and Response Management Data) and why the T24 - Pseudonymize construct doesn’t define the algorithm for the pseudonym. These become context specific.

See:

What is minimally necessary to identify an individual? All you need is Date-of-Birth, Current Zip Code, and sex. See the following.

• Latanya Sweeney, Ph.D.
  • Reidentification of Individuals in Chicago's Homicide Database A Technical and Legal Study
  • Genomic Privacy Project
  • k-Anonymity: a model for protecting privacy
  • Birthday Scam
  • Birthday Paradox Wikipedia

EPIC article that included 2 cases of failure http://epic.org/alert/EPIC_Alert_15.23.html

January 2007; Interesting article by Bruce Schneier Why Anonymity doesn't work - Anonymity and the Netflix Dataset with some really good pointers to other articles.

ISO/TS 25237:2008 - Health informatics -- Pseudonymization

DICOM Supplement 55 is a great reference for DICOM objects. This text has been incorporated into the DICOM standard, but I provide reference to the supplement as it is easier to point at and is self contained.

Certification Commission Launches 2011 Certification

CCHIT has started their new certification, targeting Meaningful Use -- they hope. They clearly did adjust their criteria to the HIT-Standards Privacy and Security selections.

I don't see ANY updates to the privacy specifications. This is consistent with the HIT-Standards Privacy and Security requirements around waiting on CAP143 and TP30 (BPPC), but I am disappointed that Consumer choice continues to be delayed even though simple consents can be supported today including: Implied Consent, Opt-In, Opt-In-Time-Limited, Opt-Out, and Opt-Out-with-Break-Glass. I didn't find these in the Advanced Interoperability Test Plan either.

They were going to try to add "Advanced Security" but I don't see this as a standalone set of requirements yet.

New in security in 2009:

• SC02.01 — Configurable inclusion or exclusion of audit events
  
  • They have tried this before, the idea is that an organization implementing the EHR should be able to make policy decisions where they decide not to save some security events simply because they don’t have a process to analyze them
  
  
• SC02.03 — Use ATNA
  
  • Wonderful idea. Not sure how useful this is to small non-connected EHR; but it is very important for EHR that is connected to an HIE
  
  
• SC02.07 — Audit Reports/Exports using ISO 8601 date/time stamps
  
  • I thought this was already in there. The point of this one is that analysis of audit logs usually requires combining audit events from many systems. The date/time that events happened is the one thing that can be sure to be common in all audit logging systems, and is critical to putting together the overall analysis
  
  
• SC06.06 — Data at rest should be encrypt-able using 3DES or later
  
  • I tried to explain that this is typically NOT controlled by the EHR vendor, but rather is a open choice of the provider organization. The provider organization can choose transparent-harddrive-encryption and purchase encrypting-USB-Memory devices. It is also unfortunate that they said 3DES here and didn’t use language such “or its successor”, as now one must implement both 3DES and AES even though no one should select 3DES if AES is available.
  
  
• SC06.07 — Configurable Log-on message
  
  • This supports warning the user (potentially malicious user) that their actions are confidential and are tracked. This type of a thing has been critical in getting convictions of hackers, or actually the lack of this kind of a message has been used by hackers to indicate that they didn’t know what they were doing was wrong.
  
  

New in Security in 2011 (This is where they guessed based on current HIT-Standards selections):

• SC03.11.1 — passwords either hashed with SHA2 or encrypted with AES
  
  • This is recognizing that the SHA1 hashing algorithm and 3DES encryption algorithms have been deprecated, their successor is SHA2 and AES
  
  
• SC03.14 – Kerberos
  
  • looks like CCHIT took HIT-Standards seriously… This requirement will likely not continue in HIT-Standards
  
  
• SC03.15 – IHE-EUA
  
  • Same thing as Kerberos
  
  
• SC06.01.1 – use of AES for network security
  
  • This is another instance of replacing 3DES with AES
  
  
• SC06.04.1 – use of SHA2 for network security
  
  • This is another instance of replacing SHA1 with SHA2
  
  
• SC06.06.1 — use of AES for data at rest
  
  • This is another instance of replacing 3DES with AES
  
  
• SC06.08 – Pseudonum capability
  
  • There is a nice long discussion but no standard referenced so it is impossible for me to figure out what would qualify as meeting this, or WHEN it would be needed.
  
  
• SC06.09 — Protection of the EHR executable
  
  • At least I think this means that they want a way that the EHR can do a self validation to confirm that the EHR executable are authentic. I am not clear what risk this is trying to fill.
  
  
• SC06.10 — use of ISO25237 for pseudonyms
  
  • WHAT? That ISO specification is not a technical specification, it is a high level discussion of the concepts of pseydonymization (which includes pseydonyms and anonymization). I have no idea how to apply this to an EHR, it can only be applied to an organization.
  
  
• SC06.11 – non-repudiation according to ASTM guidance
  
  • WHAT? This ASTM standard is again a guide to organizations on the overall concept of non-repudiation. I am sure this is taken out-of-context from the HIT-Standards privacy and security list, where all the HITSP specifications were exploded out to their component parts. Taken out of context this ASTM standard does no one any good. Further HIT-Standards put digital signatures into the 2013/2015 timeframe because of the onerous PKI requirements to support digital signatures with unclear benefits.
    
  
  

Web-base software scans EHR systems for security risks

I do not like that HITRUST is not an open organization, but anyone trying to make healthcare systems more secure is a good thing.

The Health Information Trust Alliance worked with nCircle to develop the HITRUST Security and Configuration Auditing Service, a Web-based application that screens electronic health record systems for security risks. "Most smaller [health care providers] haven't been doing anything at all to protect their systems, and we're reaching a point where that's just not acceptable," said the CEO of nCircle. Healthcare IT News

Hospitals Need to Reach Out to Business Associates

The deadline for updating the Business Associate Agreement is approaching. Likely a good thing to do all around.

Hospitals and other provider organizations should be working with their business associates now to prepare for compliance with updated federal data privacy and security provisions under the American Reinvestment and Recovery Act. That’s the advice of May Thomason, senior compliance consultant at Intermountain Healthcare, a Salt Lake City-based delivery system.
As a result of ARRA, business associates must comply with the HIPAA privacy and security rules that were modified under the law. Business associates also will be subject to the same penalties as covered entities, such as hospitals and physician groups, for privacy and security violations. More

A *NEW* HITSP eTown Hall Meeting on CONSUMER PREFERENCES

HITSP will be hosting an eTown Hall Meeting for all interested HITSP Members to review the Draft Consumer Preferences Requirements Document recently released by ONC. Due date for public comments is October 16, 2009.  The purpose of this eTown Hall is to present an overview of the draft Requirements Document and elicit discussion and comments.  The HITSP Consumer Preferences Tiger Team will then consolidate comments and submit them to ONC by the deadline.

When:

• Date:                    Tuesday, October 13, 2009
• Time:                    11:00 am - 1:00 pm ET

Registration:
Participation is complimentary but advanced registration is required. You will need to reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/980511585

IMPORTANT: After registering you will receive a confirmation email containing information about joining the Webinar, including the audio bridge dial-in information.  Please note that space is limited.


What you will learn:
During this 2-hour eTown Hall participants will:

• Learn about the ONC Consumer Preferences Requirements Document, the proposed definition, scenarios, process flows, information exchange, stakeholders,  
• Discuss and comment on any aspects of the document
• Learn more about the HITSP process for addressing Consumer Preferences requirements

Where to access the ONC Draft Consumer Preferences Requirements Document
Participants are asked to access and review the ONC requirements document prior to the meeting.  The document can be accessed from http://healthit.hhs.gov/consumerpreferences.  

Who should attend
Consumers, government representatives and policy makers, healthcare providers, standards developers, vendors, and any other interested stakeholder.

Presenters and Facilitators

• Maureen Allen, MD, Co-Chair of the HITSP Consumer Preferences Tiger Team
• Walter G. Suarez, MD, Co-Chair of the HITSP Consumer Preferences Tiger Team
• Johnathan Coleman, HITSP Consumer Preferences Tiger Team Facilitator
• Elliot Sloane, HITSP Consumer Preferences Tiger Team Facilitator

Sponsors

• HITSP Consumer Preferences Tiger Team
• HITSP Education, Communications and Outreach Committee

NHIN: The New Health Internet?

From what I can find out, this looks more like a ‘re-branding’ effort than an architectural revolution. If this is indeed what it is, then I like it. Well I don’t like the name they came up with, but then I am not marketing.  I do agree that the term “NHIN” has been possessed by a very secretive small number of big-IT-integrators, that lately have opened up. This re-branding is clearly indicating that the consumer interests will take center stage. This was already happening; see the consumer preferences use case, but renewed interest never hurt any project.

The second possibly good move would be to simplify. I have been very concerned that the current success of HITSP and NHIN have caused everyone with anything slightly healthcare related to come out of the woodwork and expect that their problem be solved. Adding too much to too soon will surely kill any forward progress. This is why i am very interested in the HIT Standards efforts to simplify what needs to be done right away. I think there is still way too much on the plate, but atleast the discussion of what is 'good enough' has started.

What I am worried about is the players that have been sitting on the outside these past 5 years coming in and totally changing everything. I am not comforted by John Halamka blog on the topic.

NHIN: The New Health Internet?

In somewhat of a re-branding exercise. Chopra and Park are proposing that the NHIN now be viewed not so much as solely a clinician to clinician care coordination exchange platform but rather one that also will focus on the consumer, creating a secure Health Internet to facilitate consumer access to and ultimately control of their personal health information (PHI). The basic NHIN, let’s now refer to it the Health Internet, is still composed of the same technology stack: platform independent, open source, freely available with published standards, etc. that support an independent software vendor’s (ISV) ability to build apps upon the Health Internet stack for consumer consumption (e.g., health & wellness services, PHRs, etc.). In June, we attended the NHIN CONNECT conference and our write-up provides a few more specifics on the Health Internet. More

Consumer Preferences Draft Requirements Document - Public Feedback Period Now Open

This is part of an itterative process between HHS/ONC and HITSP/NHIN. Anyone interested should definitely get involved in the HITSP Consumer Preferences tiger team.

Consumer Preferences Draft Requirements Document - Public Feedback Period Now Open

The Office of Interoperability and Standards and ONC are pleased to announce the release of the Consumer Preferences Draft Requirements Document for public input. The document will be available for public feedback for a period of 10 business days, ending October 16, 2009.  The Requirements Document and instructions for providing feedback can be found at http://healthit.hhs.gov/consumerpreferences.

The Consumer Preferences Draft Requirements Document addresses the processes, information exchanges, stakeholders, functional requirements, and issues and obstacles surrounding consumer preferences. This requirements document is intended to address the various types of consumer preferences and be supportive of current and potential future policies.  This requirements document will assist the Healthcare Information Technology Standards Panel (HITSP) in identifying, harmonizing, and/or facilitating the development of standards which address consumer preferences.

The OIS Consumer Preference Team would greatly appreciate your feedback on the requirements document. Please review the requirements document at your convenience and provide any feedback you may have by October 16, 2009.  Please note that submissions should not contain any proprietary or private information as they may be made available for public inspection.

All comments will be analyzed, dispositioned and utilized where appropriate in the development of the final Consumer Preferences Requirements Document. A disposition report outlining how comments were addressed will be made publicly available after the publication of the final document.

Thank you for your time, attention and input regarding this important matter.

Carol A. Bean, PhD, MLS, MPH
Acting Director
Office of Interoperability and Standards
Office of the National Coordinator for Health Information Technology