JP5604127B2 - Implementation plan support system and implementation plan support program - Google Patents

Description

  The present invention relates to an execution plan support system and an execution plan support program that support an execution plan for implementing a plurality of standardized execution actions for an execution target.

  Conventionally, a critical path showing a medical-related action in a two-dimensional structure is known. This critical path systematically guarantees and improves medical quality and efficiency by presenting vast amounts of medical knowledge accumulated as personal tacit knowledge of doctors as formal knowledge through standardization and visualization. It is useful in that it can. However, it has been pointed out that there is a possibility that the critical path cannot be applied depending on the condition of the patient, or that the critical path may be deviated from the standard course assumed in advance.

  In view of this point, the present inventor has proposed a medical process quality management system and a medical process quality management method (see Patent Document 1). This system includes a storage unit that stores a plurality of medical processes to be performed on a patient, an execution order of each medical process, and a process management unit that reads a medical process to be executed next. In this system, using “process chart (clinical process chart)” and “unit sheet”, the contents of medical practice are sequentially presented to a doctor or the like according to the clinical route. A “unit sheet” is a visualization of a “unit (process)” that is a medical practice unit formed for each target state of a patient. The “process chart” is an overhead view of a clinical route configured by connecting a plurality of units.

  In this way, by presenting each doctor with the standardized contents of the contents of the medical practice and the order of execution by using two types of tools, a process chart and a unit sheet, each doctor can independently determine the contents of the medical practice and Compared with the case where the execution order is determined, it is possible to standardize medical practice, and thereby maintain and improve the quality of the medical process. Further, according to this system, since it is possible to flexibly cope with individuality of patients, it is possible to solve the problems of the conventional critical path.

  However, when creating such a process chart, if each doctor creates one by one based on personal judgment, it will be difficult to spread the system because the labor will be burdened, or There is a possibility that the quality of standardization cannot be maintained due to the creation work based on different judgment criteria and knowledge.

  In view of this point, the inventors of the present application have proposed an apparatus for supporting creation of a process chart (see Patent Document 2). According to such a device, a process chart format composed of a plurality of medical processes to be performed on a patient can be automatically generated by having a doctor answer questions related to treatment for a case. Can do.

International Publication No. 2006/057336 Pamphlet JP 2007-128351 A

  However, in recent years, tailor-made medical care has been proposed that selects drugs to be administered according to the patient's genotype. In such advanced medical care, standardization is standardized for all patients as described above. The applied medical process could not be applied as it was.

  The present invention has been made in view of the above, and in the case of supporting a standardized execution plan, an execution plan support system that makes it possible to execute the execution plan in consideration of the attributes of the execution target, and The purpose is to provide an implementation plan support program.

In order to solve the above-described problems and achieve the object, the implementation plan support system according to claim 1 can take the contents of the implementation actions of the plurality of implementation actions that can be performed on the implementation target and the plurality of implementation actions. Execution plan information related to an execution plan including an execution order, the execution target identification information for uniquely identifying the execution target, the contents of the plurality of execution actions, and the execution order of the plurality of execution actions Implementation plan information storage means for storing implementation plan information configured by associating implementation conditions of the plurality of implementation activities with each other, implementation target identification information, and actual implementation with respect to the implementation target Implementation condition information storage means for storing implementation condition information configured to correlate the types of implementation conditions for determining the implementation actions or the implementation order to be performed, and the attributes of the implementation targets, and The implementation plan management means for changing the implementation action or the implementation order included in the implementation plan information, wherein the implementation plan management means has the implementation target attribute corresponding to specific implementation target identification information as the implementation plan. It is determined whether or not it is stored in the condition information storage means, and when it is determined that the implementation target attribute is stored, the implementation target attribute and the implementation condition type corresponding to the implementation target attribute Is generated from the execution condition information storage means, and an execution condition satisfying the execution target specified by the specific execution target identification information is generated based on the acquired execution target attribute and the execution condition type, The execution plan information corresponding to specific execution target identification information is acquired from the execution plan information storage means, and the execution condition information is obtained from the execution conditions included in the acquired execution plan information. An execution condition that matches the execution condition type acquired from the payment means is acquired, and it is determined whether or not there is an execution condition that is not satisfied by the generated execution condition in the acquired execution condition. When there is no execution condition, the execution action or the execution order corresponding to the unfulfilled execution condition from the execution action or the execution order included in the execution plan information corresponding to the specific execution target identification information By deleting the execution order, the execution action or the execution order included in the execution plan information is changed.

The implementation plan support system according to claim 2 is the implementation plan support system according to claim 1, wherein the implementation plan management means includes the implementation act included in the implementation plan information corresponding to the specific implementation target identification information or After determining the implementation action or the change order of the implementation order included in the implementation plan information by deleting the implementation action or the implementation order corresponding to the unfulfilled implementation condition from the implementation order, Information for requesting approval for the determination result is output to the user via the output means, and only when the approval for the determination result is received from the user via the input means, the execution plan information includes the information The implementation action or the implementation order is changed .

The execution plan support system according to claim 3 is the execution plan support system according to claim 1 or 2 , wherein the execution target is a patient, the execution action is a medical action, and the execution plan is a medical plan .

An implementation plan support program according to claim 4 is an implementation plan configured to include a content of implementation actions of a plurality of implementation actions that can be executed on an implementation target and an execution order that the plurality of implementation actions can take. Implementation plan information regarding the implementation target identification information for uniquely identifying the implementation target, the contents of the plurality of implementation actions, the implementation order of the plurality of implementation actions, and the implementation conditions of the plurality of implementation actions. The execution plan information storage means for storing the execution plan information configured in association with each other, the execution target identification information, and the execution action or the execution order actually executed on the execution target is determined. Included in the execution plan information, and an execution condition information storage means for storing execution condition information configured to associate the type of the execution condition for the attribute and the attribute of the execution target with each other The execution plan or the execution plan management means for changing the execution order, the execution plan management means, the execution plan management means, the attribute of the execution target corresponding to specific implementation target identification information It is determined whether or not the execution condition information is stored in the execution condition information storage means. If it is determined that the execution target attribute is stored, the execution target attribute and the execution condition type corresponding to the execution target attribute are determined. Is generated from the execution condition information storage means, and an execution condition that satisfies the execution target specified by the specific execution target identification information is generated based on the acquired execution target attribute and the execution condition type, The execution plan information corresponding to the specific execution target identification information is acquired from the execution plan information storage means, and from the execution conditions included in the acquired execution plan information, An execution condition that matches the execution condition type acquired from the condition information storage unit is acquired, and it is determined whether or not there is an execution condition that is not satisfied by the generated execution condition in the acquired execution condition. If there is an implementation condition that is not implemented, the implementation action corresponding to the implementation condition that is not satisfied from the implementation action or the implementation order included in the implementation plan information corresponding to the specific implementation target identification information Alternatively, the execution action or the execution order included in the execution plan information is changed by deleting the execution order.

An execution plan support program according to claim 5 is the execution plan support program according to claim 4 , wherein the execution target is a patient, the execution action is a medical action, and the execution plan is a medical plan.

According to the implementation plan support system according to claim 1 or the implementation plan support program according to claim 4 , it becomes possible to customize the implementation plan based on the attributes of the implementation target based on the standardized implementation plan. It is possible to carry out an execution plan that matches the target attributes. Therefore, it is possible to improve the quality of the implementation action.

According to the implementation plan support system according to claim 2 , the implementation actions or the execution order are automated to save the effort, and only the implementation actions or the execution order finally approved by experts, etc. are made into the actual implementation plan. Reflecting it makes it possible to ensure the quality and safety of the implementation plan.

According to the implementation plan support system or implementation plan support program according to claim 5 according to claim 3, based on the standardized care plan, it is possible to customize the medical care schedule based on the attributes of the patient, the patient It is possible to perform a medical plan that matches the attributes. Therefore, it is possible to improve the quality of medical practice.

It is explanatory drawing which shows notionally the whole structure of the medical plan creation assistance system which concerns on embodiment of this invention. It is a figure which shows the basic composition model of a process chart and a unit sheet | seat. It is a figure which shows the example of a display screen of a unit sheet. It is a figure which shows the specific example of a process chart. It is a figure which shows the structural example of standard medical practice information. It is a figure which shows the structural example of hospital information. It is a figure which shows the structural example of doctor information. It is a figure which shows the structural example of disease information. It is a figure which shows the structural example of patient information. It is a figure which shows the structural example of medical plan information. It is a figure which shows the structural example of implementation condition information. It is a flowchart of a medical plan creation process. It is a figure which shows the example of a display of an initial screen. It is a figure which shows the example of a display in the state which added the unit to the initial screen of FIG. It is a figure which shows the example of a display of the state which added the arrow to the screen of FIG. It is a figure which shows the example of a display of a presentation screen. It is a flowchart of a medical plan management process. It is a flowchart of the determination process of implementation conditions. It is a figure which shows the example of a display of an approval request screen.

  DESCRIPTION OF EMBODIMENTS Embodiments for implementing an execution plan support system and an execution plan support program according to the present invention will be described below in detail with reference to the accompanying drawings. First, [I] the basic concept of the present embodiment will be described, then [II] the specific contents of the present embodiment will be described, and [III] finally, a modification to the present embodiment will be described. However, the present invention is not limited by the present embodiment.

[I] Basic concept of the present embodiment First, the basic concept of the present embodiment will be described. The implementation plan support system and the implementation plan support program according to the present embodiment enable execution of an implementation plan in consideration of the attributes of the implementation target when supporting a standardized implementation plan. Here, the implementation plan includes the contents of a plurality of implementation actions that can be performed on the implementation target and the execution order that the plurality of implementation actions can take.

  The implementation plan support system and the implementation plan support program can be applied to a wide range of fields, and conceptually, formal knowledge in the field (specifically, a plurality of implementation activities performed by the implementer for the implementation target) And the order of implementation among these implementation actions) can be applied to all fields that can be visualized. Examples of this application field include “medical field”, “disaster prevention field”, and “education field”, and according to this application field, “implementation target”, “practitioner”, “practice”, The specific contents of the “Implementation Plan” may vary. For example, in the medical field, implementation target = patient, practitioner = doctor (or medical institution such as a hospital), implementation action = medical action, implementation plan = medical plan. Similarly, in the disaster prevention field, implementation targets = disaster victims and victims of terrorist acts and disaster victims, implementers = rescuers, implementation activities = relief activities, implementation plans = relief plans, and in the education field, implementation targets = students , Implementer = teacher, implementation act = education act, implementation plan = education plan.

  The following describes the case where the implementation plan support system and implementation plan support program are applied to the medical field. Implementation target = patient, practitioner = medical staff such as doctors and nurses, implementation act = medical practice, implementation Plan = medical plan. Further, the implementation plan support system will be described as a medical plan support system (hereinafter “this system”), and the implementation plan support program will be described as a medical plan support program (hereinafter “this program”). In addition, when applying this system and this program to other fields, as described above, the contents of “Target”, “Performer”, “Performance”, and “Execution plan” are set according to the other field. You can replace it with the contents.

  The medical plan is medical plan information related to a medical plan that includes the contents of a plurality of medical actions that can be performed on a patient and the execution order that the plurality of medical actions can take. “Obtain” means that it may be done, but may not actually be implemented. Further, “can be taken” means that there is a possibility that it may be taken, but there is a possibility that it may not actually be taken.

  FIG. 1 is an explanatory diagram conceptually showing the overall configuration of a medical plan support system. As shown in FIG. 1, a creation server 10 installed in the integrated support center 1 and a management server 20 installed in each of a plurality of hospitals 2 are connected to a network 3 such as a WAN (Wide Area Network) or the Internet. Are connected so that they can communicate with each other. In each hospital 2, an order server 30 and a plurality of support terminals 40 are connected to the management server 20 via a network 4 such as a LAN (Local Area Network).

  In the present embodiment, the “patient condition adaptive path system (PCAPS)” disclosed in whole or in part in the above-described Patent Document 1 or Patent Document 2 is used. This patient state adaptive path system is a bird's-eye view model showing the clinical route from the initial state of the patient to the final target state. This clinical route is divided into a plurality of “target states” based on the “patient state”. These are visualized by linking with each other, and are specifically configured by using two tools of “process chart (clinical process chart)” and “unit sheet”.

  FIG. 2 shows a basic configuration model of these process charts and unit sheets. A process chart is configured by connecting “units (processes)”, which are medical practice units (units set to an appropriate size for managing medical quality) formed for each target state of a patient. FIG. 4 is an overhead view of a clinical route to be configured, and includes all clinical states that are configured for each disease and are assumed from the initial state to the final target state of a patient having the disease. Each unit is composed of an “execution element” and a “determination element”. The execution element indicates an action of executing a medical operation incorporated so that the patient state reaches the target state of the unit, and the determination element determines whether or not the patient state has reached the target state of the unit. Indicates the act to do. A “unit sheet” is configured as means for visually displaying each execution element and the determination element immediately after each execution element.

  An example of the unit sheet display screen is shown in FIG. Specifically, the unit sheet includes “patient ID”, “unit ID”, “medical practice”, “patient state”, “target state”, “unit transition logic”, “conditional instruction”, and “withdrawal condition”. Including. The patient ID is identification information for uniquely specifying a patient to which the unit sheet is applied. The unit ID is identification information for uniquely specifying a unit corresponding to the unit sheet. The medical practice is information describing the items and contents of the medical practice to be executed in the execution element corresponding to the unit sheet, and includes, for example, a medical practice, a care practice, and an adjustment action. The patient state is information describing the contents of the patient state to be noted in the unit corresponding to the unit sheet. The unit transfer logic is information describing a condition when transferring from the unit corresponding to the unit sheet to the next unit and the unit ID corresponding to the transfer destination unit sheet. The conditional instruction includes an instruction content for promptly responding to a patient condition that occurred during a medical practice in the unit. The separation condition is configured to include a condition for performing the separation because the unit seat may be detached when a transition state indicating a criterion for judging a dangerous deviation from the target state is entered. Yes.

  The “process chart” and “unit sheet” configured as described above can be created by a doctor of each hospital 2 using an ASP (Application Service Provider) service by the creation server 10. That is, the creation server 10 includes information for specifying the “process chart” and “unit sheet” configured as described above, and a function for supporting the creation of these “process chart” and “unit sheet”. The doctors of each hospital 2 can access these information and functions through the networks 3 and 4 via the support terminal 40 and create process charts and unit sheets.

  Implementation of the “process chart” and “unit sheet” created in this way is controlled by the management server 20. In other words, information regarding the created “process chart” and “unit sheet” is stored in the management server 20. The management server 20 presents the contents of the unit sheet corresponding to the first unit in the process chart to the doctor via the support terminal 40 by display output or the like. Then, when the doctor performs a medical action included in the presented unit sheet and inputs the subsequent patient state to the support terminal 40, the patient state is accepted by the management server 20 via the support terminal 40. Next, the management server 20 determines whether or not the patient state has reached the target state of the unit. If it is determined that the target state has been reached, the next unit of the first unit is identified based on the process chart, and the content of the unit sheet corresponding to the next unit is determined by the doctor via the support terminal 40. To present. Thereafter, similarly, the process of presenting the content of the unit sheet corresponding to the unit according to the order defined in the process chart, the process of accepting the input of the patient state by the doctor, and whether or not the target state has been reached is determined. The determination process is repeatedly performed, and the series of processes ends when the medical action of the last unit in the process chart ends.

  FIG. 4 is a specific example of a process chart. This process chart is an example of performing radical prostatectomy. This process chart includes an execution element and a determination element that constitute each of a plurality of units, and a line segment that connects these elements to each other. Has been shown. For example, after executing the medical action of the execution element “A-1 radical prostatectomy”, the determination element “SA-1” makes a determination based on the patient state and the target state, and the execution element is determined according to the determination result. Transition to either “A-2 acute phase after surgery” or execution element “B-2 acute phase after surgery”. In the frame of each execution element in FIG. 4, the name and unit ID of the unit corresponding to each execution element are shown. For example, the name of the unit corresponding to the first execution element is “before hospitalization”, and the unit ID is “A-0”.

[II] Specific contents of the present embodiment Next, specific contents of the present embodiment will be described. Below, the structure of each part of the medical plan support system shown in FIG. 1 will be described, and then the processing content of the medical plan support program executed using the medical plan support system will be described.

(Configuration-creation server)
First, the configuration of the creation server 10 in FIG. 1 will be described. The creation server 10 is an implementation plan creation support device that creates a medical plan including the content and order of medical practices that can be performed on a patient. The creation server 10 is configured by functionally conceptually connecting a storage unit 11, a control unit 12, and a network interface (hereinafter “network IF”) 13 so that they can communicate with each other via a bus.

  The storage unit 11 is a storage unit that stores information and parameters necessary for various processes in a nonvolatile manner, and is configured by, for example, an HD (Hard Disk) (the same applies to the storage unit 21 described later). Specifically, the storage unit 11 includes a standard medical practice information DB 11a, a hospital information DB 11b, a doctor information DB 11c, and a disease information DB 11d in terms of functional concepts. Specific contents of the information stored in each DB will be described later.

  The control unit 12 is a control unit that controls each unit of the creation server 10, and includes a medical plan information generation unit 12a functionally. The medical plan information generating unit 12a is a medical plan information generating unit that generates medical plan information for specifying a process chart and a unit sheet. Specifically, the control unit 12 includes a CPU (Central Processing Unit), various programs interpreted and executed on the CPU (control programs such as an OS, programs defining various processing procedures, and the like), and And a cache memory for storing required programs and required data (the same applies to the control unit 22 described later). The various programs that are interpreted and executed on the CPU include this program. The program is stored in an arbitrary storage medium including a CD-ROM and a DVD, and then installed and nonvolatile in the storage unit 11. Thus, the substantial function of the control unit 12 is configured by being interpreted and executed by the CPU (the same applies to the control unit 22 described later).

  The network IF 13 is a communication unit for performing communication via the network 3, and is configured as, for example, a network board (the same applies to the network IF 23 described later). Since the information input from the support terminal 40 is received via the network IF 13, the network IF 13 functions as an input unit and outputs various information via the network IF 13. (Same in network IF 23 described later).

(Configuration-management server)
Next, the configuration of the management server 20 will be described. The management server 20 is an implementation plan management apparatus that manages the implementation of the medical plan created by the creation server 10. The management server 20 is configured by functionally conceptually connecting a storage unit 21, a control unit 22, and a network IF 23 so that they can communicate with each other via a bus.

  Specifically, the storage unit 21 includes a patient information DB 21a, a medical plan information DB 21b, and an execution condition information DB 21c in terms of functions. Specific contents of the information stored in each DB will be described later.

  The control unit 22 is a control unit that controls each unit of the management server 20, and includes a medical plan management unit 22a functionally. The medical plan management unit 22 a is an execution plan management unit that manages execution of a standard medical plan created by the creation server 10.

(Configuration-Order server)
The order server 30 is a resource management device that performs ordering of various resources, inventory management, or reservation management. The specific configuration of the order server 30 is arbitrary, and as long as it has a communication function with the management server 20, it can be configured in the same manner as a known server device, and thus detailed description thereof is omitted. In addition to the order server 30, the server arranged in the hospital 2 can include any server such as a medical accounting server.

(Configuration-support terminal)
Each support terminal 40 is a terminal device for medical personnel including doctors to input and output to the management server 20, and in particular, an input function for receiving an input of a patient state, and an output of a process chart and a unit sheet. Has an output function to perform. Since the support terminal 40 can be configured in the same manner as a known personal computer as long as it has a communication function with the management server 20 and an input / output function of various information, a detailed description thereof will be omitted.

(Configuration-Database specific contents-Creation server)
Next, specific contents of each DB of the creation server 10 and the management server 20 will be described. However, the following configuration example shows an example in which only the information according to the present embodiment is stored. Actually, any information other than the information described below can be stored in each DB, or some information May be omitted as appropriate. In addition, among the information stored in each DB, the information with the same name is assumed to have the same contents except for the case of special mention, and redundant description will not be given.

  First, specific contents of each DB of the creation server 10 will be described. The standard medical practice information DB 11a in FIG. 1 stores the standard medical practice information for specifying the content of the unit sheet for specifying the content of the standardized medical practice to be performed on the patient by the medical practice unit. Information storage means. As illustrated in FIG. 5, the standard medical practice information includes an item “unit ID”, an item “medical practice”, an item “patient status”, an item “target status”, an item “unit transition logic”, and an item “conditional. Information corresponding to the “instruction”, the item “leaving condition”, and the item “standard staying days” are associated with each other. The information corresponding to the item “standard stay days” is the standard stay days of each unit (the number of days from the transition to the unit to the transition to the next unit). The information corresponding to the other items is as described in the explanation of the display screen in FIG.

  Here, at least a part of the information corresponding to each of the item “medical practice”, the item “unit transfer logic”, and the item “conditional instruction” includes implementation condition information. The implementation condition information is an implementation condition for determining a medical practice or an implementation order that is actually performed on a patient, and is information that identifies an implementation condition based on a patient attribute (profile). In other words, here, there are some medical practices and implementation orders that make up a standardized medical plan that are preferably added, changed, or deleted in accordance with patient attributes. For example, regarding medical practice, even when the same drug is administered in a specific unit, it may be preferable to administer more than the standard because the drug is less effective depending on the genotype of the patient. Moreover, regarding the execution order, even when a specific unit ends and moves to the next unit, it may be preferable to transfer to a different unit depending on the gene type of the patient. In view of such points, in the present embodiment, the standardized medical plan includes all medical actions that can be performed on the patient and all the execution orders that the plurality of medical actions can take. In addition, the conditions for determining the medical practice and the order of execution that match the patient's attributes are further included, and when the patient's attributes are determined, the medical practice and the order of execution that match the attributes are determined. It is possible to decide.

  The specific contents of the patient attributes are arbitrary, but for example, the patient's age, gender, country of origin or region, country of residence or region, blood type, genotype can be mentioned, one or more of these Can be used. In the present embodiment, as a simple example, it is assumed that patient attributes = blood type and gene type.

  The concrete description format of the implementation conditions is arbitrary. For example, the implementation conditions may be described in all of the information corresponding to the item “medical practice”, the item “unit transition logic”, and the item “conditional instruction”, or may be described only in part. . When the execution condition is not described, it is assumed that the execution condition does not exist, and the standardized medical practice and the execution order are actually executed regardless of the attributes of the patient. For example, in the case where three medical actions are performed in parallel in a specific unit and the execution conditions are not described at all, the three medical actions are actually executed in parallel. When the implementation conditions are described, one or a plurality of implementation conditions are described for one medical practice or implementation order. For example, in a specific unit, when only one implementation condition for a specific medical practice is described, the specific medical practice is actually implemented only when the implementation condition is satisfied. Alternatively, in the case where three medical actions are sequentially performed in one specific unit, each medical action is described with a number indicating the order of execution, and as an execution condition for the second medical action, If it is described that the second medical practice should be implemented only when the result of the first medical practice is a specific result, the first practice is performed. Only when the result of the medical practice to be performed has a specific result, the second medical practice to be implemented is actually implemented. In addition, when describing a plurality of implementation conditions, a medical practice or an implementation order is actually implemented only when all of these implementation conditions are satisfied (in the case of an AND condition), or any one of these When one or more implementation conditions are satisfied, a medical practice or an implementation order may be actually implemented (an OR condition). In this embodiment, the implementation condition is described as “implementation condition = blood type O”, and in this case, the fact that the implementation is actually performed only when the blood type of the patient is the O type is shown. And

  The method and timing for storing the standard medical practice information are arbitrary, but for example, the standard medical practice information is determined based on standardization based on a doctor's hearing and the like, and connected to the creation server 10 for management (not shown) It can be stored in advance in the standard medical practice information DB 11a via the terminal. As a specific description structure of each piece of information, an arbitrary structure other than the configuration example shown in FIG. 5 can be adopted. For example, each piece of information is tagged using an XML (Extensible Markup Language) format. The meaning can be structured.

  The hospital information DB 11b in FIG. 1 is a hospital information storage unit that stores information (hospital information) about each hospital 2. As illustrated in FIG. 6, the hospital information is configured by associating an item “hospital ID”, an item “address”, an item “classification”, and an item “number of beds” with each other. Information corresponding to the item “hospital ID” is identification information for uniquely identifying each hospital 2. The information corresponding to the item “address” is the address of each hospital 2. The information corresponding to the item “classification” is information indicating the classification of each hospital 2 (in this case, either acute phase or chronic phase). The information corresponding to the item “number of beds” is the total number of beds in each hospital 2.

  The doctor information DB 11c in FIG. 1 is a doctor information storage unit that stores information (doctor information) about each doctor. As illustrated in FIG. 7, the doctor information includes an item “doctor ID”, an item “hospital ID”, an item “specialty”, and an item “experience years” that are associated with each other. Information corresponding to the item “doctor ID” is identification information for uniquely identifying each doctor. The information corresponding to the item “hospital ID” is the hospital ID of the hospital 2 to which each doctor belongs, and the content is the same as the information corresponding to the item “hospital ID” in FIG. The information corresponding to the item “specialty” is a specialized field of each doctor. The information corresponding to the item “year of experience” is the number of years of experience as a doctor of each doctor.

  The disease information DB 11d in FIG. 1 is a disease information storage unit that stores information (disease information) related to a disease to be treated by each medical plan. As illustrated in FIG. 8, this disease information is configured by associating an item “disease ID” and an item “disease name” with each other. Information corresponding to the item “disease ID” is identification information for uniquely identifying each disease. The information corresponding to the item “disease name” is the name (disease name) of each disease.

(Configuration-Database details-Management server)
Next, specific contents of each DB of the management server 20 in FIG. 1 will be described. The patient information DB 21a is a means for storing information (patient information) about a patient who is a subject of medical practice. As illustrated in FIG. 9, the patient information is configured by associating information corresponding to the item “patient ID”, the item “age”, the item “sex”, the item “address”, and the item “disease ID”. Has been. Information corresponding to the item “patient ID” is identification information for uniquely identifying a patient to be a target of each medical plan. The information corresponding to the item “age”, the item “gender”, and the item “address” is the age, sex, and address of each patient, respectively. The information corresponding to the item “disease ID” is information for uniquely identifying each disease of each patient, and the content is the same as the information corresponding to the item “disease ID” in FIG.

  The medical plan information DB 21b in FIG. 1 is an implementation plan information storage unit that stores medical plan information for specifying a medical practice to be performed on a patient and an execution order. As illustrated in FIG. 10, the medical plan information includes an item “patient ID”, an item “doctor ID”, an item “disease ID”, an item “unit ID”, an item “medical practice”, an item “patient state”, Information corresponding to the item “target state”, the item “unit transition logic”, the item “conditional instruction”, the item “leaving condition”, and the item “standard staying days” is associated with each other. The information corresponding to each item is the same as the information corresponding to the same item in FIG. 5 to FIG. 9, and each of the item “medical action”, the item “unit transfer logic”, and the item “conditional instruction”. Implementation condition information is included in at least a part of the corresponding information. Here, by associating a plurality of unit IDs with one patient ID and disease ID, a plurality of treatments for the disease specified by the disease ID are performed for the patient specified by the patient ID. Medical practices are identified. The execution order of this medical practice is specified by arbitrary information (not shown). For example, the arrangement of each unit specified in the flowchart in the medical plan creation process described later is specified by structuring as XML format data, or specified as drawing data in the flowchart, and stored in the medical plan information DB 21b. Is done.

  The execution condition information DB 21c in FIG. 1 is an execution condition information storage unit that stores the execution condition information and patient attributes in association with each other. As illustrated in FIG. 11, the execution condition information is configured by associating information corresponding to an item “patient ID”, an item “execution condition type”, and an item “patient attribute”. Information corresponding to the item “patient ID” is the same as information corresponding to the same item in FIG. 9. The information corresponding to the item “execution condition type” is information for specifying the type of the execution condition, and in the present embodiment, it is the gene type and blood type as described above. The information corresponding to the item “patient attribute” is the actual gene type and blood type of the patient specified by the patient ID.

(processing)
Next, a medical plan support process (hereinafter, this process) performed by executing this program in this system will be described. This process is roughly divided into a medical plan creation process for creating medical plan information and a medical plan management process for managing the medical plan created by this medical plan creation process. Hereinafter, each of these processes will be described sequentially. Step is abbreviated as “S”.

  In the following description of this processing, processing that does not specify the control subject is assumed to be executed by the control unit 12 of the creation server 10 or the control unit 22 of the management server 20, and does not specify the information acquisition source or acquisition route. The case is stored in advance in the storage unit 11 of the creation server 10 or the storage unit 21 of the management server 20 by a known timing and a known method, or is input by a medical worker via the support terminal 40. Shall be.

(Processing-Medical plan creation process)
First, the medical plan creation process will be described. FIG. 12 is a flowchart of a medical plan creation process. First, the doctor of each hospital 2 accesses the creation server 10 by a predetermined method via the support terminal 40 and transmits a medical plan creation request. At this time, the doctor assigns to the hospital ID assigned in advance to the hospital 2 to which the patient belongs, the doctor ID assigned in advance to the patient, the disease ID assigned in advance to the disease of the patient who is the subject of the medical plan, and the patient. The assigned patient ID is input to the support terminal 40. Among these, since there is a possibility that there will be a problem from the viewpoint of protecting personal information of the patient in presenting the patient ID outside the hospital 2, only the hospital ID, the doctor ID, and the disease ID are created together with the creation request. 10 is transmitted.

  On the other hand, the medical plan information generation unit 12a of the creation server 10 monitors whether or not a creation request has been received (step SA1), receives the creation request (step SA1, Yes), hospital ID, doctor ID, and When the disease ID is received (step SA2), the screen data of a predetermined initial screen is transmitted to the support terminal 40.

  The screen data of the initial screen is interpreted by general-purpose or dedicated browser software installed in advance on the support terminal 40, and the initial screen is displayed on the monitor of the support terminal 40. A display example of this initial screen is shown in FIG. The initial screen includes, for example, a connection button B1 and a unit button B2, and a plan drawing area A1. The connection button B1 is an instruction button for instructing the mutual connection of each unit included in the process chart and “start (start point of process chart)” or “end (end point of process chart)”. The unit button B2 is an instruction button for instructing addition of a unit. The planned drawing area A1 is an area for drawing a process chart. In the planned drawing area A1 of the initial screen, one “start” and one “end” are drawn by default.

  Thereafter, the doctor can add one “unit” to the planned drawing area by selecting the unit button B2 via the input device of the support terminal 40 as shown in the display example of FIG. Similarly, the doctor can add any number of “units” as necessary to the planned drawing area by repeatedly selecting the unit button B2. Furthermore, after selecting the connection button B1 via the input device, the doctor designates one or more sets of “start”, “unit” or “end” to be connected to each other via the input device. An arrow connecting the “start”, “unit” or “end” is drawn. In the display example of FIG. 15, an arrow AR1 that connects “start” and “unit” to each other is shown. By performing such connection designation, a transition path (medical practice execution order) in the process chart is specified.

  After the doctor designates an arbitrary “unit” via the input device of the support terminal 40, the input device of the support terminal 40 is used to present detailed information (in this case, standard medical practice information) to be set in the “unit”. If requested, the medical plan information generation unit 12a of the creation server 10 acquires standard medical practice information from the standard medical practice information DB 11a, and generates screen data of a presentation screen for presenting this standard medical practice information. It transmits to the support terminal 40 (step SA3, Yes, SA4).

  The screen data of the presentation screen is interpreted by general-purpose or dedicated browser software installed in advance on the support terminal 40, and the presentation screen is displayed on the monitor of the support terminal 40. A display example of this presentation screen is shown in FIG. In this presentation screen, for example, standard medical practice information that is structured in advance and stored in the standard medical practice information DB 11a is displayed in a hierarchical structure in a tree structure corresponding to the structure. The doctor confirms this content, edits it via the input device of the support terminal 40 as necessary, and then instructs the application of the standard medical practice information by a predetermined method. It is set as details of the designated “unit” (contents of medical practice in the unit).

  Thereafter, by repeating the same procedure for each “unit” placed in the process chart, the contents of all “units” are specified, and the transition path and the contents of each “unit” in the process charts specified so far are identified. The included medical plan information in a predetermined format is generated, and the medical plan information generation process ends (Yes in step SA5).

(Processing-Medical plan management processing)
Next, a medical plan management process will be described. FIG. 17 is a flowchart of the medical plan management process. When the doctor instructs the start of the medical process by inputting the patient ID of the patient who wants to perform medical care via the support terminal 40 at an arbitrary timing (step SB1, Yes), the medical plan management unit 22a of the management server 20 The medical plan information corresponding to the patient ID is acquired from the medical plan information DB 21b, and the medical plan information is output to the monitor of the support terminal 40 as a process chart or a unit sheet (step SB2). Therefore, the doctor can confirm the medical practice corresponding to the patient's disease and the implementation procedure and perform the medical practice with the standardized contents and procedure.

  Each time the doctor performs a medical practice displayed on each unit sheet, the doctor inputs the state of the patient on whom the medical practice has been performed to the management server 20 via the support terminal 40 (step SB3). The medical plan management unit 22a of the management server 20 compares the input patient state with the target state of the unit sheet in the medical plan information to determine whether or not the patient state has reached the target state (step). SB4). And when it determines with the patient's state having reached the target state (step SB4, Yes), the medical plan management part 22a performs the determination process of the implementation condition mentioned later (SB8), and determination of this implementation condition The contents of the unit sheet of the next unit specified by the process chart specified by the medical plan information changed by the process or the medical plan information changed by the execution condition determination process are sent to the support terminal 40 Transmit and display on the monitor (step SB9). By browsing the contents of the process chart and the unit sheet via the support terminal 40, the doctor can browse the contents of the process chart and the unit sheet that match the patient state, and can confirm the implementation contents of the medical practice.

  On the other hand, when it is determined in step SB4 that the patient state does not reach the target state (step SB4, No), the medical plan management unit 22a does not move to the next unit sheet, but inputs the next patient state. Wait until it is accepted. Here, when the patient state greatly deviates from the target state and matches the separation condition, the unit is removed (step SB5, Yes). Various methods can be used as the method for identifying the action after the withdrawal, but here, the contents of each unit sheet included in the medical plan information are sequentially presented to the support terminal 40 (step SB6), and the withdrawal destination is selected from these. The unit sheet that seems to be optimal is selected by the doctor, and if there is a selection (step SB7, Yes), this unit sheet is displayed (step SB9), and thereafter, the unit sheet is used as a starting point. , Based on the unit transition logic defined in the unit sheet.

(Processing-Medical plan management processing-Implementation condition judgment processing)
In such processing, the medical plan management unit 22a of the management server 20 performs execution condition determination processing before presenting a process chart or a unit sheet in step SB9 (SB8). That is, generally, when the medical plan management unit 22a displays a process chart or unit sheet in each of these steps, the attributes of the patient to be managed by the process chart or unit sheet and the process Based on the implementation conditions included in the medical plan information that is the basis of the chart or unit sheet, the medical practices and implementation order that may be actually implemented are identified, and the identified medical practices and implementation The process chart and unit sheet are updated based only on the order, and only the updated process chart and unit sheet are displayed.

  Details of the execution condition determination process will be described below. FIG. 18 is a flowchart of an execution condition determination process. First, when displaying a process chart or a unit sheet, the medical plan management unit 22a refers to the implementation condition information DB 21c based on the patient ID of the patient input in step SB3, and the patient corresponding to the patient ID. It is determined whether or not there is at least one attribute (here, gene type and blood type) (SC1).

  Here, in the initial stage of the medical plan for the patient, the examination result or the like is not yet known, and the patient attribute may not be stored in the execution condition information DB 21c. In such a case (SC1, No), the medical plan management unit 22a ends the execution condition determination process without specifying or changing the medical practice or the execution order based on the patient attributes and the execution conditions. In this case, the medical plan management unit 22a refers to the medical plan information stored in the medical plan information DB 21b at that time in SB9 of FIG. 17 and performs all possible medical actions that can be performed. Generate and display process charts and unit sheets based on the order. That is, in this case, the same process chart and unit sheet are managed as in the conventional case, and the unit sheet as shown in FIG. 3 and the process chart as shown in FIG. 4 are displayed.

  Thereafter, when the test result or the like is stored in the implementation condition information DB 21c via the support terminal 40 and it is determined that there is at least one patient attribute corresponding to the patient ID (SC1, Yes), the medical plan management unit 22a Then, the attribute of the patient determined to be present and the execution condition type corresponding to the attribute of the patient are acquired from the execution condition information DB 21c, and the patient ID is determined by the acquired patient attribute and the execution condition type. An implementation condition that is satisfied by the identified patient is generated (SC2). For example, when the patient attribute = O type and the execution condition type = blood type are acquired, the blood type = O type is generated as the execution condition.

  In addition, the medical plan management unit 22a acquires medical plan information corresponding to the patient ID from the medical plan information DB 21b, and acquired from the execution condition information DB 21c in SC2 among the execution conditions included in the acquired medical plan information. An execution condition that matches the execution condition type is acquired (SC3).

  Then, the medical plan management unit 22a determines whether there is an execution condition that is not satisfied by the execution condition generated in SC2 among the execution conditions acquired in SC3 (SC4). When there is no implementation condition that is not satisfied (SC4, No), the medical plan management unit 22a does not have an implementation condition to be deleted, and there is no need to change the process chart or unit sheet. The execution condition determination process is terminated without specifying or changing the medical practice or the execution order based on the attribute and the execution condition. In this case, as in the case of No in SC1, the same process chart and unit sheet management as in the conventional case is performed, and the unit sheet as shown in FIG. 3 and the process chart as shown in FIG. 4 are displayed.

  On the other hand, when at least one implementation condition is not satisfied (SC4, Yes), the medical plan management unit 22a generates an approval request screen for requesting approval for the determination result, and displays the generated approval request screen. It transmits to the support terminal 40 which is presenting the process chart and unit sheet (SC5). As a result, an approval request screen is displayed on an output means (for example, a monitor) (not shown) of the support terminal 40.

  A display example of this approval request screen is shown in FIG. This approval request screen includes a display area R1 for displaying the medical practice before the change and the execution order, a display area R2 for displaying the medical practice after the change and the execution order, and instruction buttons B3 and B4 for instructing approval / disapproval. It consists of The medical action and execution order before the change are the medical action and execution order corresponding to the execution conditions determined in SC4, and the medical action and execution order presented in the case of SC3, No are displayed. As the medical practice and implementation order after the change, the medical practice and the implementation order corresponding to the implementation conditions determined not to be satisfied in SC4 from the medical practice and the implementation order before the change are displayed. To do.

  And when a medical worker pushes down instruction button B4 via input means (for example, mouse) which is not illustrated of support terminal 40, medical plan management part 22a was not approved change of medical practice or execution order (SC6, No), the determination process of the execution condition is terminated without specifying or changing the medical practice or the execution order based on the patient's attribute and the execution condition. In this case, as in the case of No in SC1, the same process chart and unit sheet management as in the conventional case is performed, and the unit sheet as shown in FIG. 3 and the process chart as shown in FIG. 4 are displayed.

  On the other hand, when the medical staff pushes down the instruction button B3 via an input unit (for example, a mouse) (not shown) of the support terminal 40, the medical plan management unit 22a has received approval for a change in medical practice or execution order. As a thing (SC6, Yes), a medical plan is changed based on the said approved medical practice or execution order (SC7). That is, the medical plan management unit 22a determines that the implementation condition acquired in SC3 is not satisfied from the medical practice and the execution order in the process chart and unit sheet that have been presented for the patient ID so far. By deleting the execution order, a process chart and a unit sheet configured only by the medical practice and the execution order satisfying the execution conditions acquired in SC3 are generated and presented.

  For example, in the unit sheet of FIG. 3, when the blood pressure becomes 135 or more as a conditional instruction, “when blood type = O type, administration of 10 mg of a blood pressure lowering agent”, “when blood type = other than O type” In the unit sheet presented in SB9 of FIG. 17 after that, when the blood condition = O type is included in the execution conditions generated in SC2, As a supplementary instruction, when the blood pressure becomes 135 or more, only “administer blood pressure lowering agent 10 mg when blood type = O type” is displayed. In this way, medical activities that are not scheduled to be performed are excluded from the unit sheet, and only medical activities that are scheduled to be performed are displayed, so that medical staff can more accurately and easily describe the contents of medical activities. It becomes possible to grasp.

  Alternatively, in the process chart of FIG. 4, either the unit of unit ID = A−2 or the unit of unit ID = B−2 is implemented after the unit of unit ID = A−1. However, if it is determined that there is no possibility that the unit ID = B-2 is actually executed according to the execution condition generated in SC2, in the process chart presented in the subsequent SB9 of FIG. 17, the unit ID = A− Only 2 units are displayed. In this way, by eliminating the possible execution order from the process chart and displaying only the possible execution order, the medical staff can make the contents of the execution order more accurate and easy. It becomes possible to grasp. This ends the medical plan management process.

(Effect of embodiment)
As described above, according to the present embodiment, when the actual medical practice or the order of implementation is determined by referring to the implementation condition information based on the attributes of the patient, the determined medical practice or implementation is performed. Because medical plans are managed based on order, it is possible to customize medical plans based on patient attributes based on standardized medical plans, and to perform medical plans that match patient attributes Become. Therefore, it is possible to improve the quality of medical practice.

  In addition, by referring to the implementation condition information based on the patient's attributes, the actual medical practice or implementation order is determined, so that it is possible to accurately and easily determine the medical practice or implementation order. .

  In addition, since the medical plan is managed based on the determined medical practice or execution order only when approval for the determined medical practice or execution order is accepted, the medical practice or execution order is automated and the labor is saved. In addition, it is possible to ensure the quality and safety of the medical plan by reflecting only the medical action or the execution order finally approved by the medical staff in the actual medical plan.

  In addition, since the medical practice or the order to be actually carried out is determined based on the patient attributes stored in the implementation condition information DB 21c, it is possible to accumulate in the implementation condition information DB 21c every time the patient attributes are determined. The actual medical practice or order of practice is automatically determined.

  In addition, since the medical plan based on the determined medical practice or execution order is output, even the medical practice or implementation order included in the standard medical plan is included in the determined medical practice or implementation order. Since the output is omitted for the medical actions and the execution order that have not been performed, it is possible to more easily grasp the customized medical plan.

[III] Modifications to Each Embodiment While each embodiment according to the present invention has been described above, the specific configuration and means of the present invention are the same as the technical idea of each invention described in the claims. Any modifications and improvements can be made within the scope. Hereinafter, such a modification will be described.

(About problems to be solved and effects of the invention)
First, the problems to be solved by the invention and the effects of the invention are not limited to the above-described contents, and the present invention solves the problems not described above or has the effects not described above. There are also cases where only some of the described problems are solved or only some of the described effects are achieved.

(About configuration and control)
Further, all or any part of the control described as being automatically performed in the above embodiment may be performed manually, and conversely, all or any one of the control described as being performed manually is performed. The part may be automated based on a known technique or the above-described idea. Moreover, you may comprise a part or all of each functional block of each component shown in the said embodiment with a hard wired logic.

(About distribution and integration)
Further, each of the electrical components described above is functionally conceptual and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each part is not limited to the one shown in the figure, and all or a part thereof may be functionally or physically distributed / integrated in arbitrary units according to various loads and usage conditions. Can be configured. For example, the creation server 10 and the management server 20 may be integrated with each other, or some functions of the creation server 10 and the management server 20 may be distributed to other servers and support terminals 40.

(About implementation conditions)
In the above embodiment, the process chart and the unit chart are updated by deleting the medical practice and the execution order based on the determination result of the implementation condition, but by adding or changing the medical practice and the execution order The process chart and unit chart may be updated. For example, as an implementation condition, it is stipulated that a specific medicine is to be administered only when the patient's attribute matches a specific implementation condition, and the unit chart to be displayed first displays the dosage of the specific medicine. In the implementation condition determination process, if it is determined that the patient's attributes match the specific implementation condition and approval is obtained from a health care professional, the administration of the specific medicine is You may add to a unit chart as contents.

(About execution condition judgment processing)
In the above embodiment, the execution condition determination process is executed before the process chart and the unit chart are displayed in the medical plan management process, but the execution timing may be changed. For example, when a medical worker requests confirmation of whether or not to change a process chart or a unit chart via the support terminal 40, based on the patient information stored in the patient information DB 21a at that time, The determination process may be activated.

(About approval)
In the above embodiment, only when there is approval from a medical worker, the medical practice and the order of execution are changed, but the process for requesting the approval of the medical worker is omitted, and the determination of the medical plan management unit 22a You may make it change a medical practice and an implementation order automatically based only on a result.

DESCRIPTION OF SYMBOLS 1 Integrated support center 2 Hospital 3, 4 Network 10 Creation server 11, 21 Storage part 11a Standard medical practice information DB
11b Hospital Information DB
11c Doctor Information DB
11d disease information DB
12, 22 Control unit 12a Medical plan information generation unit 13, 23 Network IF
20 Management server 21a Patient information DB
21b Medical plan information DB
21c Implementation condition information DB
22a Medical Plan Management Department 30 Order Server 40 Support Terminal

Claims (5)

A implementation plan information about the configured implementation plan and a execution sequence which may take exemplary action content and the plurality of implementation acts of the plurality of exemplary actions that may be performed on the exemplary object uniquely the execution subject Implementation plan information configured by associating the implementation target identification information to be identified, the contents of the plurality of implementation actions, the execution order of the plurality of implementation actions, and the execution conditions of the plurality of implementation actions, with each other Execution plan information storage means for storing;
The implementation target identification information, the type of implementation condition for determining the implementation action or the implementation order actually performed on the implementation target, and the attributes of the implementation target are configured to be associated with each other. Implementation condition information storage means for storing the implementation condition information,
An implementation plan management means for changing the implementation act or the implementation order included in the implementation plan information,
The execution plan management means includes:
If it is determined whether the implementation target attribute corresponding to the specific implementation target identification information is stored in the implementation condition information storage unit, and if it is determined that the implementation target attribute is stored, An execution target attribute and an execution condition type corresponding to the execution target attribute are acquired from the execution condition information storage unit, and the specific execution target identification information is obtained from the acquired execution target attribute and the execution condition type. Generate implementation conditions that meet the implementation targets identified
The execution condition information acquired from the execution condition information storage unit is acquired from the execution plan information storage unit, the execution plan information corresponding to the specific execution target identification information from the execution plan information included in the acquired execution plan information. Get implementation conditions that match the type,
In the acquired execution conditions, it is determined whether or not there is an execution condition that is not satisfied by the generated execution condition. If there is an execution condition that is not satisfied, the specific execution target identification information is The execution included in the execution plan information by deleting the execution action or the execution order corresponding to the unfulfilled execution condition from the execution actions or the execution order included in the corresponding execution plan information. Change the action or the order of execution,
Implementation plan support system. The execution plan management means includes:
By deleting the implementation action or the execution order corresponding to the unfulfilled implementation condition from the implementation action or the implementation order included in the implementation plan information corresponding to the specific implementation target identification information, After determining the content of the execution action or the change in the execution order included in the execution plan information, information for requesting approval for the determination result is output to the user via the output means, and approval for the determination result is performed. Only when it is received from the user via the input means, the implementation action or the implementation order included in the implementation plan information is changed.
The execution plan support system according to claim 1. The implementation target is a patient,
The implementation act is a medical practice,
The implementation plan is a medical plan;
The execution plan support system according to claim 1 or 2 . Computer
Implementation plan information related to an implementation plan that includes the contents of implementation activities of a plurality of implementation actions that can be performed on the implementation target and the implementation order that the plurality of implementation actions can take, and uniquely identifies the implementation target Implementation plan information configured by associating the implementation target identification information to be identified, the contents of the plurality of implementation actions, the execution order of the plurality of implementation actions, and the execution conditions of the plurality of implementation actions, with each other Execution plan information storage means for storing;
The implementation target identification information, the type of implementation condition for determining the implementation action or the implementation order actually performed on the implementation target, and the attributes of the implementation target are configured to be associated with each other. Implementation condition information storage means for storing the implementation condition information,
An implementation plan management means for changing the implementation act or the implementation order included in the implementation plan information;
Is a program for functioning as
The execution plan management means includes:
If it is determined whether the implementation target attribute corresponding to the specific implementation target identification information is stored in the implementation condition information storage unit, and if it is determined that the implementation target attribute is stored, An execution target attribute and an execution condition type corresponding to the execution target attribute are acquired from the execution condition information storage unit, and the specific execution target identification information is obtained from the acquired execution target attribute and the execution condition type. Generate implementation conditions that meet the implementation targets identified
The execution condition information acquired from the execution condition information storage unit is acquired from the execution plan information storage unit, the execution plan information corresponding to the specific execution target identification information from the execution plan information included in the acquired execution plan information. Get implementation conditions that match the type,
In the acquired execution conditions, it is determined whether or not there is an execution condition that is not satisfied by the generated execution condition. If there is an execution condition that is not satisfied, the specific execution target identification information is The execution included in the execution plan information by deleting the execution action or the execution order corresponding to the unfulfilled execution condition from the execution actions or the execution order included in the corresponding execution plan information. Change the action or the order of execution,
Implementation plan support program. The implementation target is a patient,
The implementation act is a medical practice,
The implementation plan is a medical plan;
The execution plan support program according to claim 4.

Images