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.