Monday, October 31, 2011

Those Darn Error Messages

I received this email from a senior systems engineer:

Reading about this exploit reminded me about our discussion a long time ago about the perils of returning useful error messages from a privacy perspective.   In this case, it’s not privacy that’s compromised, the hackers can use their knowledge of the typical boilerplate error messages returned by a SOAP transport layer when malformed XML is sent to help them to crack the encryption.   Sounds like the fix is to avoid cipher block chaining.   Article says it’s a pretty easy change.  Hmmm.   

I love it when the message sinks in and an engineer can see the message in something new.  

Cipher Block Chaining has been the topic of other problems lately too, such as the 'BEAST' SSL problem. In both cases these are attacks on a, now understood, poorly constructed crypto mechanism – Cypher Block Chaining. This problem has been known for many years, the real problem is the slow upgrading of systems. 

In the case of this new exploit, XML-Encryption is not the problem, but rather Web-Services Security way of using XML-Encryption. This is what some consider ‘end-to-end’ security for Web-Services. Something that I have resisted for many years, but did eventually end up in IHE ATNA as an alternative (See: IHE ITI TF:3: Web-Services carrying Protected Information(PI)). Fortunately this is not often used, as it presents the same operational administrative problems as Direct has, that the sender must know the receivers Digital Certificate. For Web-Services this presents more trouble than it is worth.

My suggestion all along, also the main part of the IHE-ATNA profile, has been to use Mutually-Authenticated-TLS. It is a well mature technology. Yes it has the 'BEAST' problem, but this is mitigated by the Client Authentication. Using TLS gets away from the newest XML-Encryption problem too.  Note that the IHE ATNA approach to using Mutually-Authenticated-TLS does set the bar at Cipher Block  Chaining (i.e. TLS_RSA_WITH_AES_128_CBC_SHA); but IHE does not in any way forbid other algorithms in operational use. The IHE profile is simply there to assure that there is one algorithm set that will function (interoperability). The TLS protocol does the negotiation of the ‘best’.

To return an error message or not is a tricky problem. I do recommend that for authentication and authorization failures that we carefully consider if a security specific error code should be returned – Using Risk Assessment. The reality is that the answer to this question is not straight forward. In fact, the answer is 'it depends'. It depends on if you know the security context of the network and requester. If you don't know better, then the answer is 'do not return a security related code, just return general-failure'. But if you do know something about the requester, then you can return a security specific error code.

A specific example of this comes up in discussions around Health Information Exchanges regarding authorization. Should an HIE Access Control service be able to tell the requesting system that consent to disclose or authorization for access is needed? If this was a non-authenticated request, my answer would be NO. But when using Mutually-Authenticated-TLS, that does successfully authenticate (meaning you have a secure communications to a known and trusted requesting system), then it is ok to return a code that would indicate that 'I could give you data if consent was to be captured or break-glass was to be declared. ' 

This specific error code can then be used by the requesting system to indicate to the user that more information is available but that authorization does need to be elevated (or different security context exits). A user that is authorized to break-glass could then indicate that they want to break-glass. A  user that has the patient's specific authorization to access could indicate that they have authorization for access. Thus the error code is used to enable dynamic workflows, helping the patient get the treatment they need. 

This kind of detail is hard to ‘profile’ in IHE as the profiles in IHE are intended to be re-used in many context. Thus there is a need to be as context independent as possible. It is only when a system is designed that the context is known. This is a good example of using Risk Assessment in the design at many levels including deployment.

National Council for Prescription Drug Programs and SAFE-BioPharma to Collaborate on Life

This just crossed my desk. It is good to see a valuable use-case "ePrescription of controlled substances" moving into the electronic prescription environment using Digital Signatures. This use-case is valuable enough to overcome the expense and difficulty of using Digital Certificate identities.
NCPDP AND SAFE-BIOPHARMA TO COLLABORATE ON LIFE SCIENCE STANDARDS Scottsdale, AZ and Fort Lee, NJ (October 24, 2011) -- The National Council for Prescription Drug Programs (NCPDP) and SAFE-BioPharma Association announced today a strategic alliance to advance use of their respective standards within the life sciences.
NCPDP is an ANSI-accredited standards development organization which has led transformation in the pharmacy services sector by creating and promoting standards for electronic healthcare transactions. Working closely with its 1600+ members, NCPDP has produced operational efficiencies that save more than $30 billion annually in healthcare costs, while increasing the safety and quality of patient care. NCPDP standards, such as the Telecommunication Standard for billing and reporting claims and services, and the SCRIPT Standard for electronic prescribing, have been named in federal legislation, including HIPAA, MMA, and HITECH.SAFE-BioPharma Association created and manages the SAFE-BioPharma® digital identity and signature standard for the pharmaceutical and healthcare industries. The SAFE-BioPharma standard provides a secure, legally enforceable, and regulatory compliant way to verify the identities of parties involved in business-to-business and business-to-regulator electronic transactions. The standard is compliant with HIPAA regulations and is recognized by the Drug Enforcement Agency (DEA) as compliant with its rules for ePrescribing of controlled substances.
 The two organizations will collaborate in meetings, working groups, and a variety of other forums.
 "We are dedicated to transforming the healthcare system by collaborating on business solutions. Collaborating with SAFE-BioPharma will benefit the advancement of standardized solutions throughout the pharmacy services industry," said Lee Ann Stember, president NCPDP. NCPDP members represent every segment of the pharmacy services sector, as well as other healthcare stakeholder groups.
 SAFE-BioPharma facilitates interoperability and integration among researchers, vendors, regulators, clinicians, prescribers, healthcare providers and other pharmaceutical and healthcare stakeholders. SAFE-BioPharma digital signatures are widely accepted by global regulatory agencies.

"Our collaboration with NCPDP will lead to even greater process and cost improvements for healthcare and other sectors of the life sciences. The SAFE-BioPharma standard helps assure the secure transmission of confidential and regulated health-related information. We believe that both of our organizations will benefit," said Mollie Shields-Uehling, president and CEO, SAFE-BioPharma Association. The association's members include Abbott, Amgen, AstraZeneca, Forest Laboratories, GlaxoSmithKline, Johnson & Johnson, Lilly, Merck, Pfizer, Roche, and sanofi- aventis. ### About NCPDPFounded in 1977, NCPDP is a not-for-profit, ANSI-accredited, Standards Development Organization with over 1600 members representing virtually every sector of the pharmacy services industry. Our diverse membership provides leadership and healthcare business solutions through education and standards, created using the consensus building process. NCPDP has been named in federal legislation, including HIPAA, MMA, and HITECH. NCPDP members have created standards such as the Telecommunication Standard and Batch Standard, the SCRIPT Standard for e-Prescribing, the Manufacturers Rebate Standard and more to improve communication within the pharmacy industry. Our data services include the NCPDP Provider Identification Number, a unique identifier of over 75,000 pharmacies, and HCIdea, "The Prescriber Identity Solution." For more information about NCPDP Standards, Data Services, Educational Programs and Work Group meetings, go online at or call (480) 477-1000. About SAFE-BioPharmaSAFE-BioPharma is the global industry standard for digital trust. It was developed by a non-profit consortium of biopharmaceutical and related companies to transition the biopharmaceutical and health care communities to paperless environments. For more information visit:® is a trademark of SAFE-BioPharma Association. Any use of this trademark requires approval from SAFE-BioPharma Association

Tuesday, October 25, 2011

Critical aspects of Documents vs Messages or Elements

When IHE first was looking at the Cross-Enterprise space, the idea of building an exchange between organizations we looked at many different factors. These factors are not well documented, this is clearly something that we failed to notice. One of the critical decisions we made was around the object that would be managed in this Cross-Enterprise space. At the time it was not clear what would be the best approach.

We needed to pick an object size that was big enough to be manageable, without being so big so as to be cumbersome. One possibility was to take the approach of the HL7 V3 RIM, that is break down everything into the element level. This has some real advantages when it comes to ‘use’, but it presents great challenges when it comes to input, security, privacy, and provenance. The most hard to handle is the  provenance question. For every element must be traceable back to who submitted it and when. This quickly becomes a case of more metadata than data. This could easily be 10 times more data about the data than the underlying data it-self. The other big concern is the context of the data. A lab value may be understood by the doctor that ordered it, because that doctor remembers the context of the lab order. But 20 years later it will not be clear that there were extenuating circumstances around the order.

At the time there was the CDA vs CCR wars. Even though there was strong support for CDA within IHE, we didn’t want to lock ourselves to CDA. Another way to look at this was to recognize that there are clearly needs to manage DICOM reports and a recognition that much of the paper would simply be scanned into PDF documents. Thus we knew we had to be very content agnostic. We did however need to pick an object size, and the one represented by CDA, CCR, DICOM SR, PDF, and others seemed better than the element level. The XDS infrastructure ultimately put one condition, that the object is defined by a MIME-TYPE.  There is a small set of other metadata, and it is true we derived much of that metadata from the CDA header.

Specifically there are some well-defined attributes of a CDA Document that become really useful when we look at Cross-Enterprise HIE, especially when we recognize that this is not just Cross-Enterprise but also longitudinal. We needed an object size that could stand up to the test of time. Surely CDA will come and go, but the concept of a Document as a sustainable object will continue.

Some good discussions of the CDA Document characteristics can be found in the HL7 CDA standard (shown here in the 2008 ballot), or in the CDA Release 2:
The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is a documentation of clinical observations and services, with the following characteristics:
·         Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance).
·         Stewardship – A clinical document is maintained by an organization entrusted with its care.
·         Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
·         Context - A clinical document establishes the default context for its contents.
·         Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
·         Human readability – A clinical document is human readable.

It is very true that these are not guaranteed as part of an instance of CDA, an implementation can always produce garbage. But these characteristics are used as guiding principles in the design of CDA.

I think these same characteristics are generally available in all document formats. At least they should be if you are going to put that document into a longitudinal exchange. The way that DICOM SR does this is different than CDA, but the differences are not important. The fact that PDF is just a blob doesn't prevent these characteristics from being true. They usually are true of paper documents (aka Reports), that might be scanned into a PDF. Thus although CDA was a guiding document type, it is not core to XDS. Any document can be exchanged using XDS.  For example IHE is profiling a new document that is based on OASIS specifications and didn't exist before, and XDS will work just fine.

The fact that we start with Document as the size of an object today does not forbid us from going smaller. It does give us an object size that is reasonable and achievable. The fact that we use Documents also does not forbid us from decomposing them for use in a Clinical Decision Support system. A patient could authorize a CDS service to import all registered documents, decompose them, and create a clinical information database. I think it is more reasonable that these decomposed databases would be authorized by the patient to a service the patient uses regularly. This might be their PHR or it might be the EHR or their GP. As this service becomes more defined and mature the PHR and EHR might share an instance.  See: Access Controls on Clinical Decision Support


Monday, October 24, 2011

Using both Document Encryption and Document Signature

Sometimes one needs to have both a Digital Signature and protect the content with Document Encryption. The Digital Signature (DSG) content profile from IHE provides the Digital Signature. The Document Encryption (DEN) content profile from IHE provides encryption of the document in a transport agnostic way.  

Which should I do first, encrypt or sign?
  • I would recommend signing first, as the signature is more likely to be a long-term signature; whereas the DEN encryption is more for a specific communication purpose (even though it is transport agnostic). The other reason is that logically one will unwrap the encryption protection then need to verify the authenticity of the content. One might also hang on to the signature within a protected system to prove authenticity long into the future. 
How can the consumer tell which was done first? 
  • The fact that DEN produces a new document object, will make it obvious which document is being signed. Said another way the DSG signature identifies the document object that was signed. Thus the DSG signature could be across the original, unencrypted, document; or it could be across the encrypted document. The DSG would identify which of these objects was signed. If the signature is across the encrypted document then the DSG signature points at the new document object which is the encrypted document. If the signature is accross the original document, then the DSG signature points at the original document object, that is not encrypted. 
But the DEN profile includes "Content Integrity"?
  • The DEN profile is providing ONLY for encryption. It is not proposing to take the place of DSG. The DEN profile does include an integrity check on the original document. This integrity check (Content Integrity) is there to assure that the decryption produced the document that was encrypted. The integrity check is not intended to replace a digital signature. For example this integrity check does not include a 'purpose' for the signature.  This content integrity is there only to prove that the decryption 'worked ok'. It doesn't prove that the decrypted file is the one that you think the originator intended to send to you. It is likely that the decrypted document is the one intended, but the point I am trying to make is that DEN does not take the place of DSG.
Why keep these two functions so totally independent?
  • If you want both Authentication of the content and Encryption of the content then you should use both profiles. The main reason to keep these independent functions is to recognize the long-term needs of both are very different. Specifically the impact on long-term key management. In the case of a digital signature, one must maintain knowledge of certificate validity, but one does not need to maintain the private key. In the case of encryption, if one wants to keep things encrypted for a long time, one must maintain the private key. Organizations will also want access to encrypted content of their individuals and often will archive the encryption keys (aka Key Escrow). Surely getting the key back must be a protected action, but there are legitimate needs. This is the reason why Keys are created typically for one or the other purpose and rarely for both purposes. Usually if they are created for both, the use is for communications (e.g., TLS, SSL, S/MIME).
Edited: Note there are many other reasons to have an independent signature such as to have multiple signatures, signatures at different times, counter signatures, co-signatures, signature just for source authenticity, signatures just to indicate the content was reviewed. See Digital Signature for more on this.

For more information:
IHE - Privacy and Security Profiles - Document Digital Signature
IHE - Privacy and Security Profiles - Miscellaneous
Federated Identity.

Sunday, October 23, 2011

ISO work on Privacy and Security

This week was the workgroup meeting for ISO TC215 – Health Informatics. I have recently re-established contact with this body, having missed most of the years’ work. The advantage I have is that everything seemed fresh and new. There is no question that there is some useful work going on in ISO TC 215.

Here is my report on the work done in WG4 (Security/Privacy)

ISO 14441: Security & privacy requirements of EHR systems
  • This is a new work item. The initial reaction by both Bernd and I, both co-chairs of the HL7 Security WG, was to question why this work was being done when HL7 was already working on this as a sub-component of the EHR Functional Model
  • The members then showed us the work, and it is very impressive. They have incorporated input from many sources including EHR Functional Model, CCHIT, and elsewhere. They have done a complete cross-walk with regulations in 5 countries including USA, Russia, Brazil, and Europe. 
  • They have a cross walk with the major IT Security standard, ISO 15408 Common Criteria. 
  • The result is a set of 18 categories of security and privacy functionality with less than 60 total requirements. Many of these carrying the original wording from the source material.
  • The work item plan was to have a second part that focused on the needs of small EHR. The members concluded that on the scope of privacy and security functionality there was no difference between large or small. Thus the second part will not be worked on.
  • I then observed that this work is more mature than the EHR Functional Model, and that we need to harmonize the two works together. The EHR Functional Model will ultimately be dual balloted with ISO, so the harmonization is critical. I worked with the co-chairs of the EHR Functional model that were also present at the meeting. The hard part is that both works are undergoing ballot at the same time. The plan that I worked out is to pull all of the ISO 14441 into the EHR Functional Model, replacing the criteria in the EHR Functional Model today. Make sure that the comments already registered with the EHR Functional Model are still handled. As part of this the criteria in ISO 14441 will need to be reworded as the format of the EHR Functional Model is specific to enable their profiling. Ballots on both works will be resolved in harmony, resulting in a single set of criteria. Where the EHR Functional Model points at the ISO 14441 for details and cross-walk.
Potential new work item on Patient Consent
  • There was discussion of a new proposal to address Patient Consent.
  • Bernd and I both commented regarding the good and existing work in HL7 on consent including the Privacy/Security DAM, CDA Consent Directive, confidentialityCode vocabulary, and the work on Ontology.
  • There was much discussion of the role of IHE BPPC, the HL7 CDA Consent Directive, and future work. Many people don't understand that the HL7 work starts from the IHE BPPC and enhances it. I need to blog about this.
  • The work item will focus mostly on the high level guidance and point at HL7 for the normative aspects. Although it is not clear that this is fully agreed to. This will require much monitoring to prevent overlap.
  • The workgroup was significantly out of date regarding the concepts that have been learned regarding this space. It is not clear to me that the group contains subject matter expertise to support this item. 
  • I think this NWIP proposal will go forward. If it can be kept in harmony with HL7, then it can be a good thing
ISO 17090 new work item proposal Part 4: Digital signature
  • There is a new work item proposed to address Healthcare needs for Digital Signature. The work is being added as a new part on the Digital Certificates family. The work needs to be kept specific to the healthcare needs. It should be focused on pointing at ETSI for the Digital Signature specifics (XaDES is the XML profile). 
  • I recommended that they look to harmonize with the IHE Digital Signature Profile. This profile recognized that there is only a few things that need to be profiled given the underlying standards of XML-Signature and XaDES; the format of the date/time and a mechanism to hold the signature purpose. With the signature purpose vocabulary being specific to healthcare. 
Standards for safe health software
  • The work is now sourced out of Canada, where they are still struggling to get their regulators to recognize software as a medical device. This is in direct contrast to the FDA that has come out with specific guidance on software and even mobile applications.
  • The work is trying to be more open to discussion and input. They do now recognize the problems that vendors would have if they were forced to use two different processes for developing health software.
  • There is formal requests to make this a joint work with IEC 62A. Which is the group that normally deals with Safety.
  • I would like this work to be risk based and recognize risks to Safety as well as Security and Effectivity. This is the scope that IEC 80001 took, and it works out good for things that need to be integrated at the operational level.
ISO 16864: Data protection in trans-border flows of personal health information
  • There was not much discussion of this work item. It is attempting to take a high level view of the needs and the available standards to support those needs. 
  • The work item has failed ballot due to lack of subject matter experts. I think the problem is that the work item is simply too grandiose. 
ISO 21549-Patient healthcard data – 2, 3, 4, 7
  • The USA has and continues to ignore this work. We, at best, look to WEDI for a standard format for printed and magnetic stripe.
  • Common is a desire to keep these health cards to mostly identifiers
  • There continues to be some that think it would be useful to put data on these cards. The committee members are very much against this as it presents security and privacy concerns, and also raises the question of freshness of the data. As evidence of this, they are looking for experts to work on a new part that would define the data. No experts are coming forward. 
ISO 16114 Security Aspects of EHR Migration
  • This work items started a long time ago, and has been moving very slowly. Presented this week was the struggle with defining what an EHR is. This struggle must recognize the various deployment models including classic client/server, n-tier, software as a service, etc. 
  • I have strong concerns with this work item. I don’t see there being a possible thing to abstract enough for ISO to write a good Technical Report on. The aspects of ‘migration’ are simply too specific to the instance. 
  • There is no clear defining line where something goes from a software upgrade to a ‘migration’. They have put out of scope the case of backup with recovery.
  • Unfortunately this work is already underway so it now must conclude in something.
ISO 22600 PMAC Update
  • This is the regular review of this existing specification. There have been significant updates that are considered positive changes. The essence of the specification is not changed. Most of the changes are editorial or to update the text to modern terminology.
ISO 27799 ISM in Health Using ISO / IEC 27002
  • This is the regular review of this existing specification. The problem the committee has is that this work was originally written before IEC 27001 was final. Healthcare received a number in the 27000 family expecting this move. Now the work item needs to be reformatted and changed to reference the IEC 27000 family rather than the 17799. 
  • No significant changes beyond reformatting are expected.
ISO 21091: Directory services ballot results
  • This work was up for review, and received very little requests to change it. There was indicated much  support for it globally. This is also included in the IHE HPD, although not completely
ISO 17090-1, -2, -3: PKI Comment resolution
  • This work was up for review, and received very little requests to change it. The main things were some issues around mandatory fields. Experience has shown that there is resistance to some of the items that were considered mandatory. The changes are all reasonable.
Potential new work item on Privacy Officer Education
  • This proposal was hard to understand what was being proposed as a work item. I think that it is well beyond the scope of a standards organization. There is plenty of this kind of education available. I think the request is to put together one set of training. 
  • I don’t see how this can be done on an international level and be successful. 
DIS 27789 Audit trails for electronic health records
  • This is the work to formalize the ATNA use within EHR.
  • It is awaiting going out for second DIS ballot
  • The work item was not discussed.

I was very happy with the results of the 2 days I participated. This was far more productive than ISO meetings in the past. I would still like to see more participation from subject matter experts, the membership tends to be the same people from academia. This is mostly an effect of the way that ISO operates. It is so frustrating to have this country focused model, where all of the USA gets one vote equal to even the smallest and undeveloped country.

Friday, October 21, 2011

Patient access to Radiology

e-Patient Dave asks Is “Gimme my damn data” coming to radiology at last??

Radiology (all modalities of Imaging) have had many ways to provide patients with their Damn data. The CD that e-Patient Dave refer to is an example that is heavily used. It is not clear from e-Patient Dave's post if the CD he is given is "DICOM Compliant", if it was then the viewer on the CD is not the only viewer available. There are many DICOM viewers you could use. Further these are full DICOM objects so they can be imported into a PACS or even HealthVault. Where they can be fully manipulated by those tools.

IHE has profile of this Portable Data for Imaging (PDI)  This profile is compatible for the wider profile for any Documents on media Cross-Enterprise Document Media Interchange (XDM)

Which is the profile recommended to be used to carry content by the Direct Project.

Thus, the whole space of Healthcare Information can be put on interoperable media and provided to the patient on removable media or e-Mail.

Note that there are equivilant and compatible solutions for a local Health Information Exchange (XDS), and NationWide Health Information Exchange (XCA).

All using the same document, and same metadata, and fully specified for Privacy and Security. What is lacking is the Mandate -- the "Damn" part of the story. 

Friday, October 14, 2011

Nominations Sought for First SAFE-Biopharma Digital Identity Awards

This just crossed my desk


Ft. Lee, NJ (October 13, 2011) -- Nominations are now being accepted for the first SAFE-BioPharma Digital Identity Awards recognizing innovative uses of the global SAFE-BioPharma® digital identity and digital signature standard and the institutions and individuals contributing to broader understanding of its benefits.

SAFE-BioPharma, the global industry standard for digital trust, was developed to transition the biopharmaceutical and healthcare communities to paperless environments. The standard is managed by SAFE-BioPharma Association, a non-profit consortium of biopharmaceutical and related companies. The US Food and Drug Administration and the European Medicines Agency participated in the standard's development.

Organizations and individuals are invited to submit brief nominations in any of the following award categories:

  • Innovative implementation of the SAFE-BioPharma standard
    • Biopharmaceuticals
      • Pilots
      • Implementations
    • Healthcare
      • Pilots
      • Implementations

  • Innovative product compliance
    • For a vendor partner compliant product

  • Individual who has contributed to standard's use and advancement

  • Regulatory advances
    • New advances in regulatory acceptance

  • Global expansion
    • Use of standard globally or regionally

  • Journalistic reporting
    • For advancing understanding and use of the standard

The deadline for nominations is December 15, 2011. Nominations will be judged by the SAFE-BioPharma Board of Directors, representing many of the association's member companies.  Winners will be announced in February. The award will be presented annually.

The nomination form is available by linking to .


About SAFE-BioPharma
SAFE-BioPharma is the global industry standard for digital trust. It was developed by a non-profit consortium of biopharmaceutical and related companies to transition the biopharmaceutical and health care communities to paperless environments. For more information visit:
SAFE-BioPharma® is a trademark of SAFE-BioPharma Association. Any use of this trademark requires approval from SAFE-BioPharma Association

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.

Thursday, October 13, 2011

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
White Paper
Refactor Doc
Workload Size Estimate
The significance and urgency of the interoperability problem in the business of healthcare?
low 1 - 5 high
Benefit to global community
low 1 - 5 high
Degree of expected adoption (for WP relates to use of the content)
low 1 - 5 high
Alignment with IHE development domains outside of ITI
low 1 - 5 high
Alignment with internal responsibilities of ITI
low 1 - 5 high
Total Score
Criteria-based Ranking

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.