WO1999045453A2 - Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications - Google Patents

Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications Download PDF

Info

Publication number
WO1999045453A2
WO1999045453A2 PCT/US1999/004960 US9904960W WO9945453A2 WO 1999045453 A2 WO1999045453 A2 WO 1999045453A2 US 9904960 W US9904960 W US 9904960W WO 9945453 A2 WO9945453 A2 WO 9945453A2
Authority
WO
WIPO (PCT)
Prior art keywords
medical
information
data
document data
phone
Prior art date
Application number
PCT/US1999/004960
Other languages
French (fr)
Inventor
David P. Rohler
Thomas A. Dechant
Michelle F. Boasten
Original Assignee
Plexar Associates, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Plexar Associates, Inc. filed Critical Plexar Associates, Inc.
Priority to AU30705/99A priority Critical patent/AU3070599A/en
Publication of WO1999045453A2 publication Critical patent/WO1999045453A2/en

Links

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Definitions

  • the present invention generally relates to a system for generating
  • the remote from a central office to carry out a particular task.
  • the remote is a remote from a central office to carry out a particular task. For instance, the remote
  • locations could be locations around the state, county or city in which the central office
  • the remote location could merely be various locations aroimd a
  • central office e.g., rooms in a hospital, nursing home,
  • remote location e.g., visiting nurse, home health aide, social worker, allied therapy professional, service technician, etc.
  • a client e.g., a patient or customer
  • a device e.g., an appliance
  • the individual at the remote site may need to document tasks performed, test results, conditions observed, and other information pertinent to the task.
  • the present invention addresses the problems presented by both paper-
  • a still further advantage of the present invention is the provision of a
  • Still another advantage of the present invention is the provision of a document information system that tracks supplies used to complete a task.
  • the invention may take physical form in certain parts and arrangements of
  • Fig. 1 is a block diagram of the basic hardware configuration for a
  • Fig. 2A is a block diagram illustrating the basic software configuration for
  • Fig. 2B is a block diagram illustrating the basic subsystems of the present invention.
  • Fig. 3 is a flow chart illustrating operation of the GUI module
  • Figs. 4A-4D are flowcharts illustrating a series of basic operations of a
  • Fig. 5 is a flowchart illustrating a phone task procedure
  • Fig. 6 is a flowchart illustrating a sign-in procedure
  • Fig. 7 is a flowchart illustrating a chart selection procedure
  • Fig. 8 is a flowchart illustrating a voice mail retrieval procedure
  • Fig. 9 is a flowchart illustrating a voice mail sending procedure
  • Fig. 10 is a flowchart illustrating a visit documentation procedure
  • Fig. 11 is a flowchart illustrating an information retrieval procedure
  • Fig. 12 is a flow diagram illustrating operations of a verification module
  • Figs. 13A-13D are exemplary calendar displays generated by the
  • Fig. 14 is a flow diagram illustrating the flow of narrative data
  • Figs. 15-40 illustrate an exemplary chart generated in accordance with the
  • the present invention finds utility in any application where data is generated and/or accessed by persons located at a
  • document data refers to any data acquired, processed, stored or retrieved via the document information system of the present
  • FIG. 1 shows the basic hardware configuration of the document
  • Document information system 10 is generally comprised of a
  • computer server system 30 one or more workstation computers 80, output means 90, and
  • Phones 20 are the primary interface device to document information system 10 for field users, and may take many forms including a standard telephone, a portable phone, cellular phone or Internet telephony device. Phones
  • numeric input from a user via a phone keypad, and accept verbal responses from the
  • document information system 10 A complete description of the operation of document information system 10 will be provided below.
  • Server system 30 is generally comprised of a phone server 40, a database
  • server 60 and a network server 70. These servers can reside on a single computer system
  • communication paths "Al" and "A2" may be within a single computer system, or
  • a computer network such as a Local Area Network
  • LAN Local Area Network
  • WAN Wide Area Network
  • Internet the Internet
  • the servers 40, 60 and 70 may include one or more computer systems.
  • phone server 40 is located at a different location.
  • a high-speed communications network may be
  • server 40 is a dedicated PC computer running Windows NT operating system.
  • Windows NT operating system
  • voice cards e.g., Dialogic or Dialogic-compatible
  • Dialogic or Dialogic-compatible are installed in this computer.
  • the primary function of the voice cards is to provide an electronic interface by converting
  • Phone server 40 is basically responsible for such items as answering phone calls, collecting data entered by the user
  • Database server 60 provides a database including a plurality of database
  • the database takes the form
  • Database server 60 is basically
  • the database includes
  • VISITS information about client visits, e.g. date, time, mileage,
  • EMPLOYEE employee's personal, employment, specialty, access information
  • ACTIVITY LOG activity information collected by what was done by phone
  • CLIENT INFORMATION FORM information about the care plan, e.g.,
  • database include lookup tables such as PHYSICIAN (referral physician's name, office
  • ADDRESS states, cities, and zip codes
  • INSURER insurance
  • HOSPITAL hospital information
  • NUTRITIONAL REQUIREMENT client's nutritional requirements
  • MEDICATION medication name, category, and
  • database server 60 stores digitized voice data, such as voice
  • Network server 70 provides the communication between workstation
  • server computers 70 to enable the network communications.
  • Workstation computers 80 provide a computer-based interface to servers
  • These computers may be located in a central office, a branch office, or a remote
  • Workstation computers 80 are typically connected with servers
  • a communications path B may also be linked via a modem, or other
  • path B is a primary
  • communications path of document information system 10 may include one or more
  • LAN Local Area Network
  • Wide Area Network Wide Area Network
  • Network(WAN) and the Internet.
  • Workstation computers 80 may serve one or more functions. In this case
  • workstation computers 80 may be used to access and configure documents on
  • workstation computer 80 serves as a substitute user interface for phones 20
  • workstation computer may take the form of a portable laptop computer for convenient field use.
  • GUI Graphical User Interface
  • GUI module 82 will be described in detail below.
  • Workstation computers 80 may also provide a service interface to document information
  • system 10 for technicians to service document information system 10, and serve as a
  • workstation 80 may also include a
  • the audible voice data may be subsequently played back (e.g., like a cassette player),
  • voice data like a cassette player, using a software interface, or mechanical foot pedal
  • text data into text data (e.g., human-readable narrative text or messages).
  • text data e.g., human-readable narrative text or messages.
  • voice messages may be automatically converted to text data using well known
  • workstation 80 may also include an audio input means (e.g., a
  • a workstation 80 could be used to record a voice mail message that is associated with a user, such that when the user is logged into document information
  • the previously stored voice mail message is replayed to the user.
  • Output means 90 provides a human-readable output (e.g., hard copy) of
  • output means 90 may take the form of
  • printers one or more printers, fax machines, plotters, or other hard copy display devices.
  • output means 90 could take the form of an electronic mail gateway.
  • Communications interface 100 provides yet another interface for accessing
  • communications interface
  • communications interface 100 provides a dedicated communications path for technical
  • communications interface 100 is also suitable for use in the same manner
  • communications path B e.g, to connect a workstation computer.
  • the present invention includes phone modules 42, GUI modules 82, interface modules 92 and utility modules 102 (Fig. 2B). Each of these modules communicates
  • Fig. 2A there is shown phone modules 42 running on phone server 40.
  • a suitable software package such as Visual Voice, may be used to
  • Phone module 42 provides a "voice user interface” (VUI) to
  • Phone driver 41 is a software module that supports all
  • a main phone task module 200 (Fig. 5) provides the main logic stream for
  • each phone call activates various basic function sub-modules (i.e., user sign-in module
  • User sign-in module 44 accepts and verifies a user ID associated with a user.
  • Each user ID is associated with a user "type.”
  • a “type code” is stored in
  • the "type code” is used to control access limits and scope of
  • codes may be user-defined. Moreover, the concept of "type” may be extended to other
  • client-type may be established and
  • the chart may also include
  • client identification information (e.g., a client id) for identifying the client that the chart is
  • Visit documentation module 46 allows a user to enter visit information
  • Voice mail module 48 allows a user to retrieve and send
  • the messages may be "keyed" to a user ID and/or a chart ED, thus
  • Information retrieval module 50 Associating a message with a particular user or client.
  • Information retrieval module 50
  • This information may be in the form of alphanumeric or keyword phrases that are
  • This module can also trigger
  • narrative and voice mail messages are preferably digitized for storage in a digital
  • Database server 60 allows multiple processes to simultaneously access
  • database server 60 supports local and remote access to database files 62 with a variety of network schemes.
  • database server 60 supports local and remote access to database files 62 with a variety of network schemes.
  • server 60 provides many data integrity checks and controls access to database files 62.
  • Database server 60 stores files and tables, including those relating to:
  • agency information i.e., employee information, payor information, client (i.e., patient) information, task codes (summary of activities), visit data, treatment plan data, narrative voice files, voice mail files, and voice files for prompts supporting multiple languages.
  • client i.e., patient
  • task codes summary of activities
  • visit data treatment plan data
  • narrative voice files narrative voice files
  • voice mail files voice files for prompts supporting multiple languages.
  • GUI modules 82 run on workstation computers 80, and include several
  • GUI modules 82 A main_user_interface 104 of GUI modules 82 will now be
  • a user sign-in routine is executed to accept and verify
  • a user ID (step 106).
  • a user "type" code is associated with each user ED is retrieved for
  • the "type" code is used to control access limits and
  • document information system 10 may be limited to users having a "type"
  • step 108 code for system administrators. If the user's "type" code is for system administrator then a first series of menu choices are made available to the user (step 110).
  • the menu choices may include updating agency information (step 112 A), data
  • step 112B updating supplies records (step 112C), updating employee
  • step 112D updating payor records (step 112E) and updating physician records
  • client-type may be established and stored as
  • the documentation system 10 is keyed to the "client type.”
  • the chart may also include client
  • identification information (e.g., a client id) for identifying the client that the chart is
  • Updating agency information 112A includes such functions as updating the address of a health care provider.
  • Data maintenance 112B includes such functions as
  • Payor information is updated in 112E.
  • menu choices may include initial admission (step 118 A), documentation
  • step 118B logs and reports (step 118C), chart review (step 118D), new client setup
  • step 118E For initial admission, a chart ID associated
  • step 118A With the client is established in step 118A, and basic client information is entered in step 118E.
  • Documentation 118B allows a visit to be documented in a manner similar
  • review 118D allows the user to retrieve and view information in a client's chart.
  • Transcription 118F allows transcription of any voice data files (i.e., narrative and voice
  • the transcription capability also includes special coding for user-defined fields embedded in voice files, as will be described in further detail below.
  • One or more interface modules 92 are run on workstations 80 or database
  • the interface modules are provided for communicating data between database
  • interface modules 92 may include a
  • billing interface module for providing automatic data communication between database
  • interface modules 92 are provided to transfer data between
  • database server 60 and a remote computer system (e.g., a regulatory agency computer)
  • a remote computer system e.g., a regulatory agency computer
  • a regulatory data transmission module supports collection and summary of data for periodic regulatory
  • the interface module 92 provides the capability to
  • 100 may be directly connected (via modem) with a remote technical support
  • a backup/restore module provides for automatic activation of a backup of
  • a database maintenance module provides periodic database maintenance which may be both automatic and semi ⁇
  • Features may include: monitoring of available database server space,
  • a service module provides the
  • server system 30 can automatically initiate a message based on the detection of some
  • An invoicing module provides the capability for service invoices to be
  • the first operation is a New_phone_call
  • System 10 answers the incoming phone call (step 122) and calls a
  • get_menu subroutine for choosing a desired communication language (step 124).
  • system 10 may be configured to communicate with the user in French, Spanish or Russian.
  • the get_menu subroutine will be described in detail below. The selected
  • the get_menu subroutine 140 is illustrated by the flowchart shown in Fig.
  • This subroutine allows the user to select a menu option.
  • System 10 issues a prompt
  • the computer system may say: “Please select from one of the following three choices" The system then accepts an input response from a telephone keypad or a user-spoken response
  • step 144 a simple voice
  • recognition module is provided to interpret simple user responses such as "one, "two,”
  • the response is evaluated to determine if it is a valid response (step
  • a menu selection is returned (step 150).
  • a get_narrative subroutine 160 is illustrated by the flowchart shown in
  • Fig. 4C This subroutine is used by system 10 to record a narrative message input via a
  • the system issues a prompt (step
  • step 162 begins accepting a voice response containing the narrative (step 166).
  • step 166 the voice response is played backed over the phone (step 168). If no review is
  • get_menu subroutine is called to query the user whether they want to
  • step 170 If the narrative is not accepted then the subroutine returns
  • the get_numeric subroutine 180 is illustrated by the flowchart shown in
  • This subroutine is used by system 10 to prompt a user for a numeric (or
  • step 182 begins accepting a numeric keypad entry from the phone keypad or a user- spoken response. It is determined whether the keypad entry is valid (step 186). If the entry is not valid, then an invalid entry message is issued (step 188) and the subroutine
  • step 190 the user whether to accept the entry. If the entry is not accepted, then the
  • This routine provides a format for communications
  • routine 200 as shown in Fig. 5 is provided solely for the purpose of
  • routine 200 may
  • a user_sign_in routine is
  • step 202 executed (step 202), where the user signs-in (i.e., enters a "user id") to document
  • the user identifies themself to
  • step 206 voice mail associated with a "user id" and/or "chart id” is retrieved.
  • the get_menu subroutine is called to query the user as to a desired function (step
  • a visit documentation routine (step 210) and an
  • the visit documentation routine allows a user to
  • the information retrieval routine allows a user to retrieve information stored in database files 62.
  • a send_voice_mail routine is executed (step
  • Fig. 6 is a flowchart illustrating user_sign_in routine 220. Each user has
  • an associated user id and user type By entering the appropriate user id, a user can access information associated with the user id and user type corresponding to the user id.
  • get_numeric subroutine is called to prompt the user to enter a "user id" (step 222).
  • Fig. 7 is a flowchart illustrating chart_id_selection routine 230.
  • getjnumeric subroutine is called to prompt the user to enter a "chart id" (step 232).
  • step 236 If the "chart id" is not valid, then an invalid chart id message is issued (step 236), and the routine returns to step
  • Fig. 8 provides a flowchart illustrating the get_voice_mail routine 240.
  • the voice mail message is retrieved from database files 62 (step a).
  • the time, date and message sender of the retrieved voice mail message is issued, i.e., spoken over the phone (step 246).
  • the get_menu subroutine is called to determine if a reply is
  • step 252 If no reply is desired, the routine returns to step 242 to determine if
  • send_voice_mail routine is called (step 254). Thereafter, the routine returns to step 242. It will be appreciated that in addition to a "reply desired?" query, the user may also be
  • voice mail options such as replay, forward, delete, save, etc.
  • Fig. 9 illustrates a flowchart for a send_voice_mail routine 260. First, it is
  • step 262 determined whether the user has any voice mail messages to send. If there are
  • the get_numeric subroutine is called for entry of a "recipient id" (step 264). It is
  • step 266 determines if the "recipient id" is valid. If the "recipient id" is not valid, then
  • step 270 the get_narrative subroutine is called (step 270) to
  • the message is stored in the database
  • step 262 to determine if any additional voice mail messages are to be sent.
  • FIG. 10 there is shown a flowchart for
  • visit_documentation routine 280 This is the main routine for recording information
  • the get_numeric subroutine is called in succession to allow the user to enter a visit start time (step 282), to enter a visit stop time (step 284), and to enter
  • the measured data items are stored in a table.
  • the user is prompted to enter data for measured data items indicated in the table as being
  • step 290 The routine then returns to step 288 to
  • the task codes are codes associated with the completion of different tasks
  • step 294 the get_numeric subroutine is called (step 294) for entry of the codes, and the routine returns to step 292.
  • step 296 determined whether any supplies were used during the visit to complete a task.
  • get_numeric subroutine is called to enter a supply code (step
  • This narrative message may include such information as the condition of the
  • get_menu subroutine is called to query the user whether they want to review all of the visit documentation that
  • step 302 If a user wants to review the visit documentation, then the
  • routine returns to step 302. If a user does not want to review the visit documentation,
  • Fig. 11 is a flowchart illustrating information_retrieval routine 320. This routine allows a user to retrieve visit documentation which has been stored in database
  • the get_menu subroutine is called to allow the user to choose a retrieval method
  • step 322 If the user selects "fax" retrieval steps 324-330 are executed. In particular, a
  • subroutine is called to allow the user to enter a fax number where the information will be faxed (step 328). Faxes are then sent to the specified number for the selected visits (step 328).
  • step 338 where the get_menu subroutine is
  • routine returns to step 322. If no additional information is desired, the routine is
  • steps 332-336 In the case where a phone retrieval is selected at step 322, steps 332-336
  • subroutine is called to determine if the user desires to retrieve any additional information.
  • GUI module 82 includes a verifier, which allows
  • the verifier provides a convenient, easily visualized, color coded
  • FIG. 12 there is shown a data flow diagram for use of
  • a plan e.g., a treatment plan
  • visit documentation is generated using a phone (step 2).
  • a "phone verifier” (step 3) is used to determine if the user is authorized to complete a task. For instance,
  • document information system 10 determines whether a due date has passed for
  • system 10 may be programmed not to accept visit documentation, or to trigger an
  • authorization request from an appropriate authority. For instance the authorization
  • request may be for additional visits by a particular type of home health care professional.
  • a verifier output is generated on a workstation monitor (step 4).
  • a hard disk drive Alternatively, a hard disk drive, a hard disk drive, or a hard disk drive.
  • the verifier of GUI module 82 displays a visit pattern information in the form of four calendars: (1)
  • Verifier Calendar which displays a summary of comparisons of the What
  • Calendar includes the following information (in a first color): (a) Date; (b) Who -
  • Calendar includes the following information (in a second color): (a) Date; (b) Who - discipline (RN, HHA ,etc); (c) When - the visit time and hours (if required) have been
  • Fig. 13C there is shown an exemplary Verifier Calendar
  • FIG. 13D there is shown an exemplary Ultimate Auditor
  • the Ultimate Auditor calendar provide verification results for such items as:
  • HHA CP health aide - care plan
  • HHA CPU home health aide - care plan update
  • document information system 10 can generate
  • narrative voice files may include "custom" data that is not
  • document information system 10 is part of a standard pre-defined document. Accordingly, document information system 10
  • the customized document is typically a
  • Fig. 14 shows a data flow diagram for narrative data.
  • a user speaks into a phone (step 410) to record narrative voice data, which may
  • a narrative voice file is
  • step 412 the narrative voice data is converted to
  • a user may speak into the phone: "Mr. Smith refused to take a shower this morning. Client slept for about one hour this afternoon.
  • each item of the narrative text is recognized as "custom" data or keywords. Therefore, when they are encountered the narrative text may be encoded with encoding symbols. For example, each item of
  • custom data may be surrounded by brackets such as: [company car] [two miles] .
  • documentation system 10 may be programmed to
  • encoding (e.g., brackets) is needed.
  • the contents of the narrative text file may be displayed on the monitor of
  • the narrative text file may also be output to
  • an interface program e.g., a billing / payroll interface program
  • the interface program looks for the encoding symbols
  • the input file includes predefined data fields
  • a billing/payroll system that are recognized by another computer system, such as a billing/payroll system.
  • custom data is inserted into the appropriate predefined data fields.
  • the data stored in the predefined data fields in then output to another computer system, such as a billing/payroll system (step
  • Figs. 15 - 40 illustrate a complete chart as generated by document
  • FIGs. 15A-15B show an exemplary client
  • FIG. 16 show an exemplary history and physical report
  • FIG. 17C show exemplary 485 forms
  • Figs. 18A-18B show exemplary 487 forms
  • FIG. 20A-20B shows exemplary visits report
  • Fig. 21 shows exemplary medications report
  • Fig. 22 shows exemplary lab tests & results
  • Fig. 23 shows exemplary case comments report
  • Figs. 24A-24D shows an
  • HHA home health aide
  • Figs. 27A-27C shows an exemplary history and physical report from an occupational therapist (OT)
  • Figs. 28A-28B shows an exemplary history and physical
  • Fig 29 shows an exemplary history and physical report from a social
  • Fig. 30 shows an exemplary home safety assessment report
  • Fig. 31 shows
  • Fig. 32 shows an exemplary case
  • Fig. 33 shows exemplary case manager's comments
  • Fig. 34 shows an
  • Fig. 35 shows an exemplary audit page
  • Fig. 36 shows an
  • Fig. 37 shows an exemplary calendar report
  • FIG. 39 shows an exemplary visit report
  • Fig. 39 shows exemplary phone instructions
  • Fig. 40 shows an exemplary visit report
  • keypad data entry may be replaced with a voice recognition system to allow a user to

Abstract

A document information system including both a phone-based user interface and computer-based user interface for simple and intuitive data entry and retrieval. The document information system includes a phone server for phone communications, a database server for storing data, and at least one workstation computer providing a graphical user interface.

Description

PHONE-ASSISTED CLINICAL DOCUMENT INFORMATION COMPUTER
SYSTEM FOR USE IN HOME HEALTHCARE, POST-ACUTE CLINICAL
CARE, HOSPICE AND HOME INFUSION APPLICATIONS
Field of Invention
The present invention generally relates to a system for generating,
managing, accessing and storing documents and document data, and more particularly to an automated document information system which uses a phone as an optional or adjunct
user interface for information input and output.
Background of the Invention
There are many industries (e.g., home health care services, on-site
maintenance and repair services, and the like) which require workers to travel to locations
remote from a central office to carry out a particular task. For instance, the remote
locations could be locations around the state, county or city in which the central office
site is located. Moreover, the remote location could merely be various locations aroimd a
large facility where the central office is located (e.g., rooms in a hospital, nursing home,
factory, office complex, etc.). In many cases, there is a need to generate and/or receive
information related to the task carried out at the remote location. The individual at the
remote location (e.g., visiting nurse, home health aide, social worker, allied therapy professional, service technician, etc.) may need to access up-to-date or important
information about a client (e.g., a patient or customer), or a device (e.g., an appliance), before beginning or completing a task. Moreover, the individual at the remote site may need to document tasks performed, test results, conditions observed, and other information pertinent to the task.
In the field of home health care, paper files have typically been used to record client information and document visits. Paper files have several serious
drawbacks. In this regard, they are time consuming to generate, difficult to maintain, and
easily corrupted. Moreover, they are often illegible, require the use of costly paper
media, and are expensive and time consuming to duplicate.
While the use of a laptop computer or other handheld data entry device
can reduce the reliance on paper documents, laptop computers and other handheld data
entry devices pose their own problems when used in the field. Among these problems, they are costly to purchase and maintain. They also require the personnel in the field to
have at least basic typing skills. Many people find typing more cumbersome and time consuming than handwriting. Laptop computers are also prone to theft and damage when
used in the field. Furthermore, field personnel must be trained on the use of the computer
and the associated software.
The present invention addresses the problems presented by both paper-
based and entirely computer-based document information systems, as well as other
drawbacks of the prior art.
Summary of the Invention According to the present invention there is provided a document
information system for entering, retrieving and managing document information
including both phone-based and computer-based user interfaces.
An advantage of the present invention is the provision of a document
information system that allows for increased productivity and simplicity for tasks
requiring data acquisition, document generation and information retrieval.
Another advantage of the present invention is the provision of a document
information system that has simple, intuitive and friendly user interfaces.
Another advantage of the present invention is the provision of a document
information system that has both phone-based and computer-based user interfaces.
Another advantage of the present invention is the provision of a document
information system that generates accurate, complete and legible documents.
Another advantage of the present invention is the provision of a document
information system that reduces the opportunity for entry of erroneous or fraudulent
information.
Another advantage of the present invention is the provision of a document
information system that does not require expensive equipment for use in the field.
A still further advantage of the present invention is the provision of a
document information system that significantly reduces the reliance on paper-based
documents. A still further advantage of the present invention is the provision of a
document information system that can be interfaced with billing, payroll, scheduling and
other computer systems.
A still further advantage of the present invention is the provision of a
document information system that allows for data entry solely through spoken words and
keypad entries.
Still another advantage of the present invention is the provision of a
document information system that allows for multi-lingual communications.
Still another advantage of the present invention is the provision of a document information system that allows the generation of complex documents using a
phone as the primary data acquisition input device.
Still another advantage of the present invention is the provision of a
document information system that allows previously stored document information to be
retrieved and reviewed over a phone.
Still another advantage of the present invention is the provision of a
document information system that generates customized data fields for associated
computer system.
Still another advantage of the present invention is the provision of a
document information system that verifies completion of events related to a task.
Still another advantage of the present invention is the provision of a
document information system that verifies authorization for a user to complete a task. Still another advantage of the present invention is the provision of a document information system that tracks supplies used to complete a task.
Yet another advantage of the present invention is the provision of a
document information system that allows for a simple and efficient means for data entry,
record keeping, and reporting.
Yet another advantage of the present invention is the provision of a
document information system that integrates documentation with voice mail.
Yet another advantage of the present invention is the provision of a
document information system that enables automated and efficient medical data
documentation and record management.
Still other advantages of the invention will become apparent to those
skilled in the art upon a reading and understanding of the following detailed description,
accompanying drawings and appended claims.
Brief Description of the Drawings
The invention may take physical form in certain parts and arrangements of
parts, a preferred embodiment and method of which will be described in detail in this
specification and illustrated in the accompanying drawings which form a part hereof, and
wherein:
Fig. 1 is a block diagram of the basic hardware configuration for a
document information system, according to a preferred embodiment of the present
invention; Fig. 2A is a block diagram illustrating the basic software configuration for
interfacing phones with the document information system of the present invention;
Fig. 2B is a block diagram illustrating the basic subsystems of the present invention;
Fig. 3 is a flow chart illustrating operation of the GUI module;
Figs. 4A-4D are flowcharts illustrating a series of basic operations of a
phone driver;
Fig. 5 is a flowchart illustrating a phone task procedure;
Fig. 6 is a flowchart illustrating a sign-in procedure; Fig. 7 is a flowchart illustrating a chart selection procedure;
Fig. 8 is a flowchart illustrating a voice mail retrieval procedure;
Fig. 9 is a flowchart illustrating a voice mail sending procedure;
Fig. 10 is a flowchart illustrating a visit documentation procedure;
Fig. 11 is a flowchart illustrating an information retrieval procedure;
Fig. 12 is a flow diagram illustrating operations of a verification module;
Figs. 13A-13D are exemplary calendar displays generated by the
verification module;
Fig. 14 is a flow diagram illustrating the flow of narrative data; and
Figs. 15-40 illustrate an exemplary chart generated in accordance with the
present invention. Detailed Description of the Preferred Embodiment
While a preferred embodiment of the present invention will be described
with particular reference to a document information system for use in connection with
home healthcare, post-acute clinical care, hospice and home infusion applications, the
present invention is also contemplated for use in other "field service" applications, such
as on-site service for appliances and utilities. In this regard, the present invention finds utility in any application where data is generated and/or accessed by persons located at a
remote site or at various locations within a large facility. Moreover, it should be
appreciated that the term "document data" as used herein refers to any data acquired, processed, stored or retrieved via the document information system of the present
invention.
Referring now to the drawings wherein the showings are for the purposes
of illustrating a preferred embodiment of the invention only and not for purposes of
limiting same, Fig. 1 shows the basic hardware configuration of the document
information system 10. Document information system 10 is generally comprised of a
computer server system 30, one or more workstation computers 80, output means 90, and
a communications interface 100.
In a preferred embodiment of the present invention, one or more phones
20 are linked to document information system 10 through a telephone system (public or
private), or through any other voice communications system, including satellite, computer
network (e.g., the Internet) and the like. Phones 20 are the primary interface device to document information system 10 for field users, and may take many forms including a standard telephone, a portable phone, cellular phone or Internet telephony device. Phones
20 are used, among other things, to verbally prompt the user, accept codified (e.g.,
numeric) input from a user via a phone keypad, and accept verbal responses from the
user. A complete description of the operation of document information system 10 will be provided below.
Server system 30 is generally comprised of a phone server 40, a database
server 60 and a network server 70. These servers can reside on a single computer system
or may be suitably distributed among two or more computers systems. Accordingly,
communication paths "Al" and "A2" may be within a single computer system, or
between two computer systems connected via a computer network, such as a Local Area
Network (LAN), on a Wide Area Network (WAN), or the Internet. Furthermore, each of
the servers 40, 60 and 70 may include one or more computer systems.
It should be appreciated that when phone server 40 is located at a different
physical location than database server 60, a high-speed communications network may be
used to link the servers. This allows for "local" phone calls to phone server 60, while still
maintaining database server 60 at a central facility remote from phone server 40.
According to a preferred embodiment of the present invention, phone
server 40 is a dedicated PC computer running Windows NT operating system. One or
more voice cards (e.g., Dialogic or Dialogic-compatible) are installed in this computer.
The primary function of the voice cards is to provide an electronic interface by converting
digitized voice data to analog voice data, and vice versa. Phone server 40 is basically responsible for such items as answering phone calls, collecting data entered by the user
(i.e., voice data spoken into the phone and alphanumeric data entered through a phone
keypad), storing received data in a database, and audibly presenting stored data to a user
over the phone (i.e., outputting "spoken" data).
Database server 60 provides a database including a plurality of database
files 62. In a preferred embodiment of the present invention, the database takes the form
of a database program such as Microsoft Access or SQL. Database server 60 is basically
responsible for optimizing requests to the database, queuing up the requests and
maintaining database integrity and security.
In a preferred embodiment of the present invention, the database includes
such tables as CLIENT INFORMATION (client's personal, physical, medical, and other
health information), VISITS (information about client visits, e.g. date, time, mileage,
etc.), EMPLOYEE (employee's personal, employment, specialty, access information,
etc.), ACTIVITY LOG (activity information collected by what was done by phone and
workstation), CLIENT INFORMATION FORM (information about the care plan, e.g.,
admission, discharge, medication, visit schedules, etc.), and 485/487 FORMS
(information about the care plan, e.g., admission, discharge, medication, visit schedules,
etc.).
According to a preferred embodiment of the present invention, the
database include lookup tables such as PHYSICIAN (referral physician's name, office
information, etc.), ADDRESS (states, cities, and zip codes), INSURER (insurance
information), HOSPITAL (hospital information), NUTRITIONAL REQUIREMENT (client's nutritional requirements), MEDICATION (medication name, category, and
instruction), LAB TEST (lab test date and results), DIAGNOSIS (primary, secondary,
and surgical diagnosis), DME (durable medical equipment information), GOAL AND
EXPECTED OUTCOMES, SKILLS AND TASKS, and MEDICAL SUPPLIES. Furthermore, database server 60 stores digitized voice data, such as voice
mail messages and narrative voice data, as will be explained below.
Network server 70 provides the communication between workstation
computers 80 and database server 60 and (optionally) between phone server 40 and database server 60. It should be appreciated that there may be one or more network
server computers 70 to enable the network communications.
Workstation computers 80 provide a computer-based interface to servers
30. These computers may be located in a central office, a branch office, or a remote
location (e.g., a home). Workstation computers 80 are typically connected with servers
30 via a communications path B, but may also be linked via a modem, or other
communications interface. It should be understood that path B is a primary
communications path of document information system 10, and may include one or more
of the following connection methods: Local Area Network (LAN), Wide Area
Network(WAN), and the Internet.
Workstation computers 80 may serve one or more functions. In this
regard, workstation computers 80 may be used to access and configure documents on
database server 60, and provide a substitute user interface for phones 20. Where workstation computer 80 serves as a substitute user interface for phones 20, workstation computer may take the form of a portable laptop computer for convenient field use. A
Graphical User Interface (GUI) module 82 provides a convenient user interface for
carrying out the foregoing functions. GUI module 82 will be described in detail below.
Workstation computers 80 may also provide a service interface to document information
system 10 for technicians to service document information system 10, and serve as a
computer system for billing and/or payroll (i.e., receiving data stored in database server
60).
It should be further appreciated that workstation 80 may also include a
sound card for playback of audible voice data through a speaker. In this regard, verbal
descriptions may be spoken over the phone by the user, and entered as audible voice data
(e.g., voice mail messages or narrative) that is stored in a digitized form in database files
62. The audible voice data may be subsequently played back (e.g., like a cassette player),
and manually transcribed into text data. In this regard, a transcriber plays back audible
voice data like a cassette player, using a software interface, or mechanical foot pedal
device to control the playback through a sound card, and transcribes the audible voice
data into text data (e.g., human-readable narrative text or messages). Alternatively, the
voice messages may be automatically converted to text data using well known
conventional voice recognition technology. This eliminates the need for a sound card and
a human transcriber.
Moreover, workstation 80 may also include an audio input means (e.g., a
microphone) for directly inputting audible voice data for storage in database files 62.
This provides an alternative means for entering audible voice data, other than phones 20. For instance, a workstation 80 could be used to record a voice mail message that is associated with a user, such that when the user is logged into document information
system 10 they receive a "playback" of the voice mail message. If the voice mail
message is associated with a client, then when information associated with that client is
accessed, the previously stored voice mail message is replayed to the user.
Output means 90 provides a human-readable output (e.g., hard copy) of
data stored in data base server 60. In this regard, output means 90 may take the form of
one or more printers, fax machines, plotters, or other hard copy display devices.
Furthermore, output means 90 could take the form of an electronic mail gateway. Communications interface 100 provides yet another interface for accessing
document information system 10. In a preferred embodiment, communications interface
takes the form of a modem, which allows for a remote connection to document
information system 10 for the purpose of technical support. In this regard,
communications interface 100 provides a dedicated communications path for technical
support personnel to provide diagnostics, database maintenance, system monitoring,
software upgrades, and the like, from a remote location. However, it should be understood that communications interface 100 is also suitable for use in the same manner
as communications path B (e.g, to connect a workstation computer).
The software modules of the present invention will now be described in
detail. The present invention includes phone modules 42, GUI modules 82, interface modules 92 and utility modules 102 (Fig. 2B). Each of these modules communicates
with database server 60. Referring now to Fig. 2A, there is shown phone modules 42 running on phone server 40. A suitable software package, such as Visual Voice, may be used to
build phone module 42. Phone module 42 provides a "voice user interface" (VUI) to
document information system 10. Phone driver 41 is a software module that supports all
of the phone interaction features, which are described below. There is one operational
phone driver 41 for each active phone line. Each of the following modules utilize phone
driver 41.
A main phone task module 200 (Fig. 5) provides the main logic stream for
each phone call. It activates various basic function sub-modules (i.e., user sign-in module
44, visii documentation module 46, voice mail module 48 and information retrieval
module 50). User sign-in module 44 accepts and verifies a user ID associated with a user.
Each user ID is associated with a user "type." In this regard, a "type code" is stored in
database server 60. The "type code" is used to control access limits and scope of
interaction with document information system 10. In this regard, some information and
some "modules" may not be accessible by all user "types." It should be noted that "type
codes" may be user-defined. Moreover, the concept of "type" may be extended to other
data items, such as the client. In this regard, a "client-type" may be established and
stored as part of a client's chart. Thus, the user's access limits and scope of interaction
with documentation system 10 is keyed to the "client type". The chart may also include
client identification information (e.g., a client id) for identifying the client that the chart is
associated with. Visit documentation module 46 allows a user to enter visit information
including: visit times, physiological data, mileage, codes for tasks performed, supplies
used, a detailed narrative (i.e., audible information), and other user-defined data items
embedded in the narrative. Voice mail module 48 allows a user to retrieve and send
voice mail messages. The messages may be "keyed" to a user ID and/or a chart ED, thus
associating a message with a particular user or client. Information retrieval module 50
allows a user to retrieve information from the database residing on database server 60.
This information may be in the form of alphanumeric or keyword phrases that are
"spoken" by a computer (i.e., audible over the phone). This module can also trigger
information to be sent to a remote location via such means as fax, Email, etc. A complete
description of the foregoing modules is provided below.
It should be appreciated that the audible voice data discussed above (i.e.,
narrative and voice mail messages) are preferably digitized for storage in a digital
medium. Database server 60 allows multiple processes to simultaneously access
database files stored therein. Moreover, database server 60 supports local and remote access to database files 62 with a variety of network schemes. In addition, database
server 60 provides many data integrity checks and controls access to database files 62.
Backup and recovery schemes are also supported.
Database server 60 stores files and tables, including those relating to:
agency information, employee information, payor information, client (i.e., patient) information, task codes (summary of activities), visit data, treatment plan data, narrative voice files, voice mail files, and voice files for prompts supporting multiple languages.
GUI modules 82 run on workstation computers 80, and include several
different types of modules. A main_user_interface 104 of GUI modules 82 will now be
described with reference to Fig. 3. A user sign-in routine is executed to accept and verify
a user ID (step 106). A user "type" code is associated with each user ED is retrieved for
the database on database server 60. The "type" code is used to control access limits and
scope of interaction with document information system 10. For instance, access to portions of document information system 10 may be limited to users having a "type"
code for system administrators (step 108). If the user's "type" code is for system administrator then a first series of menu choices are made available to the user (step 110).
The menu choices may include updating agency information (step 112 A), data
maintenance (step 112B), updating supplies records (step 112C), updating employee
records (step 112D), updating payor records (step 112E) and updating physician records
(step 112F).
As indicated above, the concept of "type" may be extended to other data
items, such as the client. In this regard, a "client-type" may be established and stored as
part of a client's chart. Thus, the user's access limits and scope of interaction with
documentation system 10 is keyed to the "client type." The chart may also include client
identification information (e.g., a client id) for identifying the client that the chart is
associated with. Updating agency information 112A includes such functions as updating the address of a health care provider. Data maintenance 112B includes such functions as
purging old records. A table of available supplies is updated using updating supplies
records (112C), employee and physician information are updated in 112D and 112F,
respectively. Payor information is updated in 112E.
User's having other "type" codes may have access to other portions of document
information system 10, and thus presented with a different set of menu choices (step 116).
For instance, the menu choices may include initial admission (step 118 A), documentation
(step 118B), logs and reports (step 118C), chart review (step 118D), new client setup
(step 118E) and transcription (step 118F). For initial admission, a chart ID associated
with the client is established in step 118A, and basic client information is entered in step 118E.
Documentation 118B allows a visit to be documented in a manner similar
to that used by the phone module, which is described in detail below. In this manner, a
laptop computer can be used in the field to document a visit. Logs and reports 118C
allows such activities as listing clients, generating billing and payroll reports, generating
transaction logs, generating quality assurance reports, generating regulatory reports (such
as OASIS), and generating verification reports that verify completion of tasks. Chart
review 118D allows the user to retrieve and view information in a client's chart.
Transcription 118F allows transcription of any voice data files (i.e., narrative and voice
mail) using manual (e.g., foot pedals) or automated means (e.g., voice recognition). The transcription capability also includes special coding for user-defined fields embedded in voice files, as will be described in further detail below.
One or more interface modules 92 are run on workstations 80 or database
server 60. The interface modules are provided for communicating data between database
server 60 and workstation 80, which may be running specialized accessory software, such as a billing and payroll program. In this regard, interface modules 92 may include a
billing interface module for providing automatic data communication between database
server 60 and a billing system computer workstation. As a result, user-defined fields
which have been spoken and embedded in the transcription of the voice files can be
detected and decoded for transferal to the billing system computer workstation. This function will be described in further detail below.
Furthermore, interface modules 92 are provided to transfer data between
database server 60 and a remote computer system (e.g., a regulatory agency computer
system) via communications path B or communications interface 100. A regulatory data transmission module supports collection and summary of data for periodic regulatory
reports (such as OASIS). The interface module 92 provides the capability to
automatically upload this data to an appropriate remote computer system (e.g., regulatory
agencies).
A series of utility modules 102 integrated with communications interface
100, may be directly connected (via modem) with a remote technical support
headquarters. A backup/restore module provides for automatic activation of a backup of
database files 62 residing on database server 60. A database maintenance module provides periodic database maintenance which may be both automatic and semi¬
automatic. Features may include: monitoring of available database server space,
compression, archive, consistency checks and fixes. A service module provides the
capability to remotely access all aspects of server systems 30 from the remote technical support headquarters. This access can be initiated from document information system 10
or server system 30 can automatically initiate a message based on the detection of some
abnormality. An invoicing module provides the capability for service invoices to be
generated from a remote location.
Referring now to Figs. 4A-4D, there is shown a series of flowcharts
illustrating basic phone driver operations. The first operation is a New_phone_call
operation 120 (Fig. 4A) which is used when establishing communication with system 10
via phones 20. System 10 answers the incoming phone call (step 122) and calls a
get_menu subroutine for choosing a desired communication language (step 124). For
example, system 10 may be configured to communicate with the user in French, Spanish or Russian. The get_menu subroutine will be described in detail below. The selected
language is then enabled (step 126) and the main_phone_task routine is called (step 128)
for this phone call. The main_phone_task routine will be described in detail below.
The get_menu subroutine 140 is illustrated by the flowchart shown in Fig.
4B. This subroutine allows the user to select a menu option. System 10 issues a prompt
(step 142). It will be understood that the term "issue" as used herein refers to the activity
wherein the system "speaks" over the phone to the user. In the present instance, the computer system may say: "Please select from one of the following three choices..." The system then accepts an input response from a telephone keypad or a user-spoken response
(step 144). Where a user-spoken response feature is employed, a simple voice
recognition module is provided to interpret simple user responses such as "one, "two,"
"yes" or "cancel". The response is evaluated to determine if it is a valid response (step
146). If the response is invalid, then the system issues an invalid response message (step
148), e.g., the system "speaks" over the phone: "Your selection is invalid, please
reenter..." Once a valid response is received, a menu selection is returned (step 150).
A get_narrative subroutine 160 is illustrated by the flowchart shown in
Fig. 4C. This subroutine is used by system 10 to record a narrative message input via a
phone 20 (i.e., a voice response spoken by the user). The system issues a prompt (step
162) and begins accepting a voice response containing the narrative (step 166). After the
narrative has been completed, the get_menu subroutine (described above) is called to
query the user whether they want to review the narrative (step 166). If a review is requested the voice response is played backed over the phone (step 168). If no review is
requested, then the get_menu subroutine is called to query the user whether they want to
accept the narrative (step 170). If the narrative is not accepted then the subroutine returns
to step 162. If the narrative is accepted, then the narrative will be stored in the database
(step 172).
The get_numeric subroutine 180 is illustrated by the flowchart shown in
Fig. 4D. This subroutine is used by system 10 to prompt a user for a numeric (or
alphanumeric) input and to record the numeric input. The system issues a prompt (step
182) and begins accepting a numeric keypad entry from the phone keypad or a user- spoken response. It is determined whether the keypad entry is valid (step 186). If the entry is not valid, then an invalid entry message is issued (step 188) and the subroutine
returns to step 182. If the entry is valid, then the get_menu subroutine is called to query
the user whether to accept the entry (step 190). If the entry is not accepted, then the
subroutine returns to step 182. If the entry is accepted then the numeric response is
returned (step 192).
The flowchart of Fig. 5 provides an overview of the basic operations for
the main_phone_task routine 200. This routine provides a format for communications
between document information system 10 and phones 20. However, it will be
appreciated that routine 200 as shown in Fig. 5 is provided solely for the purpose of
illustrating a preferred embodiment of the present invention, and that routine 200 may
take other suitable forms. In the embodiment shown in Fig. 5, a user_sign_in routine is
executed (step 202), where the user signs-in (i.e., enters a "user id") to document
information system 10 over phone 20. In this regard, the user identifies themself to
document information system 10. Next, a chart_id_selection routine (step 204) is
executed. In this routine, the user identifies a chart (i.e., enters a "chart id") corresponding to a client being treated. Thereafter, a get_voice_mail routine is executed
(step 206), where voice mail associated with a "user id" and/or "chart id" is retrieved.
Next, the get_menu subroutine is called to query the user as to a desired function (step
208). Among the available functions are a visit documentation routine (step 210) and an
information retrieval routine (step 212). The visit documentation routine allows a user to
document a visit with a client. The information retrieval routine allows a user to retrieve information stored in database files 62. Next, a send_voice_mail routine is executed (step
214), which allows a user to record voice mail. Each of the foregoing routines of the
main_phone_task routine will be described in detail below.
Fig. 6 is a flowchart illustrating user_sign_in routine 220. Each user has
an associated user id and user type. By entering the appropriate user id, a user can access information associated with the user id and user type corresponding to the user id. The
get_numeric subroutine is called to prompt the user to enter a "user id" (step 222). The
selected user id and user type are then enabled (steps 224 and 226), thus allowing access
to associated information.
Fig. 7 is a flowchart illustrating chart_id_selection routine 230. The
getjnumeric subroutine is called to prompt the user to enter a "chart id" (step 232). Next,
it is determined whether the entered "chart id" is valid for this user (step 234). In this
regard, it is determined whether the user having the specified "user id" and "user type" is
allowed to have access to the chart associated with the "chart id." If the "chart id" is not valid, then an invalid chart id message is issued (step 236), and the routine returns to step
232. If the "chart id" is valid then the "chart id" is enabled (step 238), thus allowing
access to the chart associated with the "chart id."
Fig. 8 provides a flowchart illustrating the get_voice_mail routine 240.
First, it is determined whether there are any unread voice mail messages (step 242). If
their are no unread messages, then the routine is completed. If there are messages that
have not been read, then the voice mail message is retrieved from database files 62 (step
244). Next, the time, date and message sender of the retrieved voice mail message is issued, i.e., spoken over the phone (step 246). Following this step, the retrieved voice
mail message is issued over the phone (step 248). Thereafter, the retrieved message is
marked as "read" (step 250). The get_menu subroutine is called to determine if a reply is
desired (step 252). If no reply is desired, the routine returns to step 242 to determine if
there are any additional unread voice mail messages. If a reply is desired, a
send_voice_mail routine is called (step 254). Thereafter, the routine returns to step 242. It will be appreciated that in addition to a "reply desired?" query, the user may also be
queried as to other well known voice mail options, such as replay, forward, delete, save, etc.
Fig. 9 illustrates a flowchart for a send_voice_mail routine 260. First, it is
determined whether the user has any voice mail messages to send (step 262). If there are
no messages to send the routine is completed. If a voice mail message is to be sent, then
the get_numeric subroutine is called for entry of a "recipient id" (step 264). It is
determined if the "recipient id" is valid (step 266). If the "recipient id" is not valid, then
an invalid id message is issued over the phone (step 268), and the routine returns to step
262. If the "recipient id" is valid, then the get_narrative subroutine is called (step 270) to
allow the user to record a voice mail message. The message is stored in the database
files, including the date and time of the message (step 272). The routine then returns to
step 262 to determine if any additional voice mail messages are to be sent.
Referring now to Fig. 10, there is shown a flowchart for
visit_documentation routine 280. This is the main routine for recording information
regarding a "visit." The get_numeric subroutine is called in succession to allow the user to enter a visit start time (step 282), to enter a visit stop time (step 284), and to enter
travel mileage to the client's location (step 286). Next, it is determined whether there are
any "measured" data items to collect (step 288). "Measured" data items are such items
that require the user to take a measurement of some physiological parameter (e.g., blood
pressure, temperature, heart rate, etc.). The measured data items are stored in a table.
The user is prompted to enter data for measured data items indicated in the table as being
"required." If a measured data item is to be collected, the get_numeric subroutine is
called to enter the measured data item (step 290). The routine then returns to step 288 to
determine if any additional measured data items are to be collected. Once all of the measured data items have been collected, it is determined whether there are any task
codes to be entered. The task codes are codes associated with the completion of different
types of tasks (e.g., wound care, IN therapy, bath, feeding, etc.). If task codes need to be
entered, then the get_numeric subroutine is called (step 294) for entry of the codes, and the routine returns to step 292. Once all of the task codes have been entered, it is
determined whether any supplies were used during the visit to complete a task (step 296).
If supplies were used, the get_numeric subroutine is called to enter a supply code (step
298) to identify a supply item. The routine then returns to step 296 to determine if any additional supply codes are to be entered. If no further supplies were used, get_narrative
subroutine is called (step 300) to allow the user to leave a narrative message concerning the "visit." This narrative message may include such information as the condition of the
client, the demeanor of the client, family problems, need for additional services, or other
information relevant to treatment of the client. Thereafter, the get_menu subroutine is called to query the user whether they want to review all of the visit documentation that
has been entered (step 302). If a user wants to review the visit documentation, then the
system issues (i.e., "speaks") the documentation over the phone (step 304), and the
routine returns to step 302. If a user does not want to review the visit documentation,
then the user confirms that the visit documentation is to be stored to database files 62
(step 306).
Fig. 11 is a flowchart illustrating information_retrieval routine 320. This routine allows a user to retrieve visit documentation which has been stored in database
files 62. The get_menu subroutine is called to allow the user to choose a retrieval method
(step 322). If the user selects "fax" retrieval steps 324-330 are executed. In particular, a
list of available visits is "spoken" to the user (step 324), and the get_numeric subroutine
is called to allow the user to enter the selected visits (step 326). Next, the get_numeric
subroutine is called to allow the user to enter a fax number where the information will be faxed (step 328). Faxes are then sent to the specified number for the selected visits (step
330). Thereafter, the routine continues to step 338, where the get_menu subroutine is
called to determine if the user desires to retrieve any additional information. If so, the
routine returns to step 322. If no additional information is desired, the routine is
completed.
In the case where a phone retrieval is selected at step 322, steps 332-336
are executed. In particular, a list of available visits is "spoken" to the user (step 332),
and the get_numeric subroutine is called to allow the user to enter the selected visits (step
334). Documentation information for the selected visit is then "spoken" to the user over the phone (step 336). Thereafter, the routine continues to step 338, where the get_menu
subroutine is called to determine if the user desires to retrieve any additional information.
As indicated above, GUI module 82 includes a verifier, which allows
quick and simple verification that visits are taking place according to a predetermined
plan. In this regard, the verifier provides a convenient, easily visualized, color coded,
concise comparison of a "plan of treatment" with the actual visits performed and a
summary of discrepancies.
Referring now to Fig. 12, there is shown a data flow diagram for use of
the verifier of GUI module 82. First, a plan (e.g., a treatment plan) is entered into database files 62 (step 1). Next, visit documentation is generated using a phone (step 2).
This involves the process of documenting a visit, as discussed above. A "phone verifier" (step 3) is used to determine if the user is authorized to complete a task. For instance,
document information system 10 determines whether a due date has passed for
completing a task, or whether the total number of authorized visits has been exceeded by
a user of a particular discipline type. If no authorization is given, document information
system 10 may be programmed not to accept visit documentation, or to trigger an
authorization request from an appropriate authority. For instance the authorization
request may be for additional visits by a particular type of home health care professional.
A verifier output is generated on a workstation monitor (step 4). Alternatively, a hard
copy output is generated (step 5). The verifier output of steps 4 and 5 is generated by the
verifier of GUI module 82. A description of a preferred format for the verifier output
will be described in detail below. According to a preferred embodiment of the present invention, the verifier of GUI module 82 displays a visit pattern information in the form of four calendars: (1)
What Should Occur Calendar, which shows the visits that are planned; (2) What Actually
Happened Calendar, which is automatically generated based on the visits that were
performed; (3) Verifier Calendar, which displays a summary of comparisons of the What
Should Occur and What Actually Happened Calendars; and (4)The Ultimate Auditor
Calendar, which combines the Verifier Calendar with a summary of what was
documented throughout the chart.
Exemplary formats for the four verifier calendars are respectively shown
in Figs. 13A-13D. With reference to Fig. 13A, an exemplary What Should Occur
Calendar includes the following information (in a first color): (a) Date; (b) Who -
discipline (RN, HHA ,etc); (c) When - the visit time and hours (if required) for all the
disciplines; (d) Total hours/visits of what should occur at the end of a week on a
discipline basis; and (e) Week number.
With reference to Fig 13B, an exemplary What Actually Happened
Calendar includes the following information (in a second color): (a) Date; (b) Who - discipline (RN, HHA ,etc); (c) When - the visit time and hours (if required) have been
completed for all the disciplines; (d) Total hours/visits of what was happened at the end
of the week on a discipline basis; and (e) Week number.
Referring now to Fig. 13C, there is shown an exemplary Verifier Calendar,
which includes the following information (in the first color, the second color or a third
color): (a) Date (in the third color); (b) discipline (RN, HHA, etc.) and their visit hours; (c) Total hours/visits of both What Should Occur and What Actually Happened at the end of the week, on a discipline basis; and (d) Week number. With regard to display of the
discipline/visits/visit hours, if the What Should Occur and the What Actually Happened
match when compared, then the discipline and hours are displayed in the third color. If a
visit is planned, but not performed, the visit hours are displayed in the first color. If a
visit is planned but performed at a different time, then both the planned visit (displayed in
the first color) and the performed visit (displayed in the second color) are shown. With
regard to display of the total hours/visits, if the total hours/visits for What Should Occur
and What Actually Happened match, then the total hours/visits in both Plan and Done are
displayed in the third color. If not, the total in the "plan" column are displayed in the first
color, and the total in the "done" column are displayed in the second color.
With reference to Fig. 13D, there is shown an exemplary Ultimate Auditor
Calendar. The Ultimate Auditor calendar provide verification results for such items as:
intake, discharge per discipline; discharge summary (DS), start of care (SOC), form 485,
Dr. Orders (DO) Initial Assessment per discipline, history and physicals per discipline,
home safety assessment per discipline, verifier calendar, supervisory visits (SV), home
health aide - care plan (HHA CP), home health aide - care plan update (HHA CPU), case
comments (CC), case summary (CS), case manager note (CMN), incident reports (IR),
Meds / Labs. Dates associated with the foregoing information is readily apparent from
the Ultimate Auditor Calendar.
It will be appreciated that the specific data items described above are for
illustration purposes only, and that other data items may appear in the calendar displays of Figs. 13A-13D. Moreover, the use of display attributes other than color may also be used in the foregoing calendar displays.
As indicated above, document information system 10 can generate
narrative voice files. These narrative voice files may include "custom" data that is not
part of a standard pre-defined document. Accordingly, document information system 10
is configured to encode the "custom" data so that it can be recognized and inserted into a
custom data field of a customized document. The customized document is typically a
document generated by a billing/payroll computer system, or other computer system
linked to document information system 10.
The process for accepting, encoding and decoding "custom" data will now
be described with reference to Fig. 14, which shows a data flow diagram for narrative data. A user speaks into a phone (step 410) to record narrative voice data, which may
include "custom" data associated with custom data fields. A narrative voice file is
created to store the narrative voice data (step 412). During a transcription process (step 414), which may be manual or automatic, the narrative voice data is converted to
narrative text data and stored in a narrative text file (step 416). During transcription, text
corresponding to the narrative voice data is generated. When "custom" data is
encountered, it is encoded. For example, a user may speak into the phone: "Mr. Smith refused to take a shower this morning. Client slept for about one hour this afternoon.
Company car. Two Miles." When the first two sentences are encountered during
transcription, they are stored as standard narrative text data. The second two sentences
are recognized as "custom" data or keywords. Therefore, when they are encountered the narrative text may be encoded with encoding symbols. For example, each item of
"custom" data may be surrounded by brackets such as: [company car] [two miles] . As a
result, the narrative text file now include unencoded standard narrative text data and
encoded custom data. Alternatively, documentation system 10 may be programmed to
parse narrative text for specifically identified custom data or keywords. In this case, no
encoding (e.g., brackets) is needed.
Once the narrative text file has been generated several options are
available. First, the contents of the narrative text file may be displayed on the monitor of
a workstation, as part of a chart (step 418). The narrative text file may also be output to
an output means, as part of a chart (step 420). Another option is to output the narrative
text file to an interface program (e.g., a billing / payroll interface program), wherein the
narrative text file is scanned for encoded custom data (step 422). An interface program
decodes the custom data fields and translates them into a form needed by another
computer system. In this regard, the interface program looks for the encoding symbols
(e.g., brackets), and/or directly for the custom data or keywords, where no encoding is
used. During this "decoding" process, the custom data is extracted from the narrative text
file and output to an input file (step 424). The input file includes predefined data fields
that are recognized by another computer system, such as a billing/payroll system. The
custom data is inserted into the appropriate predefined data fields. Alternatively,
appropriate data associated with the custom data is inserted into the appropriate
predefined data fields. Other data generated by document information system 10 is also
appropriately inserted into predefined data fields. The data stored in the predefined data fields in then output to another computer system, such as a billing/payroll system (step
426).
Figs. 15 - 40 illustrate a complete chart as generated by document
information system 10. More specifically, Figs. 15A-15B show an exemplary client
information report, Fig. 16 show an exemplary history and physical report, Figs. 17A-
17C show exemplary 485 forms, Figs. 18A-18B show exemplary 487 forms, Fig. 19
shows exemplary doctor's orders report, Figs. 20A-20B show an exemplary visits report,
Fig. 21 shows exemplary medications report, Fig. 22 shows exemplary lab tests & results
report, Fig. 23 shows exemplary case comments report, Figs. 24A-24D shows an
exemplary home health aide (HHA) plan, Fig. 25 shows exemplary supervisory visits report, Figs. 26A-26B shows an exemplary history and physical report from a physical
therapist (PT), Figs. 27A-27C shows an exemplary history and physical report from an occupational therapist (OT), Figs. 28A-28B shows an exemplary history and physical
report from an SLP, Fig 29 shows an exemplary history and physical report from a social
worker (SW), Fig. 30 shows an exemplary home safety assessment report, Fig. 31 shows
an exemplary incidents and occurrences report, Fig. 32 shows an exemplary case
summary report, Fig. 33 shows exemplary case manager's comments, Fig. 34 shows an
exemplary discharge summary, Fig. 35 shows an exemplary audit page, Fig. 36 shows an
exemplary outcome data report, Fig. 37 shows an exemplary calendar report, Fig. 38
shows an exemplary visit report, Fig. 39 shows exemplary phone instructions, and Fig. 40
shows an exemplary billing report. The invention has been described with reference to a preferred
embodiment. Obviously, modifications and alterations will occur to others upon a
reading and understanding of this specification. As indicated above, the present invention
is not limited solely for use in connection with the home health care industry, but finds
application in any industry in which documentation is generated and retrieved from a
remote location. For instance, in the case of the appliance service industry, the present
invention could be used in connection with data such as customer identifiers, service
personnel identifiers, product model numbers, part numbers, warranty information, type of repair, repair dates, repair times, etc. Moreover, it should be appreciated that phone
keypad data entry may be replaced with a voice recognition system to allow a user to
enter data and respond to prompts using verbal commands. It is intended that all such
modifications and alterations be included insofar as they come within the scope of the
appended claims or the equivalents thereof.

Claims

Having thus described the invention, it is now claimed:
1. A document information system for use in the field of home healthcare, post-acute clinical care, hospice and home infusion, comprising:
storage means for storing document data, said document data including
medical-related task information;
phone interface means for communicating document data between said
storage means and at least one associated phone, wherein the associated phone is used to
input document data into the storage means, and retrieve document data from the storage
means;
computer interface means for communicating document data between said
storage means and at least one associated computer, wherein the associated computer is
used to input document data into the storage means, and retrieve document data from the
storage means; and
verification means for verifying said medical-related task information.
2. A document information system according to claim 1 , wherein said verification means verifies whether a user is authorized to complete a medical-related
task.
3. A document information system according to claim 1, wherein said
verification means verifies the completion of one or more medical-related tasks.
4. A document information system according to claim 3, wherein said verification means access said storage means to generate one or more verification
calendars, said calendars indicating dates associated with medical-related tasks.
5. A document information system according to claim 4, wherein a
first verification calendar displays a first information set with a first attribute, a second
verification calendar displays a second information set with a second attribute, a third
verification calendar displays a third information set with a third attribute, said third
information set derived from a comparison of said first information set to said second
information set.
6. A document information system for use in the field of home
healthcare, post-acute clinical care, hospice and home infusion, comprising:
storage means for storing document data, said document data including
medical-related task information; phone interface means for communicating document data between said
storage means and at least one associated phone, wherein the associated phone is used to
input document data into the storage means, and retrieve document data from the storage
means;
computer interface means for communicating document data between said
storage means and at least one associated computer, wherein the associated computer is used to input document data into the storage means, and retrieve document data from the
storage means; and
record generation means for generating a medical data chart including said
medical-related information.
7. A document information system according to claim 6, wherein said medical-related information includes measured data associated with a client's condition,
and task data associated with a medical-related task performed by a user.
8. A document information system according to claim 6, wherein said
medical-related information takes the form of both alphanumeric data and audible voice
data.
9. A document information system according to claim 1, wherein said
medical-related information includes medical-supply data associated with supplies used
to complete a medical-related task.
10. A method for generating medical-related documents, the method
comprising:
audibly outputting information queries over a phone communications
device for acquiring document data, said document data including medical-related task
information; receiving document data via the phone communications device in response to said information queries;
storing the received document data in a database means;
generating documents from the document data stored in said database means; and
verifying said medical-related task information.
11. A method according to claim 10, wherein the step of verifying
includes verifying whether a user is authorized to complete a medical-related task.
12. A method according to claim 10, wherein the step of verifying
includes verifying the completion of one or more medical-related tasks.
13. A method according to claim 12, wherein the step of verifying includes generating one or more verification calendars, said calendars indicating dates
associated with said medical-related tasks.
14. A method according to claim 13, wherein said calendars include a
first verification calendar for displaying a first information set with a first attribute, a
second verification calendar for displaying a second information set with a second
attribute, and a third verification calendar for displaying a third information set with a third attribute, said third information set derived from a comparison of said first
information set to said second information set.
15. A method for generating medical-related documents, the method
comprising: audibly outputting information queries over a phone communications
device for acquiring document data, said document data including medical-related
information; receiving document data via the phone communications device in response
to said information queries;
storing the received document data in a database means; and
generating a medical data chart including said medical-related
information.
16. A method according to claim 15, wherein said medical-related
information includes measured data associated with a client's condition, and task data
associated with a medical-related task performed by a user.
17. A method according to claim 15, wherein said medical-related
information takes the form of both alphanumeric data and audible voice data.
18. A method according to claim 15, wherein said medical-related
information includes medical supply data associated with supplies used to complete a
medical-related task.
PCT/US1999/004960 1998-03-06 1999-03-05 Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications WO1999045453A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU30705/99A AU3070599A (en) 1998-03-06 1999-03-05 Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/036,179 US6292783B1 (en) 1998-03-06 1998-03-06 Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications
US09/036,179 1998-03-06

Publications (1)

Publication Number Publication Date
WO1999045453A2 true WO1999045453A2 (en) 1999-09-10

Family

ID=21887095

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/004960 WO1999045453A2 (en) 1998-03-06 1999-03-05 Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications

Country Status (3)

Country Link
US (1) US6292783B1 (en)
AU (1) AU3070599A (en)
WO (1) WO1999045453A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1344119A2 (en) * 2000-11-07 2003-09-17 Antaeus Healthcom, Inc. System for the creation of database and structured information from verbal input

Families Citing this family (125)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6680999B1 (en) * 1995-08-15 2004-01-20 Mumps Audiofax, Inc. Interactive telephony system
US6704118B1 (en) * 1996-11-21 2004-03-09 Ricoh Company, Ltd. Method and system for automatically and transparently archiving documents and document meta data
US6418478B1 (en) 1997-10-30 2002-07-09 Commvault Systems, Inc. Pipelined high speed data transfer mechanism
US7581077B2 (en) 1997-10-30 2009-08-25 Commvault Systems, Inc. Method and system for transferring data in a storage operation
US7739381B2 (en) * 1998-03-11 2010-06-15 Commvault Systems, Inc. System and method for providing encryption in storage operations in a storage network, such as for use by application service providers that provide data storage services
US9037451B2 (en) * 1998-09-25 2015-05-19 Rpx Corporation Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet buses and methods for implementing language capabilities using the same
JP3747133B2 (en) 1999-04-14 2006-02-22 キヤノン株式会社 Portable terminal, control method thereof, and storage medium thereof
JP3327877B2 (en) 1999-04-14 2002-09-24 キヤノン株式会社 Information providing method, information providing system, terminal device, and storage medium storing information providing program
JP3376311B2 (en) 1999-04-14 2003-02-10 キヤノン株式会社 Information providing method and information providing system
US7035880B1 (en) 1999-07-14 2006-04-25 Commvault Systems, Inc. Modular backup and retrieval system used in conjunction with a storage area network
US7395282B1 (en) 1999-07-15 2008-07-01 Commvault Systems, Inc. Hierarchical backup and retrieval system
US7389311B1 (en) 1999-07-15 2008-06-17 Commvault Systems, Inc. Modular backup and retrieval system
US7155481B2 (en) 2000-01-31 2006-12-26 Commvault Systems, Inc. Email attachment management in a computer system
US6658436B2 (en) 2000-01-31 2003-12-02 Commvault Systems, Inc. Logical view and access to data managed by a modular data and storage management system
US6542972B2 (en) 2000-01-31 2003-04-01 Commvault Systems, Inc. Logical view and access to physical storage in modular data and storage management system
US7003641B2 (en) 2000-01-31 2006-02-21 Commvault Systems, Inc. Logical view with granular access to exchange data managed by a modular data and storage management system
US20060074727A1 (en) 2000-09-07 2006-04-06 Briere Daniel D Method and apparatus for collection and dissemination of information over a computer network
US7743073B2 (en) * 2000-11-15 2010-06-22 Pacific Datavision, Inc. Systems and methods for push-to-talk wireless applications
US7054863B2 (en) 2000-11-15 2006-05-30 Pacific Datavision, Inc. System and method for originating, storing, processing and delivering message data
US7653691B2 (en) 2000-11-15 2010-01-26 Pacific Datavision Inc. Systems and methods for communicating using voice messages
US8140627B2 (en) * 2000-11-15 2012-03-20 Pacific Datavision, Inc. Systems and methods for push-to-email communication with location information
US8577843B1 (en) 2000-11-15 2013-11-05 Pacific Datavision, Inc. System and methods for using a plurality of receiver identifications to create and retrieve a digital project log
US6889190B2 (en) * 2001-01-25 2005-05-03 Rodan Enterprises, Llc Hand held medical prescription transcriber and printer unit
US7041468B2 (en) 2001-04-02 2006-05-09 Therasense, Inc. Blood glucose tracking apparatus and methods
US7451096B2 (en) * 2001-12-28 2008-11-11 Siemens Medical Solution Usa, Inc. System and method for managing healthcare communication
US7346522B1 (en) 2002-01-08 2008-03-18 First Access, Inc. Medical payment system
US7286997B2 (en) * 2002-05-07 2007-10-23 Cembex Care Solutions, Llc Internet-based, customizable clinical information system
US20040054775A1 (en) * 2002-06-26 2004-03-18 Poliac Research Corporation Medical data collection and deliver system
US8370542B2 (en) 2002-09-16 2013-02-05 Commvault Systems, Inc. Combined stream auxiliary copy system and method
US20040111293A1 (en) * 2002-12-09 2004-06-10 Catherine Firanek System and a method for tracking patients undergoing treatment and/or therapy for renal disease
US7890341B2 (en) * 2002-12-09 2011-02-15 Baxter International Inc. System and a method for providing integrated access management for peritoneal dialysis and hemodialysis
US7177817B1 (en) * 2002-12-12 2007-02-13 Tuvox Incorporated Automatic generation of voice content for a voice response system
US20040153342A1 (en) * 2003-01-30 2004-08-05 Armintor Alice E. Methods and apparatus for managing resident data
US7395505B1 (en) 2003-03-17 2008-07-01 Tuvox, Inc. Graphical user interface for creating content for a voice-user interface
US7454569B2 (en) 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
US20040267595A1 (en) 2003-06-30 2004-12-30 Idcocumentd, Llc. Worker and document management system
US20050027567A1 (en) * 2003-07-29 2005-02-03 Taha Amer Jamil System and method for health care data collection and management
US20050043967A1 (en) * 2003-08-20 2005-02-24 Robinson Joseph R. Systems and methods for documenting home care services
US20050080820A1 (en) * 2003-10-11 2005-04-14 Koppel Carl Arnold Method and system for generating, associating and employing user-defined fields in a relational database within an information technology system
US8029454B2 (en) 2003-11-05 2011-10-04 Baxter International Inc. High convection home hemodialysis/hemofiltration and sorbent system
US7613748B2 (en) 2003-11-13 2009-11-03 Commvault Systems, Inc. Stored data reverification management system and method
WO2005050381A2 (en) 2003-11-13 2005-06-02 Commvault Systems, Inc. Systems and methods for performing storage operations using network attached storage
US7315923B2 (en) 2003-11-13 2008-01-01 Commvault Systems, Inc. System and method for combining data streams in pipelined storage operations in a storage network
US7440982B2 (en) 2003-11-13 2008-10-21 Commvault Systems, Inc. System and method for stored data archive verification
WO2005048085A2 (en) 2003-11-13 2005-05-26 Commvault Systems, Inc. System and method for performing an image level snapshot and for restoring partial volume data
US7664657B1 (en) 2003-11-25 2010-02-16 Vocollect Healthcare Systems, Inc. Healthcare communications and documentation system
EP1756785A2 (en) * 2004-02-24 2007-02-28 Caretouch Communications, Inc. Intelligent message delivery system
US20050209881A1 (en) * 2004-03-22 2005-09-22 Norton Jeffrey W Method of tracking home-healthcare services
US7647227B1 (en) 2004-04-06 2010-01-12 Tuvox, Inc. Machine assisted speech generation for a conversational voice response system
US8027458B1 (en) 2004-04-06 2011-09-27 Tuvox, Inc. Voice response system with live agent assisted information selection and machine playback
US20050251438A1 (en) * 2004-05-04 2005-11-10 Yi-Ming Tseng Methods and system for evaluation with notification means
US20060004604A1 (en) * 2004-07-02 2006-01-05 White Martin A Method and system for providing a service to a person
US8396712B2 (en) * 2004-08-26 2013-03-12 West Corporation Method and system to generate finite state grammars using sample phrases
US9552599B1 (en) 2004-09-10 2017-01-24 Deem, Inc. Platform for multi-service procurement
US8494855B1 (en) 2004-10-06 2013-07-23 West Interactive Corporation Ii Method, system, and computer readable medium for comparing phonetic similarity of return words to resolve ambiguities during voice recognition
GB2435756B (en) 2004-11-05 2008-12-10 Commvault Systems Inc Method and system of pooling storage devices
US20060253281A1 (en) * 2004-11-24 2006-11-09 Alan Letzt Healthcare communications and documentation system
US20060142057A1 (en) * 2004-12-10 2006-06-29 Beverly Schuler Med-phone
US7636743B2 (en) 2005-12-19 2009-12-22 Commvault Systems, Inc. Pathname translation in a data replication system
US7651593B2 (en) 2005-12-19 2010-01-26 Commvault Systems, Inc. Systems and methods for performing data replication
CA2632935C (en) 2005-12-19 2014-02-04 Commvault Systems, Inc. Systems and methods for performing data replication
US7617262B2 (en) 2005-12-19 2009-11-10 Commvault Systems, Inc. Systems and methods for monitoring application data in a data replication system
US8655850B2 (en) 2005-12-19 2014-02-18 Commvault Systems, Inc. Systems and methods for resynchronizing information
US7543125B2 (en) * 2005-12-19 2009-06-02 Commvault Systems, Inc. System and method for performing time-flexible calendric storage operations
US7620710B2 (en) 2005-12-19 2009-11-17 Commvault Systems, Inc. System and method for performing multi-path storage operations
US7606844B2 (en) 2005-12-19 2009-10-20 Commvault Systems, Inc. System and method for performing replication copy storage operations
US7962709B2 (en) 2005-12-19 2011-06-14 Commvault Systems, Inc. Network redirector systems and methods for performing data replication
US9117223B1 (en) 2005-12-28 2015-08-25 Deem, Inc. Method and system for resource planning for service provider
US8726242B2 (en) 2006-07-27 2014-05-13 Commvault Systems, Inc. Systems and methods for continuous data replication
WO2008014005A2 (en) * 2006-07-28 2008-01-31 Shala Cunningham Method to evaluate a client by a physical therapist
US8655914B2 (en) 2006-10-17 2014-02-18 Commvault Systems, Inc. System and method for storage operation access security
US8719809B2 (en) 2006-12-22 2014-05-06 Commvault Systems, Inc. Point in time rollback and un-installation of software
US8312323B2 (en) 2006-12-22 2012-11-13 Commvault Systems, Inc. Systems and methods for remote monitoring in a computer network and reporting a failed migration operation without accessing the data being moved
US8290808B2 (en) 2007-03-09 2012-10-16 Commvault Systems, Inc. System and method for automating customer-validated statement of work for a data storage environment
US20090125335A1 (en) * 2007-11-05 2009-05-14 Manetta Amy M Patient Treatment Planning System
US20090259493A1 (en) * 2008-04-11 2009-10-15 Venon Medhi O Mobile health book
US8255225B2 (en) * 2008-08-07 2012-08-28 Vocollect Healthcare Systems, Inc. Voice assistant system
US8451101B2 (en) * 2008-08-28 2013-05-28 Vocollect, Inc. Speech-driven patient care system with wearable devices
US8204859B2 (en) 2008-12-10 2012-06-19 Commvault Systems, Inc. Systems and methods for managing replicated database data
US9495382B2 (en) 2008-12-10 2016-11-15 Commvault Systems, Inc. Systems and methods for performing discrete data replication
US8434131B2 (en) 2009-03-20 2013-04-30 Commvault Systems, Inc. Managing connections in a data storage system
US20100274580A1 (en) * 2009-04-10 2010-10-28 Crownover Keith R Healthcare Provider Performance Analysis and Business Management System
US10552849B2 (en) 2009-04-30 2020-02-04 Deem, Inc. System and method for offering, tracking and promoting loyalty rewards
US20110029315A1 (en) * 2009-07-28 2011-02-03 Brent Nichols Voice directed system and method for messaging to multiple recipients
US20110125533A1 (en) * 2009-11-20 2011-05-26 Budacki Robert M Remote Scribe-Assisted Health Care Record Management System and Method of Use of Same
US20110141116A1 (en) 2009-12-16 2011-06-16 Baxter International Inc. Methods and apparatus for displaying flow rate graphs and alarms on a dialysis system
US8504517B2 (en) 2010-03-29 2013-08-06 Commvault Systems, Inc. Systems and methods for selective data replication
US8504515B2 (en) 2010-03-30 2013-08-06 Commvault Systems, Inc. Stubbing systems and methods in a data replication environment
US8352422B2 (en) 2010-03-30 2013-01-08 Commvault Systems, Inc. Data restore systems and methods in a replication environment
US8725698B2 (en) 2010-03-30 2014-05-13 Commvault Systems, Inc. Stub file prioritization in a data replication system
WO2011150391A1 (en) 2010-05-28 2011-12-01 Commvault Systems, Inc. Systems and methods for performing data replication
US9021198B1 (en) 2011-01-20 2015-04-28 Commvault Systems, Inc. System and method for sharing SAN storage
US9449288B2 (en) 2011-05-20 2016-09-20 Deem, Inc. Travel services search
US9471578B2 (en) 2012-03-07 2016-10-18 Commvault Systems, Inc. Data storage system utilizing proxy device for storage operations
US9298715B2 (en) 2012-03-07 2016-03-29 Commvault Systems, Inc. Data storage system utilizing proxy device for storage operations
US9342537B2 (en) 2012-04-23 2016-05-17 Commvault Systems, Inc. Integrated snapshot interface for a data storage system
US20140201140A1 (en) 2013-01-11 2014-07-17 Commvault Systems, Inc. Data synchronization management
US9886346B2 (en) 2013-01-11 2018-02-06 Commvault Systems, Inc. Single snapshot for multiple agents
US20140236915A1 (en) * 2013-02-21 2014-08-21 Baycare Health System, Inc. System and method for retrieving physician information
US9639426B2 (en) 2014-01-24 2017-05-02 Commvault Systems, Inc. Single snapshot for multiple applications
US9495251B2 (en) 2014-01-24 2016-11-15 Commvault Systems, Inc. Snapshot readiness checking and reporting
US9753812B2 (en) 2014-01-24 2017-09-05 Commvault Systems, Inc. Generating mapping information for single snapshot for multiple applications
US9632874B2 (en) 2014-01-24 2017-04-25 Commvault Systems, Inc. Database application backup in single snapshot for multiple applications
US9424832B1 (en) * 2014-07-02 2016-08-23 Ronald Isaac Method and apparatus for safely and reliably sending and receiving messages while operating a motor vehicle
US9774672B2 (en) 2014-09-03 2017-09-26 Commvault Systems, Inc. Consolidated processing of storage-array commands by a snapshot-control media agent
US10042716B2 (en) 2014-09-03 2018-08-07 Commvault Systems, Inc. Consolidated processing of storage-array commands using a forwarder media agent in conjunction with a snapshot-control media agent
US9448731B2 (en) 2014-11-14 2016-09-20 Commvault Systems, Inc. Unified snapshot storage management
US9648105B2 (en) 2014-11-14 2017-05-09 Commvault Systems, Inc. Unified snapshot storage management, using an enhanced storage manager and enhanced media agents
US9904481B2 (en) 2015-01-23 2018-02-27 Commvault Systems, Inc. Scalable auxiliary copy processing in a storage management system using media agent resources
US9898213B2 (en) 2015-01-23 2018-02-20 Commvault Systems, Inc. Scalable auxiliary copy processing using media agent resources
US10503753B2 (en) 2016-03-10 2019-12-10 Commvault Systems, Inc. Snapshot replication operations based on incremental block change tracking
US11010261B2 (en) 2017-03-31 2021-05-18 Commvault Systems, Inc. Dynamically allocating streams during restoration of data
US10732885B2 (en) 2018-02-14 2020-08-04 Commvault Systems, Inc. Block-level live browsing and private writable snapshots using an ISCSI server
US11065060B2 (en) 2018-04-26 2021-07-20 Vektor Medical, Inc. Identify ablation pattern for use in an ablation
US11622732B2 (en) 2018-04-26 2023-04-11 Vektor Medical, Inc. Identifying an attribute of an electromagnetic source configuration by matching simulated and patient data
US10860754B2 (en) 2018-04-26 2020-12-08 Vektor Medical, Inc. Calibration of simulated cardiograms
US11259871B2 (en) 2018-04-26 2022-03-01 Vektor Medical, Inc. Identify ablation pattern for use in an ablation
JP7153973B2 (en) 2018-11-13 2022-10-17 ベクトル メディカル インコーポレイテッド Dilation of images with source locations
US10595736B1 (en) 2019-06-10 2020-03-24 Vektor Medical, Inc. Heart graphic display system
US10709347B1 (en) 2019-06-10 2020-07-14 Vektor Medical, Inc. Heart graphic display system
US11042318B2 (en) 2019-07-29 2021-06-22 Commvault Systems, Inc. Block-level data replication
US11338131B1 (en) 2021-05-05 2022-05-24 Vektor Medical, Inc. Guiding implantation of an energy delivery component in a body
WO2023018626A2 (en) 2021-08-09 2023-02-16 Vektor Medical, Inc. Tissue state graphic display system
US11534224B1 (en) 2021-12-02 2022-12-27 Vektor Medical, Inc. Interactive ablation workflow system
US11809285B2 (en) 2022-02-09 2023-11-07 Commvault Systems, Inc. Protecting a management database of a data storage management system to meet a recovery point objective (RPO)

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4916441A (en) * 1988-09-19 1990-04-10 Clinicom Incorporated Portable handheld terminal
US5065315A (en) * 1989-10-24 1991-11-12 Garcia Angela M System and method for scheduling and reporting patient related services including prioritizing services
JPH03280930A (en) * 1990-03-29 1991-12-11 Aisin Seiki Co Ltd Informing device for medical information
US5301105A (en) * 1991-04-08 1994-04-05 Desmond D. Cummings All care health management system
US5361202A (en) * 1993-06-18 1994-11-01 Hewlett-Packard Company Computer display system and method for facilitating access to patient data records in a medical information system
CA2125300C (en) * 1994-05-11 1999-10-12 Douglas J. Ballantyne Method and apparatus for the electronic distribution of medical information and patient services
US5845253A (en) * 1994-08-24 1998-12-01 Rensimer Enterprises, Ltd. System and method for recording patient-history data about on-going physician care procedures
US5842173A (en) * 1994-10-14 1998-11-24 Strum; David P. Computer-based surgical services management system
US5664207A (en) * 1994-12-16 1997-09-02 Xcellenet, Inc. Systems and methods for automatically sharing information among remote/mobile nodes
WO1996030848A1 (en) * 1995-03-31 1996-10-03 Levin Richard I System and method of generating prognosis reports for coronary health management

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1344119A2 (en) * 2000-11-07 2003-09-17 Antaeus Healthcom, Inc. System for the creation of database and structured information from verbal input
EP1344119A4 (en) * 2000-11-07 2007-03-07 Antaeus Healthcom Inc System for the creation of database and structured information from verbal input

Also Published As

Publication number Publication date
US6292783B1 (en) 2001-09-18
AU3070599A (en) 1999-09-20

Similar Documents

Publication Publication Date Title
US6292783B1 (en) Phone-assisted clinical document information computer system for use in home healthcare, post-acute clinical care, hospice and home infusion applications
US6680999B1 (en) Interactive telephony system
US6088429A (en) Interactive telephony system
US7209550B1 (en) Medical information system having interactive messaging interface
CA2004853C (en) Records management system having dictation/transcription capability
US6738784B1 (en) Document and information processing system
US8037419B2 (en) Electronic system for collecting and automatically populating clinical order information
US8060380B2 (en) Apparatus and method for processing phone-in prescriptions
US8762173B2 (en) Method and apparatus for indirect medical consultation
AU2009251031B2 (en) Improvements relating to graphical user interfaces
US20060212452A1 (en) System and method for remotely inputting and retrieving records and generating reports
US20120173281A1 (en) Automated data entry and transcription system, especially for generation of medical reports by an attending physician
US20030036927A1 (en) Healthcare information search system and user interface
US20030233252A1 (en) System and method for providing a generic health care data repository
US20060031097A1 (en) Practice management system
WO2005081802A2 (en) Intelligent message delivery system
WO2002102044A1 (en) Automatic normal report system
WO2008039574A2 (en) Voice messaging systems
WO1999052024A2 (en) Phone-assisted document information computer system
WO2002052483A2 (en) System and method for integration of health care records, and for a seamless user interface, for an integrated electronic health care information system
CN112786128A (en) Electronic medical record writing quality inspection system and method
CA2415013C (en) Claim submission system and method
Teich et al. Large-Scale Clinical Systems. Large Scale Integrated Ambulatory Care Systems: Design Considerations in the BWH Ambulatory Medical Record: Features for Maximum Acceptance by Clinicians
AU2005201124A1 (en) System and method for integration of health care records, and for a seamless user interface, for an integrated electronic health care information system
AU2002232767A1 (en) System and method for integration of health care records, and for a seamless user interface, for an integrated electronic health care information system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WA Withdrawal of international application
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase