More Webinars on Basics of IEC 80001

I am still surprised at how popular my webinar was on the soon to be released IEC 80001 Technical Report on Security. The webinar didn't record well, so there is no recording of my webinar. I have posted the slides.

The background on the core IEC 80001 was the topic of two webinars about a year ago. These webinars were recorded and are still very good today. I highly recommend that you review them.

• Help is Just Around the Corner:  Guidance on implementing IEC 80001
• Learn how to prepare for risk management of medical devices on an IT network, including where to find the standard and its supporting technical reports, what is in the 4 technical reports and how to use them.  Learn also how to perform a risk assessment for a medical device using the technical reports as a guide.
• A World of Increasing Challenges: ISO 80001 and Medical Device Networking integration into Electronic Medical Records.
• Overview of the pending ISO/IEC 80001 standard requirements from one of the IEC committee members.  Considerations for Medical Device Networking integration into Electronic Medical Records.

This month and next month are two more webinars on two soon to be published Technical Reports:

• IEC 80001 Guidance for Wireless Medical IT Networks - October 19, 2011 2pm-3pm EST
• This session will provide guidance regarding wireless networks for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance on Planning & Design, Deployment & Configuration, Management & Support, and Risk Mitigation techniques.
• Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples - November 16, 2011 2pm-3pm EST
• This session will will provide step-by-step information for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance in the form of a study of risk management terms, risk management steps, an explanation of each step, step-by-step examples, templates, and lists of hazards and causes to consider.

IHE ITI New work items for 2012

The IHE IT Infrastructure (ITI) Planning committee met this week to assess the new work item proposals. There are 6 new work items this year, only 2 of them propose new profiles. There is also some unfinished business from last year to cover.

The unfinished business is

1. Completion of the De-Identification cookbook – This is instructions to other IHE domains on how to create profiles that use anonymization and pseudonymization tools.
2. Create a Cross-Enterprise Workflow (XDW) training package and assist other domains with the creation of their specific workflow that uses this infrastructure profile.
3. And the normal documentation maintenance including change proposals, wiki, and profile lifecycle management.

The new work items were presented and discussed (the FTP site has some of the presentations but not all of them)

1. Critical and Important Results – This is a white paper proposal to expand on the need to notify someone when something critical or important is uncovered. The idea is that when something critical or important is discovered, one needs to discover who should be told about this information and how should they be told. This seems to me to be something similar to how we expect PWP or HPD to be used, but with more deterministic results. 
2. Patient Encounter Tracking Query – This is a profile proposal to address the need to have a system where actors that know where a patient is can record the location, so that others that want to find the patient can discover their location. This might be automated with things like RFID, might be automated through registration desk activities, or might be manual. The profile proposal looks to leverage the PAM and PDQ profiles.
3. Configuration Management for Small Devices – This is a white paper effort to explore the area of configuration management in a very broad way. The expectation is that this white paper could point at common solutions from general IT (like LDAP, DHCP, DNS) for some problems that are not healthcare specific, while identifying gaps that are specific to Healthcare. These gaps could then be proposed as work items next year.
4. Fix XD* Technical Framework – This a project to fixup the current documentation around the XD* family of profiles. There are a well-known list of things that people who come at IHE for the first time can’t find. These things tend to be things that the long standing members simply assume are documented. This realization comes through Bill’s experience with the Connectathon test tools development and assisting individuals with their development efforts. This item seems to always be outstanding, but we must take it on as a top priority and get it done, well better. The result MUST not change any normative meaning. This is simply reforming the documentation so that it is more readable and understandable.
5. Document Access for mHealth – This is the project that Keith (and I) submitted. The proposal today is mostly identifying the constrained environment that is most prevalent on mobile devices (phones, tablets, etc) but which exists in other places. This constrained environment has troubles with the SOAP stack used in the XDS/XCA environment, and also find the ebRIM encoded metadata harder to manipulate. The proposal is thus to come up with an interface (SOA like) that an organization can offer to their users that is more attractive to these developers and thus will drive for Apps that might be more reusable across organizations.

The new work items were discussed, evaluated, and prioritized. Given the few number of items, they are all being handed over to the Technical Committee for evaluation.

Proposal title	Critical & Important Results	Patient Encounter Tracking Query	Config Mgmt for Small Devices	Fix XD* Technical Framework	Document Access for mHealth
Proposal type	White Paper	Profile	White Paper	Refactor Doc	Profile
Workload Size Estimate	Medium	Medium	Large	Medium	Large
The significance and urgency of the interoperability problem in the business of healthcare? low 1 - 5 high	4	3	3	4	4
Benefit to global community low 1 - 5 high	5	4	3	5	4
Degree of expected adoption (for WP relates to use of the content) low 1 - 5 high	3	3	2	5	5
Alignment with IHE development domains outside of ITI low 1 - 5 high	4	3	4	4	3
Alignment with internal responsibilities of ITI low 1 - 5 high	5	4	4	5	5
Total Score 5-25	21	17	16	23	21
Criteria-based Ranking	2.5	4	5	1	2.5

There was a priortization step, but it resulted in mostly the same outcome as the above evaluation.


The Technical Committee meets next month. Their task at that time is to determine the feasibility of these work items, dig deeper on the available standards, assess more strongly the size estimates, and make sure that resources are lined up and ready to execute.  The result is a joint meeting of the Technical and Planning committee to decide on what actually will be worked on next year.  The capacity estimate we guessed at during the start of the meeting seems like it might fit all this content. I worry about that as we always increase scope on work items, and then end up with poor quality and missed deadlines.

Between now and the next meeting, Keith and I must do a better job of explaining the scope of our mHealth proposal. For example does it support both query/retrieve and Create? Is it a Cross-Enterprise profile, or one that we only assess as a last-mile API that an organization hosts for their users? Of the XDS queries, which ones are needed and how constrained can those be? How much can we off-load to the Service as the Client really doesn't need to be bothered? What might the metadata encoding simplification look like? What technologies are in scope? What deployment scopes can be placed on profile? How will privacy and security be handled? Keith got a good start on this in an email.

Other business

The planning committee is responsible for other things, such as education and outreach. In this space there is some really good progress. The first white paper is critical, there isn't much to look at today but we are working hard to make it highly useful.

• White Paper on how to use the IHE Profiles to share documents
• Educational presentation content and webinars
• Wiki profile descriptions
• Preparation for meeting at HIMSS
• Assess other opportunities for communicating about ITI work

Data Segmentation - now I know where the term comes from

During the kick off meeting for the new S&I Framework project on "Data Segmentation" I found out why this concept of Patient Privacy Policy and Controls keeps being called "Data Segmentation". The key is a project funded by HHS a year ago that resulted in a white paper on September 29, 2010 titled "DATA SEGMENTATION IN ELECTRONIC HEALTH INFORMATION EXCHANGE: POLICY CONSIDERATIONS AND ANALYSIS" (Sorry for the shouting, they actually used all uppercase). This white paper was authored and presented at the S&I Framework "Data Segmentation" kickoff meeting by Melissa M. Goldstein, JD. Melissa did a fantastic job of explaining the content, and I now understand why the scope is what it is. I simply wish that the simplification of the subject would have been from later in the title "Policy Considerations".

Note that these resources are on the HHS site on Privacy and Security

The executive summary indicates

This discussion raises the issue of data segmentation, which we define for the purposes of
this paper as the process of sequestering from capture, access or view certain data
elements that are perceived by a legal entity, institution, organization, or individual as
being undesirable to share.  This whitepaper explores key components of data
segmentation, circumstances for its use, associated benefits and challenges, various
applied approaches, and the current legal environment shaping these endeavors.  

Data segmentation in the health care context can support granularity of choice with
respect to the following:

• What specific data are eligible for exchange (from individual data elements to defined categories of data, such as all behavioral health records); 
• Who has access to the information (from individual providers to other health care entities); 
• Under what circumstances access is granted (e.g., emergency access, treatment, etc.); and  
• For what period of time access is granted (e.g., unlimited, one-time access, etc.)  

The executive summary concludes

As such, it will be important for policy makers to consider various approaches to moving
not only the discussion, but also the meaningful realization of data segmentation, 
forward.  Data segmentation efforts to date have explored a variety of approaches that
show some early, but limited, success.  To accelerate this forward momentum, we would
suggest, among other pursuits, the following:
 

• Build a Bridge to Greater Autonomy: Rely on policy levers that will move us closer to the goal of supporting individual, subjective preferences for information management;  

• Provide Direct Financial and Other Support to Stimulate Change: Consider various means of supporting  the development of segmentation-enabling processes and technologies; and  

•  Generate Evidence: Given the significance of the transformation from paper to electronic means of data capture and sharing, establish and execute on a set of updated research priorities.   

We support the idea of casting a wide net in search of appropriate means of providing
patients more granular control over the exchange and use of their identifiable health
information, and point to the efforts underway in other countries as evidence that this is a
worthwhile endeavor.  While still a challenge, data segmentation holds promise for
accomplishing the ultimate goal of accommodating the needs and desires of the multiple
stakeholders engaged in the electronic exchange of health information.  

The report is very extensive.

IEC 80001 - Security Technical Report presentation

I presented the soon to be published Security Technical Report IEC 80001-2-2 "Guidance for the disclosure and communication of medical device security needs, risks and controls". There is an assumption that the audience has an understanding of the basics of IEC 80001-1 "Application of Risk Management for IT-Networks Incorporating Medical Devices". I have been involved in the creation of this set of specifications from the beginning and provided some background here on my blog.

This webinar was well attended for a security webinar with close to 150 participants. My blog has also been very actively referenced since then. So I can tell there is strong interest. Unfortunately the audio recording of the webinar failed, so the best I can do is offer up the slides. The full slide deck is available on Google Documents

ONC Announcement of E-Consent Trial Project Contract Award

This is a really great project by ONC to address the soft side of HealthIT and HIE. That being the interface with the human patient, specific here to educating and getting the consumers preferences.

C.2. PURPOSE
The Office of the Chief Privacy Officer (OCPO) within ONC proposes to award a contract to

a. Use innovative ways to
i. Educate and inform individuals of their option to give individual choice (e.g., automate informed consent process, patient-centered decision making process) in a clinical setting to share their health information electronically; and
ii. Ensure that individuals are knowledgeable participants in decisions about the sharing their electronic health information in a clinical environment.
b. Explore and evaluate ways of electronically obtaining and recording meaningful and informed choice from individuals in a clinical setting, regarding sharing their electronic health information.  

The project is designed to help identify some innovative best practices in ensuring that any choices patients make with respect to sharing their health information are indeed, meaningful: i.e., patients are adequately educated about issues that are important to them, and that they understand the choices they make as well as the consequences of those choices.  

I looked deeper in the document and was happy to see recognition of the existing works of IHE.

My biggest concern is that there doesn't seem to be enough guidance to the contractors to (a) look globally for how this is handled in other environments, and (b) to gather a set of reasonable privacy policies and their variability. In the case of (a) there are other environments that are ahead of USA on presenting Healthcare Information Exchanges, and thus there is some lead there on how they interact with the patients. 

In the case of (b) I worry that this project will focus only on what the patient wants to control, and will forget that the healthcare provider organization has the right to not accept all the controls that the patient desires. Typically this is due to real patient safety or provider safety concerns, sometimes it is because the provider organization knows they simply can't protect the data in that way. Sometimes it is because the provider organization does indeed use the data in secondary ways that do conflict with the patients preferences. This specific issue took much time to discuss in HITSP. It turned out to be a core part of TP30, that recognized that there is a need to record patient preferences that are not actionable directly but are there for a healthcare providing organization to utilize when they formulate the policy choices that they offer to the patient. It is only the binding of a patients accepted preferences to the providing organization that creates an actionable privacy policy that the organization is held to. (note I use organization here inclusive of Health Information exchange Organizations). 

I look forward to any opportunity to get involved with this project.

        From: ONC Health IT [mailto:onchealthit.@service.govdelivery.com] 

        Sent: Monday, October 03, 2011 9:01 AM
        Subject: Announcement of E-Consent Trial Project Contract Award

Announcement of E-Consent Trial Project Contract Award ONC's Office of the Chief Privacy Officer recently awarded a contract to APP Design, Inc. to find an efficient, effective, and innovative way to help patients better understand their choices regarding whether and when their health care provider can share their health information electronically, including sharing it with a health information exchange organization. The project team will design, develop, and pilot innovative ways to electronically implement existing patient choice policies, while improving business processes for health care providers. To learn more about the E-Consent Trial project, please see the Statement of Work. ONC's formal launch of the E-Consent Trial Project will be in October. Questions? Contact Us STAY CONNECTED: SUBSCRIBER SERVICES: Manage Preferences | Unsubscribe | Help This service is provided to you by The Office of the National Coordinator for Health Information Technology.

IHE IT Infrastructure Cross-Enterprise Workflow Supplement ready for Trial Implementation

This is a going to be a highly re-used fundamental profile. As it is published by the ITI committee it doesn’t do much, but when other committees put it together with a clinical workflow it becomes a powerful tool to drive workflows across enterprise boundaries. For example, enabling the kind of workflow that Keith discusses in A Patient's Viewpoint of Provider Workflow

 IHE Community, IHE IT Infrastructure Technical Framework supplement published for Trial Implementation 
The IHE IT Infrastructure Technical Committee has published the following Technical Framework supplement as of October 3, 2011:·         Cross-Enterprise Document Workflow (XDW)
Note:  This supplement will be tested for the first time at the IHE Europe Connectathon in May 2012
 
The document is available for download at http://www.ihe.net/Technical_Framework. Comments on this document can be submitted at http://www.ihe.net/iti/iticomments.cfm. We use this email distribution channel for periodic updates on IHE activities.  If you wish to respond to this message or to be unsubscribed from this distribution list, please send a message to secretary@ihe.net. 

a New S&I Initiative: esMD Call for Participation

The S&I Framework is kicking off yet another project. I exhausted with the number of projects that I need to participate in today, and I only participate in a few (Keith is our lead this year). This new project seems like 3 totally different use-cases rolled into one. So it is actually three new initiatives. I can’t quite understand what use-case 2 and 3 are. They are so broadly written that they could be almost anything. But use-case 1 is one I can help with.

Digital Signatures are a topic I have covered multiple times. I don’t know of anything new being asked for, so I will just point at the existing work on the topic. This work includes use-cases, standards assessment, vocabulary identification, and profiling of standards.

• IHE - Privacy and Security Profiles - Document Digital Signature
• Signing CDA Documents

HITSP covered this space and created C26 - Nonrepudiation of Origin

Note, the technology is easy; the hard part is getting over the administrative costs, infrastructure, and processes that are necessary to support Digital Signatures. In order to have digital signatures of any value one must have a strong certificate management infrastructure in place. One that issues Certificates to individuals, who are very careful with them. Certificate management infrastructure that can hold certificates for 100 years. This is expensive. This is the reason why few actually roll out Digital Signatures, and this is why IHE has not seen enough adoption of DSG to move it to final text. 

The other hidden complexity is timestamps, one must be able to trust the timestamp inside a digital signature. This is not the same thing as having synchronized time. This has to do with protections against malicious 'back dating' of signatures. There are technology solutions, usually implemented as a timestamp-service. This timestamp-service does nothing but apply a Digital-Signature of it's own. By agreement everyone trusts the timestamp applied by the timestamp-service. More technology, more certificate management and more trust.

I'm not going to be at the Face-to-Face, so let me know how it goes.

From: S&I Framework Admin [mailto:admin@siframework.org]
Sent: Friday, September 30, 2011 4:18 PM
Cc: Mohammed.Elias1@cms.hhs.gov; melanie.combs-dyer@cms.hhs.gov; Mera.Choi@hhs.gov
Subject: Announcing a New S&I Initiative: esMD Call for Participation Current S&I Framework Members,
ONC is pleased to announce the launch of a new S&I Framework Initiative – Electronic Submission of Medical Documentation (esMD).

You are invited to attend the esMD KickOff Meeting and subsequent discussions at the S&I Face to Face on Oct 18-19.  The esMD initiative will require inputs from several other S&I Initiatives, such as Provider Directories and TOC/CDA, so we encourage and request your participation and input to this important initiative.  For those of you who have not yet registered for the F2F Meeting, you can do so on this link: http://wiki.siframework.org/October+F2F+Meeting
Note: Registration for the Face to Face meeting has been extended through Oct 7th.  The Hyatt has also extended their discounted hotel room rates through Oct 7th. 
The Kick-off call for the esMD Initiative will occur October 18, 2011 at 9:30am EDT.  Please stay tuned for additional agenda details for the esMD sessions on Oct 18-19th, or monitor the esMD wikispace for updates: http://wiki.siframework.org/esMD+Workgroup.  On this page, you can also sign up as a Committed Member or Other Interested Party for the esMD Initiative.

Please note the attached esMD DRAFT charter. Below is a summary of the Initiative and expected Use Cases.

esMD Initiative: The Electronic Submission of Medical Documentation (esMD) pilot intends to give providers a new mechanism for submitting medical documentation to Medicare Review Contractors. The S&I Framework esMD Initiative will focus on Interoperability and Nationwide Standards needed to support esMD requirements. The objective for the initiative is to setup workgroups to develop the use cases listed below:
Use Case 1: Define technical issues and relevant standards associated with author level digital signatures and develop a list of recommended Standards and associated Reference Implementation Guide(s)
Use Case 2: Define Standards for Structured Data submission capability using esMD
Use Case 3: Define standards for electronic communication with Providers to request for Medical Documentation (Structured Outbound)
Based on current discussions among members of the HIT Standards Committee and feedback from members of the community, the following core outcomes have been identified for the esMD Initiative:

• Identify gaps in CDA Structured Document to support Progress Notes and Orders, and other documents as required for Medicare Review and similar activities

• Leverage work of Provider Directories, Certificate Interoperability, Transitions of Care, and Data Segmentation Initiatives as they apply to esMD

• Define technical issues and relevant standards associated with Author Level Digital Signatures

• Identify and address business process and infrastructure issues associated with Author Level Digital Signatures

• Identify and forward policy issues, if any, to appropriate policy bodies

• Develop a list of recommended Standards, potentially including new work by SDOs, to be incorporated in a Reference Implementation for esMD

Thank you,Melanie Combs-Dyer, esMD Initiative Coordinator;Mohammad ‘Sam’ Elias, esMD Project Manager;and the S&I Framework Support Team