TECH TIPS FROM FRED…(3/98, 4/98, 5/98 Bits & Bytes)

By Fred Henning

Interfaces, Interfacing and Integration. Last month I mentioned that parsing of data is often part of an interface between systems. Before we get to Interfacing and Integration, topics that I have been lecturing on at seminars for a number of years, I would like to use this article to talk about the Human Interface.

When people use computers the program has some type of Human Interface. At present the AlexIS system, the ABHP TXEN system, the Bonaventure SDM system and many others still have Command Line Interfaces. The idea is that the program offers the user a question on the bottom line of the screen and the user responds by entering some data. Often the data is a number or letter associated with a Menu Item. In other parts of the program the user fills in blanks on a screen. These are also called character based systems.

Windows based programs expect the user to click on graphical representations of a button on a screen to respond to the program. Windows programs also have areas on the screen that can be filled in by a user. This type of Human Interface is called a GUI (goo e) or Graphical User Interface.

The newest user interface is the Browser (Internet Explorer, Netscape, etc.). Until the last year or so, the Browser was used exclusively for access to programs and data over the internet. It is something like Windows in that it is graphical but it tends to have an uncluttered screen, few buttons or special functions as seen in typical Windows programs. Because the screens are less cluttered and it doesn't appear to require a Manual or Class to learn; progressive programmers have begun to use the Browser as the Human Interface of choice. (There are many other technical reasons why this is being done but none of them would count if it weren't for the Browser's ease of use.)

The 80, 20 rule! Programmers and/or marketing always seem to go overboard on things. Use of a Browser, as the program interface, will fall victim to this disfunctionality. A Browser is great for the 80% of users who need to get some selective data from a system or just input a small amount of information. The 20% that are called 'heads down' users will still need Human Interfaces that are designed to provide the most efficient work flow and ergonomics.

The unfortunate part of the Human Interface issue is that we very seldom are able to control the look and feel of the screens we use to view and/or input data. Even when we have the capability we may not listen to the end user. As I mentioned last time, I had written a new program to download data from AlexIS, etc. Jean Friedman (Lab) installed the program and immediately called to tell me about some Human Interface issues with the screens! (Jean is taking programming courses and knows what should be able to be done.) On the first screen of the process I had the UNIX file path, UNIX file name, PC file path then PC file name. On the second screen it was UNIX file name then path and PC file name then path. Even though the program worked correctly it was obviously not as good as having the sequence be the same from screen to screen. Since I wrote it I could make the change, and for other users it would be better because it would be less confusing. Perhaps, in the not too distant future, the technology that allows a Browser to work so well will allow us to make simple changes, for the convenience of the end user, even when we did not write the program.

Next time I will begin a discussion of Interfaces and Integration at the system level.

Interfaces, Interfacing and Integration – Part 2

When ABMC selected HBOC as our new hospital information system in 1991, a major determining factor was that the HBOC STAR system (which we call AlexIS) was comprehensive and integrated. Since then ABMC and the ABI Enterprise have established a close working relationship with our information systems vendor, HBOC, because HBOC has a vision of an Enterprise that paralleles the ABI vision of what a healthcare delivery system will look like by the year 2000 and beyond. One very important part of the vision is that HBOC will be responsible for the interfacing of hardware and application information between the various systems they provide.

There are two parts to system integration. The first part is the physical connection that allows information to flow from one system to another. ABMC made a significant technology decision in 1991 when we started the process of establishing a network to connect users and systems. We established TCP/IP as the basic low level protocol for moving information and that any other system protocol had to be compatible. TCP/IP stands for Transmission Control Protocol / Internet Protocol. Therefore, we were also going to be Internet compatible. The Novell IP/IPX protocol used for the Office Automation part of the network fit this model. When we bought the TrendStar Decision Support System, which runs on a DEC computer, we were the first client to require it be set up for TCP/IP. The same was true when the TXEN System was purchased for ABHP. This system runs on an IBM AS400 and those installing the system had never set one up for TCP/IP.

Once you have the ability to move information around on the wires, between systems, the next part is a little more complex and may require an interface engine. An interface engine is a computer that acts like a translator. One system sends out data in a particular sequence but the receiving system wants to see it in a different sequence. A very simplistic example: system 'A' sends first name followed by a ^ symbol then the middle initial and another ^ symbol then the last name and a ! symbol saying it is done. The receiving system 'B' wants to see last name,first name,initial,. The interface engine will do the translation. The actual configuration of an engine is much more complex than as illustrated in the diagram. If you want to know about all of the detail, send me an e-mail (HenningF) and I'll send you more info. We use a very powerful UNIX computer with the HBOC Interface Manager software to communicate between the various HBOC supplied systems. We use an NT based integration software system called MicroScript to communicate between non-HBOC supplied systems and HBOC or other non-HBOC systems. Our overall goal is to be able to connect anything to anything and provide integrated information to the user.

Next time I will talk about the process of mapping information between systems and the concept of a data repository.

Interfaces, Interfacing and Integration – part 3

This is the final part of this series. I will try and illustrate several of the remaining concepts used to integrate information.

In 1989 ABMC was still using the PHS Financial System & EDI Order Entry computer system. We had an interface between these systems that allowed patient registration information, orders, charges, etc. to pass from EDI to PHS. (These were the two vendors with the most installed Hospital Information Systems just as HBOC is the big guy today.)

PHS hired a very respected individual, John Quinn, to manage the upgrade of their software. He in turn became part of a group of about 12 individuals that developed the HL7 interface standard for Health Care, first published in September of 1989. Today, HL7 is as close to a Standard as you get in Health Care Computing. HBOC uses HL7 extensively as the format for the information that passes between the various Pathway 2000 systems they sell.

ABMC therefore has a low level communications protocol, (TCP/IP), which establishes connection between systems, a high level protocol that establishes formats for the data elements moving between systems (HL7) and an interface engine, (Pathways Interface Manager), that operates on the data and acts as a traffic cop between systems. We also have our MicroScript System for non HBOC supported interfaces.

What's the problem? ABMC, ABHP, etc. use some non-HBOC systems. Because we have non-HBOC systems we have the issue of mapping what we need to address.

Mapping is the most critical issue when data is exchanged between systems. As you have seen, the hardware, transmission protocols, etc. have been addressed but mapping the data is something which takes much more time, energy, communications and politics. Mapping is the part of the interface process that says that a ‘2’ in system 'A' is equal to ‘female’ in system 'B'. A trivial example. Now a hard one, System 'A' is a clinic and system 'B' is a hospital. How do you map a patient visit of 'school physical' or 'booster shots' to a Hospital visit type? Do you simply choose 'Outpatient'? What happens to that level of detail that is lost? Unless everyone that is involved with the Enterprise understands this concept, some very poor decisions are made and information is lost.

The final concept, the idea of a data repository, flows from the above. A data repository, data warehouse, data bank or whatever name you give it is a very large computer data base filled with various discrete data elements from the main Hospital Information Systems and other Information Systems. The concept can be to provide a continuous record of information, clinical and otherwise, for an individual that, at some point, becomes part of your health care enterprise. In theory this information allows for better and less costly care, particularly in a managed care environment.

When you look at data integration as it relates to an enterprise data repository, the total number of data elements you collect, and how data is mapped becomes the issue. This is the point in time I usually take 20 minutes to expound upon the qualifications for the individual responsible for the mapping, the concepts of just storing discrete data elements out of context versus storing them in context and similar topics. I'll save this for another time.