Wednesday, November 26, 2008
Differentiating between Single Sign-on (SSO), Enterprise Single Sign-on (ESSO), ESSO with Context, and Clinical Portals.
So you eventually want an EHR.
What’s the best path?
Depends on the goals.
The Evolving Landscape
Healthcare delivery organizations, departments, and stakeholders across the continuum of care use a wide variety of IT systems for storing clinical information that are rarely integrated. This disparate data can result in time-consuming and painstaking efforts to obtain a patient’s complete medical record.
Today, Healthcare organizations have a vested interest in creating an infrastructure that delivers integrated patient information. Not only is the outcome of care improved when caregivers have complete, usable data, but additional benefits are immediately acquired. These benefits include improved operational efficiency, easier compliance with regulatory requirements, a reduced need for investment in IT systems and implementation, the ability to measure and manage quality of care and participate in research, and much more.
Information systems available to healthcare organizations until now have not been able to fully to deliver these benefits. This is primarily due to IT systems lacking a common or standardized method of representing clinical data (nomenclature, terminology, coding systems, etc.). In addition, the high degree of specialization demanded by clinical practices, as well as the tendency of healthcare organizations to adopt a best of breed approach for IT systems implementation, has increased the level of diversity and disparity of data. Consequently healthcare organizations have been forced to settle for basic, limited levels or integration of their clinical applications.
Single Sign-on (SSO) and Enterprise Single Sign-on (ESSO)
Although Single Sign-On (SSO) technology dates back with some vendors to 1996, adoption has been slow. Within the past two years, interest and deployment in this technology have increased, and the solution has blossomed into more than a security solution. This technology is primarily supported by Healthcare delivery organizations to assist their IT departments in their administrative duties.
In its simplest form, Enterprise Single sign-on (ESSO) is an access management mechanism whereby a single action of user authentication and authorization can permit a user (via batch credential provisioning) to access all applications with access permission, without the need to enter multiple passwords. In the Healthcare reality, an ESSO solution by definition can reduce administrative burden, extend access to multiple applications, and increase productivity and user satisfaction.
Imagine ESSO like a Windows Desktop environment. Once logged on, users have access to any/all applications (i.e. MS Word, Excel, PowerPoint, etc.) simply by double-clicking the icon on the desktop. When the application is launched from the desktop, users naturally do not need to sign-in again. However, users still need to navigate through multiple applications, pages, and disparate data to find the clinical information they’re looking for. In a client-server environment, this is further compounded by the time required to launch the application and search for the specific patient’s clinical information. In today’s ESSO reality, to have a comprehensive view of a patient’s clinical data would effectively require launching all the associated applications and searching through disparate data individually. While the user may not need to sign-on to access the systems, it’s clear this isn’t intuitive, nor time or cost effective.
ESSO and Context Management
A conversation about SSO would not be complete without talking about context management. Some may have the impression that investing in a SSO solution means the combination of functionality afforded by both SSO and context management. Providers have expressed problems when their constituency did not understand what they were buying if they were not getting both.
Context management automatically synchronizes multiple applications in response to a single user gesture directed at any application using readily identifiable information such as a particular patient, encounter or observation. Put simply, if using multiple applications simultaneously, a Patient-search on one system can trigger a similar search in other systems. This allows for the user to access each disparate database in context. This technology is primarily supported by Healthcare delivery organizations to assist their IT departments in their administrative duties. When combined with ESSO, Context Management can extend user authentication, patient search, and allow access to multiple vendors’ native applications. More sophisticated implementations can extend context sharing at the encounter level and/or in a bidirectional manner. However, users still require the user to navigate through multiple native applications and pages to find the detailed clinical information they’re looking for. Not ideal but significantly more value than simple (E)SSO.
The premise of ESSO with Context Management implies by definition that ALL users need access to the same finite and highly detailed clinical data found in the specific department or best-of-breed system. Most would agree that the meticulous and detailed needs of those using a Lab system, for example, in the Lab environment, would be significantly different than the data needs of someone in the ER trying to access a Patients Lab results to ensure there is not a conflict. In this model, stakeholders have access to the disparate data via the native application. One of the challenges with this model is that Physicians and Clinicians have to learn and navigate through multiple (departmental or “best-of-breed”) applications to get the patient data they require.
Although steps have been made to try and optimize this delivery model, the question remains. Is this as intuitive and streamlined as it could be? Can it expand outside of a single hospital? Eventually, won’t vendors selling (E)SSO with context realize that stakeholders don’t need access to ALL the clinical information available to do their job more effectively, they need access to the clinical data that is relevant to their specific role. Each clinical stakeholder has different needs.
This author contends that the next wave of (E)SSO with context solutions will add a presentation layer to the offering such that the user is presented only with the clinical data required (versus just access to the clinical data.) However, in the context (no pun intended) of not having any access to any clinical information at the point of care, being able to access the native departmental or best-of-breed application via (E)SSO is still a quantum leap for care delivery. In the face of evolving needs and reducing resources, many opt for this path as any solution is better than no solution.
This type of solution involves the creation of a customizable user interface that can work with information from different vendors and sources. Portals are designed for the clinical end-user directly at the point of care and offer the ability to manipulate the way information is presented, in most cases regardless of the legacy vendor. They typically involve a bottom layer that is responsible for aggregation of information, and a top layer in which the information is intuitively presented to the caregiver.
For example, portals can display data any number of ways from different sources in a hierarchical structure or simple “tabbed” environment. Think of a Portal solution (results-wise anyway) as the same integration results as an (E)SSO with context solution, however served up in a customizable web-based offering where the user is presented ONLY the clinical data required (versus just access to said clinical data.)
Unlike ESSO with Context, Portals call data directly from the databases where the legacy data resides, not a duplicate of the original transaction on a repository. This ensures data is queried in real-time, eliminates the need for a centralized data repository (CDR) and associated brokers and can also provide advantages in areas such as flexibility, scalability, availability, and even security to a limited extent, because information remains where it is created and each organization is free to administer its resources as it sees fit.
Moreover, Portals by definition offer unfettered use of the information. Because information is only handled in the presentation tier, the type and depth of data manipulation, cross-reference and analysis are unlimited and can be customized by user. This is primarily because, even though Portals are easy for Hospital IT departments to maintain, administer, and manage---they were originally designed to meet the clinical stakeholder’s unique needs.
One of the strongest differentiators for Portals is the fact that Clinicians and Physicians don’t have to learn multiple (departmental or “best-of-breed”) applications to get the clinical data they require. Users only need their respective departmental solution, and a portal to aggregate all other relevant data. Today’s Portals can accomplish everything a (E)SSO with context can all on a future-ready, scalable, standards-based platform. Although (seemingly) diametrically opposed paths, both ESSO with context and Portal paths can by definition provide a comprehensive, transferrable EHR. The differences are in time to implement and cost.
The realistic and “future proof” way to achieve an actual, real-time picture of a patient’s medical history is with a solution that provides interoperability – creating a unified patient record from the various sources holding patient data, no matter where they are located, or in which format. Any solution implemented must also accomplish this while adhering to privacy and security policies as well as auditing requirements of the organization/s and relevant regulating authorities. Moreover, the solution must be able to resolve issues of identity (name with/without middle initial, married/maiden names, etc.--aka MPI) and to deal with situations in which one patient may have more than one registered identity within and across multiple information systems.
So whether starting from fresh, or currently on a (E)SSO-with-context path and looking for a presentation layer (or EHR/EMR Viewer,) clinical stakeholders need intuitive, customized and streamlined access to relevant patient data. The true benefits of interoperability will only be realized when the integrated patient information is used not only by means of having it presented to the caregiver via a portal of some sort but rather by leveraging the data as a key clinical asset and using it to meet the needs of quality, compliance and management initiatives. The challenges that most organizations deal with in their quest to execute these initiatives mainly revolve around dealing with the lack of access to the broad set of medical data required for successful implementation. A robust interoperability solution holds the key to unlocking this information and turning such initiatives into a reality.
While any given EHR solution theoretically may be achieved via multiple paths, the ultimate vision is to create a single, unified patient record based on data from different information systems, formats, sites and if needed even across organizations, enabling the data to be integrated, analyzed and used – without affecting the systems in which information is stored.