Provider and Consumer Portals for Healthcare

John D. Halamka MD, MS

Chief Information Officer, CareGroup Healthcare System

The Provider Portal Concept | Cyberprise | STARS



In October of 1996, the CareGroup Healthcare System was formed from the merger of the Beth Israel Hospital, Deaconess Hospital, New England Baptist Hospital, Mt. Auburn Hospital and 3 community hospitals in Eastern Massachusetts.

Soon after the merger, we deployed a web-based application called CareWeb to link the clinical computing systems of CareGroup hospitals. (Healthcare Intranets 1997) The rapid development time, low cost and short term wins of CareWeb illustrated the power of the web in unifying an integrated delivery network.

After the introduction of CareWeb the number of web applications in CareGroup rapidly increased. Soon, we had web pages for clinical data, web pages for performance reporting, intranet pages and web pages for consumer education, all at different urls.

Simultaneously, individual clinical departments began creating individual pages for internal and external use.

The end result was hundreds of disconnected pages spread across 5 web servers that evolved into a maintenance and navigation nightmare.

Taking the lead from Netscape and Yahoo, we launched customizable portals for the providers and patients of CareGroup in early 1999. The portals resulted in a single web-based destination for CareGroup providers and a single destination for consumers. We consolidated our servers, built a disciplined approach to web-content management and created a common look and feel for all web systems.

This chapter describes the CareGroup experience with the use of web portals in healthcare, as well as the transaction and knowledgebase systems which populate the portals.

The Provider Portal concept

A portal is simply a framework for the aggregation of links and web content. A portal could be as simple as a single home page containing fixed lists of links. Conversely, a portal can be as complex as a database driven script which generates a completely customized home page for each user at each location each time it is accessed. We elected the latter approach.

The CareGroup intranet supports the workflow, communication needs and clinical knowledgebases needed to accomplish our mission – care delivery, teaching and research. Because our internal web-based resources are focused more on staff and clinicians, we termed this cluster of resources our "provider portal."

Although our goal was simple – to unify our web content through the six hospitals, 100+ clinics and 1000+ physician offices, there was no single solution for everyone. We needed all our pages to appear on our intranet and a subset of these pages to appear on our extranet. For example, we would not want employee phone numbers and addresses available to the general public. Also, content had to vary based on the location of the computer accessing the portal. Cafeteria menus for the Beth Israel Deaconess Medical Center are not of much value to Mt. Auburn, 3 miles away across the Charles River. Also, announcements of retirement teas of long valued employees of one hospital are not relevant to other hospitals.

Also content has to vary based on date and time. If web-based call schedules are to be accurate, they should reflect the physicians on call right now. Also, as content becomes stale it should no longer appear. Announcements of the Boston AIDS ride Sept 15-18 should no longer be visible on September 19.

We built the portal entirely in Microsoft Active Server Pages, running under Windows NT 4.0, Service Pack 5, and backed with content stored in SQLServer 7.0.

We divided our portal content into thirty subject headings including major headings for Announcements, News and Publications, Institutions, Clinical Resources, and Employee Resources. The standard portal displays the links associated with each of these major headings as well as several web-based productivity tools. Since all content is stored in SQLServer, links can be specific to an institution or date. As the page is requested, the IP address of the page requester is examined and determined to be part of the intranet or extranet. If the user is coming in from outside the CareGroup network, then only those links/pages determined to be suitable for extranet use are displayed. Further, intranet users are checked against a table of institution specific network locations and their institutional affiliation is determined. This is used with the database to filter out content specific to other institutions. Additionally, the data and time are used as filters against the database to insure only timely content is delivered. The end result of this process is a portal that appears on the following page.

The standard portal needed a delegated maintenance model to insure that multiple experts could update content very easily. We build a portal editor in Active Server Pages, that allows specific users with appropriate password credentials to add, remove and change portal content. We delegated specific content areas to qualified individuals. A physician informatician maintains the Clinical Resources category content. Corporate Communications maintains Announcements and News/Publications. The portal editor allows the user to designate a specific link to be intranet/extranet, institution specific or general, effective as of a given date and needing review on a specific date. The portal editor also allows new categories of links and new links within categories to be easily added. The screen appears

The standard provider portal has both transactional systems and knowledgebases. On the left navigation bar of the portal homepage we have included those software systems used most regularly by our employees. These include clinical information lookup, links to all our mainframe applications, email, performance reporting, literature searching and managed care referrals. These systems provide a very good overview of the main types of web transactional systems – web-based, web enabled, web-developed and web-exposed databases.



Cyberprise is an example of a web-based system that accesses legacy content via emulators. Many of our clinical and financial systems were accessed via client server technology and used VT100 or IBM 3270 emulators while running on PCs. We purchased a suite of web-based emulators and built web-based easy access to many legacy systems. Although the legacy systems themselves are not web-enabled, the use of web-based emulators allowed the easy migration of many systems to the portal without having to deploy custom software on the desktop.


STARS is an example of a web-developed application. There is no underlying legacy system that was web enabled and no previous client server application that was made web-based. STARS was conceived as a web application and 100% was web developed.

One of the greatest burdens on physicians today is managed care paperwork. Physicians require different referral forms for each health plan and use a different process of benefits/eligibility checking for each health plan. Some require a phone call, some use a swipe card and some are paper-based. With STARS, we created a web-based payer blind approach to the entire managed care business process. Additionally, we laid the foundation for Health Insurance Portability and Accountability Act requirements, that when passed by Congress, will likely require the use of standard electronic means, using ANSI standards, of exchange information about patients.

When the patient registers to be seen, the office assistant logs onto STARS and provides either member number or name information via a web form. An EDI (Ansi X12 270) transaction is immediately launched to the major payers in New England – Tufts, Blue Cross and Harvard Pilgrim to check on the eligibility information of the individual. If the person is found in a payer database, an EDI response (Ansi X12 271) is sent back to STARS and eligibility information is immediately displayed include copayment data. This appears:

If a patient is not eligible a similar notification occurs.

Another comment transaction in the managed care business process is referral/authorization. STARS provides a web-based front end to take member eligibility and generate an electronic referral. The referral physician is selected and the reason for referral with diagnosis information is specified. Not only does this make the referral process easy for the physician and patient, it helps CareGroup achieve its business goals.

One of the major goals of any integrated healthcare delivery system is to insure referrals are made to its own specialists. With STARS, referrals to CareGroup specialists are seamless and most are automatically authorized. Referrals to non-CareGroup specialists require completion of a special exception survey and are automatically sent to case managers for approval.

By streamlining the managed care business process via the CareGroup portal, physicians have more time to see patients. To help physicians access the clinical information they need to deliver quality patient care, we created CareWeb.




CareWeb is an example of a web enabled legacy systems. The existing clinical information systems of the Beth Israel Deaconess Medical Center, the largest hospital in CareGroup, include an IBM 390 Mainframe-based clinical system called ODISY and a M based system running on HP UNIX systems called CCC. To improve the accessibility of these systems, we created middleware software that web enables the legacies.

Specifically, we created Active Server Pages programs for each legacy that display Problem Lists, Medication Lists, Allergy Lists, Visit History, Reports, Labs, Xrays, and EKGS in a consistent, easy to use web format.

A typical CareWeb screen appears:

Executive Information System

Easy to access clinical data makes the care delivery process more consistent and cost effective. Historically, physicians had no feedback on their performance, quality and outcomes. To provide valuable guidance, emphasize the use of best practices and to insure our financial success, we created the Executive Information System. EIS is an example of web-exposed database.

Every month, CareGroup receives claims information for the three major payers in New England. We warehouse this data and transform it into a consistent format across all three payers. This managed care warehouse is then used to create 110 reports from the database.

Examples of reports include Mammography Rate, C-Section Rate, Coronary Bypass Graft Mortality Rate and Surgical Site Infection Rate.

Our most important development to date has been the balanced scorecard for physicians. These "report cards" show physician utilization across many dimensions as compared to their practice, their institution and all of CareGroup. The most important aspect of a physician report card is risk adjustment. Many physicians will claim that report cards are invalid because their patients are sicker than the rest. We use a methodology called the DCG method to examine the severity of illness of every patient and create a risk score for each physician’s patient panel. This score is used to predict expenditures. Our scorecards then show actual expenditures v. risk adjusted predicted expenditures. A sample report card appears:

Like everything else in the Portal, these report cards are generated from a database at the point of request.

These transactional systems – Cyberprise, STARS, CareWeb and EIS make the provider portal the only place a physician needs to go for the information tools required to practice.

In addition to the transactional tools, the portal contains over 300 knowledgebases. These include best practice guidelines, formularies, drug dosing and poison treatment information, and 506 full text journals on line.

The provider portal current receives of 9000 hits per day and has been an amazing success. Despite its many functions, however, users wanted more personalization.


Although the standard portal and portal editor provided great functionality for the institutions, it did not allow custom content per user. To satisfy this need, we created MyPortal. The MyPortal concept extends the portal to be customizable to the level of the individual. The latest techniques in Cardiac Catherization may be fascinating for a cardiologist, but irrelevant for office staff. Announcements of new Microsoft Word training programs may be important to office staff but extraneous for the cardiologist.

By clicking on Create My Portal, the user is presented with the following screen:

The user specifies the categories of links which should appear, custom links unique to them, their clinical speciality/areas of interest and a username/password for accessing their customized portal.

Two special categories provide added functionality. The Mynews category uses the clinical speciality information to autoregister the user into Medscape and retrieve custom specialty specific content which is delivered to the portal every day. MyLinks allows the user to specify their own links.

A sample Myportal page appears:


Since we have 5500 desktops , many of which are located in public areas, we elected not to use cookies to store MyPortal information and all user selections are stored on the web server in SQLServer. To retrieve or edit a portal, a user only needs to provide a username and password one time per session.

Security and Confidentiality

Because the Provider portal contains access to physician and patient identified data - SecurID access is required for extranet access of all clinical data. We audit every transaction, use 128 bit Secure Sockets, and prevent clinical data from being cached on the local browser.