JP2744103B2 - Data input method in the window of office computer - Google Patents

Description

Description: BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a business computer such as a medical insurance claim business computer and an insurance dispensing claim business computer, and relates to a data input method in a window operation of the computer. .

2. Description of the Related Art Conventionally, there is an office computer that manages data on processing performed on each individual for each individual, and is used in various fields.

For example, in a pharmacy of a hospital, an insurance dispensing claim business calculator for performing an insurance dispensing claim business for each patient is used, and in this device, a dispensing act performed on a patient is stored for each individual, We work on insurance dispensing claims, such as issuing dispensing compensation invoices.

Here, in order to issue a dispensing remuneration claim statement or to perform insurance dispensing claim work such as accounting, the patient's unique name, gender, date of birth, personal / family classification, insurer number, burden rate You must register initial data such as the benefit rate. Therefore, when a new patient (new patient) arrives at the pharmacy with a prescription, first, in the counter operation, head data for the patient is extracted from the prescription and input to the computer. Such an example is disclosed in JP-B-63-59191.

And, among these initials data, name, date of birth,
Specific head data such as identification of the person / family, insurer number, burden ratio, etc. are particularly important items in business processing, so the computer determines whether or not these specific head data have been input.
If there is no input, dispensing data input regarding the dispensing action is not accepted, thereby preventing such data from being omitted.

[Problems to be Solved by the Invention] However, in a normal case, patients with prescriptions come one after another to a pharmacy in a hospital and request a dispensing. On the other hand, it takes some time to input the specific initial data. For this reason, when a new patient continues, it takes time to input these data, and the processing of the window service of a busy pharmacy is greatly delayed.

For this reason, there is a demand at the window that the processing such as the input of the initial data should be performed as quickly as possible.

SUMMARY OF THE INVENTION The present invention has been made in consideration of the above problems, and has as its object to provide a data input method of an office computer that can efficiently perform window operations.

[Means for Solving the Problems] The data input method in the window business of the office computer according to the present invention includes a dummy data generating means for generating dummy data for specific initial data. Then, in response to a predetermined key operation, the dummy data generated by the dummy data generating means is input as the head data of the visitor.

In addition, the dummy data generating means generates a dummy name using a symbol that is not normally used as a name as the name, and searches for whether the input name is the name using the symbol, so that the dummy data is input as initial data. It is characterized by extracting visitors.

[Operation] According to the present invention, dummy data is generated by performing a predetermined key operation when inputting initial data at the window, and this can be input as initial data. Therefore, the input operation can be performed very quickly.

Further, by using a symbol that is not usually used for a name as dummy data for a name, it is possible to easily extract a visitor to whom the dummy data is input.

Hereinafter, an office computer according to the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing a configuration of an insurance dispensing claim business computer according to one embodiment of the present invention, which has a keyboard 1 as input means, a display 2 and a printer 3 as output means. The keyboard 1, the display 2, and the printer 3 are connected to a processing unit 7 via an input control unit 4, a display control unit 5, and a print control unit 6, respectively.

The processing unit 7 performs processing, processing, output control, and the like of input data, a memory 8 used as a work area when performing various processing, and a magnetic disk 9 for storing data such as processing results. Is connected.

Further, in this example, the memory 8 stores the patient's name, date of birth, identification of the person / family, insurer number, burden rate,
A head data area 8a for storing head data, which is data unique to other patients, and a dispensing data area 8b for storing data of a dispensing action for the patient. The magnetic disk 9 has a head file 9a for storing head data, a dispensing file 9b for storing data on dispensing actions, and a dummy data storage unit 9c for storing dummy data.
Is provided.

In the window service, data is input from the keyboard 1 while viewing the display on the display 2 to store the patient's head data in the head file 9a and the dispensing file 9b of the magnetic disk 9 and to store the dispensing data for the patient. Do. At the time of issuing a dispensation fee billing statement at the end of the month or the like, a dispensing claim statement is created based on the stored data, and is output from the printer 3.

Here, in this example, the date of birth and the date of birth are stored in the dummy data storage section 9c of the magnetic disk 9 as shown in FIG.
Preliminary dummy data is stored for the four items of the person / family, burden ratio, and insurer number. Also,
The keyboard 1 is provided with a call key 1a for requesting input of dummy data.

For this reason, in this computer, an efficient window service can be performed using the dummy data. An input operation using the dummy data will be described with reference to FIG.

First, when the system is started, a selection screen for selecting what kind of work is performed is displayed (S1). Then, on this screen, a window key provided on the keyboard 1 is pressed (S2).

This will start the window business,
First, a window date input screen is displayed (S3). Therefore,
The operator inputs a window date (usually the date of the day) from the keyboard 1 and presses an input key (S4).

When the window date is input in this way, a window (window first-level input window) for inputting which of the window operations is to be performed (S5). Here, the window first level input screen is a screen as shown in FIG. 4, and displays the input dispensing date. In this example, the dispensing date is December 18. And this window first
When the patient code key is pressed while the level input screen is displayed (S6), a new patient registration / patient call screen is displayed (S7). The new patient registration / patient call screen is as shown in FIG. 5, and is a screen for requesting input of a patient code.

In this screen, if a patient code is input, a patient reading process is performed, and if a patient code is not input, a new patient registration process is performed. For this reason, when the patient code is input or the input key on the keyboard 1 is pressed without inputting (S8), it is determined whether or not the patient code is specified (S9).

If the patient code is specified, the data for the patient of the patient code is called up. If the input is not made, a new patient registration process is performed. That is, if the patient code has not been input, the processing unit 7 automatically generates a patient code and automatically assigns a patient code for data to be input (S10). Then, the patient code to which the automatic assignment has been performed is displayed (S11).

The display screen of this patient code is as shown in FIG. 6, in which the patient code is displayed. In this example, “65004” is assigned as the patient code. The display screen of the patient code is a screen for requesting the input of the medical institution code. By inputting the medical institution code on the left side of the patient code "65004" and pressing the input key of the keyboard 1, The patient code and the medical institution code are input (S12).

When the patient code is input in this way, it is checked whether or not the patient code has already been input (S13). This is because, if a patient code is input in S8, this may not be a patient code already assigned, but may be a new patient.

Then, in the matching of the patient code, if the input patient code already exists, the patient is not a new patient, and if not, it is a new patient.
Four). If it is not a new case, the data of the patient corresponding to the entered patient code is displayed, and the procedure may be shifted to the input of dispensing data. Must be done.

Then, after setting the new case flag F = 1 (S15), a screen for inputting initial data on the new case is displayed (S16). Here, the input screen of the initial data for the new case is as shown in FIG. 7, in which the patient code input in the previous step is displayed, and the name and the date of birth are the initial data. , A person / family, an insurer number, a burden rate, and the like. Then, on this input screen, necessary data is keyed in (S17). In this example, the medical institution code is "AA" (corresponding medical institution name: Medico Clinic)
Has been entered, and this is displayed to the left of the patient code.

In this example, when a call key (not shown) is input on the data input screen instead of a key input for the content, data input using dummy data is performed.

That is, it is determined whether or not a call key (not shown) provided on the keyboard 1 has been input (S1).
8) If this input is made, the new case flag is set to [1]
Is determined (S19). New patient flag is [1]
If not, the patient is not new. Therefore, it is not necessary to input the initial data, and the process returns to the key input (S17).

On the other hand, when the new case flag is “1”, dummy data is set in the head data. That is, first, a patient code is adopted as data on the patient's name. For this purpose, the patient code is set to the position of the name in the initial data area 8a in the memory 8 (S2).
0). As a result, the patient code is displayed in the name column on the data input screen. Note that the patient name field has two fields, katakana and kanji, and the katakana field is set to data that must be input. Therefore, the patient code is set as katakana name data.

Next, the contents of the dummy data storage section 9c of the magnetic disk 9 are read (S21), and the read dummy data is
(S22). That is, the date of birth, personal / family classification, burden ratio, and insurer number shown in FIG. 2 are read from the dummy data storage unit 9c and set in the corresponding position of the head data area 8a of the memory 8. . Then, a screen as shown in FIG. 8 is displayed according to the set data (S23).

In this example, the patient code is 65004, the medical institution code is AA, the date of birth is Taisho 15.12.23, the person / family is the person, the insurer number is 06100192, and the burden rate is 1.
It is 00%.

Here, on the screen shown in FIG. 8, the cursor is positioned in the column of the burden ratio, as indicated by hatched squares in the figure, to facilitate changing the data on the burden ratio.
In this state, the process returns to S17. This is because the burden rate is indispensable for accounting for dispensing at the counter, and it is necessary to input correct data.

Then, it is determined whether or not the input key is pressed (S24). When the input key is pressed, specific initial data, in this case, name, date of birth, distinction of the person / family, burden It is determined whether or not the five initial data of the rate and the insurer number have been input (S25). If these data have not been input, the process returns to S17, where the input of the next dispensing data is prohibited, and the input of data is prevented from being omitted.

On the other hand, if specific initial data has been entered,
The input data is set in the corresponding position of the head data area 8a of the memory 8 to determine the data (S26).

When the input for the head data is completed in this way, the process proceeds to the input for the dispensing data.

That is, the dispensing data input screen shown in FIG. 9 is displayed (S27), and dispensing data is input in this state (S2).
8). The dispensing data is data on prescribing a drug such as a vitamin, for example, and a drug name, a prescription amount, and the like are input.

The input data is set in the dispensing data area 8b of the memory 8 and displayed on the screen.

Then, when the input of the dispensing data is completed, the end key is pressed (S29). As a result, the input of the dispensing data has been completed, which means that the input of the dispensing data for the patient has been completed.

Therefore, the initial data and the dispensing data are stored on the magnetic disk 9.
In the initial file 9a and the dispensing file 9b. In this way, what kind of dispensing is performed for which patient is registered on the magnetic disk 9. Therefore, when issuing a dispensing remuneration claim statement or the like, the data can be read and a predetermined process can be performed.

As described above, according to this embodiment, by pressing the call key 1a, the dummy data stored in the dummy data storage unit 9c in advance is read and input as initial data, and the patient name is displayed. The patient code will be automatically entered.

Therefore, the input of particular important initial data can be completed in a very short time, and the processing for the patient coming to the counter can be performed quickly.

On the other hand, the initial data read from the dummy data input as described above is not data specific to the patient,
This is data having a predetermined content stored in advance. This has to be corrected in order to carry out insurance dispensing claims. Therefore, this data correction work
This will be described with reference to FIG.

First, the window at the first level of the window in S5 (4th
) Is pressed twice in succession in the state where is displayed (S101, 102). As a result, a state of the head-to-head continuous collation is established. The head-to-head collation is a process of picking up all of the head data that meets the search condition.

Therefore, search conditions are input (S103). Here, as described above, in this embodiment, the patient code is input as the name (Katakana) of the initial data.

The patient code is represented by Arabic numerals ("65004" in the above example). On the other hand, the names of ordinary patients are all entered in katakana. Therefore, by searching for a patient name input in Arabic numerals, it is possible to extract a patient inputting dummy data.

The input of such a search condition is, for example, "/ *** ...
* "Is input. Here, "/" means that it is a number, and "*" means that any data may be used. Thus, by this input, if the first character is a numeral, any data after the second character can be searched. Since the katakana data is usually input left-justified, the above-described determination can be made by determining whether or not the first character is a numeral. Also,
The number of “*” may be matched to the number of characters of the name data.

In this way, when the search condition is input, a search is made for initial data that meets this condition (S104), and the result is output (S105). This output is normally performed by printing a list of search results by the printer 3.

When the cancel key is pressed (S106), the processing level is returned to the previous state, and the window first level is displayed (FIG. 4).

In this state, when the initial correction key is pressed (S107), the mode is changed to the correction mode, and the data can be corrected. Therefore, the patient code is input based on the list of the patients to which the dummy data obtained as described above is input (S1).
08). As a result, the head data of the patient specified by the patient code is displayed, and this correction is made (S109).

Here, this correction operation is performed by inputting correct data described in a prescription or the like. Since the patient code is determined at the time of the first input of the dummy data, it may be noted on the prescription at this time.

Then, when the correction is completed, the end key is pressed (S110). Then, it is confirmed whether or not the correction work has been completed (S111), and the processing is terminated.

Such data correction work may be performed at a sufficient time, such as after the window for the patient is closed, and efficient work can be performed.

In the above example, the input patient code is used as the name data. However, the name data may be stored in the dummy data storage unit. Further, as the name data, other symbols that are not usually used for names may be used instead of numbers.

Further, in the above-described embodiment, only the insurance dispensing claim business has been described. However, the business computer according to the present invention is not limited to this and can be used for business handling medical care data and business processing data.

[Effects of the Invention] As described above, according to the present invention, an input operation can be performed quickly by inputting dummy data as specific initial data required to be input in response to a predetermined key operation. In addition, the efficiency of window operations can be improved.

Furthermore, by inputting data that is not normally used for a name as name data, it is possible to easily extract a visitor to whom dummy data has been input, so that the correction can be performed efficiently.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of a window data processing device according to one embodiment of the present invention, FIG. 2 is an explanatory diagram showing a data configuration of a dummy data storage unit, and FIG. 3 is an operation of inputting dummy data. 4 to 9 are explanatory diagrams showing display examples of screens, and FIG. 10 is a flowchart for explaining an operation of correcting dummy data. 1 ... Keyboard 1a ... Call key 2 ... Display 3 ... Printer 7 ... Processor 8 ... Memory 8a ... Head data area 8b ... Dispensing data area 9 ... Magnetic disk 9a ... Head file 9b ... … Dispensing file 9c …… Dummy data file

Claims (2)

(57) [Claims] In a counter service, a head visitor's data such as a name can be uniquely inputted from an input means for a visitor who visits a counter, and it is determined whether or not a specific head record data in the head record data has been inputted. In the office computer that accepts the input of the processing data to the visitor only when provided, a dummy data generating means for generating dummy data for the specific head data is provided, and in accordance with a predetermined key operation on the input means, A data input method in a window operation of an office computer, wherein the dummy data from the dummy data generating means is input as the head data of the visitor. 2. The data input method according to claim 1, wherein said specific initial data includes a name, and said dummy data generating means generates a dummy name using a symbol which is not usually used as a name. The office computer further comprises extraction means for extracting whether or not the input name of each visitor is the name by the symbol, thereby extracting the visitor to whom the dummy data has been input as the head data. Data input method in the window business of a computer.