JP5116423B2 - Implementation support device and implementation support program - Google Patents

Description

  The present invention provides an implementation support apparatus and implementation support for providing support information useful for the implementation of each implementation action to a practitioner who performs a plurality of implementation actions on a predetermined target in a standardized content and execution order. Regarding the program.

  Conventionally, a critical path showing a medical-related action in a two-dimensional structure is known. This critical path is useful in that it can systematically guarantee and improve medical quality and efficiency through standardization and visualization of medical planning and implementation. 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. According to this system, since medical processes are sequentially read out from the storage unit according to a predetermined standard and output, each doctor individually performs a medical action while referring to the output medical process. Compared with the case where the contents and execution order of medical practices are determined by independent judgment, the standardization of medical practices can be achieved, and the quality of medical processes can be maintained and improved. Further, according to this system, it is possible to flexibly cope with the individuality of the patient, so that the problem of the critical path can be solved.

  In particular, according to such a system, at the time when the contents and the execution order of each medical process are specified, it is possible to simultaneously specify the instruction contents corresponding to the specific state of the patient and the conditions for applying the instruction contents. In addition, it is possible to make an outlook for the execution schedule of each medical process and the reservation of resources (medical resources) used to execute each medical process.

International Publication No. 2006/057336 Pamphlet

  However, in the conventional system, conditions for applying these instruction contents, execution schedules, resource reservations, and the like are fixed when the contents and execution order of each medical process are first created. On the other hand, in an actual medical field, there are cases where fixed conditions, implementation schedules, and the like cannot be maintained due to changes in the implementation state of medical practices for patients. For example, even if the application condition of the instruction content for responding to a specific state of the patient is set in advance, the instruction based on the application condition may not be in time depending on the transition of the patient state. Alternatively, if the period required for completion of a specific medical process deviates significantly from the standard period that was assumed in advance, for the medical processes after the completed medical process, the implementation schedule and resource usage The schedule could change. Since such fluctuations could not be absorbed by the conventional fixed system, it was difficult to further improve the quality and accuracy of the process management of the medical process.

  The present invention has been made in view of the above, and in addition to changing the contents of various implementation actions and the execution order of the implementation actions according to the target state, various information regarding the implementation actions To provide an implementation support device and implementation support program that can optimize the implementation plan in addition to standardization of various implementations by adapting to the target conditions dynamically With the goal.

In order to solve the above-described problems and achieve the object, the present invention as set forth in claim 1 is characterized by implementation activity information for identifying the content of an implementation activity to be performed on a predetermined target in units of the implementation activity, as in practice information storage means for storing, as in the sequence information for identifying the execution sequence among each other of the plurality of exemplary actions content is identified by a plurality of the above-described action information, before Symbol predetermined target state, or Related information storage means for storing related information that can change according to the implementation state of the implementation act, the implementation activity information for specifying the content of the implementation activity that has been implemented in the past for the predetermined target, and the predetermined target Implementation history information storage means for storing implementation days information for specifying the implementation days of implementation actions performed in the past, and for specifying the state of the predetermined target or the implementation state of the implementation actions Condition Input means for accepting the input of the state, and when the input of the state information is accepted via the input means, the implementation may be implemented in the future by referring to the implementation action information storage means based on the state information The implementation information and the execution order of the implementation actions are specified, and related information in the case where the specified implementation actions are performed according to the specified execution order is determined by a predetermined method, and based on the determined related information Information update means for updating the related information stored in the related information storage means, and output means for outputting the related information updated by the information update means to a predetermined output destination, the information update means, The related information is determined based on the implementation action information and the implementation day information stored in the implementation history information storage means .

The present invention described in claim 2 is the present invention described in claim 1, wherein the implementation action information is information for specifying the content of a medical action to be performed on a patient by a medical action unit, The execution order information is information for specifying an execution order among a plurality of medical actions whose contents are specified by a plurality of the execution action information, and the state information specifies a state of the patient. Information or information for specifying an implementation state of the medical practice, and the related information is used when the medical practice implementation condition, the medical practice implementation schedule, or the medical practice is implemented. it is information for identifying the medical resources.

A third aspect of the present invention includes a standard schedule information storage unit that stores the standard schedule information including a standard number of days for performing the implementation action according to the first aspect of the present invention . The information updating unit obtains a standard number of days for performing an implementation action previously performed on the predetermined target from the standard schedule information storage unit, and is performed on the predetermined target in the past. In order to obtain the number of implementation days of the implementation act from the implementation history information storage means, calculate the difference between the acquired standard number of days and the obtained implementation date, and implement the specified implementation act The standard number of days is acquired from the standard schedule information storage unit, and the acquired standard number of days is updated based on the calculated difference.

According to a fourth aspect of the present invention, in the present invention according to any one of the first to third aspects, the update state notification information for notifying the state related to the update of the related information is associated with the related information. Update status notification information storage means for storing the information, the information update means acquires the update status notification information associated with the related information determined by the predetermined method from the update status notification information storage means, and the output means Outputs the acquired update state notification information to a predetermined output destination.

According to a fifth aspect of the present invention, in the present invention according to any one of the first to fourth aspects, the output means performs the implementation action on the related information updated by the information update means. Output to a predetermined resource management device for managing the reservation of the resources to be used.

The present invention described in claim 6 is a plurality of implementation action information for specifying the content of an implementation action to be performed on a predetermined target in units of the implementation action, and a plurality of contents specified by the plurality of implementation action information. Implementation order information for specifying the implementation order between the implementation activities of the implementation activities, storage means for storing the implementation information, and related information that can change depending on the state of the predetermined object or the implementation status of the implementation activities The related information storage means to store, the implementation action information for specifying the contents of the implementation actions performed in the past for the predetermined target, and the number of implementation days of the implementation actions executed in the past for the predetermined target Implementation history information storage means for storing the implementation days information for performing, input means for receiving input of state information for specifying the state of the predetermined target or the implementation state of the implementation action, and the related information An output means for outputting to a predetermined output destination, and when the input of the state information is received via the input means, the implementation action based on the state information Steps for specifying the implementation actions that can be implemented in the future by referring to the information storage means and the execution order of the implementation actions, and related information when the specified implementation actions are executed according to the specified execution order A predetermined method, a step of updating the related information stored in the related information storage means based on the determined related information, and the updated related information via the output means. Output to the output destination, and the implementation action information and the implementation days information stored in the implementation history information storage means And a step of determining the relevant information to the computer.

According to the present invention described in claims 1 and 6 , related information can be dynamically updated in conformity with a predetermined target state or an implementation state of an implementation action, and the contents of the implementation actions and the execution order are standardized. In addition to maintaining and managing quality, it is possible to optimize the contents of implementation activities and information related to implementation plans for implementation activities.
In addition, related information can be updated based on past implementation action information and implementation order information, and update processing reflecting implementation performance of implementation actions can be performed.
In particular, since the implementation schedule adjusted based on the past clinical history can be grasped, the implementation schedule that matches the individual clinical tendency of the patient can be grasped, and clinical process management according to the individual actual situation of the patient should be performed. Can do.

  According to the present invention described in claim 2, medical resources used when performing medical practice conditions, medical practice schedules, or medical practice, adapted to the patient's condition or medical practice status. In addition to maintaining and managing the quality of medical practice and the order of implementation by standardizing the content of medical practice and the order of implementation, information on the content of medical practice and the implementation plan of medical practice, etc. Can be optimized.

  According to the third aspect of the present invention, the related information can be updated based on the standard information, and the update process can be executed based on the standardized standard. Therefore, the update process itself can be standardized. And the quality of the update process itself can be maintained and managed.

According to the fourth aspect of the present invention, when the related information is updated, the update status notification information for notifying the update status of the related information is automatically output. It is possible to easily and surely grasp the updated state of information, and to alert the practitioner.

According to the fifth aspect of the present invention, the resource management in the resource management apparatus can be automatically updated by outputting the related information to the resource management apparatus.

  DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Exemplary embodiments of an implementation support device and an implementation 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. An implementation support device (hereinafter “this device”) and an implementation support program (hereinafter “this program”) according to the present embodiment support the implementation of an implementation activity for a predetermined target. It is the apparatus and program for assisting implementation of the said implementation act by presenting the various information for this.

  The apparatus and the program can be applied to a wide range of fields. Conceptually, the knowledge in the field (specifically, the contents of a plurality of implementation actions for a predetermined object and the mutual relationship between the plurality of implementation actions) It can be applied to all fields that can be visualized by structuring the execution order. Examples of application fields include “medical field”, “disaster prevention field”, and “education field”. Depending on the application field, the specific contents of the “predetermined object”, “practitioner”, and “practice” may differ. For example, in the medical field, predetermined object = patient, practitioner = physician, and implementation action = medical practice. Similarly, in the field of disaster prevention, a predetermined target = a disaster victim or a victim of a terrorist act or a disaster victim, an implementer = a rescuer, an implementation act = a relief act, and in an education field, a predetermined target = student, an implementer = a teacher, an implementation act = Educational activities are applicable. Hereinafter, the case where the present apparatus and the program are applied to the medical field will be described (the present apparatus is referred to as “medical practice support server” and the present program is referred to as “medical practice support program”). When the program is applied to other fields, the contents of “predetermined object”, “practitioner”, and “implementation action” may be read as contents corresponding to the other fields as described above.

  FIG. 1 is an explanatory diagram conceptually showing the overall configuration of the medical information system. As shown in FIG. 1, the medical information system is configured such that a medical practice support server 1, a related server group 10, and a plurality of support terminals 20 can communicate with each other via a network 30 such as a local LAN or the Internet. ing. Specific configurations of these parts will be described later. In this embodiment, an example is shown in which various medical practices performed within a specific medical institution are supported by the medical information system. However, medical practices of a plurality of medical institutions are integrated by the medical information system. The components of the medical information system may be distributed to a plurality of medical institutions.

  In this apparatus and this program, the “patient condition adaptive path system (PCAPS)” disclosed in whole or in part in the above-mentioned Patent Document 1. 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”. They are visualized linked to each other, and are specifically configured using two tools, a “clinical process chart” and a “unit sheet”.

  FIG. 2 shows a basic configuration model of these clinical process charts and unit sheets. A clinical process chart is a combination of “units (processes)”, which are units of medical practice (units set to an appropriate size for managing the quality of medical care) formed for each target state of a patient. It is a bird's-eye view of the configured clinical pathway, and is configured for each disease, and includes all clinical states assumed between the initial state and 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”, and “conditional instruction”. 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 items and contents of medical practices to be executed in the execution element corresponding to the unit sheet, and includes medical practices, care practices, and adjustments. 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 state that occurred during a medical practice in the unit and a condition parameter (“135 or more” in FIG. 3) that specifies a condition for executing the instruction content. It is configured to include.

  Information for specifying the “clinical process chart” and “unit sheet” configured in this way is stored in advance in the apparatus, and the apparatus and the program are units corresponding to the first unit in the clinical process chart. The contents of the sheet are presented to the doctor via the support terminal 20 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 20, this patient state is accepted by the present apparatus via the support terminal 20. Next, the apparatus and the program determine whether or not the patient state has reached the target state of the unit. When it is determined that the target state has been reached, the next unit of the first unit is identified based on the clinical process chart, and the content of the unit sheet corresponding to the next unit is determined via the support terminal 20. Present to the doctor. Thereafter, similarly, the process of presenting the content of the unit sheet corresponding to the unit according to the order defined in the clinical process chart, the process of accepting the input of the patient state by the doctor, and determining whether or not the target state has been reached This determination process is repeatedly performed, and the series of processes is completed when the last unit medical action in the clinical process chart is completed. According to the patient condition adaptive path constructed and executed in this way, clinical treatment charts and unit sheets can be presented to each doctor in standardized contents and order, thereby supporting medical care from the viewpoint of safety and quality assurance. .

  Part of the features of this embodiment is that the information contained in the clinical process charts and unit sheets configured as described above and the information derived based on the information are sent to the patient status and patient at that time. It is to update dynamically according to the content of the medical practice performed on the device (hereinafter, information that can be dynamically updated by the apparatus and the program is referred to as “related information”). Various information can be included as this related information. In the following example, “condition parameters” for specifying conditions in conditional instructions, “implementation schedules” for medical actions of each unit, and each unit A case where the “resource reservation” that is the reservation information of the resource used in the above is updated will be described.

[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 information system shown in FIG. 1 will be described, and then the processing content of the medical practice support program executed using the medical practice support server 1 will be described.

(Configuration-medical information system-medical practice support server)
The medical practice support server 1 in FIG. 1 corresponds to the implementation practice support apparatus and the computer in the scope of claims, and functionally conceptually includes a storage unit 2, a control unit 3, and a network interface (hereinafter “network IF”). 4 are connected to each other via a bus 5 so that they can communicate with each other.

The storage unit 2 is a storage unit that stores information and parameters necessary for various processes in the medical practice support server 1 in a nonvolatile manner, and is configured by, for example, an HD (Hard Disk). Specifically, the storage unit 2 is roughly divided into an implementation action information storage unit 2a, a standard information storage unit 2b, a history information storage unit 2c, and a related information storage unit 2d in terms of functions. The implementation action information storage unit 2a specifies a unit sheet (implementation action information) for specifying the content of a medical action to be performed on a patient in units of medical actions, and the execution order among a plurality of medical actions. For example, a process DB (Database) 2a ₁ is provided. The standard information storage unit 2b is a means for storing information for specifying the standard content of the related information. Specifically, the standard condition parameter DB 2b ₁ , standard execution schedule DB 2b ₂ , and standard resource reservation DB 2b ₃ are stored. Prepare. History information storage unit 2c is a means for storing history information of the unit sheet and process charts was performed on the patient, specifically, comprising the process history DB2C _1. The related information storage unit 2d is a means for storing related information that is updated according to the patient's condition or the medical practice implementation state. Specifically, the condition parameter DB2d ₁ , the implementation schedule DB2d ₂ , and the resource reservation DB2d ₃ is provided. The implementation action information storage unit 2a, the standard information storage unit 2b, the history information storage unit 2c, and the related information storage unit 2d are respectively an implementation activity information storage unit, a standard information storage unit, a history information storage unit in claims, Corresponds to related information storage means. The related information storage unit 2d also corresponds to update state notification information storage means in the claims. Hereinafter, a configuration example of each DB will be described in more detail. However, the following configuration example shows an example in which the minimum information according to the present embodiment is stored. Actually, any information other than the information described below can be stored in each DB.

The process DB 2a ₁ is a process information storage unit for storing standardized clinical process charts and information for specifying unit sheets (hereinafter referred to as “process information”). FIG. 4 is a specific example of a clinical process chart. This clinical process chart is an example in the case of performing radical prostatectomy, but clinical process charts corresponding to other various diseases are also stored in the process DB 2a ₁ in association with disease names. This clinical process chart includes execution elements and determination elements that constitute each of a plurality of units, and line segments that connect these elements to each other, and the execution order between the elements is determined by the line segments. Shown visually. 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”.

FIG. 5 is a configuration example of a part of the process information stored in the process DB 2a _1. Information for specifying the clinical process chart of FIG. 4 and the unit sheet corresponding to each unit of the clinical process chart It is a specific example of information for specifying the content. This information is the same as the information shown in FIG. 3, and “unit ID”, “medical practice”, “patient state”, “target state”, “unit transition logic”, and “conditional instruction” are mutually Configured in association. In particular, the medical practice includes information for identifying resources that can be used in the medical practice (here, “resource name” such as “operating room” and “OP0001” etc. for uniquely identifying each resource). "Resource ID").

The standard condition parameter DB 2b _{1 in} FIG. 1 is a standard condition parameter information storage unit for storing standardized conditional instructions and information for specifying the condition parameters (hereinafter, “standard condition parameter information”). FIG. 6 is a diagram illustrating a configuration example of standard condition parameter information. The standard condition parameter information includes a “unit ID” of a unit to which each conditional instruction is applied, a “condition parameter selection criterion” that is a criterion for selecting a conditional parameter for each conditional instruction, and a condition for each conditional instruction. The “patient state” to which the parameter is applied, the “condition parameter” that is a numerical value that is a specific criterion for each condition item, the “conditional instruction” that describes the contents of each conditional instruction, and the “guide information” It is configured in association with. Here, a plurality of condition parameters can be stored for one “conditional instruction”, and a plurality of condition parameter selection criteria for the plurality of condition parameters can also be stored. In the example of FIG. 6, as the determination logic of the unit ID “A-0”, when the patient's body temperature is “less than 37 ° C.”, the conditional instruction “ When the patient's body temperature is “37 ° C. or higher”, a conditional instruction “blood pressure lowering agent administration” is indicated when the patient ’s blood pressure becomes “130 or higher”. . The reason why the condition parameter is selected in this way is that the condition for performing a predetermined conditional instruction may vary depending on the patient condition or medical practice. For example, when the patient's body temperature is relatively low, the patient's body temperature is A blood pressure lowering agent is not necessary until it is relatively high, but if the patient's body temperature is relatively high, a blood pressure lowering agent is necessary even when the patient's body temperature is relatively low. This is because it is reflected in

The guide information is information for notifying the state related to the update of the related information, and corresponds to the update state notification information in the claims. In the example of FIG. 6, when the condition parameter is set to “135 or more”, the patient is in a relatively stable state (body temperature less than 37 ° C.), and there is no matter to alert the doctor in particular. Although the information is blank, when the condition parameter is set to “130 or higher”, the patient is in a relatively unstable state (body temperature of 37 ° C. or higher), so that the doctor is alerted. Guide information is set. The specific content of the guide information is arbitrary. For example, the fact that the condition parameter has been updated, the condition parameter corresponding to the unstable state has been set, the content of the expected disease, or a conditional instruction It is possible to make it a content for notifying special attention points and the like for implementation. In this example, the guide information is fixedly associated with the condition parameter. However, for the same condition parameter, one of the different guide information is selected based on the history of setting the condition parameter. One guide information may be selected dynamically. For example, a plurality of guide information and selection criterion information for selecting each guide information are stored in the standard condition parameter DB 2b ₁ in advance, and the selection criterion information is obtained based on the process history stored in the process history DB 2c _1. By determining, guide information may be selected. In this case, only when the update frequency of the condition parameter exceeds a predetermined reference frequency, guide information for noting the change of the conditional instruction may be displayed. In addition, the content of the guide information may be changed according to the degree of deviation of the condition parameter from the standard value. When the condition parameter is updated to the condition parameter within the predetermined range with respect to the standard value, only the fact that the condition parameter is updated is indicated. When the guide information to be notified is selected and updated to a condition parameter that deviates from a predetermined range with respect to the standard value, it is possible to select the guide information to notify that the patient state should be particularly noted.

The standard execution schedule DB 2b _{2 in} FIG. 1 is a standard execution schedule information storage unit for storing information for specifying a standardized execution schedule (hereinafter, “standard execution schedule information”). FIG. 7 is a diagram illustrating a configuration example of standard execution schedule information. This standard execution schedule information correlates the “unit ID” of each unit sheet and the “standard number of days” that is the standard number of days from the transition to each unit sheet to the transition to the next unit sheet. Configured. The example of FIG. 7 indicates that it normally takes “3” days from the transition to the unit sheet corresponding to the unit ID “A-0” to the transition to the next unit sheet.

The standard resource reservation DB 2b _{3 in} FIG. 1 is a standard resource reservation information storage unit for storing information for specifying a standardized resource reservation (hereinafter referred to as “standard resource reservation information”). FIG. 8 is a diagram illustrating a configuration example of standard standard resource reservation information. This standard resource reservation information starts using each resource based on the “unit ID” of each unit sheet, the “resource ID” of resources that can be used in each unit sheet, and the date of transition to each unit sheet. "Day" is related to each other. In the example of FIG. 8, the resource specified by the resource ID “OP0001” is used on the “1” day after the unit sheet corresponding to the unit ID “A-1” is transferred.

  The method and timing for generating the process information, standard condition parameter information, standard execution schedule information, and standard resource reservation information are arbitrary. For example, these pieces of information are determined by standardizing based on doctors' interviews and the like. Thus, each DB can be stored in advance. The standardization of each piece of information and process information is not necessarily rigid, and each medical institution or doctor can customize it to any content using the support terminal 20 so as to match the actual situation of each medical institution or patient. You may be able to do it. The specific description structure of the process information and the like is arbitrary, but the meaning and structure of each information can be described using tags, for example, by XML (Extensible Markup Language).

The process history DB 2c _{1 in} FIG. 1 is a process history information storage unit for storing information for specifying a history when process information is actually applied to each patient (hereinafter, “process history information”). FIG. 9 shows a configuration example of the process history information. This process history information is roughly the same as the process information shown in FIG. 5, the “patient ID” of the patient to which each unit sheet is actually applied, and the year when the unit sheet actually moved to the unit corresponding to each unit sheet. It is configured by adding the date (hereinafter referred to as “the date of transition”). The process history information is acquired from the process DB 2a ₁ at the initial stage of medical care for each patient, stored as an initial value in the process history DB 2c ₁ , and then updated as the clinical course of each patient elapses.

The condition parameter DB 2d _{1 in} FIG. 1 is information for specifying a condition parameter of a conditional instruction of each unit for each patient and for storing dynamically updated information (hereinafter referred to as “condition parameter information”). Condition parameter information storage means. A configuration example of the condition parameter information is shown in FIG. This condition parameter information is provided for each patient, and is configured by associating “patient ID”, “unit ID”, and “condition parameter” with each other.

The execution schedule DB 2d _{2 in} FIG. 1 is an execution schedule information storage unit for storing information for specifying the execution schedule of each unit for each patient (hereinafter, “execution schedule information”). A configuration example of the implementation schedule information is shown in FIG. This execution schedule information is provided for each patient, and correlates the “patient ID”, “unit ID”, and “transition date” indicating the date of planned migration to each unit sheet. Configured.

The resource reservation DB 2d _{3 in} FIG. 1 is resource reservation information storage means for storing information (hereinafter, “resource reservation information”) for specifying the reservation contents of resources used in each unit for each patient. A configuration example of this resource reservation information is shown in FIG. This resource reservation information is provided for each patient, and includes “patient ID”, “unit ID”, “resource ID”, and “reservation date” indicating the date of reservation of each resource. It is configured in association with.

The condition parameter information, the execution schedule information, and the resource reservation information are acquired from the process DB 2a ₁ at the initial point of each patient's medical care, and are stored in the standard condition parameter DB 2b ₁ , the standard execution schedule DB 2b ₂ , and the standard resource reservation DB 2b ₃ . After being stored as initial values, they are dynamically updated as the clinical course of each patient passes.

In FIG. 1, the control unit 3 is a control unit that controls each unit of the medical practice support server 1, and includes a process management unit 3 a and an information update unit 3 b in terms of functional concept. The process management unit 3a is a means for managing clinical processes using clinical process charts and unit sheets. The information update unit 3b updates the related information in accordance with the patient condition, and corresponds to the information update means in the claims. The information update unit 3b includes a condition parameter update unit 3b ₁ , an execution schedule update unit 3b ₂ , and a resource reservation update unit 3b ₃ in terms of functional concept. The condition parameter update unit 3b ₁ is a condition parameter update unit that dynamically updates the condition parameter according to the patient state. The execution schedule update unit 3b ₂ is an execution schedule update unit that dynamically updates the execution schedule information according to the patient state. The resource reservation update unit 3b ₃ is resource reservation update means for dynamically updating the resource reservation according to the patient state.

  Specifically, the control unit 3 includes a CPU (Central Processing Unit), various programs interpreted and executed on the CPU (control programs such as an OS, programs that define various processing procedures, and the like), and And a cache memory for storing required programs and required data. In particular, the control unit 3 includes a medical practice support program as this program. This medical practice support program is stored in an arbitrary storage medium including, for example, a CD-ROM and a DVD, then installed in the medical practice support server 1, stored in the storage unit 2 in a nonvolatile manner, and interpreted by the CPU. Thus, the substantial function of the control unit 3 is configured.

  The network IF 4 is a communication means for the medical practice support server 1 to communicate via the network 30, and is configured as a network board, for example. Since various information is input / output to / from the medical practice support server 1 via the network IF 4, the network IF 4 corresponds to input means and output means in the claims. However, in addition to the network IF 4, the medical practice support server 1 may be provided with a keyboard and a pointing device for receiving input of various information, or a monitor and a speaker for outputting various information. The keyboard and pointing device correspond to input means in the claims, and the monitor and speaker correspond to output means in the claims.

(Configuration-medical information system-related servers)
The related server group 10 includes a plurality of servers for processing various types of information in medical institutions. For example, the related server group 10 includes a medical accounting server 11 and an order server 12. The medical accounting server 11 is an apparatus that performs information processing for inputting or outputting information related to medical accounting. The order server 12 is a device that performs various resource ordering, inventory management, or reservation management, and corresponds to the resource management device in the claims. The specific configuration of each server included in the related server group 10 is arbitrary, and can be configured in the same manner as a known server device as long as it has a communication function with the medical practice support server 1. Omitted. In addition, the kind of each server contained in the related server group 10 is an illustration, and other arbitrary servers can be included.

(Configuration-medical information system-support terminal)
Each support terminal 20 is a terminal device for medical personnel including doctors to input and output to each server of the medical practice support server 1 and the related server group 10, and in particular, an input function for receiving an input of a patient state And an output function for outputting a clinical process chart and a unit sheet. Since the support terminal 20 can be configured in the same manner as a known personal computer as long as it has an input / output function for various information and a communication function with the medical practice support server 1, detailed description thereof is omitted.

(processing)
Next, a medical practice support process (hereinafter, this process) performed by executing a medical practice support program on the medical practice support server 1 will be described. In the following description of the present process, the process that does not specify the control subject is assumed to be executed by the control unit 3, and when the information acquisition source or acquisition path is not specified, the known timing and the known process Information is acquired from each server of the related server group 10 by a method, or a medical worker manually inputs information via the support terminal 20.

(Processing-Overall processing)
First, the entire medical practice support process will be described. FIG. 13 is a flowchart of the medical practice support process. First, when the doctor inputs the patient ID and the disease name of the patient via the support terminal 20 and instructs the start of the medical process, these pieces of information are transmitted from the support terminal 20 to the medical practice support server 1. When receiving the input of information from the support terminal 20 (step SB-1, Yes), the process management unit 3a of the medical practice support server 1 acquires process information corresponding to the patient's disease name from the process DB 2a _1. Then, the process history information is generated by adding the patient ID to the acquired process information, and this process history information is stored in the process history DB 2c ₁ (step SB-2). Thus, the process chart and unit sheet of the process history information stored in the process history DB 2c ₁ can be called by the doctor via the support terminal 20 at an arbitrary timing, and can be viewed via the monitor of the support terminal 20. Part of the information necessary at this time is acquired from the standard condition parameter DB 2b ₁ , the standard execution schedule DB 2b ₂ , or the standard resource reservation DB 2b ₃ based on the patient ID, unit ID, or resource ID of the process history information. . 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. The patient ID (hereinafter “the patient ID”) and the unit ID (hereinafter “the unit ID”) to be processed are input by the doctor through the process chart or the unit sheet, or When the doctor inputs the patient ID and the unit ID to the support terminal 20, it is specified in the medical practice support server 1, and the description of the process related to this specification is omitted.

(Processing-Overall processing-Initial value of related information-Condition parameters)
Next, the information update unit 3b sets an initial value of related information (step SB-3). Specifically, the initial value of the condition parameter is set by the condition parameter update unit 3b ₁ as follows. That is, the condition parameter update unit 3b ₁ acquires each unit ID corresponding to the patient ID from the process history information stored in the process history DB 2c _1, and sets the “condition parameter” corresponding to each unit ID as the standard condition parameter. obtained from DB2B _1, the "condition parameter" generates the condition parameter information by associating the patient ID and unit ID, and stores the condition parameter information to the condition parameter DB2d _1. At this time, when a plurality of condition parameters are set for one instruction content, the condition parameter update unit 3b ₁ selects any one of the condition parameters by a predetermined method (for example, stored at the head). select condition parameters as the default), and stores the condition parameters the chosen condition parameters DB2d _1. The initial value of the condition parameter information set in this way is called from the condition parameter DB 2d ₁ and stored in the unit sheet as shown in FIG. 3, for example, every time the doctor views the unit history of the process history information on the support terminal 20. Is output. Therefore, the doctor can easily grasp the condition parameters that serve as a reference for determining the conditional instruction.

(Processing-Overall processing-Initial value of related information-Implementation schedule)
The initial value of the execution schedule is set by the execution schedule update unit 3b ₂ as follows. That is, the execution schedule update unit 3b ₂ acquires each unit ID corresponding to the patient ID from the process history information stored in the process history DB 2c _1, and sets the “standard days” corresponding to these unit IDs as the standard execution schedule. to get from DB2b _2. Further, the implementation schedule update unit 3b ₂ acquires the current date (hereinafter “current date”) by a known method (for example, acquires from the internal clock of the medical practice support server 1). Then, the implementation schedule update unit 3b ₂ sets the acquired current date as the transition date of the first unit sheet in the process chart. In addition, the execution schedule update unit 3b ₂ sets the standard date of all unit sheets to be executed before each unit sheet with respect to the current date acquired for the transition date of each unit sheet thereafter. It is calculated by adding.

For example, the current date is “September 1, 2007”, the standard number of days of the first unit sheet of the process chart is “3 days”, and the standard number of days of the second unit sheet of the process chart is “4 days”. The transition date of the first unit seat is set to “September 1, 2007” and the transition date of the second unit seat is calculated as “September 4, 2007”. The transition date of the unit seat is calculated as “September 8, 2007”. If there is a branch in the process chart, the date of transition is calculated for each branch destination unit sheet. Next, the execution schedule update unit 3b ₂ generates execution schedule information by associating the migration date calculated in this way with the patient ID and each unit ID, and stores the generated execution schedule information in the execution schedule DB 2d ₂ . Store. The initial value of the execution schedule information set in this way is called from the execution schedule DB 2d ₂ and output simultaneously to the process chart every time the doctor views the process chart of the process history information on the support terminal 20, for example. Therefore, the doctor can easily grasp the implementation schedule of each medical practice in the process, and can easily manage the clinical process from a temporal viewpoint.

(Processing-Overall processing-Initial value of related information-Resource reservation)
The initial value of the resource reservation is set by the resource reservation updating unit 3b ₃ as follows. That is, the resource reservation updating unit 3b ₃ acquires each unit ID corresponding to the patient ID from the process history information stored in the process history DB 2c ₁ . Further, the resource reservation updating unit 3b ₃ obtains the “resource ID” and “use date” corresponding to each unit ID from the standard resource reservation DB 2b ₃ and stores the initial value of the execution schedule in the execution schedule DB 2d ₂ first. Get the “Migration Date” of each stored unit sheet. Then, the resource reservation update unit 3b ₃ calculates the reservation date of each resource in each unit sheet by adding the use date of each resource to the migration date of each acquired unit sheet. . For example, when the transition date of a unit sheet is “September 4, 2007” and the use date of the resource included in the unit sheet is “2”, the reservation date of the resource is “ It is calculated as "September 6, 2007".

Next, the resource reservation updating unit 3b ₃ generates resource reservation information by associating the reservation date calculated in this way with the patient ID, the unit ID, and the resource ID acquired in advance, and generates the generated resource reservation information. The resource reservation information is stored in the resource reservation DB 2d ₃ . The initial value of the resource reservation information set in this way is transmitted from the medical practice support server 1 to the order server 12 of the related server group 10, and the order server 12 performs resource ordering processing and reservation processing. Therefore, various resources required in the future can be ordered or reserved based on a standardized schedule, and resource management can be easily performed.

(Processing-Overall processing)
Next, in FIG. 13, every time the patient condition changes, the doctor inputs the latest patient condition (for example, body temperature, blood pressure, respiratory rate, numerical values indicating various test results, etc.) via the support terminal 20. This patient state is transmitted from the support terminal 20 to the medical practice support server 1. When the input of the patient state is accepted in the medical practice support server 1 (step SB-4, Yes), the related information is updated by the information update unit 3b performing an information update process for updating the related information. (Step SB-5). The specific contents of this update process will be described later.

Next, the process management unit 3a compares the input patient state with the target state of the unit sheet stored in the process history DB 2c ₁ to determine whether or not the patient state has reached the target state (step) SB-6). If it is determined that the patient's state has reached the target state (step SB-6, Yes), the process management unit 3a displays the content of the unit sheet of the next unit specified by the process chart in the process history DB 2c. ₁ and transmitted to the support terminal 20 (step SB-7). By browsing the content of the unit sheet via the support terminal 20, the doctor can browse the content of the unit sheet that matches the patient state and can confirm the implementation content of the medical practice. When the unit is transferred in this way, the process management unit 3a obtains the current date by a known method, and uses the current date as the transfer date of the unit sheet of the transfer destination unit. Store in DB2c ₁ (step SB-8).

  On the other hand, when it is determined in step SB-6 that the patient state has not reached the target state (step SB-6, No), the process management unit 3a proceeds to the next unit sheet without moving to the next unit sheet. Wait until input is accepted. Thereafter, the medical practice is performed by repeating steps SB-4 to SB-8 in the same manner. When the patient state deviates greatly from the target state, a warning or necessary treatment content may be output to the support terminal 20. In other words, in addition to the target state, a transition state indicating a criterion for judging a dangerous deviation from the target state, and a warning and action content to be output when the transition state is entered are stored in advance as process information. In addition, when it is determined in step SB-6 that the patient state has become the transition state, these warnings and treatment details may be performed.

(Processing-Information update process)
Next, specific contents of the information update process in step SB-5 will be described. FIG. 14 is a flowchart of the information update process. In this process, a condition parameter update process (step SC-1) for updating the condition parameter, an execution schedule update process (step SC-2) for updating the execution schedule, and a resource for updating the resource reservation The reservation update process (step SC-3) is sequentially performed. Hereinafter, each of these update processes will be described sequentially.

(Processing-Information update process-Condition parameter update process)
First, the condition parameter update process will be described. FIG. 15 is a flowchart of the condition parameter update process. The condition parameter update unit 3b ₁ specifies a condition parameter selection criterion that matches the patient state accepted in step SB-4 of FIG. 13 from the standard condition parameter information corresponding to the patient ID in the standard condition parameter DB 2b ₁ . Then, the condition parameter corresponding to the specified condition parameter selection criterion and the guide information corresponding to the condition parameter are acquired (step SD-1). Then, the condition parameter update unit 3b ₁ updates the condition parameter information by storing the acquired condition parameter in the condition parameter DB 2d ₁ in association with the patient ID and the unit ID (step SD-2). Next, the condition parameter update unit 3b ₁ transmits the condition parameter and guide information acquired in step SD-1 to the support terminal 20 (step SD-3). As a result, the condition parameter of the conditional instruction on the unit sheet viewed on the support terminal 20 is updated, so that the doctor matches the patient condition with the conditional instruction based on the new condition parameter corresponding to the patient condition. It can be determined whether or not. For example, in the unit sheet of FIG. 3, it is displayed that the instruction content “blood pressure lowering agent administration” is performed with the initial value of the condition parameter being “blood pressure =“ 135 or more ”, but the patient state input by the doctor is the body temperature. In the case of 37 ° C. or higher, the condition parameter “130 or higher” is acquired in the example of FIG. 6, so the condition parameter is “blood pressure =“ 130 or higher ”and the instruction content“ blood pressure lowering agent ”as shown in the display screen example of FIG. The display automatically switches to “dosing”. Further, since the guide information is displayed in the vicinity of the updated condition parameter, various alerts accompanying the update of the condition parameter can be given to the doctor. In the example of FIG. 18, the guide information is displayed inside the unit sheet. However, the guide information may be displayed on a navigation screen that is different from the unit sheet.

  In addition to the display of the guide information, a predetermined display (for example, a condition for alerting that the condition parameter has been updated) is displayed in the display section of the conditional instruction of the unit sheet viewed on the support terminal 20. The display field of the attached instruction may be blinked, or a predetermined mark for alerting may be blinked. Specifically, when the process information is described in XML, it is executed by adding a predetermined display control tag to the process information or outputting a predetermined control code to the support terminal 20. This completes the condition parameter update process. According to this process, the doctor can reliably recognize that the condition parameter has been updated, and can accurately determine whether or not the patient state matches the conditional instruction based on the new condition parameter.

(Processing-Information update process-Implementation schedule update process)
Next, the implementation schedule update process will be described. FIG. 16 is a flowchart of the execution schedule update process. First, the execution schedule update unit 3b ₂ acquires the standard days corresponding to the patient ID and the unit ID from the standard execution schedule DB 2b ₂ for the standard days of each unit sheet after the current unit sheet (step SE). -1) The current date is acquired by a known method (step SE-2). Next, the execution schedule update unit 3b ₂ sets all the execution dates of the execution schedule of each unit sheet after the current unit sheet to be executed before each unit sheet with respect to the acquired current date. It is calculated by adding the standard days of the unit sheet (step SE-3). As a result, for example, if the date on which the current unit sheet is executed (that is, the current date) is different from the transition date set as the initial value earlier, the execution schedule with the difference corrected will be Will be calculated.

Furthermore, the implementation schedule update unit 3b ₂ adjusts the transition date calculated in this way based on the clinical course of the patient so far. Specifically, the execution schedule update unit 3b ₂ refers to the process history DB 2c ₁ and calculates the number of days actually required until the patient has finished each unit sheet so far (hereinafter referred to as “required days”). (Step SE-4). This calculation can be obtained as the difference between the date of transition to each unit sheet that has been completed for the patient and the date of transition in the next order of each unit sheet. And the execution schedule update part 3b ₂ calculates | requires the difference of the calculated required number of days and the standard days of each unit sheet acquired in step SE-1 for every unit sheet, and calculates the average value of all these differences ( Step SE-5). For example, when the required number of days for the first unit sheet in the process chart is “5 days” and the standard number of days for the unit sheet is “3 days”, the difference between the required number of days and the standard number of days is “+2 days”. If the required number of days for the next unit seat is “8 days” and the standard number of days for the unit seat is “4 days”, the difference between the required number of days and the standard number of days is “+4 days”. The average value of all differences is calculated as 3 days (= (2 days + 4 days) / 2).

Next, the execution schedule update unit 3b ₂ obtains the adjusted transition date by adding the calculated average value to the transition date calculated in the previous step SE-3 (step SE). -6). Thereafter, the execution schedule update unit 3b ₂ updates the execution schedule information by storing the transition date adjusted in this way in the execution schedule DB 2d ₂ in association with the patient ID (step SE-7). The transition date updated in this way is called from the implementation schedule DB 2d ₂ and transmitted to the support terminal 20 every time the doctor views the process chart of the process history information on the support terminal 20, for example, and is simultaneously displayed on the process chart. Is output. This completes the implementation schedule update process. According to this process, the doctor can easily grasp the latest execution schedule of each medical practice adapted to the patient condition, and can perform clinical process management more accurately. In particular, since the implementation schedule adjusted based on the past clinical history can be grasped, the implementation schedule that matches the individual clinical tendency of the patient can be grasped, and clinical process management according to the individual actual situation of the patient should be performed. Can do.

(Processing-Information update process-Resource reservation update process)
Finally, resource reservation update processing will be described. FIG. 17 is a flowchart of the resource reservation update process. Resource reservation updating unit 3b ₃ First, a use date corresponding to the patient ID and the unit ID, the resource ID and use date of each resource in units sheet after the current unit sheet from the standard resource reservation DB2B ₃ Obtain (step SF-1). Further, the resource reservation updating unit 3b ₃ acquires the migration date of each unit sheet after the current unit sheet from the execution schedule DB 2d ₂ updated in the above-described execution schedule update process (step SF-2). Then, the reservation date of each resource in each unit seat after the current unit seat is calculated by adding the start date of use of each resource to the transition date of each acquired unit seat ( Step SF-3). Next, the resource reservation update unit 3b ₃ updates the resource reservation information by storing the reservation date calculated in this way in the resource reservation DB 2d ₃ in association with the patient ID, the unit ID, and the resource ID (step S3). SF-4).

  The resource reservation information updated in this way is transmitted from the medical practice support server 1 to the order server 12 of the related server group 10. The order system corrects the resource reservation made based on the initial value of the resource reservation information based on the transmitted new resource reservation information as necessary, and the order server 12 Reservation update processing is performed. This completes the resource reservation update process. According to this process, reservations of various resources that will be required in the future can be updated to contents that match the patient state, and resource management that matches the patient state can be easily performed. In particular, since the new resource reservation information is updated based on the execution schedule adjusted based on the past clinical history in the execution schedule update process, the resource use timing that matches the individual clinical trend of the patient is adjusted. It is possible to grasp and manage resources according to the individual circumstances of the patient.

(Effect of embodiment)
As described above, according to the present embodiment, a doctor can call a process chart or a unit sheet at an arbitrary timing via the support terminal 20 and can view the process chart or unit sheet via the monitor of the support terminal 20. The medical practice corresponding to the above and the implementation procedure can be confirmed, and the medical practice can be performed with the standardized contents and procedure.
In addition, since the condition parameter of the conditional instruction in the unit sheet viewed on the support terminal 20 is updated, the doctor matches the patient condition with the conditional instruction on the basis of the new condition parameter corresponding to the patient condition. It can be determined whether or not. In particular, the doctor can reliably recognize that the condition parameter has been updated, and can accurately determine whether or not the patient condition matches the conditional instruction based on the new condition parameter.
Furthermore, the doctor can easily grasp the implementation schedule of each medical practice in the process, and can easily manage the clinical process from a temporal viewpoint. In particular, since the implementation schedule adjusted based on the past clinical history can be grasped, the implementation schedule that matches the individual clinical tendency of the patient can be grasped, and clinical process management according to the individual actual situation of the patient should be performed. Can do.
Furthermore, reservations of various resources that will be required in the future can be updated to contents that match the patient condition, and resource management that matches the patient condition can be easily performed. In particular, since the new resource reservation information is updated based on the execution schedule adjusted based on the past clinical history in the execution schedule update process, the resource use timing that matches the individual clinical trend of the patient is adjusted. It is possible to grasp and manage resources according to the individual circumstances of the patient.

[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 each of the above embodiments may be performed manually, and conversely, all or any of the control described as being performed manually is performed. A part may be automated based on a known technique or the idea described above. 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, by providing the support terminal 20 with all or part of the functions of the medical practice support server 1, the support terminal 20 can execute a patient state adaptive path system alone without using a network configuration, Dynamic updating may be performed.

Alternatively, some functions of the medical practice support server 1 may be distributed to other servers. Also, each DB of the medical practice support server 1 can be separated or integrated, and the contents of the standard condition parameter DB 2b ₁ , standard execution schedule DB 2b ₂ and standard resource reservation DB 2b ₃ are used as the contents of each unit sheet of the process DB 2a _1. Alternatively, the contents of the condition parameter DB 2d ₁ , the execution schedule DB 2d ₂ , and the resource reservation DB 2d ₃ may be stored as the contents of each unit sheet of the process history DB 2c ₁ .

(Regarding the update timing of related information)
In the above embodiment, the related information is updated every time an input of the patient state is accepted. However, all or a part of the related information may be updated at other arbitrary timings. The resource reservation may be updated only when the unit sheet shifts to the next unit sheet.

(Regarding update criteria for related information)
In the above-described embodiment, the condition parameter is updated based on the patient state of each unit. However, the condition parameter may be updated based on the past patient state history. For example, in a unit that has been performed on a patient in the past, a difference between a predetermined reference state change, a patient state change with respect to a standard number of days, and a required number of days may be obtained, and a condition parameter may be selected based on this difference.

  The present invention can be applied to a standardized system for implementation activities in various fields including the medical field. Information relating to the implementation activities is dynamically changed according to the state of the target, so that the plan management of the implementation activities, etc. Useful for optimizing

It is explanatory drawing which shows notionally the whole structure of the medical information system which concerns on embodiment of this invention. It is a figure which shows the basic composition model of a clinical process chart and a unit sheet. 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 clinical process chart. It is a figure which shows the structural example of a part of process information stored in process DB. It is a figure which shows the structural example of standard condition parameter information. It is a figure which shows the structural example of standard implementation schedule information. It is a figure which shows the structural example of standard standard resource reservation information. It is a figure which shows the structural example of process history information. It is a figure which shows the structural example of condition parameter information. It is a figure which shows the structural example of implementation schedule information. It is a figure which shows the structural example of resource reservation information. It is a flowchart of a medical practice support process. It is a flowchart of an information update process. It is a flowchart of a condition parameter update process. It is a flowchart of an implementation schedule update process. It is a flowchart of a resource reservation update process. It is a figure which shows the example of a display screen of the unit sheet | seat after condition parameter update.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Medical practice assistance server 2 Memory | storage part 2a Implementation action information storage part 2a ₁ process DB
2b Standard information storage unit 2b ₁ standard condition parameter DB
2b ₂ standard implementation schedule DB
2b ₃ standard resource reservation DB
2c history information storage unit 2c ₁ process history DB
2d related information storage unit 2d ₁ condition parameter DB
2d ₂ schedule DB
2d ₃ resource reservation DB
DESCRIPTION OF SYMBOLS 3 Control part 3a Process management part 3b Information update part 3b ₁ Condition parameter update part 3b ₂ Implementation schedule update part 3b ₃ Resource reservation update part 4 Network IF
5 Bus 10 Related Server Group 11 Medical Accounting Server 12 Order Server 20 Support Terminal 30 Network

Claims (6)

The execution order between the implementation action information for specifying the content of the implementation action to be performed for the predetermined target in units of the implementation action and the plurality of implementation actions whose contents are specified by the plurality of implementation action information. Implementation action information storage means for storing implementation order information for specifying;
Related information storage means for storing related information that can change according to the state of the predetermined object or the implementation state of the implementation action;
The implementation action information for specifying the contents of the implementation actions that have been performed in the past for the predetermined target; the implementation days information for specifying the number of implementation days of the implementation actions that have been performed in the past for the predetermined object; Implementation history information storage means for storing
Input means for receiving input of state information for specifying the state of the predetermined target or the state of implementation of the implementation act;
When the input of the state information is received via the input means, the implementation action that can be implemented in the future by referring to the implementation action information storage means based on the status information and the implementation of the implementation action The related information in the case where the order is specified and the specified implementation action is performed according to the specified execution order is determined by a predetermined method, and stored in the related information storage means based on the determined related information Information updating means for updating related information;
Output means for outputting related information updated by the information update means to a predetermined output destination ,
The information updating means determines the related information based on the implementation action information and the implementation day information stored in the implementation history information storage means;
Exemplary action assistance device according to claim. The implementation action information is information for specifying the content of a medical practice to be performed on a patient by medical practice unit,
The implementation order information is information for specifying an implementation order among a plurality of medical practices whose contents are specified by a plurality of implementation practices information,
The state information is information for specifying the state of the patient or information for specifying an implementation state of the medical practice,
The related information is information for specifying an implementation condition of the medical practice, an implementation schedule of the medical practice, or a medical resource used when the medical practice is implemented,
The implementation act support apparatus according to claim 1, wherein: Standard schedule information storage means for storing standard schedule information including a standard number of days for carrying out the implementation action,
The information updating unit obtains a standard number of days for performing an implementation action previously performed on the predetermined target from the standard schedule information storage unit, and is performed on the predetermined target in the past. In order to obtain the number of implementation days of the implementation act from the implementation history information storage means, calculate the difference between the acquired standard number of days and the obtained implementation date, and implement the specified implementation act Obtaining the standard number of days from the standard schedule information storage means, and updating the obtained standard number of days based on the calculated difference,
The implementation support apparatus according to claim 1 or 2, characterized by the above. Update state notification information storage means for storing update state notification information for reporting a state related to the update of the related information in association with the related information,
The information update unit acquires the update state notification information accompanying the related information determined by the predetermined method from the update state notification information storage unit,
The output means outputs the acquired update state notification information to a predetermined output destination;
The implementation act support apparatus according to claim 1, wherein The output means outputs the related information updated by the information update means to a predetermined resource management device for managing reservations of resources used to implement the implementation action;
The implementation support device according to any one of claims 1 to 4, wherein: The execution order between the implementation action information for specifying the content of the implementation action to be performed for the predetermined target in units of the implementation action and the plurality of implementation actions whose contents are specified by the plurality of implementation action information. Implementation action information storage means for storing implementation order information for specifying;
Related information storage means for storing related information that can change according to the state of the predetermined object or the implementation state of the implementation action;
The implementation action information for specifying the contents of the implementation actions performed in the past for the predetermined target; the implementation days information for specifying the implementation days of the implementation actions executed in the past for the predetermined target; Implementation history information storage means for storing
Input means for receiving input of state information for specifying the state of the predetermined target or the state of implementation of the implementation act;
Output means for outputting the related information to a predetermined output destination;
A program to be executed by a computer equipped with
When the input of the state information is received via the input means, the implementation action that can be implemented in the future by referring to the implementation action information storage means based on the status information and the implementation of the implementation action Identifying the order, and
Determining related information in a predetermined method in the case where the specified implementation action is performed according to the specified execution order;
Updating the related information stored in the related information storage means based on the determined related information;
Outputting the updated related information to the predetermined output destination via the output means;
Determining the related information based on the implementation action information and the implementation days information stored in the implementation history information storage means;
An implementation support program for causing the computer to execute.

Images