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

• mHealth Security (1), (2), (3), (4), (5), (6), (7), (8), (9), (10), (11), (12)
• FHIR (1), (2), (3), (4), (5), (6), (7), (8)
• Safety (1), (2), (3), 
• Privacy (1), (2), (3), 
• DS4P (1), (2), (3), 
• De-Identification (1), (2), (3),
• Accounting of Disclosures (1), (2), (3), (4), 
• HIE (1), (2), (3), (4), (5), (6), (7), (8), 
• Digital Signatures (1), (2)

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.

• Meaningful Use Encryption - passing the tests
• Meaningful Use Certification issue with Encryption of data-at-rest
• Meaningful Use Security Capabilities for Engineers

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.

Optimism

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. 

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

• Cardiology
• Dental
• Endoscopy
• Eye Care
• IT Infrastructure
• Laboratory
• Patient Care Coordination
• Patient Care Device
• Pharmacy
• Quality, Research and Public Health
• Radiation Oncology
• Radiology

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.
http://www.ihe.net/Webinars/

Conclusion

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.

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:

• Bloginar on Security and Privacy Profiles
• Blog - Table of Contents by Topic

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.

Conclusion:
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

• HIE Patient Identity problem
• Identity Proofing and Authentication -- Patient vs Provider
• Patient Identity Matching
• Universal Health ID -- Enable Privacy
• The Basics of Cross-Community Patient Discovery (XCPD)
• NwHIN-Exchange use of XCPD for Patient Discovery
• Direct addresses- Trusted vs Trustable
• Identity Proofing and Authentication -- Patient vs Provider
• Level setting on Level of Assurance 

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.

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.

What is a Connectathon?

Connectathon has two very important purposes and one very important principle. A Connectathon is an event that is centered on an open consensus built Interoperability (Connection) specification. The purpose of a Connectathon is both to prove that the specification is complete as well as to prove that implementations written to that specification can ‘connect’. The most important principle of a Connectathon is that it is a safe place for failure in these endeavors. That is that it is free of negative consequences of a mistake in someone’s implementation and that the specification might need to be refined.

In healthcare today many people might view that IHE invented the concept of Connectathon, this is not true. It was invented back in 1986 by those that had written the Internet specification and those struggling to implement it. In 1986 there was also "Interop" which focused more on the infrastructure standards of TCP/IP, and DNS, while "Connectathon" focused more on the application standards such as NFS, FTP, Telnet, and e-Mail. This quote is pulled from the Internet Archive WaybackMachine describing Connectathon as first introduced by Sun Microsystems in 1986:

“Connectathon is an excellent opportunity for vendors to verify that their distributed computing software interoperates with a wide range of client/server implementations on different operating systems. Everything from laptops to supercomputers can be linked together under one roof, encouraging interaction among vendors, engineers and developers in a confidential atmosphere. Implementations are tested and debugged at Connectathon. There are panel discussions as well as open sessions on the latest developments in technologies and solutions by Connectathon participants. Connectathon is a place where engineers can gather without marketing hype and can exchange ideas and information.”

You can see in this quote the purpose and principle that make a Connectathon successful.

Up to this point most networking protocols were proprietary. This meant that they were designed, specified, and implemented within the confines of the vendor that invented the protocol. Thus that vendor knew exactly what they intended the specification to say. That vendor knew exactly what other implementations (none) they needed to work against. That vendor could fully test their implementation in simulated deployment all safely within that vendors walls. Any bugs found during this pre-release testing were only the concern of that vendor. Actually any bugs found at a customer site were also only truly known by that vendor.

So it was considered critical to the success of the Internet that we know and love today that with open consensus ‘standards’ for connectivity have a similar but clearly different mechanism. Thus the Connectathon.

Connectathon is a Safe place to Fail

This simple principle has many dimensions that are worthy of exploring. The alternative to using a Connectathon as a safe place to fail, is to first try connecting to others at the customer site. One can see very quickly that this is not an optimal situation. The customer is expecting to use the product, not participate in debugging. The customer has likely paid money for the honor of having the systems fail to communicate. The customer will hold the two (or more) parties against each-other. But the customer really can’t tell which party is the one with the broken implementation. Thus finger pointing happens, and likely the most powerful vendor wins. This win means that the smaller vendor creates a custom implementation just for connecting to that powerful vendor. This means that the powerful vendor doesn't ever fix their implementation. This situation repeats with all the various vendors, great and small. Each time two vendors are integrated, they need to debug their various differences. Thus no-one is actually implementing the standard, thus there really is no ‘standard’ there is just a specification that hints at some concepts that might or might-not be implemented.

This situation is not good for the customers, they must each push their vendors hard to solve problems that simply shouldn't be. This causes delays in deployments. These deployments are also very fragile to changes. This is very expensive.

This situation is not good for the vendors, unless you have an alternative proprietary solution that you want to succeed. Vendors are pitted against each other in a very hostile environment under the watchful eye of the customer. Time is short, tools to debug are few. It is very hard to reproduce that specific environment. The software was written months ago, possibly years ago. The software developer has likely been working on something else in the last few months, so is not thinking about their implementation.

A Connectathon is a purely testing environment, so no worry about exposing real patient data or creating real patient safety risks.

Connectathon provides a Referee

At Connectathon there are others besides the vendor peers, including those that wrote the specification itself. There is often a set of people who have taken the specification and written test tools. Test tools are a form of implementation as well. As a test tool, it is not expected to be used at a customer production environment. Those that wrote the test tool are not a vendor and are thus not bias in a debugging dispute. Thus the test tool tends to be a non-biased implementation. Those that wrote the test tool are seen as the referee. Those that wrote the specification are also often consulted when a dispute comes up.

The whole purpose for a ‘standard’ is to have a single specification that is highly reusable. The fact that an implementation can be re-used at many deployments drives down the time and costs and drives up quality.

Connectathon is about Cooperation not Competition

As a “Safe Place” a Connectathon is an environment where those that are close to the implementation can come and be blunt. The participants of a Connectathon agree that they will not speak negative of their peers. One is allowed to speak of their successes, and they are encouraged at Showcases. But everyone must agree that the most important Principle of a Connectathon is that it is safe to fail, and one aspect of this is that one can fail without their competition blabbing about it. This principle is typically part of the agreement to participate, but most of the time is just socially encouraged. It is in the best interest of all parties.

The main reason why failure must be allowed, is that it must be encouraged. Everyone wants to get through Connectathon having cross-tested with all possible peers. This because by testing in a Connectathon means that they will likely not have problems at a customer site. Thus the more testing that can be considered ‘successful’ the better for yourself. The best case is that you can walk away from Connectathon with a huge list of your peers that you have successfully tested with. These successes can be spoken of, and are often included in a press release by your marketing department after the event.

The fact that Connectathon is a safe place to fail, means that vendors are more likely to send the developer that implemented the specification in their code. In fact it is useless for a vendor to send marketing or sales, there are no customers to speak to. Developers really want their code to succeed too. Thus the developer is much more likely to work with their peer to get the systems working. Often times the developers from competing vendors will be sitting right next to each other at Connectathon, often times reviewing source code. Yes, they are sharing their source code so that another can help them debug it. This concept is totally foreign to most vendor-to-vendor interactions, but it happens often on the Connectathon floor.

This does not mean that a Connectathon eliminates Competition, far be it. There is plenty of aspects of the software that are kept very well hidden during Connectathon. Some social networking is built, but the vendor organizations are clearly direct competitors.

Connectathon is not a Showcase

This because there are no customers present at a Connectathon. Sometimes customers are allowed on the Connectathon floor but this needs to be highly orchestrated and announced in advance. It is not uncommon for there to be a very detectable atmosphere change during these customer visits, the room gets more quiet, the participants do tests that they know from previous testing will work. During these customer visits everyone is on their best behavior, essentially the Connectathon event stops for a dog-and-pony show. The participants do want to show-off for their customers, they want to be seen at these events by their customers. This is because there is a common good that both vendors and customers see in the event. However one must recognize that Connectathon is not happening while customers are in the room.

Connectathon might fix the Specification

A less visible but just as important aspect of a Connectathon is that the Interoperabilty Specification is also open for discussion. Specifications that are early in their maturity are more open for debate. When two vendors find that they had to fix something in their code, one must ask the question of the specification. Was the specification at fault? Presumably both vendors wrote their implementations from the same specification, and came to different solutions. This could be because one of them simply didn't read the specification correctly, but it could also mean that the specification was not complete enough. Thus the specification is often improved during Connectathon too.

This is so fundamental that IHE requires that their Profiles go through a ‘Trial Implementation’ state. A Profile can’t move to “Final Text” state until three independently implemented systems prove that they can interoperate at a Connectathon event. This governance is there to show that at least three different development groups were able to read the same specification and end up with the same interoperability implementation. There are other governance measures for IHE “Final Text”, but that is a different topic.

Connectathon principles and purpose are critical

A Connectathon is not the only event where developers gather, some other concepts that are related but are different:

• Hackathon – More focused on the development of code to implement some goal. A Hackathon, or Hackfest, or Codeathon, has a targeted solution as the goal. Those that come to the hackathon are cooperating to achieve a goal. There might be more than one independent solution, but generally the goal is the writing of code. A Hackathon might not be focused on an Interoperability Specification, it might be a functional need. A Hackathon is a cooperative environment, again where it is safe to fail. A Hackathon succeeds when it builds buzz, educates the developers, and proves out alternative designs
• Plugfest – This is similar to a Connectathon, but typically focuses on a physical ‘plug’. That is that it is a Connectathon plus it tests physical and electrical interoperability too.
• Bake-off -- This is an event where different technical solutions to a problem are brought together to be compared to the goal. This is used to evaluate each potential solution so that the best solution can be picked. This is a form of implementation first consensus system. In healthcare this is how the "Direct Project" selected secure e-mail as the solution to the problem of 'replacing the FAX'.
• Showcase – To build awareness, educate, and display success. A showcase has been a follow-on event going back to the original Connectathons that were followed by a Telecommunications tradeshow. For much of the  IHE profiles the showcase is part of HIMSS Interoperability Showcase, or RSNA Demonstration
• Certification – Organized testing to prove a system conforms to a specification. Needed when the customer is incapable or unable to prove conformance to the specification. Automobile example. Crash safety is based on certification. Engine oil ratings are based on certification. Style, interior, features, handling, etc. are not subject to certification. An automobile buyer is genuinely unable to evaluate engine oil or crash capabilities of their purchases. They are able to decide what kind of car they want. There is no such thing as a complete automobile certification. Certification is limited to those items that the purchaser is unable to evaluate.

A Connectathon must be a safe place to fail, and be focused around an interoperability specification. If these are not true then you are not at a Connectathon, and you will not be benefiting from the Connectathon concept.

Distinction between Documents and Messages

While Keith was presenting an introduction to CDA training, the topic of Documents vs Messages comes up. After he presented his material, I asserted a more important distinction between Document and Messaging is that of state-less vs state-full.

Keith presents that Messages are: Real-time / temporary, system-to-system, not linked to creative process of the caregiver, not typically sign-able or legally attest-able, and often customized for the usecase. While contrasting with Document as  persistent, human-to-human, core to training of caregivers, legally recognized, and defined by precedent (the paper world). These might be true, but seem more argumentative than factual.

If we agree to look to HL7 to help us define the difference, this is documented in HL7. However we also must recognize that this is documented in the Structured Documents section. The HL7 standard for Structured Documents Section 1.2 describes the document vs. message distinction as follows 

“A document is designed to be persistent for long periods of time, whereas messages are more often expected to be transient. There is a place for both of these constructs in healthcare.” 

Messages are

A Message is sent in a context of a conversation between the sender and the recipient. These are typically system level transactions, I just don't think that is an important characteristic. The context of the transaction is an important factor to understanding the message by the recipient. Messages tend to be used in a STATEFUL world. A good example is the NAK message, it is totally dependent on knowledge of the message that is being negatively acknowledged. An order message is expecting that it is starting the state of something being done. It is true that there are some messages that don't fit this. I am not trying to setup absolutism, but rather setting general observations.

Health messages are not expected to be persistent, but represent a unit of information at a moment in time. The content is not always whole, where context may exist in the messaging environment rather than inside the message itself. Another example is that messages sometimes just use a vocabulary value without including the textual description or even include the code system identifier. Given that the sender and recipient know that they are using the  same value-set, they don't feel compelled to be complete.

Documents are

The HL7 standard for Structured Documents Section 1.2 describes the document vs. message distinction as follows “A document is designed to be persistent for long periods of time, whereas messages are more often expected to be transient. There is a place for both of these constructs in healthcare.” HL7 characterizes a document by the following properties:

• Persistence – Documents are persistent over time. The content of the document does not change from one moment to another. A document represents information stored at a single instance in time. 
• Wholeness - A document is a whole unit of information. Parts of the document may be created or edited separately, or may also be authenticated or legally authenticated, but the entire document is still to be treated as a whole unit. 
• Stewardship –A document is maintained over its lifetime by a custodian, either an organization or a person entrusted with its care. 
• Context - A clinical document establishes the default context for its contents 
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated. 

So what?

The distinction between message and documents can get blurry at times, as messages sometimes can be persisted and can contain all necessary context. Documents too can be incomplete, and rely on external content through links. In fact, messages can be converted to documents and can carry documents within their content. But documents are expected to be persistent, relevant over time and having the same meaning regardless of environment. And messages need not be any of those things.

What is more important to me is the relationship of these two in the context of a long-term, longitudinal, record. In that context the wholeness of documents is more useful than the benefits that messages bring. This is especially true in Cross-Enterprise Health Information Exchanges.

See  Critical aspects of Documents vs Messages or Elements

Webinar: An Introduction to XDS Testing

UPDATED: The recording of this and many Connectathon webinars are available at

http://na2014.wustl.edu/Training.html

Bill Majurski will host a webinar to present "An Introduction to XDS testing".  Though the primary target for the presentation is developers preparing for the January 2014 IHE Connectathon, other users of the toolkit will benefit from the information Bill presents.  The event will be recorded for those unable to attend.

Date/Time: Wednesday, November 6, 2013 9:00AM CT

Event Link: https://himss.webex.com/himss/onstage/g.php?t=a&d=922642992

Event password: 12345 Topics: • Scope:  XDS, XCA, XDR, XDM, MPQ, Metadata Update • Overview of the tools • Overview of the tests • How tests are graded Dial-in Information:  Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 Global call-in numbers: https://himss.webex.com/himss/globalcallin.php?serviceType=EC&ED=245688547&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code: 922 642 992

IHE ITI Profile Proposals - Round One

The first round of evaluations for the new IHE ITI work items has finished this week. There were 12 proposals submitted. The IHE ITI committee can’t do all of this work in the work cycle, so we need to cut the field some. This is first done by the Planning Committee. The Planning Committee met this week in Oak Brook, IL. They have heard the proposals presented in webinars, and this week they were given a chance to hone the message. The committee members ask questions of the individual or team presenting so as to help understand what the proposal is, and in order to understand it relative to all the other proposals. The Planning committee in this round is mostly interested in uncovering the most well justified work items. It is simply a prioritization exercise. Those that don’t get selected are not bad proposals, they are just not more important than the other items presented. This is especially hard on proposals that we see almost every year since the beginning of the ITI committee, such as the proposal for dynamic service configuration.

Thank You to the ONC contractors that went above and beyond.

The ONC through S&I Framework submitted many proposals. With the Government shutdown there should have been no-one to present and defend these proposals. BUT, my hat is off to the contractors. They showed up and presented and advocated for their proposals. Kudos to John Feikema, Johnathan Coleman, (Dragon) Bashyam, and special thanks to Jennifer Sisto who showed up in person. All clearly showing they believe in this strongly. 

The Proposals evaluation

The biggest proposal came from ONC through S&I Framework. The Data Access Framework (DAF) is a project that has been developing for a while now, most actively within the S&I Framework. I have participated in the S&I Framework as much as I can, but I am spread way to thin. The DAF includes just way more than would be a single profile, so it needs to be dissected. These parts can then be shown to either be already addressed by IHE profiles, in process of being profiled, or as gaps to be prioritized in the future. This effort has been taken on by the PCC committee with joint work by ITI and QRPH. I suspect Radiology, Cardiology, and other domains will also be involved as we start to work on this. The PCC committee turns out to be a better place for this work for two very good reasons: First, they have a light workload this year; second they can better address the top-to-bottom needs. They have done this before. Having PCC take this on was a big weight off ITI committee that was warmly welcomed.

The rest of the proposals were scoped and shaped until we felt we understood them well enough to prioritize. We used a tool that Gila first introduced to IHE 5ish years ago, a tool that adds some formality to the evaluation. It can cause over-analysis, but when used correctly it simply makes sure that all aspects of the proposal have been exposed. Meaning some proposals come well developed when others are nascent; yet the nascent one might be more important so it needs to be given a chance to show itself well. After discussing them to this point we use a Multi-Voting method where each voting member gets 5 votes to spread across the proposals in any way they want. This is done in the open, but not necessarily intended to be publicized. Those on the phone get to vote through the IHE secretary.

We often times expect that we need to do multiple rounds removing the clear winners and clear losers and doing a runoff election of the middle. This time the split was very clear so we only needed one vote. The only ones on the bubble were adjusted by the individual that submitted the proposals.

The proposals approved by the Planning Committee will now go to the Technical Committee that meets next month. At that time the proposals are looked at in more detail including their fitness as a profile, needs assessment, standards availability, and how much work the committee estimates it will take to complete the work. This effort further narrows the field usually.

The Planning Committee accepted and passes to the Technical Committee:

1. Standardized Operational Log of Events (SOLE) – a framework for recording operationally useful events in a framework for analysis. It is not clear to me what this will result in. 
2. Mobile Patient Discovery - This profile is a compliments MHD and allow it to be extended to use cases requiring patient discovery. This would be a PDQ like functionality using REST. Likely a profile of FHIR. 
3. Re-Documentation of the Transactions (Volume 2) of the Document Sharing Profiles -- This is fixing up the transaction documentation. Bringing all the profile specific requirements together.
4. De-identification Handbook (complete the work that is almost done) 
5. Secure XDS Retrieve system – A system that makes more efficient Access Control rules enforcement across a distributed XDS environment. 
6. ATNA Repository Federation – Specifically the need to ask partners in an HIE for Patient specific Collection, Use, and Disclosures. Likely to be a profile of FHIR SecurityEvent to enable queries 
7. Data Segmentation for Privacy (DS4P) using REST – Seems that the current path for MHD will fit this nicely, so the effort will be simply sub-profiling MHD+IUA with the rules. 
8. Findings Notification -- A notification system for when an unexpected finding is found such as discovery of a tumor while reviewing a broken-bone. 

This means that the following proposals did not go forward:

1. RESTful XDW and other RESTful extensions – presentation --This will be addressed by the IHE Mobile Task Force 
2. Federation solution for HPD – This seems to be only a USA problem. Other regions are simply using off-the-shelf means not specific to healthcare. 
3. Dynamic Configuration Management– presentation -- Some use UDDI but this is not considered good enough. Priority is never high enough given that everyone has manual means to do this today. 
4. XDS based Sharing under Patient Control -- The ITI Planning committee will work on this 
5. Other XDS re-documentation efforts: Patient, Abstract Information Model, and such 

IHE ITI Technical Framework Volume 1 - Appendix

Updated October 26th: IHE ITI has revised Volume 1 so that the Appendix show up in the Table Of Contents. They also fixed a few other editorial issues. This revision only was done to Volume 1, as that was the only volume impacted. The changes were only editorial so no need to worry if you are using version 10, or 10.1. They are all the same normative content. The link on the IHE web site is always to the current version, with the older normative versions in the archive.

The Appendix is often considered a useless organ, but not always. The IHE ITI Technical Framework Volume 1 has failed to show the list of Appendix in the Table of Content. The new version of the Technical Framework didn't fix this. These Appendix are not necessarily critical, but are informative. The Appendix in Volume 1 of an IHE Technical Framework are those that help people understand the relationships between multiple profiles or larger concepts. This is different than the Appendix in Volume 2 that are usually technically oriented. I think IHE ITI has been doing less work in these Appendix than they should be. As a result there are quite a few profiles this year that would typically be handled by a Volume 1 Appendix.

Here is the Appendix found in Volume 1 of the ITI Technical Framework. They are there, the Table of Contents simply doesn't include their existence.

APPENDIX A: ACTOR DESCRIPTIONS 236
APPENDIX B: TRANSACTION DESCRIPTIONS 239
APPENDIX C: IHE INTEGRATION STATEMENTS 244
APPENDIX D: USER AUTHENTICATION TECHNIQUES - PASSWORDS, BIOMETRICS, AND TOKENS 247
APPENDIX E: CROSS PROFILE CONSIDERATIONS 248
APPENDIX F: REQUEST TO STANDARDS DEVELOPMENT ORGANIZATIONS 261
APPENDIX G: SECURITY CONSIDERATIONS 261
APPENDIX H: INTENTIONALLY LEFT BLANK 263
APPENDIX I: INTENTIONALLY LEFT BLANK 263
APPENDIX J: CONTENT AND FORMAT OF XDS DOCUMENTS 264
APPENDIX K: XDS CONCEPT DETAILS 266
APPENDIX L: XDS AFFINITY DOMAIN DEFINITION CHECKLIST 271
APPENDIX M: CROSS-ENTERPRISE DOCUMENT SHARING AND IHE ROADMAP 272
APPENDIX N: INTENTIONALLY LEFT BLANK 274
APPENDIX O: INTENTIONALLY LEFT BLANK 274
APPENDIX P: PRIVACY ACCESS POLICIES (INFORMATIVE) 274
GLOSSARY 279

For more on the IHE ITI Technical Framework update: Understanding XDS metadata - IHE re-documentation effort. The 2013 version of the IHE IT Infrastructure Technical Framework v10 Final Text are published on the IHE web site. New Trial Implementation supplements were are also there.

Need more Security and Privacy Standards in Healthcare

There are new standards organizations taking on the apparent dearth of Security and Privacy standards in healthcare. Center for Internet Security", or ITU-T SG17 "Security in applications space". Both of these are classically in the non-healthcare (non-any specific industry) standards business. Yet they somehow think they need to make special new efforts for healthcare. They are not the only ones, I have interrupted many healthcare standards organizations, like HL7, with news that there are plenty of available and appropriate standards. Even IHE is looking at a bunch of Profile Proposals this year that are feeding on the fallacy that there is no way to enable patients to participate in an HIE.

Organizations like the "

The reason why these organizations see a dearth of Security and Privacy standards in healthcare is clear, because there are so many failures. Open up the news feed and you will surely find yet another healthcare information breach. The Privacy Advocates are highly frustrated that patients are not getting Privacy. The FDA is being pressured to address cybersecurity. Even mild mannered healthcare leadership are frustrated:

Deven McGraw ‏@HealthPrivacy 3 Oct 2013 Unencrypted laptop stolen, leads to #HIPAA breach http://ow.ly/psn5S Wow, what a shock (not). Encrypt your damn data, health care!

These are real problem, but they are not because we lack standards. These events are hurting the healthcare industry. These events are no good for anyone. When Healthcare is not secure - trust suffers. They are happening because we are not implementing the standards that exist. Even the FDA recognizes this fact.

I am not trying to say that there is no standards development needed. I am very actively working on multiple efforts to develop standards.

Do the basic security

What I am trying to point out is that the basics of cybersecurity are readily available and appropriate. Healthcare is NOT SPECIAL. Healthcare needs to simply implement the basic stuff. General purpose portable devices (Cellular phones, Laptops, Tablets, USB-sticks) are top priority yet also plenty of technology readily available. Like all businesses, recognize that some equipment will need extra enclave protection. Like all businesses, recognize that data is like water and wants to leak out of a container, so you need to watch for it, review the audit logs.

Note the links below will not work while our USA government is shutdown... SAD!

• SP 800-146 Cloud Computing Synopsis and Recommendations.  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. 
• SP 800-124 Guidelines on Cell Phone and PDA Security
• SP 800-111 Guide to Storage Encryption Technologies for End User Devices 
• SP 800-53 - Catalog of Security and Privacy controls - technical, operational, physical, and management
• SP 800-30 - Security Risk Assessment
• SP 800-144 - Guidelines on Security and Privacy in Public Cloud Computing
• IR-7497 - Security Architecture Design Process for Health Information Exchanges (HIEs)
• The rest of the NIST 800 Special Publications

• IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network
• IEC 80001 - Security Technical Report presentation

I have plenty more on my Topics page

Healthcare is special in the complexity of policies

What typically frustrates healthcare is Policy, not technology. Too often someone presents a problem that they think is a technical problem, but is actually rooted in a policy problem. As a systems engineer, I look at any presented problem looking for the root cause. If you don't find the root cause, then you will be just putting a patch over a systemic problem. The problem will reappear.

Healthcare policies are complex, there is no way around this. This is especially true in the USA, but also true even in a highly organized and contained country. First there is the fact that healthcare information is potentially very sensitive, highly personal, potentially valuable, and not revokeable. This is totally different than the Banking industry, especially because in the banking industry data loss can be revoked and insured for. When banking information is lost, the credit card numbers are revoked, a fraud alert is registered, and damages are kept to a defined value. This is simply not possible in healthcare.

The bigger problem healthcare has is that it is has grown up "as needed", meaning there are many healthcare providers from an individual to a multi-national organization; various disciplines; and a scale of features. Many layers of practice: home-health, walk-in, general practice, specialty, out-patient, clinics, hospice, and other. We patients move around all the time and go shopping for the best treatment when we have a special need. Fortunately for healthcare doctors are amazing inference engines and thus can do a fantastic job without knowledge of your past data.

What we need is "Policy Standards"

What we need is some boiler plate policies that handle 80% of the cases. We can then show how to assemble the current technical standards to meet those needs. We must recognize the 20% of cases that are missing out, and kick off tasks to resolve them. But the needs of the many out weigh the needs of the few.

FHIR Demonstration of DS4P

This is a video that was made by Duane, working for the VA.
This video is of his work done at the FHIR Connectathon. Recognize that he wrote this application from NOTHING, learning FHIR starting Saturday. Love it when someone like this proves the “Fast” in FHIR. Note that he does sugar coat some things, like any good engineer showing his boss what he did.

Duane did indeed start with his existing ‘security/privacy classification service’, that was developed in the USA under the Data Segmentation for Privacy (DS4P). DS4P is a region specification of the more fully functional Healthcare Security/Privacy Classification System. In that project this service operates on a CDA document. It is handed the CDA document, and based on a set of programmable privacy/security rules and leveraging a Clinical Decision Support engine for clinical knowledge assessment, will find and mark anything that falls into an expressly sensitive topic (e.g. HIV, Sickle-Cell, Drug-Abuse, etc).

The rules are programmable, and indeed he had to change the rules as he couldn't find any evidence in the FHIR test servers of these kinds of issues, so he just adjusted the rules. The ultimate rules would be up to policy writers. In his case, DS4P has specific rules from USA regulations/laws.

So, once the CDA is marked, other rules tell the code what to do with those marked areas. Again programmable rules. For example one could say that for users with role=X, that Sickle-Cell information must be totally removed. Yes this has issues with Medical Records and Medical Ethics; but it is intended to be a demonstration of possibility to automate, not necessarily a best-case of the rules themselves.

YES, we have had plenty of doctors totally appalled at the idea. But rather, think about a Dietitian putting together a lunch meal, no need to know if the individual has Sickle-Cell.

Anyway, he took this service and the ability to find healthcare information through FHIR,
and mocked up what he could. Imagine this is a shim that sits between the user and the raw FHIR data. It speaks FHIR on the top and bottom. Just like one of the diagrams found in the FHIR security section.