Physician Portal Development, from the Data Up to the Human

The rise of health information exchange allows for the movement of clinical information between very different health care information systems, while, at the same time, maintaining the meaning of the information.  The objective is to leverage this information to provide better patient-centered care. 

However, while we may have system-to-system data integration in place to support HIE, the larger issue is how to bring this information to human beings. 

We covered the basics of a patient portal development in my last post, where useful information is brought forth from many back-end systems to the patient, as well as giving the patient an opportunity to provide current health-related data. This month let’s focus on the other major human in the loop, the doctor. 

The objective of a patient portal is to provide the doctor with the right data at the right time and in the right way so they can make the right diagnostic calls and treatment recommendations.  The core problem with the existing state of most health care delivery systems is that not all physicians will be able to connect to an HIE.  Thus, the use of a portal becomes critical to leverage important data such as the patient’s treatment history, and other patient data that will assist the doctors in making better decisions about patient care. 

Portals that are built to meet Meaningful Use Selections 170.304(h) and 170.306(d) provide patients with the ability to access clinical summaries, as well as health information.  If the portals are well built, they facilitate communications with patients and doctors using a common set of data, and they put the data into a more understandable context for the doctor. 

Moreover, the use of these portals increases the amount of meaningful data that’s available within the portals.  This includes leveraging analytics built around local and remote big data systems that provide the ability to validate diagnostics and treatment against massive amounts of historical treatment and outcome data. 

Building a physician portal leverages many of the same tricks we’ve developed around building general portals, with a few new twists and turns.  Indeed, you may not decide to build this yourself, but purchase one of the many physician and patient portals that are on the market today.  Your path is determined by your requirements.

Core activities that need to occur, no matter if you’re building or buying a physician portal, include:

Review all relevant regulation, and make sure there is a plan for compliance.  This has a tendency to be pushed to the back of the project, which generally means disruptive and expensive changes.  Keep in mind, even if you leverage a provider, you’re still responsible for compliance.

A complete inventory of all of the systems that will provide information to the portal, including all interface information and the structures of the data produced.  This forces you to understand the open and proprietary APIs at play, and also determine the cost and complexity of accessing the various systems via the “back-end” interfaces they may provide.  You’ll find that many of the clinical systems are quick work, where others require a great deal of thought and planning.  You can read my old EAI book to better understand the complexity of data integration with databases, as well as with clinical system interfaces.

Create a common abstract schema in support of the portal.  This is typically an abstraction of all the interface structures defined in the previous step.  This binds the information together into meaningful bundles, such as a physician’s view of patient treatment data, and perhaps links to various research documents that are automatically added to the treatment instances to assist the physician in finding up-to-date information about a particular treatment.  You can create a new database structure just for use by the portal, or leverage data virtualization technology that is able to create an abstract representation of the data within middleware.

Select the interface approach and technology, supporting both existing popular platforms as well as the future.  The user interface should not be locked into a particular platform.  It should support the popular computing and mobile devices today, as well as new platforms that will emerge in the future.  Thus, while the inclination is to write down to the native user interface API, such as those provided by Windows, IOS, or Android, the ability to create your user interface look, feel, and behavior for portability across existing or emerging platforms is typically a better approach.  Avoid approaches that don’t take full advantage of the platform’s capabilities, and, as always, the tradeoff will be native features and functions and portability.  You can find a happy compromise…trust me. 

The rise of portals, both patient and physician, are a great way to improve care for providers.  The idea is to place the right information in the right hands, at the right time, as well as take advantage of the close collaboration of patients and physicians.  The advantages to providers and patients are too numerous to list here, but if implemented with some thought, health care costs should go down while patient care metrics quickly rise.

David Linthicum is an SVP with Cloud Technology Partners, a cloud computing consulting and advisory firm. David’s latest book is "Cloud Computing and SOA Convergence in Your Enterprise, a Step-by-Step Approach." His Web site is www.davidlinthicum.com/