Make sure you attend Education Session 246 at HIMSS 2010 Atlanta to hear John Fraser, CEO of MEDNET, speak about NHIN and Federated Identity Management!
Thursday, March 4, 11:15 AM – 12:15 PM Room B405
HIMSS10 » Education » Healthcare Identity Management and Role-Based Access in a Federated NHIN: http://bit.ly/6xfmeu
- By Jesse Erdmann
This month, Jesse Erdmann, Certified Information Systems Security Professional (CISSP), explains how to segregate services for internal versus external usage, as well as approved HIE to HIE communication versus public dissemination of information.
Security systems, like castles of yore, are designed in concentric circles of protection. Each ring should be more restrictive as to whom is allowed access and more difficult for attackers to bypass. On the outermost ring, everyone is allowed as long as they don’t misbehave and there are some general controls as to what the milling masses have access to. In our castle example, people from outside of the castle are allowed in to visit shops and trade services, but the guards generally frown on people fiddling with the lock to the stores or treasury. In a network security scenario, the same principles are applied in such a way that anyone can access a web server via the standard web protocol, but they cannot access the administrative protocol. Users that display certain poor behavior, port scanning, password guessing, etc can be sanctioned as appropriate.
In the next ring, privileged users are granted access to a few more services, but have a few more hurdles to clear. Merchants and other select persons have their housing and stores within the next ring of the castle. In the network, users from specific addresses on machines that provide an acceptable digital signature are allowed read only access to restricted data sets. For instance, an organization might select reportable, de-identified data for the CDC from their master database and publish it to a restricted, smaller database outside of their core infrastructure. When a machine from the approved CDC address range that provides digital credentials matching the appropriate certificate from the CDC it is allowed to query the restricted database for the de-identified case information. Likewise in an HIE to HIE setting, specific machines from HIEs that have established business agreements could access whatever information has
been approved for exchange without allowing those business partners access to the innermost core network infrastructure.
Finally, only the most privileged users are allowed access to core infrastructure. To conclude the castle example, only the king, his family, personal guests and personal guard are allowed access to the throne room. In the network example, machines access core infrastructure can be required to have physical access to the local network, a non-internet routable address, provide appropriate credentials and require the user of the machine to provide their own personal credentials. None of these requirements on their own is enough to grant access, but all of these factors combined can provide a high enough level of certainty to allow access. Depending on the needs of the organization, different users can be granted access as appropriate for their role.
It is important to keep in mind when designing a security system that traditional security methodologies are not all that different from modern digital security methodologies even though the details of implementing the methodologies are drastically different. Prized assets should be positioned nearest to the center of the security infrastructure with the most layers of controls and the fewest people with access. As assets become less valuable and need to have greater access the controls can be peeled back. Also, never lose sight of the fact that a network’s digital security is only as strong as its weakest point, including physical security. An attacker with physical access can, with time, bypass practically any software controls put in their way.
- By John Fraser
Designers took a broader and more scalable approach to connectivity, security and patient privacy when building NHIN, the Nationwide Health Information Network. The designers realized that to scale NHIN, gateways installed in individual hospitals or HIEs would need to be able to talk to each other, at any time. A directory of all NHIN gateways is being implemented so that any NHIN gateway can look up the address of any other gateway quickly and seamlessly. This NHIN ‘lookup service’ helps scalability, insuring that the multitude of NHIN gateways that will be needed can connect to any other NHIN gateway to exchange medical information.
As for security, the NHIN designers decided that security should be built in, not layered on. Each message exchanged between NHIN gateways is natively encrypted so that hackers can’t read these messages as they flow across the Internet. The NHIN security layer actually increases patient privacy, as no messages are ever sent unencrypted, or rely on another layer (like VPN solutions) to provide security.
Additionally, NHIN designers realized that each message, although encrypted, should also have some type of authorization to ensure that the receiving systems could trust each message. By utilizing the same security technologies as the military, users of NHIN can trust that each message has not been tampered with, and each message actually came from the sender listed in the message. Each NHIN message is signed with a “digital certificate” at each and every NHIN Gateway, before the message is sent out. These “digital certificates” are part of the public key infrastructure (PKI) technologies used by NHIN that helps ensure the privacy and security of patient information flowing over NHIN.
Although NHIN is extremely secure now, there is interest in building addition security in later versions of the NHIN system. One example is getting security down to the individual level, so NHIN messages can transport trusted information about individual providers and NHIN users. There will need to be a way to issue digital credentials to individuals such as doctors, emergency response personnel, public health individuals and others in the health care ecosystem. A new standard is emerging to make this individualized digital credential process easier and national in scope, without requiring federal or state government involvement. Lead by the Kantara Initiative, an Identity Assurance Framework (IAF) is being put into place to allow companies to issue digital credentials to individuals that can be trusted and exchanged by systems like NHIN, the Nationwide Health Information Network.
- By Chris Smith
As the building and implementing of Health Information Exchanges increases, critical decisions must be made on HIE use cases (how the HIE will use interoperable data from the HIE members), as well as the HIE infrastructure components.
Often, the focus around building an HIE is about the technology / infrastructure layer (as the key component of a Health Information Exchange). While important, technology is but one piece of building an effective Health Information Exchange. Use cases, or how the data and information from the HIE will be used within the HIE, are critical in defining the relevance, success, and overall sustainability of the HIE.
The core use cases for an HIE should be clearly defined and agreed upon by all constituents prior to construction of the infrastructure for the HIE. Questions such as ‘What is the data the HIE will be sharing’ and ‘How will the HIE use this data’ should be asked and answered. Is the HIE looking for an Emergency Responder use case? A Medication Management use case? A Lab Reporting use case? What are the core goals and focus the HIE wishes to accomplish with interoperable data exchange, both now and in the future? Defining the HIE use cases, and building a clear, attainable roadmap of use cases will add credibility, success, and overall membership growth to the HIE.
Some say ‘We could build a moon rocket, given enough time and money’. Certainly, an HIE could build a technological wonder with the choices for HIE infrastructure components and technology solutions in the marketplace. However, having a clear, focused, attainable roadmap of use cases for the HIE, prior to infrastructure selection, will define the infrastructure needed, as well as insure the HIE gets started on the right path to sustainability.