IHE broadens IT Infrastructure Support with extensions and new profiles for 2010

The IT Infrastructure Domain of IHE (Integrating the Healthcare Enterprise) has finalized its scope for its 2010 activities.  It includes three new Profiles focused on back-office support and three extensions to existing interoperability Profiles:

• New Profile: System Directory for Document Sharing (SDDS): This Profile is intended to support the participating systems (EHRs, Clinical IT systems, PHRs, etc.) in the Health Information Exchange (HIE) to discover the web services end point metadata of the infrastructural services. The Profile will target the Cross-Enterprise Document Sharing (XDS) family of Profiles, but will likely be extensible to other network service endpoints.
• New Profile: Healthcare Provider Directory (HPD): This Profile develops a unified approach for authorized users discover healthcare provider organizations/individuals. This Profile will define network transactions to Directories/Registries and the attributes and vocabularies available. 
• New Profile: Enhanced Sharing of Value-Sets (ESVS): Healthcare interoperability is enabled by the combination of syntactic and semantic consistency. This Profile builds upon the IHE Shared Value Set supplement profile to add Value-Set Registry Actors dedicated to vocabulary distribution. This will enable consuming systems to discover and access the most current and relevant set of terminology codes.
• Update to Cross-Enterprise Document Sharing (XDS) to allow updating of document entry metadata held by the XDS Document Registry. This new transaction will allow privileged entities to modify the metadata about a document without replacing the document. This also will include a way to mark a document entry as removed without deprecation. 
• Update to Cross-Enterprise Document Sharing (XDS) and Cross-Community Access (XCA) to support the sharing of document content that will be created at the time of retrieval. This will allow a publishing endpoint to indicate that it is willing to provide an instantiated document upon demand that will include the most current information.
• Update to Cross-Enterprise User Assertion (XUA) to define specific authorization attributes based on the experience of existing regional and national project experience. This extension is looking to enable Role-Based Access Control, Level-of-Assurance, Legitimate-Relationship, and others.

Overall this year the IHE IT Infrastructure committee will be focused on making small adjustments to the overall Healthcare IT infrastructure. This is recognizing the maturity of the Cross-Enterprise Document Sharing (XDS) family of profiles as an infrastructure to build a Health Information Exchange (HIE).

HHS Posts Data Breach Notifications

HHS now has a Web site where they have posted all of the breaches they know about. This will cause some new pressures to secure large databases. I think the more convincing information is that Data Breach Costs Top $200 Per Customer Record. This new web site will also cause some over-reactions and reopen a past discussion that Encryption is mandatory.

The Office for Civil Rights in the Department of Health and Human Services has launched a Web page listing covered entities that have reported breaches of unsecured protected health information affecting more than 500 individuals. More

Related Post on ONC investigation into de-identification

Healthcare use of iPhone presents hidden risks

It should not be any surprise that any platform that is used to deliver sensitive information, such as healthcare information, must be holistically considered within a Risk Assessment framework. There are two REALLY good blog articles on some not-so-obvious risks that occure when the iPhone platform is choosen. The original blog post by MedPage Today blog  is “iPhone Security Risks and How to Protect Your Data — A Must-Read for Medical Professionals.”   This was further elaborated on by IdentityBlogger in the post SpyPhone for iPhone. 

The basic message is that one can't simply worry about their own application, they must look at how the device might be used by the end-user. In the case of the iPhone it is simply too enticing to pull apps down from the AppStore. Apple does a good job of reviewing these applications, sometimes too good, but all it takes is for one malicious application or poorly-written application to get through to cause data leakage.

For any mitigation of this risk, new risks or costs must be considered. If one tries to lockdown the medical iPhone so that it can't use the AppStore would very much inconvenience the user. Try to isolate the application, and the user might not be able to use legitimate cross-over applications. 

HHS appoints Joy Pritts chief privacy officer

I know of Joy Pritts due to her work in Healthcare Privacy. It seems she has the background to do this job. The big question is if this job will be anything other than a figure-head.

The Health and Human Services Department named Joy Pritts, an assistant research professor at Georgetown University's Health Policy Institute, as chief privacy officer in the Office of the National Coordinator for Health IT. More

Georgetown Health Policy Institute bio

How to Write Secure Interoperability Standards

I am an active member of "Interoperability Standards" organizations: HL7, ASTM, DICOM, ISO TC215, OASIS, and IETF. I am also an active member of "Profiling" organizations: IHE, and HITSP.  I am most active in the security/privacy workgroups in these organizations, where we receive strange requests from the 'other' workgroups. These requests are a fragment of a security issue, but don't have enough information around the issue to make them actionable work items. Some of them are issues for which the organization already has a solution, such as Transport Layer Security (TLS). Some of them are simply "Security Theater".

The security workgroups decided to provide some guidance to the 'other' workgroups on how to appropriately design their standard with security-built-in. Security is about mitigating risk to Confidentiality, Integrity, and Availability. So we knew that our guidance would be an instruction set on how to do a Risk Assessment. We knew that the 'other' workgroups are made up of smart people that needed simply a little guidance, but knew that we needed to carefully craft our guidance so that it would be used. So, we wrote a "Cookbook" on the topic of  writing the "Security Considerations" section of their standard. A title that we figured would have people thinking we were giving them simple instructions, read "Cut-and-Paste", on how they should write their Security Considerations section. We know it is the most simple approach even if one must first do a risk assessment which is typically not seen as a 'simple' task.

The advantages of this approach are:

1. The 'other' workgroup must first describe the expectations of the environment that they expect their standard will be used. This includes describing the already available underlying security technology.
2. The 'other' workgroup uses the risk assessment tool to quantitatively prioritize the actual risks. Thus they focus on real risks, and can prioritize the most 'risky' issues. 
3. The 'other' workgroup will flow-down unmitigated risks to the next level of design. There are risks that can't be mitigated by a standards organization. These unmitigated risks should be documented in their standard, "Security Considerations", as risks that are identified but not mitigated. This list of risks can be picked up by the next level of design.
4. The 'other' workgroup has good documentation of issues that the 'security' workgroup should work on. The risk assessment is a clear communications tool that has the background and the risk well defined and prioritized.

These Procedures are now available at:

• HL7 version of the "Cookbook for Security Considerations" has a really good PowerPoint training package. This one has not yet been piloted, but there are a few projects that will be running this process. These pilot projects are closely associated with the security workgroup.
• IHE version of the "Cookbook for Security Considerations" has some good experience having used the tool on a set of profiles already. The risk assessments are not considered normative, but are archived so that they can be reviewed when the Profile gets revised. These risk assessment spreadsheets are useful reference when a new 'other' workgroup uses the tool.

In both cases, more has yet to be learned.

Three Security Concerns for 2010

One of the HIMSS groups that I participate in asked the members for their three security concerns for 2010. (This is what also caused Glen to write the text that I have as a guest blog: Accounting of Disclosure Challanges and Top Information Security Concerns).

1) Identity. Including Patient Identity, Provider Identity, and User Identity. Identity is important to make sure that we get operational access controls correct, patient-privacy-preferences correct, delegation correct, accounting of disclosures correct, oversight correct, etc.

• Patient The aversion to a federally issued identity is well known. I am amazed that we are the only country that can’t get over this, yet have so many federally issued identities. We don’t need a federally issued identity, but a federation of identities. This is a strong linkage between the various healthcare identities. There could be purpose-of-use views into this federation that forbids the viewing of identities that your purpose-of-use does not need access to. What is important is that this is a STRONGLY provisioned linkage. This is NOT an algorithm that evaluates two sets of demographics and ‘decides’ that there is a probability that they match. The act of entering a new identity and matching it to the existing identities must be done following only well documented process. Essentially I am worried that a fuzzy matching of patient identities will have too many false positives and false negatives. Patient’s lives are too important. Patient misbehavior is too valuable.
• User Identity. This is highly linked to the Patient Identity as they are often going to be ‘users’ in the context of a PHR. This is also highly linked to “Provider Registries” that can be used to find a provider for treatment. And this is highly linked to “Directories” that are used today in the operational setting to manage user accounts for healthcare applications as well as other business applications (yes healthcare is a business and users need to do things besides use the EHR). Again a Federated approach is needed. The reason here is different than for Patient Identities. There is already a federally issued identity for Providers, NPI. This does not address all the ‘users’ of a Health Information Exchange; that is the P and O in TPO. Further there are many ‘users’ in the Treatment side that would not be issued a NPI.
  Former Posts on the topic: Federated ID is not a universal ID 

2) Secure by Design. I am worried that there is such a rush to carry on with point-to-point links without thinking through the security and PRIVACY issues that this would raise. I participate in standards, profiling, and government initiatives because I want to build security into the architecture, not bolt it on later when success accidentally happens. I attribute this to the false perception that if we let the security guys in to the discussion up-front they will slow us down and make the system non-functional. There is very good excitement around the medical advantages of sharing healthcare information. The Security geeks must not be pushed aside; we MUST push our way back into the discussion. And when we push our way into the discussion we must NOT prove ‘them’ right. Designing in Security does not need to be a problem. Use a RISK based approach, and Keep It Simple and Secure (KISS).

Former Posts on the topic: IT security problems continue, What has HITSP done to protect confidentiality with a suite of implementable security standards,  Implementing standards takes time. 

• A sub-theme here is abuse of de-identification. This is a method of LOWERING risk, it does not eliminate risk. ONC to test re-identification of protected data, De-Identification is highly contextual, How Private can Electronic Information Ever Be?

3) Accounting of Disclosures. This very important part of patient-centered-healthcare needs to be discussed more than it is today. There are many bad ways to implement this, as in assuming that it can be generated on-the-fly ala a security log. I suspect that the requirements today are not even meeting the need, especially in the USA. I expect that over time this topic will morph into something far more useful to the patient and less frightening to the healthcare organizations. I expect that we will learn much from the likes of Facebook/Twitter/YouTube/etc, yet will also have our social norms educated. ATNA and Accounting of Disclosures, Patrick Pyette: The Case for Privacy Accounting

4) Privacy Policies. I put this one in at #4 of 3 because I have little faith that this is solvable in 2010. There are simply too many divergent views on Privacy Policies.  IHE took a brave move in creating BPPC, a profile that simply provided a basic framework for indicating that a patient has agreed to a policy. No details about the policy are given except for it's unique identifier. HL7 is now extending this concept with a mechanism to add variables to the policy so that the content of the policy can be customized by each Organization-Patient pair. This customization is going to take a while to work out. This will be useful, but will take another 5 years before one could say that it is mature enough to implement. Consumer Preferences and the Consumer, Opt-In, Opt-Out.... Don't publish THAT!, RHIO: 100,000 Give Consent.

IT security problems continue (Designing a Secure HIE)

A new articile “IT security problems continue” is one of many articles that seem to hint that Healthcare IT, EHR, PHR, and all of the Healthcare Internet are stalled because of IT Security Issues. Yet Nowhere is there an list of these Issues. This article points at a press release “Hacker Attacks Targeting Healthcare Organizations Doubled in the 4th Quarter of 2009 according to SecureWorks’ Data” by a security vendor “SecureWorks”.

Actually the security vendor press release is more informative than the ‘news’ article. The press release is pointing out that based on statistics that they have from their customers, attacks on healthcare have increased where others have not. This seems to indicate an intentional shift in the attacker community.

SecureWorks®, Inc., a leading global provider of information security services protecting 2,700 clients worldwide, reported today that attempted hacker attacks launched at its healthcare clients doubled in the fourth quarter of 2009. Attempted attacks increased from an average of 6,500 per healthcare client per day in the first nine months of 2009 to an average of 13,400 per client per day in the last three months of 2009. Attempted attacks against other types of organizations, protected by SecureWorks, did not increase in the fourth quarter. More

This vendor then goes on to advocate for “Defense-In-Depth”, and implementation of the kinds of services that they offer. All good ideas. What they don’t cover is some architectural solutions that can be put inplace.

The concern that people are having with Healthcare IT movement today is that this is an effort that will connect many healthcare organizations to each other. This connection can be done the way it is today with point-to-point solutions. This kind of a solution means that each connection between two organizations requires that one of them open up a hole in their defenses, and sometimes can mean both must open up.

The alternative architecture that I have been advocating for, due to my involvement, is the model around an XDS based HIE. In this model each healthcare organization will be making outbound connections to some common infrastructure, and only needs to have one inbound connection. There is a central set of services (Registry, PIX Manager, PDQ Manager, Audit Record Repository, Time Source, and XCA Gateways) that do need to be highly protected.

These central services are critical, but contain very minimal healthcare information as they are focused on different types of indexes and cross-references. In all cases IHE has also provided in the ATNA profile a way to highly-authenticate both sides of any connection and protect all communications. Any hacker would be incapable of this authentication step, so would not be able to attempt other secondary attacks like SQL injections. This is also true of the potential inbound connection to the healthcare organization to give access to the high-fidelity documents in the Repository (this could also be outsourced for the really small organizations).

As an architecture the XDS family has other Privacy and Security benefits that are beyond this core approach. These are nicely outlined in an IHE white paper on Security and Privacy in an HIE

Security/Privacy comments on the IFR

I have submitted comments through a couple of different organizations that I am honored to be a part of including HIT-Standards Privacy & Security Committee, EHRA, HIMSS, and GE. I have vented on my blog, given advice to implementers/providers, and commented on CCHIT comments. Now I reproduce my comments on the  IFR (Bookmarked).

The modularity mechanism:

The modularity mechanism is important for separation of clinical/quality functions, but causes difficulty with regards to security and privacy. Security and Privacy are cross-cutting requirements that can only be evaluated when a complete system is brought together. In some cases of modularity the software module really has no security/privacy controls as it is relying on the platform and integration. An example of this is a software component that is plugged into a CCOW, Web-Service, or Browser-plugin. These software components can and do rely on their environment to provide the necessary security functionality. In other cases of modularity the software component needs to take responsibility for some of the security functionality, such as audit logging while leveraging the platform to provide access control and secure communications. In these cases of modularity the software component (module) can state how the component leverages these platform capabilities without providing the capability it-self.

Security must be applied and evaluated on a complete system. Any portion of a complete system can present security holes. Modules can be designed to be securely assembled into a complete system, this requires that they be designed with a specific security expectation. When modules are certified, they should not be required to meet specific technical requirements, but rather be required to explain how they are to be securely assembled into a complete system. This allows for web-applications to explain their expectations of the web-server environment and such.

I recommend that this modularity be recognized by requiring that modules declare how they address security/privacy, rather than placing technical requirements upon these components.

Goal of Requirements are unclear:

The criteria are conflating functional, interoperability, and operational requirements. This causes confusion on who is responsible to meet the requirements. That is to say that there are requirements listed that are much more efficiently implemented operationally through the assembling of common hardware, operating-system, and IT-software. In these cases the solution is totally transparent and fully encompassing of the ultimate EHR technology used. These Organizational solutions are flexible and scalable. These Organizational solutions are driven by a Risk Assessment such as the one already required by HIPAA.

There are times when an Interoperability solution should be imposed. In these cases the solution needs to be specific to assure interoperability, yet flexible to allow Operational choices beyond the single interoperability solution. A good example of this is the Mutually-Authenticated-TLS-using-RSA-3DES-SHA. This is a very specific solution so that it assures that all vendors can interoperate in at least one way. But it is also flexible in that it is only imposed as a ‘capability’. Thus Operationally a provider can choose to rather use a VPN at a lower level and thus NOT use the specified technology.

I recommend that the security standards should be specific to Interoperability so as not to get in the way of Interoperability, and therefore be specific to capability to at-least do XXX. This does not constrain operational use.

Specific Requirements

• §170.210 (a) - Encryption and decryption of electronic health information
• The biggest problem here is their lack of standards references, thus anything can qualify as encryption (e.g., XOR with a 128 bit fixed key that is simply appended to the data).
  
• Although the regulation text does not specify "AES", the specified bit values are only supported by AES. 
• AES is not supported in older versions of Windows, which are very commonly used in business especially in Healthcare (i.e., Windows XP, NT, 2000)
• FIPS 140-2 Annex A allows for 3DES or AES, so there should not be a mandate in the IFR that is more restrictive than FIPS 140-2. 3DES is widely available.
• It is unclear to what this encryption is to be applied. Many encryption solutions are provided by the platform (transparent hard-drive encryption, encrypting USB-Memory, S/MIME or PGP email) or network (VPN). These solutions are very effective and do NOT require that the EHR technology be aware of the technology. By placing an encryption requirement on the EHR technology, this IFR is proposing that the EHR solution provider involve themselves in a way that removes flexibility currently available to an operational environment.
• The goal of the item is unclear. For transport encryption it is important that both the sender and the receiver are using the same technology. Thus 'interoperability' is important. For interoperability to function a standard must be selected and assured that all involved can at-least support that standard. This 'at-least' qualifier does not constrain the operational environment to that standard, but does enable at-least one way of communicating securely. I presume that Interoperability is the driving force throughout the IFR and thus the security requirements are targeting 'secure interoperability'. 
• The IFR does not specify end-point authentication. It is only through mutual authentication of both end points of a network communications that a system can be sure that it is talking to an authentic and authorized (trustable) system. 
• To place encryption on all network communications would be burdensome. Many network communications are within the organization where isolation techniques can mitigate risks effectively.
• To place encryption on all data-at-rest would be burdensome. Data-at-rest in a secure server room would be burdensome and not mitigate any risks as the servers in the room are not likely to be stolen. Data-at-rest on a portable device like a USB-Memory stick is far more likely, but can be mitigated through proper selection of USB-Memory devices that include encryption technology and are thus transparent to the EHR technology.
• It is understandable that the encryption requirements could be applied to the Meaningful Use workflows that ‘export’ or ‘import’ individually identifiable information. The concern I have here is that there are limited standards to support this, and often times the solution can easily be added-on as a transparent hardware solution or software solution. There are few standards for portable encryption, and thus should not be imposed on the certified EHR.
• It is understandable that encryption may be applied to portable devices such as laptops. Where the certified EHR is hosted on Provider hardware, the encryption of the portable device can be supported transparently with hardware or software solutions. 
• The encryption requirements should NOT be applicable to devices/systems that are physically secured or secured through access controls. These physically secured systems are not likely to be lost or stolen. This will eliminate unnecessary encryption of databases that are housed in a well secured location. 
• Encryption technology requires good key management. The specification lacks key management requirements. These techniques are typically built into network protocols such as TLS. These techniques are typically manual and/or proprietary for data-at-rest.
• The “User-Defined Preferences” is overly broad. There needs to be some expectation of reasonable user defined preferences. It would be completely unworkable to have user-defined preferences for different encryption requirements on a doctor-by-doctor basis.
  
  I Recommend:
  A) Specify that for network communications that cross the organizational boundary (e.g. HIE), that TLS be available with mutual authentication of both endpoints and that the encryption algorithm be at least 3DES with a recommendation that AES be made available.
  B) Do not specify any data-at-rest criteria as this is most efficiently and effectively handled at operational implementation.
  C) Please be clear that these are requirements for the product to be capable of meeting, and clearly differentiate from operational use.
  D) I like the CCHIT criteria
  
• SC 06.01.1 - The system shall support protection of confidentiality of all Protected Health Information (PHI) delivered over the Internet or other known open networks via encryption using the Advanced Encryption Standard (AES) and an open protocol such as TLS, SSL, IPSec, XML encryptions, or S/MIME or their successors.
• SC 06.03 - For systems that provide access to PHI through a web browser interface (i.e. HTML over HTTP) shall include the capability to encrypt the data communicated over the network via SSL (HTML over HTTPS). Note: Web browser interfaces are often used beyond the perimeter of the protected enterprise network
• SC 06.06.1 - The system, when storing PHI on any device intended to be portable/removable (e.g. thumb-drives, CD-ROM, PDA, Notebook), shall support use of a standards based encrypted format the Advanced Encryption Standard (AES).
  
  
• §170.210 (b) Record actions related to electronic health information
  
•  The Alert requirement is very difficult to meet in a complete EHR system, when modularity is added there is no way to coordinate Alerts. Recommend that the Alert requirement be deferred and made into a modular requirement that may be met by an audit record repository.
  
  I Recommend:
  A) The events be constrained to the minimal events that are related to HIE interactions.
  B) Future certification require the ATNA message/transport to those that are representative of the transactions that cross the organizational boarder (meaning they are subject to Meaningful Use). This would allow a mature EHR to not try to get all security relevant events into ATNA compliance (e.g. System startup, User Login, view of flow-sheet, etc).
  C) I like the CCHIT criteria: 
• SC 02.03 - The system shall be able to detect security-relevant events that it mediates and generate audit records for them. At a minimum the events shall include those listed in the Appendix Audited Events. Note: The system is only responsible for auditing security events that it mediates. A mediated event is an event that the system has some active role in allowing or causing to happen or has opportunity to detect. The system is not expected to create audit logs entries for security events that it does not mediate.
  
• SC 02.04 - The system shall record within each audit record the following information when it is available: (1) date and time of the event; (2) the component of the system (e.g. software component, hardware component) where the event occurred; (3) type of event (including: data description and patient identifier when relevant); (4) subject identity (e.g. user identity); and (5) the outcome (success or failure) of the event.

• §170.210 (c) Verification that electronic health information has not been altered in transit
• The requirement listed is a reasonable functional requirement, but the standard specified can not accomplish all of these functionality expected of it by Table 1.
  I Recommend
  A) that this be limited to transport of health information, where the Mutually-Authenticated-TLS discussed above would be the solution. B) I like the CCHIT criteria
•  SC 06.04 - The system shall support protection of integrity of all Protected Health Information (PHI) delivered over the Internet or other known open networks via SHA1 hashing and an open protocol such as TLS, SSL, IPSec, XML digital signature, or S/MIME or their successors.
   

• §170.210 (d) Cross-enterprise authentication 
• There is not sufficient implementation of the infrastructure necessary to support this requirement today.
• Today mutually authenticating both endpoints of a network communications to assure that systems only talk to other authorized systems is sufficient when procedures have proven that operationally these systems enforce the necessary access controls and log the necessary audit events. 
• The text would allow any method of carrying a user identity, presumably even a plain text string. 
• The user identity is often not enough to support RBAC or Policy enforcement. Additional profiling has been done by XSPA, NHIN, epSOS, etc. This is being brought together in an update to XUA this year by IHE.
  
  I recommend:
  A) The criteria should be delayed until 2013/2015 so that Providers can focus on developing the operational environment that can support identity assertions using SAML as profiled by HITSP/C19 and IHE/XUA.
  Note) This kind of requirement is missing from CCHIT as CCHIT recognizes that further profiling of SAML is needed beyond XUA/C19. This is spoken of in the IFR comments, but not in the regulation text.

• §170.210 (e) Record treatment, payment, and health care operations disclosures
• The 'description of the disclosure' needs to be made more clear. As with 'patient identification' and 'user identification', the 'description' should be allowed to be an object identifier that can be de-referenced in post-processing. In this way the real-time auditing of the events is kept minimal, the record in the log is accurate yet minimal.
• The security audit log should be focused on identifiers and not on descriptive values. These identifiers can be decoded in post-processing into descriptions, for example a user-ID can be looked up in the user-directory into the name of the user. This is especially true of the healthcare object that was accessed, as putting a description of the healthcare object accessed would be difficult in realtime and would make the security audit log it-self a record with PHI in it. 
• The security audit log contains many events that are not relevant to an Accounting of Disclosures, but it can be informative to an Accounting of Disclosures. Many of the security events may need to be combined to produce sufficient information to fully describe a recordable Accounting of Disclosures event. The security audit log can be post-processed into patient specific Accounting of Disclosure reports.
  
  I Recommend:
  A) Replace 'description' with 'description or identification'.
  B) The realtime audit log be focused on recording all security events without regards to if the event will be used in an Accounting of Disclosures.
  C) Account of Disclosures be clearly indicated as a post-processing task
  D) I like the CCHIT criteria 
• SC 02.03 - The system shall be able to detect security-relevant events that it mediates and generate audit records for them. At a minimum the events shall include those listed in the Appendix Audited Events. Note: The system is only responsible for auditing security events that it mediates. A mediated event is an event that the system has some active role in allowing or causing to happen or has opportunity to detect. The system is not expected to create audit logs entries for security events that it does not mediate.
  
• SC 02.04 - The system shall record within each audit record the following information when it is available: (1) date and time of the event; (2) the component of the system (e.g. software component, hardware component) where the event occurred; (3) type of event (including: data description and patient identifier when relevant); (4) subject identity (e.g. user identity); and (5) the outcome (success or failure) of the event.
• AM 30.06 The system shall have the ability to provide support for disclosure management in compliance with HIPAA and applicable law.
• (and others)

I do not think that CCHIT has everything right. But I must be forward about the fact that I spent years as co-chair of CCHIT Security workgroup getting these written well and testable.

Missing Requirements

If the certification requirements are to be complete set of functional requirements, then there are many requirements missing. In the early years of CCHIT I was co-chair of the Security Workgroup and lead CCHIT effort to define a set of comprehensive yet reasonable requirements for a secure Health IT system. These requirements have been very carefully crafted to not interfere with healthcare workflows, implementations, or the creativity of the EHR vendor.

In some cases these are requirements for specific documentation from the vendor. This is a good way to support the communications between the vendor and the operational environment. These documentation requirements ultimately force the vendor to think beyond clinical functionality and make declarations on security topics including such non-functional aspects as hardening the system to network attack.

Without these additional requirements I am concerned that the IFR will leave the false impression that a system certified to the criteria is secure. If these additional requirements are not also included then I would recommend that the security requirements be totally removed. The Operational environment is already required to meet the HIPAA Security requirements that are based on Risk Assessment and Mitigation. This is a far more comprehensive and reasonable approach.

I recommend that the other requirements found in the Security section of CCHIT be considered.

Privacy Consent


Totally absent is Privacy, not even opt-in or opt-out Consent. I think that BPPC can and should be used to enable OPT-IN in an XDS like RHIO (HIE/HIO). This is not to say that BPPC is the long term solution, but without an OPT-IN ability we will get nowhere on deploying the Health Internet. BPPC is 'good enough', and is a logical path toward something more advanced. HL7 is already working on that more advanced solution, and it is a logical extension to where BPPC is today.

I recommend that BPPC be used in HIE/HIO networks, which means that the EHR needs to be aware and honor the OPT-OUT or OPT-IN registered there.


Egregious Statements


The text on SOAP vs RESTful should be removed. It is not germane to the goal of the IFR. The current HL7 v2 transport required by other IFR sections are neither REST nor SOAP; thus the IFR is in conflict with itself. The specification of SOAP or REST would forbid the use of the most successful healthcare standard, DICOM. Please remove the SOAP and REST discussion, both are good solutions that should be built on when they are appropriate. Focus on specifying data transports that are optimal for their intended use and fully specified.

I recommend that all discussion of SOAP vs RESTful be removed.

IHE ATNA adjusts a little bit more

At the IHE meeting today we had a very interesting discussion of some unintended concequences of ATNA. Turns out the concequences were fully intended, but as 'systems' scale into highly networked systems the original mode is harder to conform to than it really needs to be.

When ATNA was originally concieved of, IHE was made up only of the Radiology Domain. At that time, even a RIS or PACS system was sold as a single system on vendor provided hardware. So at the time the concept of "Secure Node" seemed logical. That is, that the whole system needs to be secure before it should be allowed to communicate to other systems, and that all systems it talks to should also be fully secured. It is this network of trusted links between trustable systems that ATNA was making.

A few years ago the first problem with Secure Application was uncovered, as the ITI domain matured and we started to see more healthcare software that was delivered to the hospital/clinic. These products are not whole systems but rather software that gets installed into the hospital/clinic server farm. For example an application that is web-application. The server-farm is managed by the hospital/clinic and not by the healthcare software vendor. Thus the healthsoftware vendor had trouble declaring that it had control over everything happening on the hardware (with server-farms it is even hard to figure out what is the hardware). Thus was born the Secure Application.

Secure Application simplifies the ATNA requirements by allowing the vendor/supplier to define what their 'Application' is, showing that the application can't possibly be responsible for hardware centric events like 'boot' or 'shutdown'. The ATNA secure-communications requirements need to be applied to everything that crosses that Application boundary. The IHE Integration Statement describes the product in the header, and thus the customer knows by looking at the Integration Statement what the scope of the product is. Any of the ATNA security-relevant events that happen inside that Application must be recordable via the ATNA audit message/transport. And any access to individually identifiable health information are controlled by reasonable Access Controls. A side note is that a Secure Node is simply a Secure Application where the boundary of the Application is the physical boundary of the System that makes up the Node.

The discussion today was that with EHR like products that have very many network communications this 'secure all network communications that communicate PHI' becomes technically hard, and the customers have not really asked for inherently internal network communications to be secured. It should not be surprising that vendors will not develop functionality that customers don't ask for. This is a typical problem of security, since generally speaking customers still today don't ask for any security. It is still very important to indicate that the product has applied the secure communications requirements to transactions that cross an enterprise boundary. So we came up with the following solution:

1. We can't break older Integration Statements where indicating that the system has applied Secure Node or Secure Application means that they HAVE provided the secure communications capability to all network communications that communicate PHI.
2. Thus we need to create a new OPTION on ATNA that indicates that the product uses a NEW model for ATNA secure communications. Thus if this option is on the ATNA Secure Node or Secure Application this is an indication that the only network communications that have the secure communications capability will be highlighted.
3. This highlighting is done with another ATNA option that can be added to any IHE Profile/Actor. Therefore this option will indicate which Actors have the capability to use the secure communications channel.

This has the added benefit of dealing with another change proposal request to deal with Secure Nodes that operate only on protected networks and thus these products never need to support the secure communications. In these products case they can declare the option described in (2), and never indicate the option described in (3).

This will NOT change the requirement that within the context of the Secure Node or Secure Application that ALL accesses to PHI must be protected by reasonable Access Controls, and that ALL security relevant events must be audit-able using the ATNA audit message/transport.