by Jim Roach & Jon Sund

March 5, 1998

Acknowledgements

We want to express a special thanks to Stephen Lankton, MSW, DAHB, for his behavioral science analysis, input regarding the interface design, and his review and comments.

Background

This paper assumes that the reader is acquainted with the following terms:

World Wide Web (WWW), Internet / Intranet
HTML, HTTP, and CGI
Portable Document Format (PDF) from Adobe
Media Independent Publishing

Media independent publishing provides for the delivery of knowledge to the point of need in the media that suites the requester. This can be accomplished through a number of way:

Traditional publishing
Electric publishing with on-demand printing
Electronic hyper-linked documents (HTML or PDF) using CD-ROM or Internet/Intranet facilities.
The goal is to have the same information available in electronic or hard copy format. This requires the use of a relational database in most instances. Data / Information is stored as well as pointers to complete documents.

Internet / Intranet

There are 4 tiers or levels to publishing documents on an Internet / Intranet site

1. Static Publishing – This level consists of plan HTML and PDF pages with text and or graphics. The information is static and the same for each user. Links within the pages are single point locations. JavaScript can be used, but is limited in its functionality and scope. Examples of this level are:

Policies and procedures manuals
Static Phone Directories
Reports, memos, and newsletters
FAQs
2. Dynamic Applications – This level provides server side applications that allow the user to query and search the site for information. This is accomplished through the use of CGI, scripts written in Perl, C++, or Visual Basic. The HTML pages are no longer static information but are composed on the fly and delivered to the browser as HTML pages. Examples would be:

Full text / key word searches of the HTML and PDF documents.
Database queries of directories and cross references
Database updates of client records
Virtual documents
3. Collaboration & Workflow – This level provides a form for interactive communication and collaboration. Examples would be:

E-Mail
Calendars and schedules
Conferencing with voice and video
Internal newsgroups
4. Extranets – This level provides for the external communication to suppliers and customers of the Intranet site. The users of an Extranet could have the same or restrictive access to the same documents and applications as an internal user. Examples of Extranet users for the Health Insurance Industry are:

Doctor’s offices
Hospitals
Lavatories
Set-up Considerations

Before developing an Intranet the client should have a clear understanding of their document needs and how they effect their core business processes. This can be accomplished through two channels.

The first is a Critical Document Survey, where documents are mapped to Core Business Process and all aspects of the Document Life Cycle are recorded. With this understanding, key documents can be chosen and studied further to determine the need for re-engineering as well as determining the advantages of Media Independent Publishing.

The second channel of analysis consists of enhanced focus groups and Rapid Assessment and Image Prototype Knowledge Exchange groups. In this groups a behavioral science analysis is conducted to determine the needs of the internal and external users of the knowledge. From the analysis an interface design can be sculpted that will insure knowledge exchange via the Intranet meets the human and business needs of all users.

Approach

Empire Blue Cross Blue Shield of New York has implemented an Intranet site that holds their critical documents as identified in a critical Document Survey. This survey identified 35 documents. The documents were divined across several core business processes and operating divisions. The document were cataloged and ranked according to business priority. Empire commissioned a prototype design and proof of concept Intranet project on recommendations from XPDS.

The project was divided into the following stages:

Architectural design of the logical physical layers of Empire’s Repository of documents and knowledge. This design included both hardware and software.
Design of the navigational aids as well as the home pages for each of the critical document groups.
Prototype designs for the Medical Policy and Benefit Literature documents.
Server side applications.
Recommendations on resources and personnel to manage and run the day to day operations of the site.
Work flow process for the development, testing, quality control, and production of documents placed on the site.
A. Architecture

The development of an Intranet requires that a structure be developed for the clients critical documents. This structure must take into effect both the Logical and Physical make-up of the clients knowledge repository.

1. Logical Layers

This is the association of documents and data and how then relate to each other. Companies have repository of knowledge that can be broken down into smaller sub-groups or layers of documents and data. The following diagram shows the relationship of high to lower levels and how they apply to each other.

Repository – This is the whole of the written corporate knowledge that is assessable.

Library – This is a collection of like knowledge in the case of Health Insurance it would be all Benefit literature, Medical Policies, or Provider Directories.

Family of Documents – This is the collection of books of like information. An example would be Benefit Booklets, Riders, or Contracts.

Documents – Are the individual Booklets for a member or single Riders .

Data Elements and Link – Are the records and paragraphs that make up the documents. At this level there can be paths to other documents the reside in different families and Libraries. This is where Database Publishing starts.

2. Physical Layer

Initial environment – Empire had an infrastructure that consisted of a 16 bit Token Ring network running Novell Netware. The Client had no HTTP servers or TCP/IP protocols running. The workstations were IBM 486 PC’s with 16meg of memory running OS/2 and blank and white high resolution monitories. The workstations would have to stay because of legacy applications.

Hardware – the client agreed to install the following servers with these options:

Two (2) IBM 704 servers with hot back between the servers.
256 meg of RAM for each server
RAID 5 with 4.5 gigabyte of disk space for each server
10x CD ROM for each server
Token Ring card for each server
Fast Ethernet cards, for the hot back-up between the severs
Software – the following software was agreed to for the servers:

NT4 server operating system
IBM WEB Server software
Verity “Search 97”
Software – the following software was agreed to for the workstations

OS/2 Wrap 3.0
Netscape 2.02 version for IBM OS/2
Abode Acrobat Reader 3.0 as a plug-in
B. Navigational Design

The site is designed to provide easy access to the different Libraries within the Empire Document Respiratory. The guiding rule was that a user could navigate from any home page to their document within 4 or less mouse clicks. This navigation goal was accomplished through the use of frames. The browser display area was divided into 3 frame areas:

Top Bar
TOC
DOC
This structure is carried through the whole site, from the top level Libraries, to the Family of documents into the individual documents.

1. Bridge File

The three (3) frames are called through a Bridge file that sets up the viewing area. The Bridge file defines the size and placement of the frames within the viewing area. It is the main file for defining the spatial relations of the site. The general layout is shown below in figure 1. The site requires two (2) bridge files, one each for the Text and Graphic sites. The naming conventions for the Bridge files are:

“TXT_Bxxxxx_x.html” for the Text site (xxxxx_x is the file name or policy number).
“Bxxxxxxx.html” for the Graphic site.

Top_Bar Frame

TOC

Frame

DOC Frame

Figure 1

2. Frame Descriptions

Top_Bar Frame

The Top_Bar frame displays hot links to all Libraries within the Empire Document Respiratory. The design of this frame is such that the navigation bar is always displayed. This is the key to providing quick and easy access across the site. The bridge calls the following Top_Bar files:

TXT_Top_bar.html for the text site
Top_bar.html for the graphic site
TOC Frame

This frame is the Table of Content area. The information within this frame will change depending on the information in the DOC Frame. When the DOC frame is at a Library level, the TOC frame will display major categories in the library, listed by products. As the DOC frame changes, the TOC frame will also change to reflect the sections and sub-sections within the DOC frame. This frame provides hot links into the document that is displayed in the DOC Frame.

Tab1 Clinical (Image Capture 1)

Hot links to tab2 and tab3
Section and Subsection information
TOC hot links to the sections within the DOC frame
Up Arrow hot link to Top of the DOC frame
Tab2 Procedural (Image Capture 2)

Hot links to tab1 and tab3
Section and Subsection information
TOC hot links to the sections within the DOC frame
Up Arrow hot link to Top of the DOC frame
Tab3 Descriptive (Image Capture 3)

Hot links to tab1 and tab2
Section and Subsection information
FAQ hot link to the DOC frame
CPT4 codes used with that Medical Policy
Up Arrow hot link to Top of the DOC frame
DOC Frame

The DOC frame displays the primary contents of the library. From this frame the user is able to access the site’s full text search engine and display the content of the documents. This is also the frame where the Adobe Acrobat PDF and HTML documents are displayed. HTML tables without borders are used throughout this section to ensure alignment for readability.

The sections for this frame are:

Tab1 Clinical (Image Capture 1)

Description
Policy
Policy Guidelines
Benefits
Application
Source
Codes
SMCR

Tab2 Procedural (Image Capture 2)

Type of Service
ICD-9-CM
Diagnosis
Modifiers
Provider
Information
Coding Guidelines
Code Specifications

Tab3 Descriptive (Image Capture 3)

Description
Key Talking Points
Did You remember
FAQ

C. Directory Design and File Name Convention

The site was setup to allow for the easy access of the information within it, directories were made for each library and Document Family. Below is a diagram of the recommended file structure:

:inetpubwwwroot
:InetPubwwwrootbenlit
:InetPubwwwrootbenlithtml
:InetPubwwwrootbenlithtmlbensum
:InetPubwwwrootbenlithtmlbensumbridge
:InetPubwwwrootbenlithtmlbensumdoc
:InetPubwwwrootbenlithtmlrider
:InetPubwwwrootbenlitpdf
:InetPubwwwrootbenlitpdfbooklet
:InetPubwwwrootbenlitpdfcont
:InetPubwwwrootbenlitpdfrider
:InetPubwwwrootcom
:InetPubwwwrooteob
:InetPubwwwrooteobhtml
:InetPubwwwrooteobpdf
:InetPubwwwrooteobpdfinst
:InetPubwwwrooteobpdfprov
:InetPubwwwrooteobpdfsub
:InetPubwwwrootglossary
:InetPubwwwrootimages
:InetPubwwwrootmedpolicy
:InetPubwwwrootmedpolicyhtml
:InetPubwwwrootmedpolicyhtmltab1
:InetPubwwwrootmedpolicyhtmltab1b
:InetPubwwwrootmedpolicyhtmltab2
:InetPubwwwrootmedpolicyhtmltab2b
:InetPubwwwrootmedpolicyhtmltab3
:InetPubwwwrootmedpolicyhtmltab3b
:InetPubwwwrootmedpolicypdf
:InetPubwwwrootprovdir
D. Server Side Applications

Server Side Application are software applications that run on the HTTP Web server or on a specialized server. The application receives its instructions from the user through the browser interface and performs its specific task, upon completion the application returns its output to the browser. This interface between the browser and the application is completed through the HTTP CGI (Common Gateway Interface) standard. An in-depth discuss of the workings of CGI is beyond the scope of this paper.

Current implementation

The Empire site was constructed so that a user could access it in one of two ways:

Through the TOC interface
Through a search engine using the software application “Verity”
The second interface uses the Verity software as a server side application. This software package uses the HTTP CGI (Common Gateway Interface) standard to interface with the client’s browser. Through the use of this package users can search the site for matches on words or phases. The software then presents a list of documents that meet the search requirement. From this list the user can select the document that best meets their needs.

Future Implementations

The implementation has the ability to provide access to a database for searching and querying tabular data. This type of application could provide access and query capability to provider and institutional directories information. (reference White Paper on “Media Independent Publishing” )

E. Human Resources (Staffing)

Client Project Manager and Team Leaders

Because this project has two (2) libraries that are being implemented at once, it was decided that there would be a Team Leader (TL) for each library. The two (2) TL’s would report into a single Project Manager (PM). The duties of the PL’s consist of day to day preparation of the source documentation that would become the HTML document on the Intranet site.

The TL’s interfaced with the Source Matter Experts (SME) that were in the process of rewriting the source documentation.

Site Designer / Architect

This position has responsibility for the business application of the site, design of the site, directory layout, software interface, and over all look and feel of the site. This position interfaces with the Behavioral Science Interface Expert , Technical Writers, Graphic Artist, and other members of the development team.

This position is usually the Team Leader on the vendor’s side and interfaces with the Client Project Manger and Team Leaders.

HTML programmer

This position was used to convert the MS Word documents to HTML and program in links. During the design phase of the project this position can be a member of the Vendor team, how ever the client should provide for a HTML programmer for on going support and future development.

Librarian

This position is the post Team Leader position. It is the responsibility of the Librarian to interface with the SME on new documentation as it is developed for use on the Intranet. Documents are logged and given to the HTML programmer for conversion.

Unity Testing is completed by the Librarian on all new documents. After which the new documents are release to the Web Master for posting and System testing. Reference Work flow process charts 1 and 2.

Web Master

In addition to the basic duties of a Web Master, Installing the Web Server software and implement the directory structure for the site, they were responsibility for the installation the Verity software.

When the HTML document s were ready, the Web Master “System Tested” the documents on the test site and quality assured the site for production. This is the final step before the documents are released to the production site. Reference Work flow process charts 1 and 2.

F. Work Flow Process

Medical Policy Work Flow Process charts 1 and 2 show the steps required to produce, convert, test, and place into production a Medical Policy. The other Libraries have similar work flow processes.

Conclusion

The Intranet provides added features and benefits that the previous system of lose leaf paper publishing could never achieve. The following “problems” and “answers” outline some of these benefits.

Problem 1

The old system could not ensure that the users keep their book up to date, i.e. Updates were sent out with a tracking sheet that need to be completed by the Customer Service Representative (CSR) when he/she completed the update. The old system did not have spot quality checks to ensure the compliance, to the update requests.

Answer

With the new system, updates can be guaranteed that they are in place on time and that the old policies are no longer being referenced after a cut-over date.

Problem 2

The cost of producing and distributing a new policy was $100,000. This included Labor, Materials, Production, Coping, Distribution, and Filing cost.

Answer

The cost of production and distribution for the same policy on the new system is less then 5% of the old way. 30 % of the cost is fixed and 70% is labor.

Problem 3

Because the old system could not guaranteed that the CSR was using the correct policy to adjudicate a claim. Improper payment of claims was a factor.

Answer

At this time there are no figures; However a study is proposed to capture these costs after the Intranet is fully launched and in operation.

The new system is in limited release at the time of this paper. The client is moving forward with the implementation of the system by rewriting old Medical Policies and Benefit documents and placing them on the Intranet. A nine (9) month phased release and training schedule is in place for the new system.

This site uses Akismet to reduce spam. Learn how your comment data is processed.