Monday, December 30, 2013

My Predictions and Year in Review 2013

I don't like predictions or reviews, but it seems bloggers are obliged to do this. I did make predictions last year, so I must also measure myself against those predictions.
Speed Bump Comic Strip
I am still excited by opportunities and results.

Less Blog posts in 2013 and 2014
My job at GE Healthcare is to create and promote Interoperability Standards; specifically in HIE, Security, and Privacy. This means that I have a dual focus: outside development in standards organizations (HL7, DICOM, IHE, ISO) and government adoption (S&I Framework, HIT-Standards, HealtheWay, WISHIN, epSOS, Saudi-MoH); and inside promulgation of those standards into products and services. The outside efforts had been put into place in the previous years, and had a reasonable trajectory; so my focus this year has been far more internal focused. Thus I have created less blog articles in 2013. In the three previous years I have created about 95-97 articles, with some months producing 14 or more (thanks to ONC). In 2013, I have only produced 56 articles, with one month with 12 articles (thanks to HL7 ballots including Digital Signatures, DS4P, and FHIR). Some people try to produce a blog article every day, I am happy with one a week, or one a month.

Past Predictions
I predicted three themes for 2013: Mobile, Privacy, and Services. The following themes that appeared throughout the year nicely fit these three high level themes, most of the time fitting all three (Accounting of Disclosures).

Measurements toward Predicted Theme
The themes that appear in 2013 posts
Others view of my blog
This is satisfying to me, but not what my blog Google Analytics show was most interesting to the readers during 2013. The top most viewed articles are all from 2011 and 2012. One of them I didn’t even write.. In order, the most popular Posts in 2013 by click count:
  1. Meaningful Use Stage 2 - Audit Logging - Privacy and Security
  2. Meaningful Use Stage 2 -- 170.202 Transport
  3. How to apply Risk Assessment to get your Security and Privacy and Security requirements
  4. IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
  5. Creating and using Unique ID - UUID - OID
  6. Topics (my table of contents)
  7. Patient Portal - view, download, TRANSMIT
  8. IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
  9. How granular does an EHR Security Audit Log need to be?
  10. The Basics of Cross-Community Patient Discovery (XCPD) - Guest blog by Karen Witting
Posts fading away
I was glad to see these past popular articles become less interesting. They are all now 3+ years old, and likely not accurate today. Please let them fade away.
Theme in the theme
I am very happy that the most top viewed article posted in 2013 during 2013 was the one where I Define Privacy. This comes in at the 15th most popular article this year. The other articles written in 2013 that breaks the top 40 are where I Define Security Audit, and try to Define mHealth. Is this telling me that I should be in the Definition or Vocabulary space? I also posted this year that Vocabulary Standards make poor User Interfaces.

Predicting 2014
I suspect that the US government will continue to be consumed by things that are already in play. There will be a small number, mostly ONC and HIT committees, that keep trying to figure out what MU3 should be. The problem they will face is that it is not clear what the benefit of MU3 is going to be when so many are consumed by things already in play. 

Bluebutton+ will seem right, yet confuse. There will be some easy things, like "Bluebutton+", but as I point out on Keith's blog this is too nebulous of a specification to figure out what it means. The message needs to be made more clear, what part of the "Bluebutton+" experience is to be mandated and measured? I hope it is the CCDA, and not the transport. But Keith sees it otherwise.
Add caption
I don't object to the transport but it is pre-standards specification. I would rather see us mature the "RESTful" concept under FHIR and MHD, with security models from IUA, DS4P, and other projects underway. Getting this right is more important than getting it done fast. This is not to say that HIEs should not look to Bluebutton+, they should. The action should be to experiment and reflect on that lessons learned so that we improve the standards so that we get something worthy of mandate and measurement.

HIE Patient Identity. We will continue to work on the Patient Identity problem, more so this year. There was much talk in the past few years. There was some intense, urgent, work done in CCC and CommonWell. This work will be brought out into the open. We will learn that this is NOT  at technical problem, the standards support what is needed. This is a 'business' operational issue, and a 'privacy' issue. Meaning businesses don't want to change what they are gathering, yet everyone gathers different information. If we must  do patient matching, then we must all gather the same demographics with the same level of accuracy (Level of Assurance). For example, everyone must gather the SSN completely, not just the last four digits. This brings up the 'privacy' problem that this creates. We will not see a universal patient ID, but we will see what sure looks like one. It will simply be a well-structured-and-normalized mashup of the demographics all hashed together. This will fail to match sometimes, but it won't have false matches (false-positive).

Profiles. Simply the  USA will realize the need for Profiles. This  might not be "IHE" profiles universally. I am okay with that. I fully expect that HL7-FHIR will produce some profiles this year. I fully expect that HHS/ONC/HIT-Sc/HIT-Pol/S&I-Framework will come up with a concept closer to a 'profile'.  This is not far off, but not being done today with purpose. The purpose will come when the community sees what IHE does with DS4P. The result is simple and measurable. 

And everything else. Yes Security, Privacy, and HIE will continue to evolve and mature. This is going along at the right pace. Many want it faster, but faster is not how one moves such a large industry like healthcare. Especially since healthcare is very much thousands of competing organizations with highly educated and driven individuals as the workers. My themes from last year will continue to be the right themes: Mobile, Safety, and Services.

Overall I am excited at our progress. It really is a team-sport. There are far more people 'doing' than ever before. There is a more common goal than ever in the past, and the majority of efforts are all clearly toward that goal. 

Saturday, December 21, 2013

Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)

Any standard is not easy to approach. This is especially problematic when that standard is so central to a concept that affects so many. The
Health Information Exchange as a mechanism to Exchange Health Information under some Organization or Federation of Organizations.

HIE Background and Introduction

Most high level document from IHE is the white paper on what an HIE is and the various methods of communications that are profiled in IHE
Health Information Exchange: Enabling Document Sharing Using IHE Profiles - Published 2012-01-24

Second most high is the Volume 1 material on the different profiles. The format of an IHE profile very specifically has volume one material targeting the users and product management. Volume 1 (ITI TF-1): Integration Profiles (rev 10.1 added 2013-10-25)
This is where one will find XDS, XDR, XCA and the other profiles explained in terms of their benefit. This explanation in the context of the ITI committee is rather abstract, as ITI doesn't deal with any specific domain of healthcare. Thus it is all about the IT Infrastructure.

Third most high is the section 4.1 of Volume 3, that outlines specifically the high-level concepts behind the Document Sharing metadata.  Volume 3 (ITI TF-3):

This metadata description has been re-documented as IHE came to understand how hard it was to read. It historically was written over 10 years little by little. So it was time to take a step back and document it more formally. So it now contains an abstract/conceptual definition, and platform specific definition. This will likely be further refined as IHE approaches RESTful

HIE Profile details

The fourth most deep is best to get from the other IHE domains. The reason is that these other domains focus on actual workflows, not just the infrastructure to support workflows. So you will find better explanations of how to translate a clinical need into detailed encoding of documents. Each of these have a Document Content profile, a profile of some document standard (DICOM SR, HL7 CDA, PDF) and how it maps into the HIE framework
The Deepest that IHE goes is found in Volumes 2 and 3. Specifically in the ITI Technical Framework this is where XDS and family are documented in detail.
  • Volume 2a (ITI TF-2a): Transactions for the following profiles CT, PSA, EUA, PIX, RID, XDS, ATNA, PDQ, PWP, NAV
  • Volume 2b: (ITI TF-2b): Transactions for the following profiles PAM, XDM, XUA, XDS, XCA, PIX V3, MPQ
  • Volume 3 (ITI TF-3): Contains Section 4 Cross-Transaction Specifications and Section 5 on the ITI Content Specifications
  • Volume 3 (ITI TF-3): Detailed descriptions in the section 4.2 and 4.3 of Volume 3 is very specifically targeting the programmer or one picking the specifics of the technologies and vocabularies. These are the deepest detail we have on the metadata.
  • There are also supplements that are not yet in "Final" state. Specifically the Mobile Healthcare Documents, the RESTful API to XDS/XDR/XCA

Deployment Guides

Detailed descriptions of what those that are deploying an HIE would need to consider is found in a ‘handbook’. This is useful to others, but is specifically focused on those responsible for deployment, policy, vocabulary management, and those long term concepts. It is rather focused on XDS, but the concepts are useful for any of the document sharing exchange methods
Template for XDS Affinity Domain Deployment Planning - Revised 2008-12-02

Detailed descriptions of Privacy and Security concepts are in the other ‘handbook’. This is useful to the programmer, but is more useful to the security and privacy developers and those deploying.
Access Control - Published 2009-09-28

I cover many ways to bringing this Access Controls to life including using the newest concepts of data tagging to enable federation of access control enforcement.
I also have plenty of other blog articles covering all the various "Topics" that I cover.

There are various levels of complexity found in the IHE IT Infrastructure Technical Framework Appendix found in Volume 1 and Volume 2(x). The volume 1 should be less technical but this isn't always as well done. Volume 2x is mostly completely for the programmer or software architect.
Volume 2x (ITI TF-2x): Appendices A through W and Glossary

IHE and HIE Webinars

I could say that higher than any of this is our Webinars… but I think that is stretching to be called documentation.


So, like eating an elephant, one must take it one bite at a time. There are many more resources too. I have liked what some of the HIE vendors have done.

Sunday, December 15, 2013

On Infuence

My methods of Influence are quiet and patient. Keith wrote on his blog "On Influence" about the ways that he influences. All really good and classic methods of leading and influencing. I agree with everything said, but do things slightly different, some might say totally different. Keith likes to be seen and likes to socialize with the influential. This is shown with his Klout score of 61 today. Yeah, Klout is not that important, but it is recognized by those that like to recognize it.

I however have a Klout score of 47, which is rather high for me. I usually only have a score in the 30s. The difference is that I am less interested in being seen and recognized. I guess I am simply more of a classic geeky engineer. I prefer to act more like Larry Niven's Pierson's Puppeteers, lead from behind the scene. That is not to say that I don't speak with people that do like to be visible. I like to feed those who take on a visible role with information.

The most useful "Influencing" tool that I have, I learned from my Grandfather. My Grandpa Jake was a construction engineer and architect. He was the Superintendent on the Frank Lloyd Wright designed Johnson's Wax Building. One day when my brother-in-law asked "How come you are so quiet Grandpa?" He said "I never learned anything while I was talking." I take this to heart. I do know things about Healthcare Interoperability, Medical Device Safety, Privacy, Security, etc. But I don't know everything, so I try to do more listening than talking. I hope this comes through as better informed opinions when I do speak. I don't mind speaking, and will when asked. I just don't use it as a primary way of influencing.

I do agree with Keith on the importance of associating yourself with activities that will succeed, and also the importance of being willing to fail early. I too use my blog to throw ideas against the open world to see if they are possibly useful or good. It is always good to get positive reinforcement, but more useful to me to hear when I am wrong.

I will add that a very important aspect of Influence in Open Healthcare and Open Standards is a willingness to wait a long time for success. This is not a place for those that want results tomorrow or even this-year. If you are not willing to wait a very minimum of 5 years, and more likely 8 or 10 years; then you should not get excited about this line of work. The things I am working on this year are not likely to be successful for at best 5 years, and I am willing to see it through. During those 5 years lessons will be learned and tweaks will be made. Very little survives this 5 year 'trial implementation' phase unchanged. This goes back to the listening principle. One of the first blog posts I did in 2009 was on the IHE Access Control white paper that I helped write, the fundamentals of this are still being 'discovered' by people and organizations such as the HL7 Healthcare Classification System (HCS) and Data Segmentation for Privacy (DS4P)

I do hold a co-chair position in HL7 Security WG. Politically one must have a co-chair position to be seen as authoritative. Many people think that I am a co-chair in IHE, but I keep avoiding it.

Enough about me:

Saturday, December 14, 2013

Policy needs to get out of the way of good Patient Identity management

I am reviewing the materials that are being presented to the ONC Patient Matching Meeting on Monday December 16th. These materials are fantastic. There is much work that has gone into the current investigation. Detailed and constructive research. There is research on why patient matching isn't working, what technical issues are in the way.

THE PROBLEM IS NOT TECHNICAL. The problem is Policy. This is not to say there are not technical issues, there certainly are problems with current technology. No matter what the policy solution is, technology will need to change. We need to get the policy out of our way so that we can apply technology to that solution. Right now Policy is in the way!

Here is a quote from the report that illuminates the problem
The research questions did not include any specific questions on unique patient identifiers; however, many of the environmental scan participants indicated that their organizations support the study and development of a universal patient identifier (either mandated or voluntary). At the same time, there was acknowledgement that it would not eliminate the need for patient matching methods/programs and would take a number of years to have an impact.
The problem is that in the USA there are rules and prevailing-wind against a universal patient identifier. I understand why this is, it is for good privacy reasons. BUT the result is a far worse privacy issue, and one that also causes Safety issues and Financial issues.

Healthcare needs a high-quality universal identity. I say this not just because it would solve the 'patient matching' problem, but also because I truly believe that it will solve PRIVACY issues, Safety, and Financial issues. I assert that Universal Health ID Enables Privacy

It solves privacy issues because we STOP needing to push so much demographics data around to everyone under the hope that that 'everyone' would be able to do a Patient Match and provide relevant healthcare information. This Privacy violation is 'not seeing the forest for the trees', or 'cutting off your noise to spite your face', or 'throwing out the baby with the bathwater'. How can we not see this?

With a high-quality universal patient identity we will need to only communicate that opaque identity when requesting information. It works just as well in push use-cases. A Patient can express their Privacy preferences/consent using this high-quality universal patient identifier and it will be applicable for ALL uses of that identifier. Indeed the Accounting of Disclosures or even the Access Log is much easier to implement.

The problem with universal patient identifier: I recognize the privacy worry about a universal patient identifier, but this problem is far better solved in the POLICY space. Solved through simple rules. The universal patient identifier MUST NOT be used for any purpose other than the provision of healthcare or payment of such. I am sure there are other parts of this 'simple rule', but I am sure it is more approachable in Policy than anywhere else.

Who should provide this high-quality universal patient identifier? Very good question that I wish I had a good answer for. In most of Europe they are the national identifier, we should look to Europe for both the solution and how they handle the privacy issues.  I am also willing to say that the identifier could be a patient selected identifier, ala Voluntary Patient Identifier. I just want it to be high-quality, which means it needs to be backed by good solid identity proofing.  One can only outsource your identity proofing if you trust everyone that you  are outsourcing your identity proofing to. In healthcare we are outsourcing our identity proofing to everyone, yet no-one.

If you as a human opt-out of getting a universal patient identifier, then you can't be covered by insurance, no deferred billing available, and your historic information can't be used. You are allowed to do this, but you will need to pay up-front for any healthcare and you will need to pay for extra tests each time you are seen since no historic knowledge can be brought forward. Further your data will be marked with your demographics, not an opaque universal identifier. YES, there is a price to your behavior, but it is your choice.

We need to drop this archaic policy against a universal patient identifier. Move the policy to where it can be effective, and issue high-quality patient identifier.

Patient Identity

Monday, December 9, 2013

If you don't understand, Please ASK!

I really like it when someone asks a question. Especially when that question uncovers something that seems obvious but clearly isn't. There have been quite a few of them in the past few weeks. I am sure there will be far more in the future. I like investigating questions in the same way that I liked to debug code. A question where it seems obvious is not unlike a bug in code where the programmer thought they did it right. I recognize that I might be special, as most people I talk to hate to debug code.

I must give credit to the one asking the questions lately. Mostly the questions are coming from Grahame. big effort to rewrite Volume 3 documentation on the metadata we didn't fix many of them, I am not sure if we fixed any of them. So there will be a pile of Change Proposals queued up this winter/spring.
When I ask him why he is just now asking questions about XDS when I know he has worked with XDS for many years. He responded that now that he is doing the work to incorporate XDS into FHIR he knows that he will be answering questions, therefore he needs to feel very strong about the details. Grahame has uncovered many issues with XDS documentation that I am sure most of us on the core of IHE-ITI simply figured were properly documented. Clearly even with the

This kind of questioning should have happened during the IHE Process,
specifically "Public Comment" and/or "Trial Implementation". This is the time when changes are expected. This is the time when it is expected that the documentation is incomplete or even that the chosen solution is wrong. This is the time when those that are developing their solutions to their read of the Supplement, and bringing their solution to Connectathon. This is why IHE requires three independently developed solutions before a Profile can become "Final Text". But this is NOT the only time that something can be wrong, and why IHE has a "Change Proposal" system.

The influx of questions is from a new set of people, that come with different perspectives. Please feel free to ask questions. This is not to say you won't be told to "Read The Friendly Manual". So, when you ask your question please tell us that you have already RTFM and found it confusing or wrong.

Saturday, December 7, 2013

Safety vs Innovation - not just a 23andMe or mHealth problem.

I am a longstanding customer of 23andMe, and am very disappointed at the current behavior. 23andMe have decided to stop offering a healthcare service rather than work with the FDA to achieve safe offering. This approach to questions of patient safety from the FDA seems to be very typical of new product groups. This is not unique to 32andMe. From my read of the 23andMe blog, they are not done but seem they might be working toward a peaceful solution.

I am not upset at FDA, I am an advocate of Safety. I was introduced to the FDA mechanisms 16 years ago. Maybe I was lucky and had good teachers, but I think it was also the fact that I understand the basics of “Risk Assessment and Management”. When one learns of concept domains that are fundamental risk domains, one learns that there is no shortcuts to addressing that concept domain. I am often explaining that there are many risk domains that must be managed: Safety, Security, Privacy, and Effectiveness. There are frameworks, like for security/privacy there is NIST 800-53, but these just try to get the bulk of concerns out of the way using standards based solutions. These frameworks always are backfilled with risk assessment and management frameworks, such as NIST 800-30 for security.

23andMe was approached by FDA many years ago, 23andMe had plenty of time to learn the proper way to address the Safety risk domain. My experience as a customer of 23andMe is very positive. I am very confident that everything that 23andMe have told me about my health has been done in a very respectful and cautious way. I have spoken to others that are 23andMe customers and gotten the same feedback from them. As an example there are some new studies that they are very careful to walk you through a cautious page that is very clear about the sureness or lack of sureness. As a more visible proof, go to the 23andMe web site right now and see an example of their insistence on informed consent.

Given my experience with 23andMe, and my 16 years of working for a company that is FDA regulated, I struggle with understanding what the current problem is. That said, in my 16 years working for a company that is FDA regulated, I also know that the ‘confidential’ letters that come from the FDA are very detailed and require very specific and auditable actions. Thus there must be one of these letters that 23andMe needs to respond to. We don't know the content, and it can take time to resolve all the issues. I am hopeful that 23andMe will come out of this stronger and with the FDA approval. I certainly hope so.

mHealth innovation vs Safety

There is much concern that FDA will quash innovation in mHealth. If one only looks at the negative that FDA brings, that of process rigor and paperwork, I can understand the worry. BUT one must look at what this process rigor and paperwork brings relative to protecting patient safety. Safety really must be a high priority. There is much anger about the NY train crash, much press questions asking why there was not automated safety systems, yet a year ago had someone brought up the question of extra money to outfit the trains with automated control systems there would have been outrage.

I just started Bruce Schneier’s latest book “Carry On: Sound Advice from Schneier on Security”. In the first chapter he covers the paradox of how humans when faced with a loss situation will choose large loss with high-risk over a sure small risk. This is referred to as the Prospect Theory. It is not the typical logical approach, but does seem to be proven out as a human approach. It shows why it is hard to use a 'security' feature as a reason to buy one product over another. It is also why it is hard to use a 'safety' feature as a reason. Too often this means fear is used, which is an equally noneffective approach.

mHealth developers should be allowed to develop applications, but they should not be allowed to cause patient harm through negligence. This is all that FDA regulates. One can follow FDA with little overhead. The alternative is to wait for the FDA to force a visible issue like 23andMe; or for a train wreck to happen for which blood is on your hands.