'Confer' Web-based Communication Service

Draft Documentation Prepared by Richard Rathe, MD on June 24, 2004

Purpose

To provide a secure, simple means of communication between physicians, nurses, clinic staff, and patients.

Background

Email is a powerful means of communication, however, it has several serious drawbacks when it comes to patient care, including:

There is growing interest in systems that use the Web as the foundation for healthcare related communication. Confer is one such system and is described in detail here.

Accounts and Logging In

All users must have an account before they may use the system. Each account is assigned to a group that defines the boundaries for communication (ie, the available clinics, clinicians, and staff). Users login with a unique user ID and password. In most situations the user ID will be the patient's medical record number.

Any established patient may request an account online. Accounts do not become active until they are checked for validity by the clinic staff.

 

 

Typical Workflow

  1. Patient logs in and initiates message to clinician.
  2. Clinician receives an email inviting him/her to read the message. (No patient info, names, etc. are used here.)
  3. Clinician logs into Confer and reads new message.
  4. Clinician replies to message.
  5. Patient receives email notification of reply.
  6. Patient logs into Confer and reads message.
  7. Clinic staff managing the message queue print this exchange for filing in the paper medical record. (This could be replaced with an interface/batch upload to an EMR.)
  8. Messages are moved to an archive once the staff are finished.

Other Specifics

The program also has the ability to queue messages for delivery on a specified date. This can be used for appointment reminders or as a simple todo list. For example, you could send a message to yourself in six months to look for a repeat mammogram report.

The system uses encryption on two levels: 1) SSL for data flowing over the network and 2) the Tiny Encryption Algorithm (TEA) for data stored on the server.

The program will support multiple practice groups with separate data storage areas on the server. Multiple clinics/locations are possible within each group. The program also supports the concept of a "consultant" who might be someone outside our system.