PASS Audit: Ballot Pool is now open

The HL7 Privacy Access and Security Services (PASS) project team is pleased to announce that the result of our efforts to define a Healthcare Audit service specification is now ready for membership review. The PASS project is a joint effort between the HL7 SOA, Security, and CBCC Workgroups and has had the benefit of active participation from members and Co-Chairs of each of those Workgroups.

 

The ballot pool for the latest specification entitled "HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) - Audit Services, Release 1" is now open until September 20, 2010. We'd like to encourage anyone interested to to sign up for the ballot pool and provide support for this work in the form of review and comments. The HL7 Ballot Desktop can be accessed at: http://www.hl7.org/ctl.cfm?action=ballots.home&ballot_cycle_id=521&ballot_voter_id=0

Healthcare Provider Directories

This is where all the buzz is right now. Although it would seem that this is a NHIN-Direct item; it is not. NHIN-Direct has been rather ignorant of these efforts. I have tried to get them to recognize the use of Provider Directories, especially related to distribution of the digital certificates that secure the communications. The Provider Directory should be a way to discover a Provider or Providing Organization; their address information including their NHIN Direct address; and the mechanisms to securely communicate including their NHIN Direct endpoint certificate. There is still hope, and movement lately on the topic.

The Provider Directory is far more than a way to assist with NHIN Direct. The first reason to have a provider directory is for all the normal reasons to have a directory. Discovery of a type of healthcare provider in a geographic area.

IHE Has profiled this  Healthcare Provider Directory (HPD) - Published 2010-08-10

This is the list of use-cases included in the IHE profile.

• Yellow Pages Lookup: A patient is referred to an endocrinology specialist for an urgent lab test. The referring physician needs to get the contact data of close-by endocrinologists in order to ask whether one of them can perform this test in their own lab. The patient prefers a female endocrinologist who can converse in Spanish regarding medical information.
• Identification in planning for events: Emergency response planning requires the identification of potential providers who can assist in an emergency. Providers must meet specific credentialing criteria and must be located within a reasonable distance of the emergency event.
• Provider Authorization and lookup during an emergency event: During Hurricane Katrina, health care volunteers were turned away from disaster sites because there was no means available to verify their credentials. At an emergency site, the Provider Information Directory
• Forwarding of Referral Documents to a Hospital : A PCP refers a patient to the Hospital for admission. The PCP needs to send various documentation to the Hospital to be part of their EHR when the patient arrives. The PCP needs to identify the Hospital‘s electronic address such as email or service end point where the patient‘s documentation should be sent.
• Keeping agency provider information current: A German government agency dealing with healthcare services for its constituents wishes to keep its agencies healthcare provider information current. The agency determines that it will use the Provider Information Directory to access the most current provider information. The German agency only requires a subset of the Provider Information Directory available information. On a regular basis, the Provider Information Directory provides to the agency a list of the updated information needed.
• Providing Personal Health records to a new Primary Care Physician: An individual has changed health plans. As a result that individual must change his Primary Care Physician. The individual has a Personal Health Record and would like to provide that information to his new Primary Care Physician. The individual needs to determine where to have the Personal Health Record transmitted to.
• Certificate Retrieval: National regulations in many European countries require that an electronically transmitted doctor‘s letter be encrypted in a way that only the identified receiver is able to decrypt. In order to encrypt the letter, the sender has to discover the encryption certificate of the receiver.
• Language Retrieval: An individual who only speaks Italian requires healthcare services at an Outpatient Clinic. That individual would like to be able to communicate with the Clinic personnel, if at all possible. The individual or his caregiver needs to determine which clinic supports Italian and provides the service that is required.

NIEM - making lemonade out of lemons

Yesterday I learned yet more about NIEM, attending the same session that Keith blogged about. He has some good references worth looking at to get some background. It is clear that NIEM is here to stay. Good, Bad, or Indifferent. So, lets figure out the best way to use this tool.

The NIEM process as visualized by ONC

Overall I think the NIEM process will be a good thing. It is a high level model for dealing with the issues we have been looking at for years. It includes steps that HITSP never got to (although I think this was more a funding problem than anything).
            *** So, will funding be provided to make the WHOLE process work? If it is going to be underfunded or cut apart; then it is not going to be very useful.

The NIEM process is actually very similar to the IHE process.

Except that IHE doesn’t require a 'reference model'. Rather they expect real products to show up at Connectathon, and until three independent products show interoperability at Connectathon then the specification can’t progress. The Reference Implementation model drives ‘academic’ proof, which is not always a good indicator of reality. I have seen how OASIS members abuse this. IHE is a partnership of those that have a problem and would like a solution, and those that could solve the problem if they were given assurances that the solution would be universal and desired. This is critical to why IHE continues to be successful. Yes sometimes what was thought to be desirable at one point is not later on.

            *** The ‘reference model’ is a fine thing, if it happens. But a reference model does not prove the spec will work in real-world situations.
            *** I would like to add the IHE product centric proof step into the NIEM process.

Re-use, don’t Re-invent; I think I heard this in the latest meetings on NIEM. But it needs to be emphasized as important. Most importantly it needs to be communicated that Re-Use is allowed and encouraged. I think NIEM can be very useful at the high level, it needs to be kept very thin. Similar to the overall approach in HITSP, only better (because we have learned).

           

           *** The biggest risk to success is that NIEM offers consultants unending work.
            *** The NIEM documentation tools are impressive and if they work as advertized the answer to world hunger.


Legacy. Healthcare is not a new, green field. Therefore part of the analysis must include this legacy. The analysis does not need to choose the legacy method, but it must consider the impact. This seems to be totally missing in the NIEM process. Further the focus of NIEM on producing XML and web services will be unproductive in some use-cases (it will be fine in others).

            *** How is the impact on existing investment included in the NIEM process

            *** When there is no single solution, how can NIEM indicate that there are 2 solutions acceptable?

            *** When the solution is not XML or web services, we need a light weight way to document this.


SOA. The process we saw is very heavy on SOA, and the use of SOA terms. This is not a bad thing. The concern is that some will take this as a directive that everything must be reformulated and relabeled using SOA modeling and SOA terms. IHE wrote a white paper that tried to show that there is synergy between the new SOA modeling and terminology; and the IHE modeling and terminology. Unfortunately this renaming exercise wasted lots of valuable time in HITSP and resulted in multiple layers of documentation with no value-add.  Religious wars are unproductive.
            *** We need a more light weight method of handling this.



International. This is not as big of a concern to providers, although they do benefit without knowing. But it is very critical to big vendors that don’t want to have to do things two ways. I suspect the attitude expressed by Doug Fridsma at the NHIN-Direct meeting, that of re-use where standards exist and fit the need, will take care of this issue. But it is still a force to consider. Often times it looks like inventing something special for USA is the right thing to do, it should be resisted. This is not limited to healthcare either, there are plenty of good international security standards to re-use rather than invent something special for USA. Overall I have not come up against a problem being internationally friendly.

            *** Be aware of and guided by experience in the international community


Coordination. ONC needs to Coordinate all of these National initiatives. Hopefully they allow the 10 contracts to coordinate directly rather than force all communications through ONC. I am hopeful that this will happen.

            *** Enable coordination, don’t become a bottle neck


I welcome NIEM, and want to help it succeed by focusing it and keeping it lean. NIEM should be leveraged to add value and clarity; not duplicate what others do and have done. Where a gap is found, NIEM can be leveraged to best describe the gap and determine the best SDO/PDO to fill the gap. Reuse, not Reinvent.

Privacy from the other perspective

Often times people are very quick to understand Privacy from the Patient's perspective. Often times these discussions include many overt violations of the Provider's Privacy. There is an article on "Doctor records taken offline". This article title doesn't hint at the actual article content. I am not going to side one way or the other on the actual problem. I will point out that Privacy has many perspectives, and focusing too closely on one perspective can cause unintended consequences.

Illinois once provided the public with detailed histories of the state's doctors — including whether the physician was convicted of a crime, fired by a hospital or forced to make a medical malpractice payment within the previous five years. Judging from online traffic, there was great hunger for that information: During the two years that they were posted, the physician profiles generated 130,000 clicks per week. But access to the profiles came to a screeching halt in February, when the state Department of Financial and Professional Regulation removed them from its Web site and placed them under lock and key — the latest chapter in a long political battle that has pitted patients' advocates against the state's medical lobby.   Read More

Top O' the Week

Keith has shown me the blogspot beta tool that can be used by a blogger to see the statistics on their blog. I find that it gives somewhat radically different results than Google Analytics. The likely reason is that Google Analytics requires my readers to have JavaScript enabled, where as blogspot uses simple page hits. Given that my blog audience is sensitive to security and privacy topics, it is not too surprising that Google Analytics shows about %25 fewer hits than the blogspot tool. But the top hits from each tool is also different. Given that I have not posted anything in over a week, it is nice to see that I have any traffic at all.


The Top O' the Week according to blogspot results

1. Meaningful Use Security Capabilities for Engineers...
2. IHE IT Infrastructure Technical Framework Suppleme...
3. Healthcare use of Identity Federation
4. Consumer Preferences and the Consumer
5. Data Classification - a key vector enabling rich ...

The Top O' the Week according to Google Analytics

1. IHE IT Infrastructure Technical Framework Suppleme...
2. Meaningful Use Security Capabilities for Engineers...
3. Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent 
4. Data Classification - a key vector enabling rich ...
5. Healthcare use of Identity Federation

While in DC this week I heard a few people saying that my piece on Data Classification and the Redaction and Clinical Documentation has been the topic of discussions. I am very glad for this, as I fully want to get people discussing these ideas

IHE IT Infrastructure Technical Framework Supplements available for Trial Implementation

The IHE IT Infrastructure (ITI) committee has published the Trial Implementation specifications. This is the version of the supplements that have been through a 30 day public comment, and now are ready for testing at the coming Connectathon. The following supplements are now in Trial Implementation

• Cross-Enterprise User Assertion - Attribute Extension (XUA++) 
• These updates add three named options: Role-Based-Access Control, Consent/Authorization, Purpose of Use, and adds Other Descriptive Attributes
• Healthcare Provider Directory (HPD) 
• Creates a way to discover and get attributes about both Individual Providers and Organizational Providers
• On-Demand Documents - 
• This extends XCA/XDS with support for publication of 'on-demand' documents
• Sharing Value Sets (SVS) -
• This was enhanced with a new transaction "Retrieve Multiple Value Sets"
• XDS Metadata Update - Published 2010-08-10
• New administrative interface to allow for direct manipulation of metadata entries

Also updated, but still in Trial Implementation (all changes are fixes from experience/connectathon. Previously documented in Change Proposals)

• Asynchronous Web Services Exchange
• Cross-Community Access (XCA)
• Cross-Community Patient Discovery (XCPD)
• Document-based Referral Request (DRR)
• Document Metadata Subscription (DSUB)
• Multi-Patient Queries
• Notification of Document Availability (NAV)
• Patient Identifier Cross-Reference (PIX) and Patient Demographic Query (PDQ) HL7 v3
• Pediatric Demographics Option for PIX and PDQ
• Retrieve Form for Data Capture (RFD)

Of course the Technical Framework, where Final Text profiles are published, has been revised too

Current Technical Framework - Revision 7.0
August 10, 2010
Copyright © 2010: IHE International, Inc.
Final Text Version

• Vol. 1 (ITI TF-1): Integration Profiles
• Vol. 2: Transactions - Volume 2 is divided into three separate sub-volumes:
• 
  
  • Vol. 2a (ITI TF-2a): Transactions ITI-I through ITI-28. These transactions are used in the following profiles CT, PSA, EUA, PIX, RID, XDS, ATNA, PDQ, PWP, NAV
  • Vol. 2b: (ITI TF-2b): Transactions (cont'd) ITI-29 through ITI-50. These transactions are used in the following profiles PAM, XDM, XUA, XDS
  • Vol. 2x (ITI TF-2x): Appendices A through W and Glossary
• Vol. 3 (ITI TF-3): Contains Section 4 Cross-Transaction Specifications and Section 5 IHE Content Specifications
  

These volumes provide specification of the following profiles:

• Audit Trail and Node Authentication (ATNA)
• Basic Patient Privacy Consents (BPPC)
• Consistent Time (CT)
• Cross-Enterprise Document Media Interchange (XDM)
• Cross-Enterprise Document Reliable Interchange
• Cross-Enterprise Document Sharing (XDS.b)
• Cross-Enterprise Sharing of Scanned Documents (XDS-SD)
• Cross-Enterprise User Assertion (XUA)
• Enterprise User Authentication (EUA)
• Patient Administration Management (PAM)
• Patient Demographics Query (PDQ)
• Patient Identifier Cross-Referencing (PIX)
• Patient Synchronized Applications (PSA)
• Personnel White Pages (PWP)
• Retrieve Information for Display (RID)

Redaction and Clinical Documentation

I seemed to touch a nerve yesterday in my blog about  Data Classification - a key vector enabling rich Security and Privacy controls. A minor part of this blog was a few paragraphs where I laid out a way to produce related documents that would have different Data Classifications. The main goal was to show that documents could be transforms that have lesser content thus resulting in a lesser sensitivity. IT seems that I hit a nerve (Data Classification, Redaction and Clinical Documentation)  in Keith Boone, who I always defer all CDA discussions to. But, like Keith yesterday, who said he defers discussions of Security and Privacy to me, then goes on to make statements about Security and Privacy; I will do similar.

My post yesterday was about the original author making privacy informed decisions to post a second document that is a logical transform of their original document. This surely could be assisted by technology, but I was not trying to say that this would be automatic. I am, just like Keith, concerned with CDA documents that are built by an automated process without a clinical human involved.

I am not going to claim that there is no use for a CDA document or an automated transform of a CDA document. Seems to my non-clinician mind that knowing something is better than knowing nothing; especially if you are well informed that what you are given is less than total knowledge. The Author of a document is a very important part of the metadata on or in a document. Surely an automatically generated document needs to be authored by the computer that generated the document.

I have seen a presentation Dave Riley did at OSCON on the CONNECT project where I heard of a Redaction Service. I looked into this Redaction Service, and it turns out to be exactly that service that Keith and I are worried about. It claims to be able to automatically apply privacy rules to strip out sensitive content. I applaud the CONNECT project for trying, but I am very worried that the risks of this approach are not being made fully clear. These risks are no just Privacy risks, but clinical risks, safety risks, integrity risks, and other. I certainly hope that the resulting CDA document is authored by the CONNECT Redaction Service and does NOT indicate that it is authored by the original author. It is clearly a NEW document.

Data Classification - a key vector enabling rich Security and Privacy controls

In this article I will introduce the concept of Data Classification, what it means to Healthcare IT, and how it can enable rich Security and Privacy controls. There are many aspects to rich Security and Privacy controls, so Data Classification is not THE answer, just like Consent is not THE answer. These many aspects of Security and Privacy controls work together.

The concept of Data Classification is not new, it has been around for likely thousands of years. The idea is that some data is rather PUBLIC and can be exposed to anyone, while other data is very SECRET the kind of data one would only share with a very small number of people. I am not going to say that this concept has been around since the XXX ages, because I don't know and don't think it is important to look it up. I am sure you can look down in the comments and someone will have done the research and they should get credit. I suspect this could be seen back thousands of years.

There is much talk in the US healthcare initiatives about "Segmentation". Segmentation is typically what ones does to physically separate different Data Classifications. I think it is being spoken about in the US healthcare initiatives more as a direct synonym to what the classic Security community sees as Data Classifications. Even if Segmentation is the classic idea of physically separating data of different Data Classifications then we need to understand Data Classifications. I will assume that the word "Segmentation" is being used so as to not to be confused with Military Classification Levels. They have the same goal, but there are individuals that can't grok.

One of the models that has received the most visibility (ahem) is the Military "Classification Levels". We have all seen movies where there is a piece of paper or folder with the word "Top Secret" stamped across it. This is a 'Classification' of the content of the paper/folder into one of the various Classifications. Typically there are 5 classifications that we are use to seeing: Unclassified, Restricted, Confidential, Secret, and Top Secret.  We all know from the movies that Unclassified documents are available to everyone, yet Top Secret documents can be seen only by a very few.

This label on the document is 'metadata' that is carried by the document. This metadata is an outcome of the classification step, and is an independent step from provisioning of a user into Roles and roles into Permissions. Thus there is independent processes for classifying data, and for assigning permissions that a specific user has.This use of metadata also decouples the data from the transportation mechanism, as no matter what way that document is transported the metadata that explains the classification is attached.

Confidentiality Code

Healthcare Standards have our own version of this, the confidentialityCode. Looking at this today, we would likely pick a different name, but this is the one we got. Almost without exception healthcare standards have a confidentialityCode associated with all objects. This is true of HL7 CDA (CCD), HL7 v3 messages, and HL7 v2 messages. This is true of DICOM objects. This is true of IHE XD* metadata about documents. This is a universal place to hold the sensitivity classification of the object. This is a way that a sender can inform a receiver of how to handle the data in their access controls. This is a way that a publisher of documents can indicate the sensitivity classification of a document.

Unfortunately the vocabulary for the confidentialityCode needs some work. I say unfortunately, but in reality this reflects that we have not been able to look at this value very consistently. So today the vocabulary for confidentiality code is part Sensitivity Classification, and part Confidentiality Classification. These are not necessarily incompatible ideas, but they are trying to encode in the same value something different. Where as Sensitivity Classification would say this is "Secret", the confidentiality code would explain why it is secret (i.e. HIV).

My experience is that most implementations understand this, and choose a small subset of the existing confidentialityCodes and use them as Sensitivity Classifications, similar to the Military Classification.Note that like with the Military Classifications, these are clearly increasing in sensitivity and don't expose 'why' the classification is given. There are other codes, but they are inconsistent with Segmentation. I recommend against using the other HL7 confidentialityCodes (e.g. HIV, PSY, SDV).

Useful Value-Set from the HL7 ConfidentialityCode vocabulary (2.16.840.1.113883.5.25)
L -- Low -- Low sensitivity,
N -- Normal -- Normal clinical data to be handled by normal 'good health care practice' rules
R -- Restricted -- Restricted clinical data, restricted to those having a care relationship
T -- Taboo -- Information not to be discussed with the patient

The process for establishing an objects confidentialityCode must be inclusive of the healthcare organizations evaluation of how sensitive the information is AND how the patient would evaluation how sensitive the information is (See Magic section below).

Redaction

Add we even have seen where documents with high classification levels are "Redacted", and the Redacted version of the document is considered of a lower classification level. For example when someone makes a request for release of a highly classified document, large segments of the document may be blocked out. These large blocks of text might be specific names of individuals that were involved but who were not considered important to the message of the text.

When the identifiers are being Redacted, we in healthcare should see this as De-Identification. That is the idea that one can remove the identifiers from health information and thus the information becomes less 'sensitive'. I very much believe in the ability to use De-Identification to provide new-life to the data, but also know many ways in which it can go wrong. See De-Identification is highly contextual.

Clinical trials is a domain where there is funding and motivation to establish meaningful redaction and transform profiles that can provide automatic processing. It has been common for years to use manual Redaction (Paper and Film) on the data shared with a clinical trial. This is not just for Privacy reasons, but also for the clinical trial integrity (blinding of factors other than the one being studied). This experience with Redaction has resulted in updates to standards such as DICOM supplement 143. An important distinction that clinical trials has is that it is very clear what the purpose of the specific clinical trial, what data is needed, and what data is not needed; this is not true in general healthcare.

Removal of the sensitive information is a very useful tool. Done wrong, it can be a very bad tool. There are plenty of examples of where someone has 'thought' they had done proper redaction, but it turned out to be simply a display layer where the actual sensitive information was still present. 

Transforms

Redaction can be used in a different way that is highly useful. One might remove the most sensitive information from a document leaving just the critical health values. This form of Redaction is often seen as a "Transform" of the data. When the data is in XML form, this form of Redaction is quite easy. One must be very careful to only allow information into the transform that is well-known to be safe. This means that any free-text fields need to be blocked.

One of the most talked about health documents today is a C32. A C32 is a Medical Summary, the content may include administrative (e.g., registration, demographics, insurance, etc.) and clinical (problem list, medication list, allergies, test results, etc) information. Generally this is a minimum of clinical information that is needed by almost every care giver. Although this document is not about a specific episode of care, it could contain information that is highly sensitive. It is possible to provide two documents, one with the highly sensitive information and a transform that has removed this highly sensitive information. The system doing the publication of the document knows best what information is specifically sensitive, so it is uniquely qualified to publish these two different documents. These documents could then be Segmented or Classified differently.

In the context of XDS, the original document could be registered with a "R". The Transform could be registered using the XDS relationship of Transform with a "N" classification. In this way someone can see that the two documents are related and access the one that the user is authorized to view. This publication of two independent but linked documents may be preferred by those that want to Segmentation as there is a clear line between the two documents. This eliminates the need to perform a transform at retrieve time, and reduces the risk of accidental inappropriate disclosure. For example the audit log clearly indicates which of the two documents were used vs relying on a real-time transform.


Enabling Policy

Just like how the Military Classifications allow them to separate the act of classifying data from authorizing individuals, so does the confidentialityCode. So, lets look at a simple Truth-Table. Note that I added "Research Information" . This just to show that the limited set of confidentiatlityCodes can be extended. So imagine information marked with Research Information is specifically published for research use. This Truth-Table also shows the results of a set of Policies.

.                                   ConfidentialityCode Functional Role	L	N	R	T	Research Information
Administrative Staff	X	X
Dietary Staff		X
General Care Provider		X	X
Direct Care Provider		X	X	X
Emergency Care Provider		X	X
Researcher					X
Patient or Legal Representative	X	X	X

It is very possible for a Patient Consent to directly influence these. For example the patient may be given the ability to provide their Preferences for this Truth-Table, and if accepted that would become the Policy for their data. Thus the Consent Policy becomes the Truth-Table for that patient's data.

There could be a different Truth-Table for "Emergency Mode" of operation, such as under natural disaster like Katrina.

Magic:

The unsaid magic in all of this is that there is no well-known mechanism today to automate the Data Classification. We have the place to store and communicate the Data Classification in the confidentialityCodes, but we don't have rules to use to determine if the object should be described as R rather than N. We have Consent Directives that can explain how to handle these differently categorized data, capturing the truth-table. But we do not have a good way to determine for any given object, what should the confidentialityCode be. We leave this as a task for anyone publishing data. The one creating a document or object is the one most aware of the information that is in the document or object. Today this is the individual or system that is expected to make the hard decision. In XD*, the confidentialityCode is mandatory. Most simply say "N".

We do have some regulatory assistance. In the USA 42 CFR Part 2 "Confidentiality of Alcohol and Drug Abuse Patient Records" makes it clear the types of things that we should certainly mark as "R". But even with this very specific regulation text, it is hard to be exact. Often times when one thinks they have a well-known set of rules, a doctor will come along and indicate that the combination of three factors would indicate that a patient is HIV positive. The combination become really hard to track down.

This Magic is likely to continue for sometime. Is this a bad thing? It is bad in that it is a part of the process that is not deterministic, so yes we want it fixed. Many organizations have tried to come up with a way to do this. Ultimately we would like to encapsulate the rules that patient wants used to determine the Data Classification in a Patient Preference or Consent. This is ongoing standards work.

Usually the magic is the publishing doctor selecting a radio-button: R vs N. They are usually right.

Conclusion:

For now, I just want to get confidentialityCode used. Having information differentiated by the Data Classification enables Role-Based-Access-Control. Without it, all data is seen as viewable by everyone.

Resources:

• Internet2 Data Classification Toolkit
• University Mass Data Classification
• Wikipedia Data Classification
• DICOM Supplement 142 Clinical Trial De-identification Profiles
• IHE Access Control White Paper - Published 2009-09-28
• HL7 Confidentiality Code Vocabulary

My Blog

• Availability of Consent Documents and their rules 
• De-Identification is highly contextual

President's Council of Advisors on Science and Technology - another dissapointment

On July 16th the President's Council of Advisors on Science and Technology (PCAST) held a webcast where the afternoon agenda was a report out "Health Information Technology Study". This report was put together over 8 months by Christine Cassel, M.D., president and CEO of the American Board of Internal Medicine; William Press, University of Texas Professor of Computer Sciences; and Craig Mundie, Microsoft's Chief Research and Strategy Officer.

I saw ONE writup on the session: Calls for Privacy, Quality in PCAST Report  by Healthcare Informatics. There was not that much information given in the article, but it did get me interested in what Privacy aspects might have been brought up. 

University of Texas’ Press spoke about privacy considerations with electronic health records and mentioned the saliency of a 2006 Marco Foundation survey in which 80 percent of those respondents said they very concerned about theft or fraud of electronic health records. “From the very beginning of our discussions and of the working group's discuss we realized that privacy and security couldn't be add-ons to any system of healthcare exchange,” he said. “They had to be engineered in from the very start.”

So I went and listened to the Webcast. Fortunately it took only 50 minutes for the presentation, questions, and approval of the document. A document that is still not yet available today. My impression from the webcast is that they were given good and wonderful news about what could be. They held up VA and Kaiser as examples of comprehensive EHR systems. Yet they also referred to the original Markle Foundation report, and other studies from 5+ years ago. I further had my hopes dashed by comment after comment that showed that they had not learned anything new, but were simply making the same old mistakes over again. This has nothing bad to say about VA, Kaiser or Markle; These are all good things. What was disappointing is that the workgroup had not dug deep enough to have learned about the problems that we are all working had to solve today.

The positive that could come out of this is more visibility into and by ONC. However frustrated I am at what ONC does, they are at least in the trenches with the rest of us working toward a solution. I will always back those that are working toward a solution, even if they might be frustrating me by not simply doing it 'my way'.



report

Meaningful Use Security Capabilities for Engineers

The Final Meaningful Use standards and certification are out. They are not the best written my comments and rants that Meaningful Use Security Capabilities are Lacking, Privacy Capabilities NON-existent. Today I want to point out what the Meaningful Use Security and Privacy requirements are in language that EHR engineers can understand. What you are going to see is not exactly the minimal necessary for MU, but rather my recommendation relative to the specific items. This is similar to my  Comments on the IFR Security/Privacy.

Meaningful Use does require that the deployment use Risk Analysis as the method to select the technologies that are actually used. What this means is that the operational environment will likely need capabilities well beyond anything mentioned in the standards and certification criteria. The good news is that the certification is going to focus less on these criteria. These criteria are, as I mentioned before, the typical ones found in the CCHIT and NIST SP 800-53 “Recommended Security Controls for Federal Information Systems and Organizations” (http://csrc.nist.gov/publications/PubsSPs.html).

The things that you are going to be tested against are the Meaningful Use Standards

Specific Requirements

• §170.210 (a) - Encryption and decryption of electronic health information
• FIPS 140-2 Annex A allows for 3DES or AES.
• Many encryption solutions are provided by the platform (transparent hard-drive encryption, encrypting USB-Memory, S/MIME or PGP email) or network (VPN, IPSec). These solutions are very effective and do NOT require that the EHR technology be aware of the technology. By placing an encryption requirement on the EHR technology, they are proposing that the EHR solution provider involve themselves in a way that removes flexibility currently available to an operational environment.
• It appears that Data-At-Rest is expected to be in scope. Leverage built in Database encryption or Transparent Hard drive  encryption. 
• Hopefully the EHR can specify a 'class of off-the-shelf hard drive encryption products' rather than having to specify a single one.
  
• Have the capability to cover all network communications that include PHI with Mutually-Authenticated-TLS as is the specification in IHE ATNA
  
  
• §170.210 (b) Record actions related to electronic health information
  
• Future certification should and likely will require the ATNA message/transport to those that are representative of the transactions that cross the organizational boarder (meaning they are subject to Meaningful Use).
• Today one must simply record the security audit events. The date, time, patient
  identification, and user identification must be recorded when electronic health
  information is created, modified, accessed, or deleted; and an indication of which
  action(s) occurred and by whom must also be recorded.

• §170.210 (c) Verification that electronic health information has not been altered in transit
• See §170.210 (a) - Encryption and decryption of electronic health information

• §170.210 (d) Record treatment, payment, and health care operations disclosures
• Have the capability to record a 'disclosure' event. Meaning add a user interface specifically for doing nothing but capturing the event
• The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.

and

• §170.302 (o) Access control. Assign a unique name and/or number for identifying and tracking user identity and establish controls that permit only authorized users to access electronic health information.
• Have the capability to differentiate a reasonable set of roles for your application workflows. Some applications will logically have many (doctor, nurse, dietition), while some specialized EHR or Modules will have few.
• Have the capability to differentiate the level of access these roles have. Again this is going to be highly dependent on the product type.
• §170.302 (p) Emergency access. Permit authorized users (who are authorized for emergency
  situations) to access electronic health information during an emergency. 
• Note that 'emergency situations' is NOT the people scheduled to work in the Emergency Room.  This is normal Access Controls, as this is the normal workflow for these people
• An Emergency is a truely exceptional condition as defined in HIPAA. Your product may not actually have any of these. 
• Some EHR may have a permission that can be assigned to individuals or roles that allows for 'Break-Glass'.
• §170.302(q) Automatic log-off. Terminate an electronic session after a predetermined time of
  inactivity. 
• I really hope they don't test to this criteria as written, as it is really counter to workflows that require continunity where a screen-blank functionality would be preferable to anyone.
• The point is the same point in HIPAA.. When the system detects that there is no user activity, then it is likely there is no human present and thus to prevent the currently displayed data from being exposed to the user something must be done. 
• Do the right thing for your workflows.
• §170.302 (r)  Audit log. 
• (1)—Record actions. Record actions related to electronic health
  information in accordance with the standard specified in §170.210(b). 
• See above §170.210 (a) - Encryption and decryption of electronic health information
• (2) Generate audit log. Enable a user to generate an audit log for a specific time period and to sort entries in the audit log according to any of the elements specified in the standard at §170.210(b).
• I read 'generate audit log' as 'create a report from the audit log'.
• I am not sure all the elements are really that important to sort on.
• Have the capability to produce reports based on the audit log
• §170.302 (s)  Integrity.  
• (1) Create a message digest in accordance with the standard specified in §170.210(c).  
• See above §170.210 (a) - Encryption and decryption of electronic health information
• (2) Verify in accordance with the standard specified in §170.210(c) upon receipt of
  electronically exchanged health information that such information has not been
  altered. 
• See above §170.210 (a) - Encryption and decryption of electronic health information 
  
• (3) Detection. Detect the alteration of audit logs. 
• Audit Logs need to be protected against inappropriate modification or purging. Thus the Audit Logs need to be protected using the same level of access controls as any PHI
• §170.302 (t)  Authentication. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information. 
• There is no guidance here, so have some User Authentication mechanism.
• I might stretch this item to indicate that this is why you must do Mutually-Authenticated TLS on the network as well.
• §170.302 (u) General encryption. Encrypt and decrypt electronic health information in accordance with the standard specified in §170.210(a)(1), unless the Secretary determines that the use of such algorithm would pose a significant security risk for Certified EHR Technology. 
• I have nothing positive to say about this.. see my rant on the Ugly
• §170.302  (v) Encryption when exchanging electronic health information. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in §170.210(a)(2). 
• See above §170.210 (a) - Encryption and decryption of electronic health information  
  
• §170.302 (w) Optional. Accounting of disclosures. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in §170.210(d).
• See above §170.210 (d) Record treatment, payment, and health care operations disclosures

 
Missing Requirements

If the certification requirements are to be complete set of functional requirements, then there are many requirements missing. In the early years of CCHIT I was co-chair of the Security Workgroup and lead CCHIT effort to define a set of comprehensive yet reasonable requirements for a secure Health IT system. These requirements have been very carefully crafted to not interfere with healthcare workflows, implementations, or the creativity of the EHR vendor.

In some cases these are requirements for specific documentation from the vendor. This is a good way to support the communications between the vendor and the operational environment. These documentation requirements ultimately force the vendor to think beyond clinical functionality and make declarations on security topics including such non-functional aspects as hardening the system to network attack.

Without these additional requirements I am concerned that the IFR will leave the false impression that a system certified to the criteria is secure. If these additional requirements are not also included then I would recommend that the security requirements be totally removed. The Operational environment is already required to meet the HIPAA Security requirements that are based on Risk Assessment and Mitigation. This is a far more comprehensive and reasonable approach.

Privacy Consent

Totally absent is Privacy, not even opt-in or opt-out Consent. I think that BPPC can and should be used to enable OPT-IN in an XDS like RHIO (HIE/HIO). This is not to say that BPPC is the long term solution, but without an OPT-IN ability we will get nowhere on deploying the Health Internet. BPPC is 'good enough', and is a logical path toward something more advanced. HL7 is already working on that more advanced solution, and it is a logical extension to where BPPC is today.



Although not required, I recommend that for HIE operations an EHR be capable of supporting Stepping stones for Privacy Consent

ITI Call for Proposals Opens and Invitation to the ITI Planning Meeting October 18-19, 2010

It is with great pleasure that we announce the IHE annual planning cycle kick off beginning in August 2010, and continuing through October 2010. This e-mail describes the ITI planning cycle process.

IHE ITI Call for Proposals: Interested parties are invited to submit proposals for new Profiles and/or White Papers for the IT Infrastructure (ITI) Domain to be considered for development in the 2011-2012 cycle.  Additionally, all IHE members are invited to forward this announcement to their committee mailing lists and other interested persons.

The deadline for submission of a proposal for new Profiles is September 17, 2010, at 11:59 pm CST.  

Proposals must follow the structure and format of the Brief Proposal Template attached, specifically addressing the following:

1. What is the problem you propose to solve by this proposal, and how is that problem expressed in practice? (eg. a use case)
2. How would fixing this problem improve health care in practice?
3. What specific components of standards could be used to solve this problem?
4. Include some indication of the business case surrounding the situation if possible. For example, is there an economic motivation for addressing this problem immediately?
5.  Identify one or more potential editor(s) in the event that the proposal is selected for further evaluation and possible development. 

Please use the attached Brief Profile Template to submit your proposal.  Alternatively, and for those who are comfortable documenting on the Wiki, you may also submit your proposal using this Wiki page template found here or visit: http://wiki.ihe.net/index.php?title=Brief_Proposal_Template. Don’t forget to follow the template instructions, and to save your proposal on the Wiki using a unique NAME.

Email Completed Proposal documents (or the link to your completed proposal on the Wiki) to both ITI Planning Co-Chairs and HIMSS secretariat: 

·         Michael Nusbaum: Michael@mhnusbaum.com

·         Charles Parisot: Charles.Parisot@med.ge.com

·         HIMSS Secretariat: ihe@himss.org

Invitation to attend IHE ITI Planning Committee meeting:  Monday & Tuesday October 18-19, 2010 

The meeting RSVP survey link, hotel accommodations, and agenda will be sent out the week of August 9, 2010. Please save these dates on your calendar by opening the ICS calendar invite that is attached to this email.

Dates: October 18 – 19, 2010

Location: Radiological Society of North America

820 Jorie Boulevard , Oak Brook, IL  60523 Phone: (630) 571-2670

The ITI Planning Committee will hold its 2011-2012 planning meeting on October 18-19, 2010 at RSNA in Oakbrook IL. A preliminary agenda of our activities will be sent out after the September 17^th deadline, however, history has indicated that our time during the days is flexible and depends on the nature and number of profile proposals. The ITI Planning Committee will vote on the final selection of short-listed proposals at this meeting to move forward for submission to the ITI Technical Committee.

We urge those who propose profiles or white papers to attend the Planning Committee meeting either in person or by phone. In-person advocacy has proven to be especially effective in getting proposals understood and accepted.  We have a relatively short window for turn-around of the detailed proposals for the items selected for this year's cycle so acceptance of proposals depends heavily on the Planning Committee's consensus about the market needs, relative priorities, and level-of-difficulty of all profile proposals at this face-to-face meeting.

IHE membership is required to attend or participate in the ITI Planning face-to-face meeting, and to submit votes on October 18-19, 2010.  If you are unsure your organization is an IHE member, please check the membership list. If you would like to apply for membership, please visit this webpage. 

In order to participate in meetings, you must first be a delegate of an approved IHE member organization.  Membership is granted only to “organizations” and each member organization names delegates to participate in various domain committees.  Please check the membership list to ensure your organization is a bona fide member of IHE. If not, then you can apply for membership (it’s free) using this webpage.

ITI October face-to-face Planning Meeting participation: Any member is entitled to send a delegate to attend a meeting. However in order to vote, the member (organization) must have earned (and maintained) voting privileges prior to the designated meeting.  The rules around voting privileges are articulated on the IHE website.  

ITI Planning Webinars (Prior to the face-to-face): ITI will schedule four Planning Webinars prior to the October meeting to allow authors to present their proposals to the ITI Planning Committee in advance of the face-to-face. This procedure also allows all Planning Committee members to re-establish their voting rights. We have established specific procedures for the Planning Webinars, so please make sure you understand and follow the instructions below to ensure you will have the right to vote at the meeting. 

1.       ITI Planning Webinars have been tentatively set for the dates listed below. The exact dates and times will be sent out as soon as possible. We will populate the schedule of presentations immediately following the September 17^th submission deadline.

§  The ITI Planning Webinars will run during the following weeks:

§          September 27 – October 1, 2010

§          October 4 – October 8, 2010

§          Webinars will be two hours long with 6- 15 minute profile presentations

2.       These webinars will be considered decision meetings.  We will attempt to reach consensus (rather than hold a formal vote) at each webinar as to the validity of each individual proposal, including whether it makes sense to request proposal authors to combine initiatives where overlaps exist.  No proposals will be rejected at this stage, only aligned with one another, and only where appropriate.

3.       In order to ensure voting privileges at the October face-to-face Planning meeting in Oakbrook, we will require each member (organization) to attend a minimum of 2 (out of the 4) webinars that precede the meeting.  We will be taking very careful attendance at each webinar to ensure a fair execution of this process.  Please ensure you clearly understand this requirement.

4.       Committee rosters can be viewed on the FTP site at: ITI Rosters

ITI Planning Webinar Procedures:  Each webinar will be organized as follows (this will vary slightly depending upon how many proposals we will be reviewing):

1.       The two hour time allocation will be divided into 6x15-minute time-slots, with the remaining 30 minutes for introductory remarks and follow-up discussion.

2.       Each 15-minute timeslot will be allocated to a profile proposal. The first 10 minutes will be taken up by a presentation by the proposal author, with the remaining 5 minutes reserved for discussion and any disposition (if required).  In order to maintain equity across all presenters, we will manage this time rigorously!

3.       Each 10-minute presentation will be comprised of a maximum of five (5) PowerPoint slides, presenting your proposal concisely and completely.  We have taken the liberty of supplying a presentation template that you may choose to use, and this can be found in the following folder on the IHE ftp site.

4.       A sample webinar agenda is shown below (however, please note that we will assign presenters/topics to each timeslot after the September 17^th deadline):

Sample - IHE IT Infrastructure Planning Committee Webinar #1 (of 4) October 4, 2010 • 10am-noon Central Time
Item	Description	Time (min)
1	Introduction	10
2	Presentation #1 (topic, presenter) Discussion	10 5
7	Presentation #6 (topic, presenter) Discussion	10 5
8	Wrap-up discussion, disposition	20

5.       The final webinar will be reserved for presentation/discussion on any proposals that have been combined or otherwise re-worked as a result of discussion during the first three sessions.  We will ensure that the agenda for this session is published with as much advance notice as possible.

6.       Each of the four webinars will be recorded with links published, so members can view (or review) the profile proposals prior to the October 18-19, 2010 face-to-face meeting.  We will also publish an agenda, together with procedures, for our face-to-face meeting.

IHE ITI Planning Webinar Dates:

• Webinar #1 & 2:  September 27 – October 1, 2010 – Dates and times TBD.
• Webinar #3 & 4:  October 4 – October 8, 2010 – Dates and time TBD.

The agenda’s for these Webinars will be sent out after the September 17^th, 2010 deadline.

If you have any additional questions please contact the ITI Planning Co-Chairs.

Thank you for your participation and support of IHE.

Sincerely,

Michael Nusbaum and Charles Parisot

IHE ITI Planning Co-Chairs 

Webinar on the NEW work from IHE IT Infrastructure - Including updates to XUA

This Webinar will introduce the audience to the updates done this year. Including the updates to the Cross-Enterprise User Assertion (XUA) Profile. These updates add three named options:

• Role-Based-Access Control – option supporting specification of user roles to authorize the transaction -- Supporting role based access decisions on the service side
• Consent/Authorization – a specific way to carry an indicator of relevant consent or authorization policies that would authorize the transaction-- Supporting push of consent policies and provider-patient relationship
• Purpose of Use – option supporting the specification of the Purpose of Use that describes the reason for the transaction -- Supporting better Accounting of Disclosures
• Other Descriptive Attribute to support consistent way to carry some additional descriptive values

Here is the general information for the Webinar:

IHE Domain- Review of IT Infrastructure Profiles & Technical Frameworks

Thursday, August 5, 2010 at 10:30 am — 12:00 pm CST

New & Past Participant Webinar: IT Infrastructure is one of the eleven clinical & operations domains in IHE. Learn more about the most current profiles and technical frameworks which the ITI technical committee is working for implementation at the IHE 2011 N.A. Connectathon. Note: Past profiles and technical frameworks will not be discussed in length on this webinar. Please refer to the 2008 & 2009 webinars or secretary@ihe.net.

Speakers:
Karen Witting, Charles Parisot, Rob Horn, Michael Nusbaum — IT Infrastructure Domain Co-Chairs

Register Online >>

Stepping stones for Privacy Consent

Over the last few weeks HHS/ONC have produced lots of reading material. I have not had any trouble falling asleep lately, but it sure is getting hard to get through all of this reading material. The executive summary is that there appears to be a reasonable and comprehensive approach to Security, but Privacy is left behind.

That is to say that HHS/ONC have caught on to the need to use Security Risk Assessment as the prime 'framework' for Security. With the blog post EHR Security: A Top Priority by: Dr. Deborah Lafky of HHS it s clear that low-hanging fruit needs to be identified and picked. This is the lesson that I had hoped they would learn. I have seen many organizations learn this lesson, and indeed have seen many organizations have to learn this lesson multiple times. And so it is with HHS, who learned this lesson back at the original HIPAA Security rule and again now with the current set of specifications including the update to HIPAA.

They also recognized that the Standards and EHR products need to have reasonable security 'capabilities', but that using these capabilities is a policy choice that the provider should be free to choose to do, based on their Risk Assessment. I have further drill down on the Meaningful Use Standards: Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent

The bad news is that they seem to have backed off on Privacy Controls, again. I do understand why they do this, but I don't agree with their approach. What it seems to me is that they feel that if they can't do Privacy right, then it shouldn't be done at all. I think this is an approach that will lead to continued non-action. Unlike Security, that has the Risk Assessment approach to come to the rescue, Privacy is harder. But trying to slice Privacy up into digestible portions is a delicate thing.

What should be done?

HHS/ONC should have focused Privacy within the HIE. I understand how difficult Privacy is to deal with inside the existing healthcare provider organization. There is already policy and procedures and sometimes technology in place to deal with the HIPAA Privacy requirements. This environment is going to be hard to change, eventually it must. But it is the green-fields of HIE that need to be designed from the beginning with Privacy.

From what I read, an Accounting of Disclosures is clearly needed for every communication of PHI in a HIE; so why not require that an EHR interacting with an HIE must record this? There are standards for this, ATNA can inform an Accounting of Disclosures. There is ongoing work to make this better and better (See the new IHE XUA++ supplement soon to be published for Trial Implementation), but the basics are in place. Accountability using ATNA Audit Controls is critical to success.


From what I read in the HHS white paper on Consumer Consent Options, there are some basics of consent policies. Indeed going with the stepping-stones idea, why not require the standards and EHR to support blanket opt-in or blanket opt-out regarding participation in an HIE. This policy would not need to be related to any existing Provider Organizational policy, it would be restricted to the interactions with HIE.

When I say blanket opt-in or blanket opt-out, I really mean without exceptions. I really mean without break-glass. I am too afraid to declare about Government access, such as quality reporting. Seems to me these can already be handled by access to the Provider Organization.  I have been saying this for almost a full year on this blog Opt-In, Opt-Out.... Don't publish THAT! The HIE would still need to choose if they want a default opt-in or a default opt-out; meaning an implicit consent vs explicit consent environment. Then there is the question of if opt-out means that documents are not submitted to the HIE, a very difficult topic.

This choice of exactly 2 policies, opt-in vs opt-out, is not that friendly to those patients that want more control, but lets at least deal with those that are willing to choose YES vs NO. Today we have nothing but chaos, and chaos favors statuesque. An interesting study on the economies of privacy showed:

"When you have privacy, you value it more,” said Mr. Acquisti. “But when the starting point is that we feel we don’t have privacy, we value privacy far less.” More

It is somewhat unsettling that I am agreeing with Deborah Peel . Awareness of Privacy is not enough, action is necessary. I simply want to push for some achievable stepping stones that clearly head in the right direction.
I am excited that the HIT- Security and Privacy Tiger Team has also recommended this, and More

An excellent blog article on this topic Health IT policy intensifies focus on consent.  This article very nicely picks apart the actions going on in DC.

Reference my blog article: The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!,  Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.