A reasonable clinical front-end "client" program should be intuitively easy to use and should meet most of the regularly recurring data needs of the clinician and the clinician-manager. Here are a few examples of common tasks that have proven difficult to do using some of the commercial systems we have seen.

 

Clinical Care Tasks Examples of common clinically-related tasks that should be easily performed by a clinician using the client software.
	For a patient named John Smith, find out to what service and what bed the patient was admitted, and who is listed as the admitting attending.
	Find the patient I saw in the office "some day last week" who had a complaint of palpitations, and see the results of her chest x-ray.
	Show me all the patients I saw yesterday who had an abnormal test result.
	Find the lab and x-ray results for a patient given only the patient's name, when the spelling of the name is uncertain.
	Find a patient by medical record number or by account number.
	Show me all prior diagnoses and procedures for a patient.

 

 

Clinical Management Tasks Examples of "typical" tasks requested by clinical managers, chairs, and departmental administrators.
	Show me all the patients admitted to Internal Medicine since midnight who have Kaiser insurance.
	Show me all the patients admitted yesterday or today who have a glucose over 200.
	What was the distribution of presenting complaints in patients who died in-hospital over the past 9 months?
	How many patients in my department had a diagnosis of "thrombophlebitis" since the beginning of the year?
	How many lumbar punctures were performed on patients in my department last month?
	Show all patients who returned to the hospital within 3 days after discharge.
	Show all patients who had an abnormal biochemical marker for acute MI this month.
	List every diagnosis given to a patient in my department for the past year, in descending order by the number of times that diagnosis was used.

 

 

Openness

An open system is one that conforms to published, well-documented, non-proprietary industry standards in the way it receives data, stores the data, and delivers the data in response to a query.

 

The mere fact that a product "uses" open standards internally does not make it "open" -- to be open, the product must accept incoming data via open standards, must accept standards-based queries for every stored data element, and must respond to a query by delivering data in some open standard format.

 

Linking and Joining to external datasets

The most important reason for having an open system is that we want to be able to join our enterprise-level data  to departmental datasets and to external benchmarking datasets "on the fly." This is critically important because the value of a single item of data is much greater when that item can be linked to all the other items of data for the same patient, the same caregiver, the same department -- or any other cohort.

 

Example: we have an ODBC-compliant database of all contaminated blood culture specimens listed by patient account number. The database is updated on an ongoing basis. We wish to join this database to the enterprise dataset, to the credentialling office dataset, to the pathology dataset, and to other external datasets so that we can display such things as the fraction of contaminated cultures for which the patient subsequently had true-positive culture results, grouped by the organisms involved. Once the linkages have been defined, we can easily display the answers to a wide of clinically important questions, such as the fraction of contaminated cultures, cross-tabulated:

• by room
• by floor
• by physician
• by nurse
• by number of days in hospital
• by site of draw
• by number of years of experience of the person who drew the blood
• by number of months since a blood culture draw in-service training course was completed
• by type of line from which the draw was taken
• Etc.

 

Example: we have a cardiovascular surgery database stored in an ODBC compliant form in an offsite dataserver. We wish to reduce the number of data elements that must be keyed into the database by linking to the enterprise database for all the data elements that already exist. We also wish to increase the usefulness of the cardiovascular data by "marrying" it to all the other data that exists for the patient. Instead of re-entering all the patient's demographic data into the cardiothoracic database, we will enter only the patient's acccount number, and will link to the enterprise dataset "on-the-fly" to obtain

 

• Admission and discharge date and time
• Age, sex
• Patient identifiers
• Lab results (e.g. first, last, highest, lowest)
• X-ray results
• Medications given
• Dictated summaries
• Prior diagnoses and procedures
• Cardiac catheterization reports
• Etc.

 

 

Reducing dependency on an outside vendor

Another important reason why an open system is essential is that we cannot afford to be totally dependent on a single vendor every time we want to add some new data source to the system and every time we want to pull some data out of the system for re-display in some customized way to meet the needs of a specific department or a specific user.

 

No two clinical users are exactly alike, and it is naïve to expect a single front-end solution to meet the needs of every clinical department. It is vitally important that we be able to purchase or develop department-specific systems that can work with enterprise data to meet specific needs as they arise.

 

Clinical operational data is an extremely valuable asset that can help us to improve our processes and our productivity. In today's rapidly changing medical marketplace, we need to be able to work with that data in as rapid and flexible a manner as possible. We simply cannot afford to wait for a single vendor to make changes or additions to a proprietary data system. Vendor-supplied solution cycle times are on the order of 12 - 24 months, while local departmental solutions can be purchased (or developed) and linked to an open enterprise database at least ten times faster.

 

To demonstrate openness, a system should be able to

• Receive and store new data types from a new data source through an open interface. An example would be the ability to connect to an infrared badge locator system and to receive and store a stream of transactions showing the exact physical location of a patient at any time.
• Publish a complete description of all stored data elements, relations among data elements, and sources for data elements.
• Respond to any valid standard ODBC query for any existing data elements by delivering the requested data in ODBC format.
• Participate in a "Join" of any internal view or table with other views or tables that exist in external ODBC-compliant databases. The user will be able to build queries using any data element that exists in any of the joined databases, just as though all the data elements belonged to a single large database. Examples would be the ability to link the enterprise database to the cardiovascular surgery database, to the infection control database, or to the Emergency Department databases.

 

 

Definitions

ODBC    Open database connectivity.

SQL       Structured (standard) Query Language.

HL-7      Health Level 7 data exchange format.

TCP/IP   Transmission Control Protocol / Internet Protocol.

Sockets  A standard for passing data from one software application to another using TCP/IP.

Join        A standard method for linking two data tables so that they behave as though they were one.