One of the most difficult issues for a health care CIO is authentication. Unlike most industries where a single login gets you complete access to applications and databases, health care systems require levels of authentication. For example, not everyone within a clinical institution has the authority or privilege to write a prescription.
A good electronic health record (EHR) implementation will have authentication levels based on roles so only an authorized physician can write a prescription. This means that when physicians log into an electronic health record system, their authentication provides them access to a restricted area of code that allows the processing of a prescription. That is what is sometimes referred to as role-based authentication.
Let’s walk through a basic patient encounter at a typical health care service provider:
The front-desk receptionist logs a patient into the EHR system, verifies the patient’s appointment time and demographic information, and starts the process that alerts the clinicians that the patient has arrived for the appointment.
A nurse calls the patient and escorts him to an exam room. Typically, patient vital information is taken (blood pressure, weight and temperature). The nurse usually confirms the patient’s medication list and then enters all this information into the EHR system. The clinician next sees the patient and reviews the appointment information, probably reviews the patient medical history within the EHR system and performs the patient exam. The clinician will then process orders in the EHR system (labs, X-rays, MRI, prescriptions).
Not so simple with an EHR implementation
Sounds simple? Not quite. Each individual servicing the health care needs of this patient requires authentication levels within the electronic health record systems. The front-desk person is not allowed to see patient medical history. The nurse is restricted from processing prescriptions, as well as many orders. The clinician would also have restrictions based on his authority for what procedure could be ordered for the patient. What’s worse is that typically, clinical EHR systems (lab, pharmacy and X-ray) are from different vendors and require separate logins. So a simple medical encounter now becomes an authentication nightmare for IT.
Secure electronic health record implementations will need to require role-level authentication, in which the user’s health care role determines his level of authentication within the EHR system. I am not aware of present-day EHR systems that provide that sophisticated authentication. You will not find that level of authentication within Microsoft Active Directory authentication. Lightweight Directory Access Protocol (LDAP) may offer something close, but it requires a third-party “authentication authority” to cross entities and platforms. Many legacy EHR systems are not LDAP-compatible, so a complete solution is not available.
One potential mechanism is Kerberos authentication, provided by MIT. Kerberos offers basic authentication across nodes with a certification “ticket” -- transmission of data is encrypted and access to servers can be mutually authenticated, but there is no multilevel authentication. In addition, the application running on the server being accessed has to be Kerberos-capable.
Originally known as Project Athena, Kerberos has become a consortium in which even MIT is losing interest. Its original mission, “to establish Kerberos as the universal authentication platform for the world's computer networks,” is noble, but in the two decades of Kerberos availability, acceptance at the EHR software vendor level has been limited. Microsoft, which embraced Kerberos authentication under Windows 2000, is now moving away from it.
SAML the solution for EHR implementations
The vision I see for health care vendors and institutions for authenticating users to EHR systems is Security Assertion Markup Language (SAML). SAML is an XML standard, as defined by the Organization for the Advancement of Structured Information Standards (OASIS), which allows secure domains to exchange user authentication, entitlement and attribute information and authorization data.
Each individual servicing the health care needs of a patient requires authentication levels within the EHR systems.
Using SAML, an information systems health care provider could contact a separate health care identity provider to authenticate users who are trying to access secure electronic health records or personal health information. The major hardware and software vendors are investing time and development into SAML for authentication. IBM, Microsoft, Sun Microsystems Inc. and Oracle Corp. are Foundational Sponsors for OASIS.
I believe this will be the mechanism needed for health care vendors and services providers to meet President Barack Obama’s goals for privacy and portability. I have not seen anything else being designed as an authentication standard that comes close to what is being presented by OASIS.
The Department of Health and Human Services (HHS) has assigned the Health IT Standards Committee with making recommendations to the National Coordinator for Health Information Technology on standards, implementation specifications and certification criteria for the electronic exchange and use of health information.
In its Aug. 20 update report, “Privacy and Security Standards Applicable to ARRA Requirements,” the Health IT Standards Committee board is recommending to the HHS the implementation time of 2013 for OASIS SAML v2.0, and an implementation goal of 2011 for the Kerberos Network Authentication Service (V5).
Al Gallant is the director of technical services at Dartmouth-Hitchcock Medical Center in Lebanon, N.H. Let us know what you think about the story; email firstname.lastname@example.org.
This was first published in November 2009