The following article on eServices Group's HIPAA Philosophy was featured in HCFA's Medicaid Managed Plus Newsletter in November 2000.
Medicaid information technology organizations need to seize the opportunity that is being presented by the HIPAA transactions and codesets to develop HIPAA-compliant web portals to support the goals of public health.
The current generation of MMIS systems are steeped in 1970s and 1980s technology decisions. The batch-orientation of many of these systems made sense when they were originally designed, but the HIPAA transactions and advancements in technology should cause us to revisit those aging architectural decisions.
When the current MMIS systems were built, paper claims were the primary input mechanism, and green bar reports were the primary output mechanism. Today, web browser access dominates our society, and many organizations are attempting to web enable their systems. In the very near future, our users will be empowered with inexpensive handheld and wireless devices that will enable them to submit claims and encounters as a by-product of performing the clinical functions. Are our MMIS systems fully prepared to accept transactions and provide information to both web browsers and these emerging devices? If we can fully accommodate the use of these technologies, we will greatly reduce the cost of processing transactions and allow the provider network to focus their efforts on healthcare (rather than administrative tasks). The HIPAA transaction set is the mechanism that will allow us to embrace these emerging technologies.
According to the HIPAA schedule, within two years we will have completed this nation's largest interoperability test. Imagine the number of different entities that need to confirm that they're speaking the same language -- the HIPAA transactions. In this new world of universal interoperability, there are two irrefutable facts. The first is clearly the mandated data formats specified in the HIPAA transactions and codesets. The second is a universal connectivity path that allows those transactions to be communicated between the thousands of participating parties. This universal connectivity in today's society is the Internet. When viewed in combination, HIPAA transactions over the Internet represent a windfall of efficiency in our nation's healthcare processing systems.
HIPAA - The Functional Specification
The implementation of any modern data processing system begins with a high level functional specification -- what are the inputs to the system, what are the outputs from the system, and what occurs between input and output. The HIPAA transactions and codesets represent the input and output functional specifications for the next generation healthcare processing system. If we only had more time we could implement a totally new, object-oriented MMIS designed around Internet specifications, but we only have two years. It can't be done. What is accomplishable in this timeframe is to design a perfect virtual MMIS that is accessed through a portal and relies heavily on existing legacy systems to accomplish its tasks.
The Foundation - The Portal
Access into the virtual MMIS is accomplished exclusively through a well-defined Internet portal. A portal is a doorway or a gateway into our MMIS of the future, and that's the way we should think of it. It is the access point where we control who's allowed in and what they're allowed to do when they're in our system. It is the focal point that allows us to adapt to the proliferation of new technologies, such as wireless devices, encryption algorithms, and advances in authentication such as biometrics. There are six major functionality levels in our portal.
The first level of portal functionality is connectivity. Connectivity today means access to a wired Internet. When someone connects to our portal using their local service provider, they're connected to our portal using today's existing Internet standards of TCP/IP, HTTP, HTTPS, HTML, etc. -- a web browser. In the future, our portal will need to support wireless connections and the protocols associated with those, such as Wireless Access Protocol (WAP). Our portal will need to support the technologies that we know of today as Interactive Voice Response (IVR), and promote the evolution to natural speech. The connectivity aspect of our portal needs to be modular in nature to facilitate access by devices and technologies that are not even in our thoughts today.
The second level of portal functionality is authentication. Authentication is the process by which we determine who is trying to gain access to our portal. In today's world, authentication is accomplished by associating a username with a password. If the user has the password, we assume that they are the person they claim to be. In the future, other emerging technologies, such as biometrics (i.e., finger print recognition, iris scanning) -- all of the things we hear about in the news -- will be used to more positively authenticate or identify the user. If our portal is designed in a modular fashion, we will be able to support these emerging techniques in a plug-able fashion.
Authorization is the third level of portal functionality. At this point, the user of our portal has been connected, authenticated or identified, and now it is the responsibility of the authorization module to determine what aspects of the system this user is allowed to access.
The fourth level of portal functionality is encryption. The user of our portal has been connected, authenticated or identified, authorized, and now it is our job to ensure that the information being presented to our user is rendered unusable by all others. In today's Internet world, the commonly employed encryption technology is known as Secure Socket Level (SSL) or triple DES. This technology, although widely accepted today is, in fact, a 20 year old technique that will be replaced in the future. The federal government has recently determined the encryption techniques of the future. These new encryption algorithms won't be deployed for some years to come, and its deployment will be gradual. We need to be prepared to assimilate these new encryption techniques without perturbing our existing systems.
The fifth level of portal functionality seems simple and is a critical part to our security infrastructure. Because the portal is the one access point through which all information passes, the portal is the point at which all transactions are logged. A focal point for transaction logging is critical as we implement future aspects of HIPAA, such as privacy.
Data transformation is the sixth level of portal functionality. Data transformation refers to taking information supplied in one format and transforming it into another. For example, taking the results of an eligibility request HTML form and transforming that information into an X12-formatted 270 request, or taking an X12-formatted 271 eligibility response and formulating HTML that can be presented in a web browser in a human-readable format.
Having these six functionality levels embedded within the portal, as opposed to distributed throughout the various backend systems (i.e., claims processing, eligibility, etc.), enables us to quickly adapt to emerging technologies while methodically evolving our legacy systems.
Virtual MMIS and Legacy Integration
Once we have completed our portal or access point, it's very tempting to immediately try to integrate that portal with our existing legacy systems. This temptation must be avoided. We should build a virtual MMIS between the portal and our legacy systems. So what is a virtual MMIS? The inputs and outputs of the virtual MMIS are dictated by the HIPAA transactions. If you want to know eligibility, give the virtual MMIS a 270. It will return to you a 271. The question is, how did the virtual MMIS know what data to complete in the 271? The answer is, it asked the legacy system. Integration with the legacy system is accomplished differently depending on the legacy system -- some may be CICS transactions, some may be database queries, others as simple as 3270 screen scraping. The virtual MMIS approach facilitates HIPAA compliance and buys us time by utilizing the existing legacy systems. As new features, functionality, and subsystems are implemented, they are implemented in the virtual MMIS so that new investments are applied to the virtual MMIS -- ultimately supplanting the legacy systems in total.
Remember that all healthcare payer systems will have to be HIPAA compliant over the next couple of years. This allows us to create a portal that interfaces with not only our MMIS but with any other payer system as well. In fact, our portal can act as a focal point for all healthcare transactions regardless of their ultimate destination. For transactions other than those destined for our MMIS, our portal acts as an agent or a proxy to those other systems by forwarding those HIPAA transactions. The destination system replies to our portal with a HIPAA transaction, and the user of our portal receives the response information as if the transaction were performed locally.
Summary
The intent of the HIPAA transactions and codesets is to simplify and standardize the process of electronically exchanging healthcare information. Implementing these transactions over a standard Internet portal has the potential of returning tremendous cost savings. In addition to the cost savings, the communications to our provider networks and other healthcare organizations will be radically improved and the integration with other systems vastly simplified. Implementing the HIPAA transactions over an Internet portal provides the mechanism for the adoption of emerging technologies such as wireless and Personal Digital Assistants (PDAs). Seize this opportunity to implement a HIPAA-compliant web portal that supports the goals of public health.
