Tuesday, May 31, 2011

US Audit of Healthcare security concludes that Meaningful use does not mean secure use

I could have told them that Meaningful Use didn't include core security needs, actually I did on this blog Meaningful Use clearly does not mean Secure Use. That blog post was January 2010, and is my 3rd highest hit article overall.

Executive Summary

The Department's Office of the National Coordinator (ONC) provides leadership for the development and nationwide implementation of an interoperable health information technology (HIT) infrastructure. ONC is charged with guiding the nationwide implementation of interoperable HIT to reduce medical errors, improve quality, produce greater value for health care expenditures, ensure that patients' individually identifiable health information is secure and protected, and facilitate the widespread adoption of electronic health records (EHR). 
Our review found that ONC had application information technology (IT) security controls in the interoperability specifications, but there were no HIT standards that included general information IT security controls. General IT security controls are the structure, policies, and procedures that apply to an entity's overall computer operations, ensure the proper operation of information systems, and create a secure environment for application systems and controls. At the time of our initial audit, the interoperability specifications were the ONC HIT standards and included security features necessary for securely passing data between EHR systems (e.g., encrypting transmissions between EHR systems). These controls in the EHR systems were application security controls, not general IT security controls. 
We found a lack of general IT security controls during prior audits at Medicare contractors, State Medicaid agencies, and hospitals. Those vulnerabilities, combined with our findings in this audit, raise concern about the effectiveness of IT security for HIT if general IT security controls are not addressed. 
We recommended that ONC (1) broaden its focus from interoperability specifications to also include well-developed general IT security controls for supporting systems, networks, and infrastructures; (2) use its leadership role to provide guidance to the health industry on established general IT security standards and IT industry security best practices; (3) emphasize to the medical community the importance of general IT security; and (4) coordinate its work with the Centers for Medicare & Medicaid Services and the Department's Office for Civil Rights to add general IT security controls where applicable. ONC concurred with our recommendations.
More
Both reports are available with the following titles:

  1. Nationwide Rollup Review of the Centers for Medicare & Medicaid Services Health Insurance Portability and Accountability Act of 1996 Oversight
  2. Audit of Information Technology Security Included in Health Information Technology Standards
An excellent summary is "Audit report hit HHS on digital security" by Joseph Conn
No comments:

IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion

With the growth of communications between organizations there is a strong need to provide user identity, role assignment, and other claims about the context of the communication. These transactions are happening between different organizations that are otherwise competitors, and thus not likely that they will be able to agree on a centralized user identity system like EUA. This communications between organizations is the space that the Cross-Enterprise User Assertion (XUA) profile fills by using Federated Identity.

The initial use-cases that drove the creation of XUA is the Health Information Exchange built on the XDS and XCA profiles;  A Health Information Exchange model using a Discover and Retrieve exchange model needs the user identity inside the query or retrieve transaction to assure that the organization holding the data can get a detailed audit log and could enforce policies through access controls.

This diagram shows a typical implementation of an EHR (in white) accessing an HIE based XDS Registry (in black). The XUA Profile provides the orange functionality: X-Identity Provider creates the SAML Assertion given the User Authentication identity and EHR security context, the X-Service User inserts this SAML Assertion into the normal XDS Query Transaction, and on the XDS Registry the X-Service User (not shown) uses the SAML identity and includes that identity in the Audit log.

The XUA profile is not limited to clinical users, it includes use-cases where the patient is participating in a Health Information Exchange, for example this diagram is identical for a PHR as a peer on the HIE. The XUA profile is also not limited to XDS profile, but is generic to Web-Services and thus can enable any  Web-Services transaction.

The XUA profile is a very thin profile that simply indicates that the SAML 2.0 standard includes a specification for an identity Assertion. These SAML Assertions are self-contained XML objects that can contain claims about the identity, attributes about the identity, and claims about the context.

The XUA Profile explains how to add a SAML identity assertion to a Web-Services (SOAP) transaction, in this way the XUA profile can be used to enable any Web-Services transaction. The method of adding SAML assertions to Web-Services is well known and already profiled by the WS-I, a general IT industry consortium that do profiling.  The SAML protocol does include transactions for retrieving and validating SAML assertions, but IHE recognized that these protocols are not the only legitimate way to obtain a SAML assertion for example the WS-Trust standard is more commonly used.

The XUA profile has had a few additional use-cases added to it as named options.
  • User Role -- To support Role Based Access Control
  • Consent / Authorization -- To support use-cases where the requesting party has explicit consent that they want to point at to assist the service
  • Purpose Of Use -- Carry an indicator of what the reason for the transaction is and what will be done with the result
The SAML assertion does not carry a simple attribute, Level Of Assurance, such as described in NIST SP800-63 “Electronic Authentication”. This is because although the NIST specification identifies 4 levels there is still a need for specific Policy and Vocabulary definition.  The SAML assertion does carry an identifier of the method that was used to authenticate the user, outlined by oval in this diagram. From this identifier, of the method used to authenticate, the relying party can determine the relative Level of Assurance in the view of the relying party organization. The future might provide a Level Of Assurance vocabulary, but we don't have this right now.

Resources
Additional Comments
XUA - Very thin profile that simply says to use SAML Identity Assertions for authenticating users on Cross-Enterprise transactions

No comments:

Monday, May 30, 2011

IHE - Privacy and Security Profiles - Enterprise User Authentication

The oldest of the IHE Security Profiles is still a useful and foundational one. The Enterprise User Authentication (EUA) Profile addresses the issue of user authentication for the multitude of users in healthcare: a doctor, nurse, technician, etc; across the multitude of systems they need to login to; and in a way that does not result in 'post-it' notes plastered all over the computer screen.

The use of a single user authentication across a hospital or clinic would simplify the user experience as they would then only need to remember one username and password, thus 'single sign-on'. Given that in healthcare the users tend to need to use many different systems, the only way to get single sign-on is to have all systems use the same standard for user authentication. If this is not coordinated centrally, the users will simply use the same password at all systems; resulting in poor password handling. The solution is the IHE EUA profile.

The EUA profile doesn't just enhance the user experience, but it also enhances the overall security of an organization as it enables much quicker provisioning of user accounts when someone is added, including in catastrophic disasters, but it also enables the quick disabling of user login when someone is suspected of wrongdoing. The single user account also simplifies audit log analysis as it is easy to see all the events that a specific user caused.

The EUA profile needs to support many different platforms, as there are many different systems used in healthcare (EHR, X-Ray, Ultrasound, EKG, etc). The workflows in healthcare systems and applications tend to  to be different than a desk environment. There is a  need to enable workflows such as an exam-room where the registration clerk brings the patient into the room, thus needing to setup the patient on the EHR but clearly needing to logout when leaving. The nurse then arrives to take vital measurements and interview the patient, thus needing to login to the EHR but eventually also logout before leaving. The doctor then continues with the workflow. This workflow is Patient centered and thus the typical desktop login session would be very cumbersome, and slow. Thus the login workflow is radically different, but still needs to be secure.

The solution is to point at the Kerberos protocol. This protocol is very well suited for use within an organization and at the time had been successfully integrated into the Windows platforms as the default authentication. This protocol had been a stable user authentication model in Unix and Linux for decades. Therefor the choice was not a hard one for IHE to make.

The kerberos protocol is commonly used for authenticating users via password, and has a strong protocol for assuring that the password is correct without exposing the password.  The protocol is not specific to passwords and could be used with a pluggable authentication including tokens, biometrics, and smart cards. These technologies however do require pluggable software and hardware which is not fully defined in the Kerberos standards realm.  The user authentication step is the first transaction of the EUA profile. The EUA profile, because of Kerberos requirements, does require that the Consistent Time profile is used to keep all systems relatively synchronized to a time source.

The EUA profile and Kerberos are not just about user authentication, but also support methods of passing the user identity to services in a secure way. This functionality is what the second and third transactions are used for. Once the user is authenticated using a Kerberos Authentication Server, the Client Authentication Agent can request "Service Tickets". These Service Tickets can then be passed to a Service that supports Kerberized Service actor in a way that the Service can trust and use the identity. This Kerberized Service functionality is defined for Web services using Kerberized HTTP Authentication. Other transactions can also be defined as to how they can use Kerberos Service Tickets, the IHE Retrieve Information for Display (RID) profile uses this grouping for user identity.

References
  • Status: Final Text
  • IHE ITI Technical Framework
    • Vol 1: Section 4
    • Vol 2a:  Section 3.2, 3.3, 3.4
  • Standards Used
    • Kerberos v5 (RFC 1510)
    • Stable since 1993, 
    • Widely implemented on current operating system platforms
    • Successfully withstood attacks in its 10-year history
    • Fully interoperable among all platforms
Additional Comments:
EUA - Very thin profile that simply says to use Kerberos protocol for safely authenticating users

  • Kerberos is a pluggable protocol, but really is only used for username/password
  • Kerberos is the standard that Windows ActiveDirectory uses for authenticating users.
  • Kerberos is the standard that Windows uses at windows login (with minor Microsoft extensions)
  • Kerberos is very common in Unix as it was invented at Berkely
  • Kerberos is really good for within an organization, but has real problems that prevent it from being useful on the internet
  • There are also Kerberos ways to pass authentication 'tickets' between an application and server
  • See: Kerberos required in 2011 then forbidden in 2013
1 comment:

Sunday, May 29, 2011

IHE - Privacy and Security Profiles - Audit Trail and Node Authentication

This is the prime security profile in the IHE toolbox. Prime in so many ways, but it wasn't the first. The Audit Trail and Node Authentication (ATNA) profile is composed of three things.

The first part of ATNA is not found in the name, that is that the profile expects that the system functionally includes reasonable access controls. Because this is a functional requirement, IHE doesn't further define it. This has more to do with the purpose of IHE than the need. The expectation is that product suppliers will do the right thing, and that operational environments will inspect their systems before they grant them network access. The other two parts of ATNA: Audit Controls and Network Controls will be further explained below.


The Actor/Transaction diagram looks complex, but it isn't as complex as it appears. The diagram includes the actors from the Consistent Time profile. The diagram complexity comes from the practical fact that our original Actors were more monolithic and reality is more plug-and-play. IHE had originally defined a Secure Node as complete hardware and software system that is considered in whole to be one, although it may be made up of multiple computers, but it is one distinguishable system.
Examples:

  • MRI – made up of many components and computers, may even be made up of discrete physical cabinets
  • EHR – whole system considered as one including all workstations and supporting servers
  • EKG device – single small medical device

The concept of a Secure Node is ultimately the configuration desired, but we had to recognize that software components and services are being developed and they need to be responsible for what they control. Thus IHE had to define Secure Application – a software component that is expected to be integrated into a larger system. Where this software component is responsible for securing any communications it is controlling, initiating, receiving; responsible for any controlling access that it is responsible for; and responsible for logging any security events that it is in control of. This means that a Secure Application is simply not responsible for something that is out of it’s control (for example: auditing of the system startup event, or user-login event) Example:

  • A network service, such as a eMPI, that requires to be integrated into a database farm
  • A software application that must be installed onto a workstation

The other Actor shown is  the Audit Record Repository – Receives the Record Audit  Event transaction. A system implementing this actor will typically process, report, record, alert, forward, and in any other way process the security events. More on this later.

Secure Nodes and Secure Applications are expected to use secure communications, specifically the "Authenticate Node" transaction. This transaction is not really a transaction but an augmentation of transaction in a way that both sides of the transaction can be assured of mutual-authentication, and that the communications between them are protected against risks to confidentiality and integrity.  The easy part of this to understand is that the network communications is encrypted. The thing that I usually need to emphasize is that this communications is mutually-authenticated. 
On the Internet we are getting use to using a web-browser to connect to a web-server, normally this has no security. For sensitive sites we are using HTTPS, which adds authentication of the server and encryption. This would mean that the browser user knows which server they are connecting to with high assurance (not as much trust as you would think). But the problem with this model is that the web-server has zero knowledge of the client. For healthcare we want to not only make sure we are connecting to the server we wanted to connect to, but the server wants to make sure it is only connecting with clients that it can trust. It is this client authentication that is special, and allows for a trusted network to develop.

The most simple protocols profiled in ATNA is Transport Layer Security (TLS). This is what is otherwise referred to as SSL. The difference is that TLS is defined in an IETF standard, where as SSL is defined by Netscape. Ultimately they are now the same, and advancements are being made to TLS. TLS has advantages that it is very easy to deploy, has built in protocol negotiations, built in certificate discovery, and is built into many toolkits and platforms. 
Sometimes other configurations are called for, so IHE ATNA also recommends end-to-end security with Web-Services Security, and S/MIME for e-mail. In both of these cases the certificate discovery and management is not automated, thus they are more complex to deploy.

Audit logging is the final component of the ATNA profile. The idea of the Audit logging in ATNA is that ultimately the use of an audit log is a specialized functionality that needs to have all events that happened on all the various systems in the organization. This is a specialty that has been developing in the general IT market around Firewall, Intrusion Detection, Routers, Databases, and Operating system audit log analysis. Given that specialty exists, we felt it was better for healthcare specific products to simply note that a security relevant event happened and send the details off to an Audit Record Repository for this analysis. So we followed the general IT market architecture. Here is some history and the relationship of the standards:
  1. ASTM E2147 – Setup the concept of audit logs for healthcare including accounting of disclosures
  2. IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
  3. DICOM Supplement 95 – Made the information model Normative, defined Vocabulary, Transport Binding,  and Schema
  4. IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
  5. NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
  6. HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
  7. ISO 27789 – is defining the subset of audit events that an EHR would need 
The goal of the Audit log is to support security surveillance to look for abuse of policy, abuse of systems, and to inform an accounting of disclosures. The ATNA audit log is not intended to be used to track changes made to the medical records, this would be the responsibility of the medical records systems.

This diagram shows a use-case where there are multiple Audit Record Repositories distributed across an XDS environment. This would be a common configuration where each organization in an Health Information Exchange (HIE) has decided to maintain their own Audit Record Repository independent from the HIE. In this way the Audit Record Repository in any one organization would manage the audit log entries for that organization and would forward copies of any audit log entry that is a result of a transaction with the HIE (the dotted orange lines).

A good example of why this is important is the basic XDS Document Retrieve transaction. If this transaction does not force an user assertion (discussed later) then the Document Repository can only record the document unique ID that was requested and the system identity that requested it. This is not enough information for the organization hosting the Document Repository to fully report an account of disclosures, but is sufficient information to trace the specific event back to a specific Document Consumer system where the further details can be found.

When this transaction includes an XUA assertion the audit log on the Document Repository would include the user identity and likely purpose of use, but would require extra processing to determine the patient (this extra processing could take place during the transaction, could be known through other means, or could be looked up during audit analysis and reporting)

References:
  • Status: Final Text
  • IHE ITI Technical Framework
    • Vol. 1 - Section 9
    • Vol. 2a - Sections 3.19, 3.20
  • Standards Used
  • “Security Considerations” section found in other Profiles may specialize how ATNA is applied
  • The Audit Event Message typically specialized in Vol 2 at the Transaction level
    • PIX QueryTransaction : See section Vol 2a:3.9.5.1
    • XDS Register Document Set-b: See section Vol 2b:3.42.7.1
Additional Information:
ATNA - This is a comprehensive profile that indicates that Access Control, Audit Control, and Network Controls are important

  • Access Control
    • There is no standards pointed to by ATNA here. There is simply a statement that a system needs to have access controls that can be shown to a local authority are sufficient to protect the systems resources according to the local policies
    • If this can't be demonstrated, then the system should not be authorized to be used. Specifically it should not be given a network identity (see network controls)
  • Audit Controls
    • Specifically Security Audit logging
    • This is a very thin profiling of the commonly used SYSLOG protocols for communicating that an auditable event has occurred
      • There is statements that relax size limits
    • This is a FULL PROFILE of the content of that auditable event into an XML encoded message
    • There is a set of 'auditable events'. That is events that when they happen an audit log should capture what happens
    • The audit log message is fully describing: Who, What, Where, When, How, and Why.
    • This requires that the audit event time be kept consistent. Which is why the CT profile exists. The CT profile says use common NTP protocol to keep clocks synchronized to about 1 second, which is generally good enough for security audit logs
    • See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures
  • Network Controls
    • There are a set of standards specific to the type of network communications. They all address three aspects of network communications of protected information. Not all network communications are protected, for example DNS is not generally needing to be protected as it is not communicating protected information (mostly)
    • Authentication of both sides of all communications that include protected information
      • This is consistently done using machine/service-end-point identities using public/private keys (certificates)
      • Certificates can be directly trusted. One-by-one
      • Certificates can be trusted because they 'chain' to a known authority (certificate) that is trusted directly
      • Caution: the method used on the internet with SSL certificates is technically the same, but not administratively the same. In the internet browser world the 'known authorities that are trusted' are authorities that your internet browser decides should be trusted.
      • ATNA wants a deliberate decision of trust to be done, not a decision by a vendor.
    • Encryption of the communications that include protected information
      • AES is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least AES needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
    • Integrity control of the communications that include protected information
      • SHA1 is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least SHA1 needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
      • Note also that the communications is transitory, not long-term-storage, so the use of SHA1 is acceptable. SHA1 tends to not be acceptable for long term signature (See DSG below)
    • TLS is the general mechanism when no other mechanism is used. TLS is the 'standardized' protocol that is more commonly called SSL. (mostly)
      • IHE profiles that BOTH sides of the communication need to be authenticated
      • Whereas common SSL only authenticates the server. This is not sufficient as it allows any client to connect. In healthcare we want to know where the data is coming from and where it is going. Not just the server
    • S/MIME is used for e-Mail
    • WS-Security mechanisms are allowed for Web-Services that want to use end-to-end security. Note that none of the IHE profiles leverage this as they are all profiles defining endpoints that need access. But this is specified because there may be deployments where someone puts in the middle of an IHE transaction some form of intermediary that needs partial access
    • See Also
  • Open Source Implementations
1 comment:

Saturday, May 28, 2011

IHE - Privacy and Security Profiles - Consistent Time

This Profile is one of the most simple profiles in the IHE toolbox. Indeed it should take absolutely no development by anyone as the protocol has been incorporated into operating systems since the early 2000s. Windows XP enables it by default and connects to the internet to get the time. This is similar with the various flavors of Linux as well. This need to have a reasonably synchronized clock is universal and not specific to healthcare. But in IHE we leverage this profile in a couple of ways. First ATNA (defined later) profile leverages the Consistent Time profile to assure that audit logs are all timestamped with a comparable time-stamp. In this way a security officer can look at the audit logs coming from different machines and be able to know which things happened at the same time, which things happened first and what happened next. This profile is also used by EUA (defined later) as it is important to the authentication protocol that the client, authority, and servers all have a clock that is pretty closely synchronized. This profile has been leveraged in Patient Care Devices to assure that events that are recorded by medical devices have a reasonably accurate clock, and identify some use-cases where higher accuracy is needed.

The profile simply shows some of the use-cases and indicates that the Network Time Protocol (NTP) with it's simplified Simple Network Time Protocol (SNTP) be used. There really are no restrictions on these protocols, besides some emphasis of things that the standard it-self says.
One should note that this Profile does not say what system must be a time source, it is possible that a large hospital wants to run their own isolated time-clock. Another organization may choose to utilize one of the time-sources on the internet such as pool.ntp.org (see http://www.pool.ntp.org/en/). Although the concept is simple, the practice of actually keeping clocks synchronized even within 1 second is quite complex.

Resources

Back links

No comments:

Friday, May 27, 2011

IHE - Privacy and Security Profiles - Introduction


Update: The recording of the webinar is now available.

This summer I will be presenting the IHE (Integrating the Healthcare Enterprise) Security and Privacy Profiles. I have been putting together the slide deck for the Privacy and Security Overview. The purpose of the webinars is not to educate an engineer on the technical details, but rather to give an overview of the profile and what it can do. I now have version 6 up for the committee review, so I figure now is a good time to 'practice' giving the webinar. So, I will give the presentation on my blog, well kind of. This will take almost a dozen posts, so be patient and you might see all of the presentation. I also hope that while doing this I will uncover problems with the slides, so please feel free to ask questions so that I can help you understand and make the presentation better.

When I finished the first draft of the presentation, keeping just to overview material, I had well over 60 slides. Given that webinars typically have 45 minutes of material and 15 minutes of Q&A; we decided to break this into two parts. Part 1 covers basic security, while Part 2 covers advanced topics and privacy controls. In this blog post I will stick only to the "Overall Security and Privacy Controls"; which is an introduction to the space of Security and Privacy.

IHE produces Interoperability Profiles, they don't produce service specifications, application functional specifications, system design, organizational plans, or physical controls. This means that the scope of what one will find in an IHE profile is very limited to the kinds of things that are needed to (a) Enable Interoperability, and (b) Protect that Interoperability mechanism from Security Risks. The result is that you will not find any advice from IHE on things like: user interface, anti-virus, patch-management, door locks, room layout, spam protection, or Policies. These things are very important, they just are outside the scope of IHE.

Before any technology can be applied to enforcing Security or Privacy, an organization must define the Security and Privacy Policies that they are going to need to enforce. The Profiles from IHE are designed to be policy agnostic, meaning they can enforce almost any policy. In this way there is no constraint to implement a single policy.

These policies are built up of many layers of external policies. Starting with the highest level policies in the International community, such as the Organization for Economic and Co-operation and Development (OECD). This highest layer should also respect human rights, ethics, and norms.

The next layer down are those of the country, such as HIPAA in the USA, EC95/46 in Europe, and Act 57 in Japan. The next layer is those policies from the specific industry domain, in this case Healthcare. Some of the sources for this layer comes from the country, but they also come from medical professional societies. And finally the Enterprise needs to consider good organizational policies such as backup and recovery policies. Recognize that these different policies up-down and side-by-side can conflict with each other.

This is clearly an overview of all the potential influences on policies, but the important thing to take away is that policies must be created and written before technology is discussed. This is not to ignore the very fact that sometimes technology limits the policies, such as we will get into later in this presentation around Privacy Consents.

Security is best approached using a Risk Assessment model. That is to determine the risks to security; that is risks to Confidentiality, Integrity and Availability. As part of a Risk Assessment the Risk level is measured in terms of a combination of the likelihood of occurrence (probability) and degree of impact (positive or negative) of an anticipated event. Imagine a “hole in the roof” scenario, the risk is that weather (the threat) could cause damage to components inside the building as well as the building itself. As long as the weather report shows that there is little chance of precipitation, our risk level is low. However, this risk increases as the likelihood of precipitation increases. Since we cannot control the threat of precipitation, we mitigate our risk by changing the vulnerability; we fix the hole in the roof. The cost of fixing the vulnerability is much less, in this case, than the damage rain or snow would cause.

a)Examples of Threats -- natural disaster, random accident, disgruntled employee, employee snooping, external indiscriminate hacker, external motivated hacker, external highly motivated and highly funded)
b)Examples of Vulnerabilities – access without user identification, access without user authentication, user accessing data that they don’t need to know for their job, open network interface,
  • Likelihood is an assessment of how likely that threat is going to exploit that vulnerability. Typically a gross assessment of High, Medium, and Low 
  • Impact is an assessment of how much damage (harm) would result if that threat exploited that vulnerability (regardless of how unlikely). Typically a gross estimate of High, Medium, Low 
  • Prioritization uses the combination of Likelihood and Impact to assure that the most important things are addressed first and that appropriate resources are applied (e.g. make sure the remedy matches the risk)
Another thing that varies from organization to organization is the policy they apply to accountability. There are two different types of accountability models that usually are mixed.

In the Access Control Model the users are simply prevented from doing anything that they should not do.

In the Audit Control Model the user is empowered to go beyond what they are minimally to do for their job, because there are situations where they may be called upon to do more.

For example where doctors should only access the patients records that they are assigned to, but are given access to all patients so that they can more quickly assist with a consult, urgent care, or even an emergency.

In healthcare there is typically a mixture that is more Audit Controls centric. In all models, the janitor is still prevented from seeing clinical data as there is no reasonable expectation that the janitor will ever need to. It is this flexibility that drives standards to be capable of handling either extreme as standards must function in any of these environments.

This table is going to be used across the presentation, it shows how the IHE Security and Privacy Profiles affect the security and privacy domain. Where a check-mark is shown there is a strong contribution by the Profile and a dot represents a minor contribution (or supporting relationship).

Most of these Profiles will be further discussed in this presentation. PWP and HPD are discussed in a different webinar. Document Encryption is not yet final so is not yet discussed in the webinar series.

  • Which profiles should we use to prevent the wrong people from looking at PHI? 
  • Which profiles would you use in an investigation of a potential incident? 
  • Which profile would give you strong assurances that a document hasn't been modified? 
  • Which profiles would inform an accounting of disclosures

Back links
This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:
The recording of the webinar is available too
No comments:

Wednesday, May 25, 2011

Introduction to IHE impact on Meaningful Use

I was asked to present at the 12th International HL7 Interoperability Conference. All of the final presentations and papers are now available on the HL7 Web site. The topic I was asked to cover is to introduce IHE (Integrating the Healthcare Enterprise) and provide input on how IHE contributes to Meaningful Use. The simplified message is quite easy:

  1. Profiling (documentation that focuses on a use-case, specifying the standards to use and the constraints on the standards)  is an International need that IHE and Continua are addressing: 
  2. IHE is increasingly adopted world-wide (see Where in the World is XDS and CDA implemented)
  3. In the context of the stage 1 choices there is consistency in many area. Going forward, in Stage 2, IHE is consistent with DIRECT and can bring the most robust and already implemented solution that address the needed use cases deployed approach to point-to-point, HIE and NHIN Exchange.
A slide that I spent a good bit of time on, as many don't realize how formal the IHE process is.
  1. Use-cases are submitted from any interested party. These must be justified and go through a priortization process to pick the few that will be worked on
  2. The use-cases are then decomposed into the abstract actors and abstract transactions, and available standards are identified. This results in the Public Comment
  3. After Public Comment the Profile is further developed into the technical specification that goes out for Trial Implementation.
  4. Trial Implementations are used by developers that bring their solutions to the Connectathon. This tests both the software implementation, which must show interoperability with two other independently implemented solutions. The result tends to also uncover issues with the Profile text, what IHE calls a Change Proposal. Once a Profile has been proven at Connectathon, then it gets frozen in the Final Text phase. No breaking changes are allowed once a Profile enters Final Text. This is also when the Profile gets translated into the formal documentation publication form of the Technical Framework.
  5. Those products that pass Connectathon are allowed into some form of trade show demonstration, with HIMSS being the big one for the IHE ITI committee. These demonstrations leverage the capabilities provided by the Profiles implemented in as close to a real world setting as possible.
  6. Products are expected to publish an IHE Integration Profile as a statement of their products capabilities. This is a binding statement that they are expected to back through fixing any issues of non-conformance found.
  7. The result of this is that products are available in the market space that are easy to identify their capabilities through the IHE Integration Statement, and have proven them-selves at Connectathon
  8. Ultimately the result for everyone is better Interoperability. The Providers participate through offering up problems to solve, and by agreeing that they want the solutions. The Vendors participate through working through a solution and implementing it because they have assurances that the solution is desired. Both sides win.
The other slide that I think really says a great story in pictures is the one showing the Health Information Exchange Transport options. The message here is that there are 5 different patterns to a Health Information Exchange, shown across the bottom:
  1. e-mail Push of a document without metadata
  2. e-mail Push of documents with metadata to enable automated processing (XDM)
  3. Web-Services Push of documents with metadata between automated systems (XDR)
  4. A Community Exchange using Publication and Discover/Retrieve (XDS)
  5. Multiple Communities Exchanging using Discover and Retrieve (could be XDS or proprietary source)
In each of these there is a richer and richer capability, but there is also a common use of Documents as the objects and a common definition of metadata to describe these Document objects.

This was a fun experience and I really enjoyed the other presentations. I encourage everyone to review all the presentations and papers that are now published on the HL7 site.
1 comment:

Tuesday, May 24, 2011

A broadly usable HIE Directory

The HIT Standards Privacy and Security committee was given the task to pick 'standards' that would support the use-cases of an Entity Level Provider Directory (ELPD). This is a directory that has information about a healthcare organization, entity. We knew that a Individual Level Provider Directory (ILPD) is going to be needed, and asked for directly following the completion of the ELPD. Thus we considered the ILPD while evaluating the ELPD. It seems this forward looking was a bad idea in the minds of the larger HIT Standards Committee. I can't stop thinking about sunday's Dilbert, replace "Lawyer" with "Systems Engineer". Dilbert.com

John Halamka has presented  A Strawman HIE Directory Solution. I see many problems with this approach, and it seems that this approach includes things that add no value. The problems are not security, or trust. These issues are inherit in the X.509 Digital Certificate system. Digital Certificates can be distributed by any means, they don't need to be restricted. The HIT Standards P&S committee was asked to select a standard, what the HIT Standards committee did was reject it on operational deployment concerns. Concerns that are only half true.

Here is my alternative. The HIT Standards committee has already recommended to HHS/ONC that there would be great value to Healthcare exchanges (both direct and discovery/retrieve) if the certificates used were issued off of a Certificate Authority that is bridged to the Federal PKI. This advantage is two fold, first it is required for the federal healthcare (VA, DoD, IHS, etc), second it will force a specific level of assurance that everyone really would like to know they have. I will assert that this would result in a small number of Certificate Authorities.  This is the good part of the John Halamka step #2 plan, but there is no need for a new healthcare specific top-level-domain (TLD) or restrictions on query.

What I would augment is part #3 of the John Halamka plan, very simply with adding that these Certificate Authorities are recognized as the ELPD suppliers and would be compelled to publish using BOTH the DNS model and the LDAP model recommended by the HIT Standards P&S committee. Given that there is only a few of these ELPDs, they surely could work out LDAP federation between them.

Please note, I am not against the DNS model as an alternative, I am just against a model that is not supported by off-the-shelf solutions. The community must understand that the DNS model for certificate distribution is not working perfectly for the Direct Project, and has well known issues. This DNS model for certificate distribution is NOT supported by off-the-shelf software (aka e-Mail systems); nor by any e-Mail service provider. This DNS distribution of certificates is not even supported by widely used DNS services. It is totally restricted to the Direct Project reference implementation and a few open-source tools.

I am very worried about John Halamka's approach to discoverability through faith in internet search engines. This proposal is not any different than what we have today (http://www.bidmc.org/ContactUs.aspx), and I can't find reliable provider contact information. A program surely couldn't find reliable provider contact information from this page. I fail to see how this can be called 'standards' based. Putting our faith in internet search engines is NOT a standard.

I simply suggest that as we move from ELPD to ILPD, and from minimal support of the Direct Project to a richer set of use-cases; we will need the power of a real directory. DNS is a wonderful tool, but it is a hammer and the problem before us is not a nail.

(added this after first publication)
Note that DNS 'SRV' records are used to discover the address of an LDAP directory for a given domain. Thus it is not hard to find a LDAP directory, one uses DNS. This is a correct use of DNS, to find a Network Service.


(added this 5/27/2011)
Wes Richel has provided a solution to the part missing from John Halamka's blog. He has indicated that the web page that a provider would publish would use microformat, pretty graphical things. This ultimately is
useful as the microformat which for contacts is hCard which is a way to display vCard formatted information on a web page. Where vCard is a format that holds X.500 directory schema information. This is a potentially good idea and not inconsistent with what I have been recommending. The main difference is that Wes proposes this new flashy graphic format as the method of distribution on a web page (is there an app for that?). The microformat is just a distribution method, what are you distributing?

Ultimately we need a directory schema that meets the use-case needs. This is where the IHE HPD project spent most of their time. Trying to determine what are the attributes and how would they be encoded. This schema is nothing more than an X.500 directory schema, which can absolutely be distributed by vCard encoded in hCard microformat. The nice part is that this is very much along the right trajectory.

So what we have is the IHE HPD directory schema as a common schema and various distribution methods including: hCard, vCard, LDAP, DSML, etc. Sounds like a useful 'profile' that the S&I Framework could define for the US Realm.

My concern, that simply needs some research, is to what level does off-the-shelf e-mail support this? It is all nice that there is an app for an iPhone to view the hCard information; but if it can’t get that hCard information into the e-mail system for use then it isn’t really a useable solution (this is the same problem I see with the DNS model).

Note: The use of extended-validation-certificates would not be necessary on the web page. The digital certificate must it-self validate to a trusted root, so the trust is self-described. Digital Certificates do not need a trusted distribution method.

Prior Blog/Resources: 
No comments:

Monday, May 2, 2011

There is No Security Pixie Dust

At IHE, HL7, DICOM, and elsewhere those writing a Profile or Standard turn to the security-geeks in the room and ask them to fill out the now highly recommended "Security Considerations" section, or ask us which other Profile they can cut-and-paste from. The security-geeks respond with "There is no security pixie dust".

Within IHE the security-geeks have published a process the "Security Considerations Cookbook" that is intended to be used by the writers of Profiles, a process that 'considers' 'security'.  The reason why we came up with the Security Considerations Cookbook is exactly because each profile is different, and that security must really be 'considered' by the profile authors. There really is no short-circuit of the process with a cut-and-paste from another profile. There is no magic security pixie-dust.    

The profiles in the Final Text were published well before we came up with the cookbook, so they are not a good example (BPPC and XDS are good, but not simple profiles). It turns out that the Profiles where we have spent significant effort using the "Security Considerations Cookbook" have  not gone to final text yet. This is why you don't find a really good example of Security Considerations in the Final  Text Technical Framework. For good examples of Security Considerations one needs to look at the Trial Implementation supplements, But having a 'really good example' is impossible. Let me explain by example:

SVS
  • This is a really good example of a profile that has explicitly declared that ATNA is not mandatory, but if one decides to group them in their application, then the encoding of the audit message is specified.
  • The wording is not perfect, we always find some text that likely needs changing. The volume 2 stuff should actually be more clear about the 'if a developer does group with ATNA, this is the encoding'
  • But this  profile has the advantage that it is just operating on vocabulary, and thus no identifiers or clinical data.

XCPD
  • This is also a really good example, especially for Vol 1.

RFD
  • This is a good example of Vol 1, and that is all that this one identifies. This is because the actual content carried by the Vol 2 transactions is unknown.

HPD
  • This is a good example of something totally different
  • This one might have the best wording in Vol 2...

But in ALL cases, you can see the influence of the RISK ASSESSMENT.
  • It is only after the risk assessment that we know if a mandatory grouping with ATNA is the right thing to do.
  • It is only after the risk assessment that we know if other things should be done, or should be explicitly NOT done.
  • Etc...

So, you MUST actually 'consider' security, through following the process defined in the Cookbook_for_Security_Considerations. There is no magic security pixie-dust.  

Note: The same is  true in the HL7 Security Considerations Cookbook 
3 comments:
Subscribe to: Posts (Atom)