Standards - one more and we will have it right

xkcd seems to nail our space more often than not, of course the same can be said for Dilbert and many others. I think we are being watched, but this really means that we are just like everyone else.

.

Wes asks, over in Google+, "Would that we were so orderly in health IT standards and that we were moving towards simplicity."

I am sure that everyone is thinking their plan brings Health IT to simplicity, and I would even assert that each plan would succeed. The problem is we don't all have the same plan, thus your efforts to take us down your plan toward your simplicity takes everyone off of my plan toward my simplicity (metaphorically speaking you vs me). Multiply this by the 100 some plans in play, and we get a mess.

This is not specifically bad, because every individual plan has some specific perspective on the problem that exposes a specific need. It is only with these divergences that we get to see what the other plan has to offer. Ultimately we get course corrections that are good. Good examples can be seen in the standards around ‘documents’, going back to text documents (with various character encodings).

Unfortunately in healthcare right now, there are too many alpha-dogs that are unwilling to listen to others. Some are protecting their business-plan, some are wounded by history, some focus on the big picture, some focus on the minute details. Unfortunately in healthcare we don't have just a few big vendors pushing the market, we have 10s of thousands (this is not bad, just not helpful toward fast convergence). We also have intermediary payers that most other industries don't have, who also have an opinion. Unfortunately in healthcare we also have a strong influence by some luminary patients (this is also not bad, just not helpful toward fast convergence). Specifically these unfortunate facts mean there are many plans in play.

This is reality, we must accept and work with this reality. Best case we would use an open and transparent discussion among equals where these perspectives can be harmonized before we start developing. This is simply not reasonable. I hope for reasonable ‘good enough’ stepping stones that seem to head in the direction that most plans are pointing. Each step is an opportunity to re-evaluate both the horizon, present, and past. I see evidence of this behavior changing, I am hopeful that we are close to making a huge leap forward. Unfortunately we have 1000* that huge leap to go. 

HealthIT standards Maturity vs Adoption

This week the HIT Policy committee had a meeting with an agenda item where Doug Fridsma and John Halamka gave a Briefing on HIT Standards Committee. I have been following these meetings closely, so it was rather surprising what this Briefing contained. As always I encourage everyone to participate, this is one of the only Transparency mechanisms that these FACA committees have (They claim to be Open with the open public comment at the end of each meeting, but these comments seem always to fall on deaf ears). John Halamka blogged his summary of this testimony.

One slide has come up over and over in discussions, slide 24. This slide seems to have appeared out of nowhere. I know that none of the groups I participate in were asked for input to it. There is no explanation of the axis, but they were verbally explained. Not too surprising. Maturity is related to how solid the specifications are and includes if there are implementation guides available.

The concern I have is with the Adoption definition. I am hearing the same concern from others as well. The problem is that the Adoption measurement don't seem to be being applied equally to each item. The REALLY BIG PROBLEM is that there seems to be no way to correct the chart. Now that the chart has been presented to the HIT Policy committee, it will now be considered fully correct. Now, I don't have too much in the way of corrections, but I would like to see an OPEN and TRANSPARENT analysis.

I understand how "Direct Transport" is being looked at as "SMTP", and easily agree that SMTP is very mature and widely adopted. But if we look at how a Direct ecosystem is built, this is not enough of a picture. We must also think about the support transport for all of the Direct Specifications and specifically how well these are implemented in Healthcare workflows. Saying that "SMTP" is highly adopted doesn't mean that "Direct" is highly Adopted. Until the transport is integrated into Healthcare workflows we must recognize this as pure pilot projects and pure pilot use.

I really don't understand how the "Direct Security" is put into this space. The HIT Standards, HIT Policy, S&I Framework, and others are still arguing over certificate distribution; something that will take a long time to argue over due to the need to have the certificates before you communicate.

Where as the NwHIN Exchange specifications seem to be split all over the pace. I am surprised at how the Query could be less adopted than the Retrieve; especially since the only way to Retrieve something is to have previously Queried for it. Thus one must implement Query at the same rate as Retrieve.  I and others on the NwHIN Exchange calls expressed surprise at the NwHIN Exchange evaluation. Somehow all the participation in the NwHIN Exchange is discounted as LOW:

From the NwHIN Exchange site -- Participants (as of 6/13/11):

• Center for Disease Control and Prevention 
• Department of Defense 
• Department of Veterans Affairs 
• Douglas County Individual Practice Association (DCIPA)
• EHR Doctors 
• HealthBridge 
• Inland Northwest Health Services 
• Kaiser Permanente 
• MedVirginia 
• North Carolina Healthcare Information and Communication Alliance, Inc. (NCHICA) 
• OCHIN 
• Social Security Administration
• Regenstrief Institute 

And that list is short, as GE Healthcare participates through my direct participation and indirectly through a set of State based Health Information Exchanges such as KeyHIE.

Please give us a way to provide input. Please allow us to participate in an open and transparent process. There is such positive movement, why is it always ignored?

Healthcare in the cloud

Michael Koploy has a really nice blog article where he uses the HHS breach notification data to see if there really is a security/privacy problem in Healthcare with using 'the cloud'. His analysis is that the data doesn't prove significant security/privacy problem with the cloud, and might actually say that the cloud is a good place for Healthcare.

In the space of, low hanging fruit, there are far more security/privacy problems with simple theft of highly portable devices. I suspect, and have said the same in past analysis of the HHS breach notification data, that these thefts are simple thefts for pawn purposes. I suspect that the theft has very little to do with the data and everything to do with a cool piece of technology that is worth money. A factor that is simply going to grow with the increase of use of these cool pieces of technology, like the iPad.

Unfortunately the latest security/privacy problems in the internet space (e.g. Sony, RSA, Honda, etc) where cloud services were hacked and the data (e.g. names, email addresses, birth date) were exposed. These cases get people very concerned about the 'cloud'. I think that they should be concerned, but then as Michael points out they should likely be more concerned about those cool pieces of technology that Doctors like to carry around with them.

Much of the concern is simply FUD (Fear, Uncertainty, and Doubt). People see what is happening elsewhere and multiplying that Fear by many factors because the EHR in the cloud would be far more detailed. However I don’t think they really assess just how poorly EHR protection would be in a small-doctor office that has no IT support. Far better to put the task of security in the hands of an expert. Still doesn't automatically make it safe, but that is where sharing best practices like NIST 800-146 Cloud Computing Synopsis and Recommendations. 

NIST 800-146 does a really good job of outlining not just the technology, but also the operational and policy issues.  They have touched on issues I had never thought of. They do a really good job of explaining responsibilities between the cloud subscriber and the cloud provider. I highly recommend that people use this guide. 

French National EHR based on IHE XDS

This just crossed my desk:

The national PHR/EHR, or DMP (Dossier Medical Personnel) based on IHE XDS and 6 other IHE profiles has been technically open since December 17^th 2010.  April 2011 was the official opening with clinical use authorized.  They have now records for about 20,000 patient  and a few hospitals and physician offices connected (20 EMR products have been certified).  They expect to reach between 1 and 2 million patient “dossier” by the end of 2011. 

It is both an “shared EHR” and a “PHR” in one system: patient/professional and professional/professionals share the same system, where the patient that opts-in controls access.
The communication and explanation to health professionals and patients is very well done, I think. 

You will not be able to open your own records, because it requires: (1) a health insurance card (2) an encounter with a health professional (trust and education).
 Even if you do not know French I recommend browsing:
http://www.dmp.gouv.fr/web/dmp/page-accueil where I suggest you select the “professional side”, and start with “Comment ça marche ? ” (how does it work ?).
Simple but clear animation.
http://www.dmp.gouv.fr/web/dmp/professionnel-de-sante/comment-ca-marche Try also the “Histoire du DMP”, stories about DMP. These are for both doctors and patients, the story of Julie, Michel and José.
http://www.dmp.gouv.fr/web/dmp/professionnel-de-sante/le-dmp-de-julie For those who want to dive deeper into “policies” hit the tab: “securité and confidentialité”.
For those who want to go into the details hit the tab “école du DMP” or “DMP School”.  Where you will have more detailed tutorial for health professionals.

The June HIT Standards Committee Meeting - concerns

I listened intently and helplessly to the HIT Standards Committee meeting on Wednesday. I was very frustrated at the first half, fortunately for me I have less knowledge about the second half discussion. John Halamka works really hard to keep the group on-track and to bring the discussion to conclusions. What I heard on the call seemed frustrating, but ultimately didn't conclude on anything too hard to live with. BUT, when I look at John Halamka's blog summary, I get re-frustrated.


I am very concerned that there is so much experience in Healthcare and Internet space that is being ignored. I certainly hope this is not intentional, but it is painful anyhow.  I even know of experience that is counter to what I think is the right solution. I am good with this information being discussed, I am confident of my knowledge and am very willing to be proven wrong. Those that were involved in the Direct Project, should remember this and I hope they recognize that once a decision is made in an open and transparent way that I will adopt that decision. I simply want OPEN and TRANSPARENT evaluation.

Here is some comments I left on John Halamka's blog. I know this not well presented. I will expand on some of these topics over time. If you don't understand an item, please ask. It is only with open discussion that misunderstandings can be made clear.

Data Classification: 

a) please don't reinvent data classification, it is a very mature part of IT Security http://healthcaresecprivacy.blogspot.com/2010/08/data-classification-key-vector-through.html

b) Data Classification is just one vector. Just like User-Role is just one vector. Access Control inclusive of Privacy considers them all. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf

c) Complex Consent does not need to be NwHIN portable. Enforce it at the Data-Source, no need to tell Data-User why they don't get access. Once Data-Source determines data can be disclosed; control of the  copy becomes Data-User responsibility.   --- I need to blog on this, I realize now that this lesson learned in NwHIN has not been explained to those not involved in that discussion, or the DURSA.

Provider Directories:

d) the HITSC should not be making the Policy decision on 'who' or 'how' one decides to trust. Certificates are self-validating, the infrastructure does not need to add this complexity (risk of failure). Organizations will make different decisions on who to trust, and for what they trust them to do.

e) I was listening closely and there was disagreement about the new microformat model. I am worried that it has some real questionable operational issues. I worry that google/bing are good, but not good enough. I worry that publication on a web page is not automatically supported. I don't see how the use of this can be automated without being overly constrained. I worry that off-the-shelf e-mail doesn't support this today. I hear that this microformat solution was presented to S&I today by Dixie as a solid mandatory solution to replace LDAP recommendation - This is NOT what I heard on the Wednesday call.

f) I really don't understand how Google/Bing/Yahoo is an authority on Healthcare, but HL7/DICOM/ISO/ASTM/IHE are not. I really don't understand how blog posts by individuals is considered more authoritative than an open and transparent ballot process by HL7/DICOM/ISO/ASTM/IHE.

Metadata

g) CDA is not an envelope, it is a document. XDS Metadata is a generic envelop that can carry MANY document types of documents including DICOM and CCR. Why was XDS/XCA not considered?

h) I understand that there are people that misunderstand XDS as being restricted.. it's only restriction is to a document that has a MIME-TYPE. the XDS Metadata is specifically designed to be content agnostic, yet derived from CDA as a mature model.

i) experience with CDA and XDS is available at http://tinyurl.com/wwxds . This experience is EXTENSIVE. It should NOT be ignored. If it there is a good reason for it to be ignored, please explain.

Patient Identity Matching

j) Matching Consumers credit reporting in the financial industry has lots of false positive/negative; but their failures don't hurt/dismember/kill. Same is true in many other industries. This does not relieve us from learning from others, but we should not blindly assume they have solved the problem to the extent that Healthcare needs it.

k) Please look at XCPD. It has included much input from many global subject matter experts, including Voluntary Patient ID. It is primarily the work of those involved in NwHIN. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_XCPD_Rev2-2_TI_2011-03_04.pdf

Also:
I agree with the comments from dining_phil and David on John Hamamka's post. LDAP must be considered; and OIDs are not healthcare specific and should not be frightening. Yes, they should never be shown to a human.

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment

This just crossed my desk. Most interesting to my usual followers is the "Document Encryption (DEN)" supplement. This includes a comprehensive analysis of all the use-cases around document encryption including existing solutions from IHE regarding transport and media encryption. It then fills the gaps with a standalone document content profile for transport independent document encryption; and updates XDM with a method for encrypting XDM content on USB and CDROM media.

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment
The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for Public Comment on June 3, 2011: ·         Cross-Community Fetch (XCF)
·         Cross-Enterprise Document Workflow (XDW)
·         Document Encryption (DEN)
·         Support for Metadata-Limited Document Sources
·         XAD-PID Change Management (XPID)
 The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 3, 2011 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements.  Comments should be submitted at http://www.ihe.net/iti/iticomments.cfm 

US ONC Requests Comments - Certificate Issuing

There is a very narrow window of opportunity to provide comments to our US Government comment.  The memo went out on June 1, and the deadline is June 5. This is a 5 day window if you received the memo 3 days ago, 2 days if you waited for me to tell you. Does it bother anyone else that not only is this only 5 day window, but the deadline is SUNDAY.  Exacerbated by the very fact that those most likely to have the answers are NOT watching ONC on a daily basis. Those with the answers are those that deal with general purpose IT Security.

This commenting opportunity is regarding how to handle the problem that is, issuing Digital Certificates for securing Healthcare IT. The press release is not that helpful, but I will pull it apart for you. First drill down and you will find that there is a really good presentation by the HIT Policy Privacy and Standards Tiger Team (Not the committee I am on). They have done an exceptional job of bringing together very helpful information.

The key areas that ONC wants comments on include:

• What burdens will providers face to obtain and manage these digital certificates both at an individual and organizational level? How can these burdens be minimized? 
• Is there sufficient competition in the marketplace to ensure that providers will have access to best pricing and service? 
• What role can Health Information Exchange (HIE) and Health Information Service Providers (HISPs) have in providing and maintaining digital certificates for providers and organizations? 
• Among the options listed, what are the costs and time requirements for each? 
• What is the incremental cost to become a cross-certified certificate authority compared to the cost to become a WebTrust/ETSI-certified CA? What factors contribute to the increased cost? 

Your comments need to go to a specific place as well. 

                http://wiki.siframework.org/message/view/CI+-+Analysis+Support+Team/39763196

They need comments regarding this. I have my opinion, and it has been registered. I encourage everyone to respond. Specifically I think that we need to get comments from the International community, where there is already deployment of certificates for their healthcare use. We need to get comments from other industries where certificates are issued (not likely to happen, especially given the timeframe). We need to get comments from healthcare organizations that have certificate deployment projects underway, I am guessing here that the large provider organizations have something.

My latest opinion is that 

I recommend that we don't look to lower our standards (that is to make the solution cheep and thus not really secure) but rather raise the usefulness of the Certificate Identity. If the Government would combine many projects 'need' for an identity then we could rationalize an equitable solution. That is to say that all of these needs for identity should be Coordinated. 

a) Direct - end-to-end message security/authenticity
b) Exchange - organization participation in a regional and/or national exchange (NwHIN Exchange)
c) Medicare plus - and other insurance exchange needs
d) Prescribing (especially the new eRx on Schedule 2)
e) Medical Records - signatures attesting authorship
f) Quality Reporting - identity of the institute reporting
g) Immunization Registries -
h) Medical Credentials
i) Clinical Trials - attesting each submission is already done this way. But participants in a clinical trial could also attest to their participation
j) Medical Professional Societies - HIMSS, RSNA, AAMI, etc...
*) etc... surely there are others... 

Ultimately enough uses of an identity and the costs and inconvenience of getting it well provisioned become insignificant 

Ultimately these could then be used for daily authentication to the EHR (or more practically requested on-demand when the system wants to be sure the user is who they say they are. Meaning lesser and more convenient means are used at each touch, possibly RFID/nearField/wireless based) 

Tie this to NPI - they already have a directory (private) for NPI. 

I would however make sure that the identity is just an identity. Meaning the binding to authority is done outside the identity. That is to say that none of the above use-cases is directly inside the certificate/identity; but rather these are legitimate uses of the certificate/identity. The Authority thus can be granted and revoked while the identity remains constant.