WO2012098613A1 - 救急医療管制支援システム及びサーバ並びに携帯端末 - Google Patents

救急医療管制支援システム及びサーバ並びに携帯端末 Download PDF

Info

Publication number
WO2012098613A1
WO2012098613A1 PCT/JP2011/006758 JP2011006758W WO2012098613A1 WO 2012098613 A1 WO2012098613 A1 WO 2012098613A1 JP 2011006758 W JP2011006758 W JP 2011006758W WO 2012098613 A1 WO2012098613 A1 WO 2012098613A1
Authority
WO
WIPO (PCT)
Prior art keywords
medical
list
hospital
server
unit
Prior art date
Application number
PCT/JP2011/006758
Other languages
English (en)
French (fr)
Inventor
則明 青木
祥子 大田
Original Assignee
Aoki Noriaki
Oota Sachiko
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aoki Noriaki, Oota Sachiko filed Critical Aoki Noriaki
Priority to US13/980,877 priority Critical patent/US20140025394A1/en
Priority to JP2012553478A priority patent/JP6052875B2/ja
Publication of WO2012098613A1 publication Critical patent/WO2012098613A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G06Q10/063114—Status monitoring or status determination for a person or group
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Definitions

  • the present invention relates to an emergency medical control support system, a server, and a portable terminal.
  • the diseases that can be treated differ depending on the “specialty of the on-duty doctor”. For example, even in the same surgery, neurosurgeons cannot perform abdominal surgery, and abdominal surgeons cannot perform heart surgery. Therefore, in emergency medicine matching, it is important to transport “patients requiring treatment” to “hospitals that can be treated”. However, there is still a “latest transport (transport to the nearest medical institution)” in the emergency services. In other words, the ambulance team has no scale other than the most recent transport. At the same time, the ambulance team doesn't know why they don't do "the most recent transport”. There is no clear rule that "If you have 10 illnesses, but you have a disease A, you should transport it to your medical institution.”
  • the Fire Service Act which was revised last year, requires each prefecture to formulate transport standards according to severity and urgency and to create a list of transported medical institutions.
  • This list of delivery destination medical institutions should not be determined by the “candidate” of each medical institution, but should originally be based on the “objective evaluation” of each medical institution. To that end, each medical institution needs to calculate a “medical quality index” based on the same criteria and make an objective evaluation.
  • the medical institution displays the availability of beds and resources for each department or specialty by “ ⁇ ”, “ ⁇ ”, etc., and the emergency team determines the transport destination based on the signature.
  • the current demanding system is “a place away from the emergency room and the input is troublesome”, “actually, in order to judge the acceptance comprehensively based on the situation at that time and the condition of the patient, It is rarely used due to the fact that “can't be made x”, “there is a phone call even if it is x in the last transport”.
  • the number of inquiries to medical institutions marked with ⁇ and medical institutions marked with ⁇ was almost the same in the demand system.
  • more than half of the number of patients that occurred on a single day were rejected in response to inquiries, despite the fact that there were many medical institutions with ⁇ on the demand system.
  • each fire department, headquarters, and union currently manages data separately, but in order to properly grasp the emergency medical situation in the region, it is necessary to integrate these data. It is necessary to widen the area at the information level.
  • the emergency medical server always knows the reception status of the emergency transport destination hospital before the patient occurs, and searches for the optimal medical institution when the emergency medical application is made from the ambulance.
  • An emergency medical system is disclosed.
  • the present invention can make a convincing decision by the emergency team and the medical institution to make a decision based on the “same information”, and can provide all the emergency medical information at all prefecture levels. As a result, it is possible to make optimal decision-making according to the situation.As a result, the transportation time and “time from onset to treatment start” are shortened, the prognosis of the patient is improved, the transportation standard and An object of the present invention is to provide an emergency medical control support system, a server, and a portable terminal that can periodically evaluate and improve the validity and reliability of a hospital list.
  • a server that can communicate with a mobile terminal via a network after predetermined authentication, the main control unit that performs overall control, Display control unit that generates screen data to control the screen display at the terminal, dispatch from the terminal, arrival at the site, departure from the site, observation findings at the site, observation findings during transportation, arrival at the hospital, diagnosis / treatment at the hospital
  • a time stamp acquisition unit that detects an event including an outcome and acquires a time stamp, an information registration unit that accepts information registration, a list creation unit that creates a list indicating the hospital activity status based on the registered information, and
  • a severity determination unit that determines the degree of urgency and severity of the disease state based on at least the registered information and the implementation standards for the transportation and acceptance of the victims determined by each local government;
  • the server being characterized in that includes a provided.
  • an emergency medical control support system comprising a mobile terminal, a cooperative server that can communicate with the mobile terminal via a network, and a statistical server, wherein the cooperative server includes: The main control unit that controls the whole, the display control unit that generates screen data to control the screen display on the terminal, dispatch from the terminal, arrival at the site, departure from the site, observation observation at the site, during transportation Timestamp acquisition unit that detects events including observation findings, hospital arrival, hospital diagnosis, treatment, and outcome, and obtains time stamps, information registration unit that accepts information registration, and hospital activities based on the registered information Based on the list creation unit that creates a list showing the situation, and the registered information and a predetermined standard determined by each local government, the urgency and severity of the disease state are determined.
  • a symptom determination unit, and the statistical server automatically and periodically creates a predetermined report based on the acquired time stamp and registered information, and the severity determination unit of the server Based on the urgency and severity and the list of medical institutions that can be handled by each local government, if the corresponding medical institution or a specific medical condition is suspected, the display control unit will display the medical care corresponding to the specific medical condition.
  • An emergency medical control support system is provided that is controlled to be displayed as an institution candidate list.
  • a portable terminal that can communicate with a server after predetermined authentication via a network, a main control unit that controls the whole, a communication control unit that performs the communication, a screen Display control unit that performs display control based on data and input that accepts input of events including dispatch, arrival at the site, departure from the site, observation observation at the site, observation observation during transportation, arrival at the hospital, diagnosis, treatment, and outcome at the hospital
  • a severity determination unit that determines the degree of urgency and severity of the disease state based on at least the registered information and the implementation standards for the transportation and acceptance of the victims determined by each local government, and a display unit that performs display If the corresponding medical institution and a specific medical condition are suspected based on the urgency and severity and the list of medical institutions that support transportation determined by each local government, the above indication is displayed.
  • Control unit is a portable terminal, characterized by controlling so as to display on the display unit as the corresponding conveying medical institutions candidate list for a particular disease state is provided.
  • the emergency team and the medical institution can make a convincing decision by making a decision based on the “same information”, and the emergency at the prefectural level
  • the delivery time and "time from onset to treatment start" are shortened, and the prognosis of the patient is improved.
  • the adequacy and reliability of transport standards and hospital lists can be regularly evaluated and improved.
  • FIG. 1 It is a flowchart which shows in detail the process sequence by the emergency medical care control assistance system which concerns on one Embodiment of this invention. It is a figure which shows the structure of a database. It is a figure which shows the structure of the patient list. It is a figure which shows the structure of the past disease list. It is a figure which shows the structure of the conveyance list
  • FIG. It is a figure which shows the structure of the ambulance team treatment record list 408.
  • FIG. It is a figure which shows the structure of the acceptance request
  • FIG. It is a figure which shows the structure of the transfer acceptance request
  • FIG. It is a figure which shows the structure of the terminal side hospital condition list
  • FIG. It is a figure which shows the structure of the destination hospital list.
  • FIG. It is a figure which shows the structure of the treatment detail list
  • FIG. 10 is a diagram showing a display example of a dispatch-to-arrival screen 501. It is a figure which shows the example of a display of the initial branch screen 502. FIG. It is a figure which shows the example of a display of the consciousness state input panel 503. FIG. It is a figure which shows the example of a display of the blood-pressure input panel 504. It is a figure which shows the example of a display of the pulse input panel 505.
  • FIG. 5 It is a figure which shows the example of a display of the respiration input panel 506. It is a figure which shows the example of a display of the body temperature input panel 507. It is a figure which shows the example of a display of the SpO2 input panel 508.
  • FIG. It is a figure which shows the example of a display of the acceptance status screen 509. It is a figure which shows the example of a display of the transmission item panel 510.
  • FIG. It is a figure which shows the example of a display of the acceptance availability input screen 511.
  • FIG. It is a figure which shows the example of a display of a background / conveyance source input panel 512.
  • FIG. It is a figure which shows the example of a display of the acceptance difficulty reason input panel 513.
  • FIG. 2 is a diagram illustrating a detailed configuration of a mobile terminal 200.
  • the emergency medical control support system of the present invention is not limited to the following description, and can be appropriately changed without departing from the gist of the present invention.
  • FIG. 1 is a schematic diagram illustrating an emergency medical control support system network according to an embodiment of the present invention.
  • an information terminal 101a such as a notebook or a desktop or a touch panel type terminal 101b is installed in the command headquarters, and an Internet network 106 is provided via an optical fiber, cable, ADSL, or 3G mobile network. It is connected to the.
  • a resident uses an information terminal 102 such as a notebook to connect to the Internet network 106 via an optical fiber, a cable, and ADSL.
  • the medical institution uses the information terminal 103a such as a notebook or the touch panel terminal 103b to connect to the Internet network 106 via an optical fiber, a cable, an ADSL, or a 3G mobile network.
  • the doctor / nurse uses the touch panel terminal 104 to connect to the Internet network 106 via a wireless LAN (in-hospital), an optical fiber, a cable, an ADSL, or the like, or a 3G mobile network.
  • the programs to be implemented are (1) Thin clients mainly used on mobile terminals (pure SaaS (Software As A Service), which runs on the browser and most algorithms run on the server), (2) Rich clients (Install the framework, download the content as appropriate, and many algorithms run on the client). Both enable connection in a general connection form regardless of the use of a specific vendor's network.
  • the mobile terminal of the rich client is a terminal having a strong structure that can withstand daily use by an emergency team, and is a 3G mobile phone network (for example, FOMA, WiMAX, e-mobile, etc.) that can be connected by this terminal.
  • WAN Wide Area Network
  • the thin client is assumed to be accessed from a normal notebook or desktop, and is designed to be compatible with any fixed line (ISDN, ADSL, CATV, optical fiber, etc.).
  • ISDN International Subscriber Network
  • ADSL Advanced Driver Assistance Systems
  • CATV Advanced Television Standards
  • optical fiber etc.
  • FIG. 2 shows and explains the terminals used in the emergency medical control support system and the access mode from each terminal to the linked server.
  • ambulance teams and medical institutions use terminals with a strong structure that can be connected to 3G mobile phone networks, and others assume the use of PC terminals such as notebooks and desktops.
  • PC terminals such as notebooks and desktops.
  • access from the general population to some information is planned, and in that case, access from mobile phone terminals, PDAs, etc. is also considered.
  • Fig. 3 summarizes the connection type and terminal type, Internet connection, and users. That is, a thin client (Thin-Client) adopts a notebook or a desktop as a terminal form, and is connected to the Internet by an optical fiber, a cable, or an ADSL. As a user, it is suitable for the command headquarters and residents. On the other hand, a rich client (Rich-Client) adopts a touch panel terminal as a terminal form, and connects to the Internet via a 3G mobile network. As a user, it is particularly suitable for ambulance teams, and it is also used by command headquarters and medical institutions, but it is difficult for residents to use.
  • FIG. 4 shows an outline of security measures in the system aspect of the emergency medical control support system according to the embodiment of the present invention. As shown in the figure, the security of this emergency medical system is secured at the following five levels.
  • Access to terminal 200 is permitted only to individuals who have obtained permission.
  • an authentication system such as ID and password, barcode, IC card, fingerprint, etc. is utilized.
  • access is restricted by ID and password.
  • the portable terminal 200 and the server authenticate with a digital ID. All data transmission / reception is encrypted by SSL.
  • the database server 202 ensures physical and electronic security at a level that can store patient data of medical institutions.
  • the database server 202 is permitted only access from the IP address of the WWW server 201 described above.
  • the statistics server 204 anonymizes all data.
  • the concatenation table that enables concatenation with the original data is stored in a USB having an encryption / access restriction function and stored in a physically locked storage.
  • This emergency medical system has the following versatility and model.
  • This emergency medical system takes the form of a SaaS that is accessed and used in a data center with a level of security that can store patient data.
  • the maintenance cost of each facility can be reduced by centrally managing maintenance of the portable terminal 200 and updating of software and contents.
  • Open design that does not depend on vendor, OS, or hardware Standardization at the information level rather than the data level enables any medical information system installed in each medical institution It is possible to design free of charge from vendors of medical information systems by obtaining “data necessary to extract data”.
  • a thin client and a rich client are developed.
  • the thin client is scheduled to run on a general browser, and the rich client is also designed to run on a general OS (MacOS 10.5 or later, Windows (registered trademark) XP, Windows (registered trademark) 7 or the like).
  • FIG. 5 shows and describes the configuration of the cooperation server of the emergency medical system according to the embodiment of the present invention.
  • this cooperation server conceptually includes the www server 201 and the database server 202 of FIG.
  • the cooperation server 300 has a configuration including a control unit 301, a communication control unit 302, and a storage unit 303.
  • the control unit 301 functions as a main control unit 301a, a display control unit 301b, a time stamp acquisition unit 301c, an information registration unit 301d, a severity determination unit 301e, and a list creation unit 301f by executing a control program.
  • the main control unit 301a governs overall control.
  • the display control unit 301b generates screen data so as to control screen display on the terminal.
  • the time stamp acquisition unit 301c detects events such as dispatch from the terminal, arrival at the site, etc., and acquires a time stamp.
  • the information registration unit 301d accepts information registration from an ambulance team or a medical institution.
  • the severity determination unit 301e calculates the severity of the patient based on the registered information and an index described later.
  • the list creation unit 301f creates a list or the like indicating the activity status of today's hospital based on the registered information or the like.
  • the statistical server 204 shown in FIG. 4 stores all time stamps and data as a repository. Based on the acquired time stamp and the registered information, a predetermined index (characteristic, process, Calculated), enabling feedback to fire and medical institutions and provision of information to the government and residents.
  • the ambulance team records are recorded as a time stamp when a button on the touch panel is pressed. All records can be viewed in real time by the terminal of the “destination medical institution”.
  • the server transfers data such as the patient's age, gender, and state (S2). After this data transfer, the ambulance team is dispatched. At this time, the dispatch button on the terminal is pressed (S3), and the server records a time stamp related to the dispatch (S4).
  • the on-site arrival button of the terminal is pressed (S5), and the server records a time stamp related to the arrival at the scene (S6).
  • the ambulance team records data necessary for the determination of “severity / emergency” in the patient's past history, current medical history, and physical findings (S7). Based on this recorded data, the server uses a severity / emergency determination algorithm incorporated internally based on the “Employment Standards for Transporting and Accepting Victims” determined by each local government. A determination is made (S8).
  • the server sorts the list of medical institutions that can be transported based on the judgment of severity and urgency and the characteristics and list of pre-registered medical institutions according to the distance from the site and the busyness of each medical institution.
  • Display S9.
  • a list of transport destination candidates is displayed at the terminal of the ambulance team (S10). This list reflects the status of each medical institution on the day in real time, making it possible to avoid contact with busy medical institutions.
  • the ambulance team sees this list of candidate transport destinations and contacts a medical institution (S11).
  • the medical institution makes a decision regarding the acceptance of the patient, and the result is notified to the server (S12).
  • the server updates the list based on this notification (S13).
  • the medical institution and the emergency team make the best decision while sharing the same information (patient outbreak status, busyness of each medical institution, patient status, etc.).
  • the ambulance team makes an inquiry, if it is difficult to accept due to the situation of the medical institution, the information can be shared by touching the ambulance team.
  • the ambulance team departs from the scene. If the current button on the terminal is pressed at that time (S14), the server records a time stamp regarding the departure from the site (S15). Furthermore, the ambulance team arrives at the hospital (disease). At that time, when the sickness button on the terminal is pressed (S16), the server records a time stamp related to the sickness (S17).
  • the information obtained by the ambulance team is automatically transferred from the server to the terminal of the medical institution (S18). This information is displayed on the terminal of the medical institution (S19).
  • the diagnosis button is pressed (S20), and the server records the diagnosis content and the diagnosis time with a time stamp (S21).
  • the treatment / surgery button is pressed (S22), and the server records a time stamp related to the treatment / surgery (S23).
  • the outcome button is pressed (S24), and the server records a time stamp related to the outcome (S25).
  • data integration and information sharing can be realized by inputting three items of “diagnosis”, “treatment / operation contents”, and “outcome” of the transferred patient.
  • the medical institution is busy for a predetermined period of time (eg, 1 hour for general hospitalization, 3 hours for abdominal surgery, etc.) This is recorded on the server, and the information is shared among the related parties, and at the same time, the fact is displayed on the medical institution selection list.
  • various indexes are created based on the accumulated information, and then the information is shared (S26). In this way, a series of processing is completed.
  • the various indicators are related to the verification of transport rules and whether or not the medical institution properly accepts patients.
  • the basic ones are implemented in advance as content, but can be added or updated. .
  • FIGS. 7 to 22 show and explain the structure of the database.
  • the database includes a patient list 401, a past disease list 402, a transport list 403, a patient transport instruction list 404, a patient status detail list 405, a terminal-side hospital status list creation request list 406, a transport ambulance crew.
  • a management information list 416, a hospital schedule detailed information list 417, and a rotation number information list 418 are stored in a table format.
  • the patient list 401 (see FIG. 8), the patient number, patient state classification, patient age, patient gender classification, patient name, patient birth date, cardiopulmonary arrest presence / absence classification, vomiting presence / absence classification, alcohol consumption classification, A conveyance difficulty presence / absence classification, abdominal pain presence / absence classification, and a consciousness disorder presence / absence classification are associated with each other, and a past medical condition list 402, a conveyance list 403, a patient conveyance instruction list 404, and a patient condition detail list 405 are associated with each other.
  • items in the patient list 401 can be appropriately added, deleted, integrated, and the like. The same applies to the other lists described below.
  • a past disease number, a past disease state classification, a past disease, a hospital name, a hospital number, and a patient number are associated with each other.
  • the transport No In the transport list 403 (see FIG. 10), the transport No, transport state classification, location of occurrence, site address, site latitude, site longitude, dispatch request date and time, transport dynamic category, ambulance No, patient number, dispatch date and time, terminal side Hospital status list creation request No., current arrival date / time, transportation cut-off category, hospitalization date / time, illness onset date / time, return date / time, occurrence date / time are associated with each other, and transport ambulance crew list 407, emergency team treatment record list 408, an acceptance request list 409 is linked.
  • the patient transport instruction list 404 see FIG.
  • the patient transport instruction number, the patient transport instruction status classification, the dispatch command number, the reporter name, the reporter gender classification, the reporter relation classification, the awareness method classification, and the mobile transfer Received content, date and time of notification, details of report, transfer category, fire department headquarters No., patient No., requesting hospital No., terminal-side hospital status list creation request No. are associated with each other, and transfer acceptance request list 410 is linked. It is attached.
  • the patient condition detail list 405 (see FIG. 12), the patient condition detail number, patient condition detail condition category, item type category, JCS, GCS_E, GCS_V, GCS_M, systolic blood pressure, diastolic blood pressure, respiratory rate, pulse rate, body temperature. , SpO2, ECG section, left pupil, right pupil, left light reflection section, right light reflection section, and patient No. are associated with each other.
  • the terminal-side hospital status list creation request list 406 (see FIG. 13), the terminal-side hospital status list creation request No., the terminal-side hospital status list creation request status classification, the request source, the transfer No, the request source hospital No, and the patient transfer instruction No. Are associated.
  • the transport ambulance member list 407 (see FIG.
  • the transport ambulance member No, the transport ambulance member state classification, the UserNo, and the transport No. are associated with each other.
  • the ambulance treatment record list 408 see FIG. 15
  • the ambulance treatment record No., the ambulance treatment record state classification, the treatment date / time, the conveyance treatment classification, and the conveyance No. are associated with each other.
  • the acceptance request No the acceptance request status category, the acceptance request method category, the acceptance availability category, the hospital No, the transport No., the patient No, the hospital acceptance category, the reason for rejecting the acceptance request.
  • the transfer acceptance request list 410 see FIG.
  • the terminal-side hospital status list No. the terminal-side hospital status list status classification, the hospital No., cardiopulmonary arrest presence / absence classification, blood discharge presence / absence classification, melena / exclusion classification , Conveyance difficulty presence / absence classification, abdominal pain presence / absence classification, consciousness disorder presence / absence classification, hospital name, hospital address, hospital telephone number, medical suspension period, next medical treatment start time, terminal side hospital status list request number, distance, medical treatment by symptom sign
  • the engine selection category is associated.
  • the destination hospital list No., destination hospital list state classification, hospital No., hospital name, hospital address, hospital phone number, terminal-side hospital status list No., destination selection category are It is associated.
  • the acceptance number, hospital number, patient number, acceptance status category, patient bed ID, patient acceptance detail category, doctor number, acceptance request number, acceptance date / time, emergency diagnosis name, final diagnosis A name, a receiving patient outcome category, an outcome date and time, and a transfer acceptance request No. are associated with each other, and a processing detail list 414 is further associated therewith.
  • the treatment detail list 414 see FIG. 21
  • the treatment detail No, the treatment detail status category, the processing category, the processing start date and time, the scheduled processing end date and time, the treatment end date and time, and the acceptance number are associated with each other.
  • the hospital status list No. the hospital status list status category, the number of waiting rooms, the endoscope usage category, the operating room usage category, the categorical room usage category, the ICU usage category, the hospital fullness
  • the classification, the equipment use start date and time, the equipment use scheduled end date and time, and the hospital number are associated with each other.
  • the hospital schedule management information list 416 the hospital schedule management information No, the hospital schedule management information state classification, the medical year, the medical month, and the hospital No are associated with each other, and the hospital schedule detailed information list 417 is linked. It is attached.
  • the hospital schedule detailed information list 417 see FIG.
  • the hospital schedule detailed information No the hospital schedule detailed information state classification, the medical treatment date, the medical treatment day type division, the morning medical treatment division, the morning medical treatment start time, the morning medical treatment end time, and the afternoon medical treatment
  • the classification, the afternoon medical service start time, the afternoon medical service end time, the night medical service classification, the night medical service start time, the night medical service end time, and the hospital schedule management information No. are associated with each other.
  • the rotation number information list 418 see FIG. 22
  • the rotation number information, the rotation number information state classification, the start date and time, the end date and time, the corresponding department, the district, and the hospital number are associated with each other.
  • a screen appears asking if the disease is fatal (eg, cardiopulmonary arrest or severe trauma) (S50).
  • the transport destination is set (S51A to S51E). That is, according to the screen selection at the terminal, traumatic CPA support (S51A), child CPA support (S51B), CPA C (S51C), CPA B (S51D), and trauma C (51E) are determined as the transport destination.
  • traumatic CPA support S51A
  • child CPA support S51B
  • CPA C S51C
  • CPA B CPA B
  • trauma C 51E
  • the corresponding hospital is selected.
  • the child is a pediatric disease (S53A)
  • the child corresponding hospital is determined as the transport destination (S54A)
  • the special disease corresponding hospital is determined as the transport destination ( S54B)
  • a mother transport compatible hospital is determined as the transport destination (S54C)
  • trauma (S55) other hospitals are selected as transport destinations.
  • the delivery destination is determined based on the information.
  • the state of high urgency that is, 1) presence / absence of consciousness disorder (JCS / GCS) (S57A), 2) presence / absence of shock (SI is 1.5 or more) (S57B), 3) abnormality of 2 or more vitals (
  • S57C presence / absence of pulse, respiration, blood pressure, body temperature, SIRS 3 items or more
  • a candidate for delivery destination is presented based on the “delivery compatible medical institution list” that can handle severe cases determined by each local government Be done
  • a transport destination candidate is presented based on the transport compatible medical institution list determined by each local government based on the state. For example, in the current algorithm, when there is an intrinsic disease with consciousness disorder (S59) or when there is a pupil abnormality (S60), stroke C is determined as the delivery destination (S62), and when there is no pupil abnormality (S62) S61), a medical institution supporting consciousness disorder B is displayed as a candidate (S63). 2) If it is endogenous that satisfies any of 3) (S64), it is assumed that the disease is an intrinsic disease accompanied by vital abnormality (S65), and a lifesaving center / C-compatible medical institution is displayed as a candidate ( S66).
  • Screen data on the terminal is generated under the control of the display control unit 301b of the server.
  • Information input by the terminal is registered in the information registration unit 301d of the server.
  • the list displayed on the terminal is created by the server list creation unit 301f.
  • FIG. 24 shows a dispatch / current arrival screen 501.
  • This screen 501 displays a route (map) display area from the site to the hospital, a display area for patient information such as age and sex, complaints, incoming calls, and discovery status, and a progress information display area for symptoms.
  • the screen changes to the initial branch screen 502 of FIG.
  • a highly urgent disease input designation region is provided in the upper left, a specific disease input designation region in the center, a site-specific symptom input region in the upper right, and a vital sign input region in the lower part.
  • vital signs consciousness state, blood pressure, pulse, respiration, body temperature, SpO2 and the like can be input.
  • the present invention is not limited to these.
  • a consciousness state input panel 503 as shown in FIG. 26 is displayed.
  • one of 10 items related to JCS is selected, and the corresponding item is selected from among restlessness, incontinence, and spontaneous loss (multiple selections are possible).
  • One item is selected from each exercise, and the input completion button is pressed.
  • a blood pressure input panel 504 as shown in FIG. 27 is displayed. On this panel 504, a measurement site may be selected and a blood pressure value may be input. The tactile will be grayed out until measurement impossible is pressed.
  • a pulse input panel 505 as shown in FIG. 28 is displayed. On this panel 505, a measurement site may be selected and a pulse value may be input.
  • a respiration input panel 506 as shown in FIG. 29 is displayed. In this panel 506, the patient's corresponding symptom is selected and selected from levels 1 to 3. In this example, “word-only conversation”, “cyanose” at level 1, “phrase conversation”, “inspiratory wheezing” at level 2, “sentence-by-text conversation”, and “shortness of effort” can be selected at level 3. It has become.
  • a body temperature input panel 507 as shown in FIG. 30 is displayed.
  • a body temperature measurement site is selected and a numerical value is input.
  • the measurement environment can be input under a low temperature environment or a high temperature environment.
  • an SpO2 input panel 508 as shown in FIG. 31 is displayed.
  • the measurement site and numerical value (%) of the patient's SpO2 (arterial blood oxygen saturation) are input.
  • the screen transits to an acceptability status screen 509 regarding CPA.
  • the occurrence status (map), the activity status of today's list hospital, and current patient information are displayed.
  • the site and neighboring hospitals are displayed on the map.
  • the activity status of today's list hospital the name of the corresponding medical institution, the distance to the medical institution, the status, the diagnosis name, the seriousness of injury, the reception status, and the like are displayed in association with each other.
  • a transmission item panel 510 as shown in FIG. 33 is displayed.
  • the estimated cardiopulmonary arrest time, age, sex, presence / absence of DNR correspondence are input as basic items, and CPA-specific information is presence / absence of eyewitness, presence / absence of bystander, initial electrocardiogram, AED, medical history, family The clinic, pass ID, transport history, disease name, transport destination, ETA, etc. are input.
  • a plurality of background factors can be selected, and one of the transfer request sources is selected.
  • the terminal is operated at a medical institution or the like and the difficult to accept button is pressed, a difficult to accept reason input panel 513 as shown in FIG. 36 is displayed. On this panel 513, it is possible to select a reason for difficulty in acceptance.
  • the server is the servers 201 and 202 that can communicate with the mobile terminal 200 via the network after predetermined authentication, and the main control unit 301a that controls the entire system.
  • a display control unit 301b for generating screen data to control screen display on the terminal 200, dispatch from the terminal 200, arrival at the site, departure from the site, observation observation at the site, observation observation during transportation, arrival at the hospital ,
  • a time stamp acquisition unit 301c for detecting an event including diagnosis / treatment / outcome in a hospital and acquiring a time stamp, an information registration unit 301d for receiving information registration, and an activity status of the hospital based on the registered information
  • a list creation unit 301f that creates a list, and at least the registered information and the transportation and reception of the victim determined by each local government. Based on the performance standards of les, characterized in that a determining severity determining unit 301e the urgency and severity of the condition.
  • the severity determination unit 301e uses a medical institution (mainly a lifesaving emergency center) that can cope with a highly urgent pathological condition based on the urgency specified by the algorithm as a transport destination candidate, and has a high urgency.
  • the transport destination candidate is selected in consideration of the suspected disease and its severity.
  • an emergency medical control support system includes an emergency medical control system including a mobile terminal 200, servers 201 and 202 that can communicate with the mobile terminal 200 via a network, and a statistics server 204.
  • the servers 201 and 202 include a main control unit 301 a that controls the entire control, a display control unit 301 b that generates screen data to control screen display on the terminal 200, and a terminal 200 Time stamp acquisition unit 301c for detecting events including dispatch, on-site arrival, on-site departure, on-site observation findings, observation observations during transportation, hospital arrival, diagnosis / treatment / outcome in hospital, and time stamp acquisition unit 301c, and information registration Information registration unit 301d that accepts information and creates a list showing the hospital activity status based on the registered information List creation unit 301f, and severity determination unit 301e that determines the degree of urgency and severity of pathological conditions based on the registered information and the “implementation criteria for transport and acceptance of victims” determined by each local government
  • the statistical server 301 a that controls the entire control
  • the severity determination unit 301e of the servers 201 and 202 is periodically created, and the corresponding medical institution and the specific disease state are suspected based on the urgency and severity and the list of medical institutions that can be handled by each local government. In the case where it is broken, it is displayed as a candidate list of carrier medical institutions corresponding to a specific disease state.
  • the portable terminal may be a touch panel type terminal.
  • the touch panel type terminal conceptually includes a terminal such as a tablet PC or a smartphone.
  • FIG. 37 shows an example of an input screen 600 on the hospital side.
  • an input screen 600 for a “heart / circulation” disease is shown.
  • the hospital side selects the triage of the patient (determining treatment priority).
  • the doctor at the receiving hospital makes a selection from “super emergency”, “emergency”, “semi-emergency”, “low emergency”, and “mild”. Even if the patient was urgently transported by the ambulance team at the time of acceptance, the triage was reviewed at the time of selection, and the order of the patients who were waiting for a medical examination at the hospital was updated according to the selected triage.
  • examination contents in this example, electrocardiogram, etc.
  • diagnostic contents in this example, STEMI (ST elevation myocardial infarction), heart failure, arrhythmia, etc.
  • treatment / treatment contents CAG (selective coronary angiography), PCI etc.
  • PCI means coronary artery treatment with a catheter, but when this PCI is selected, the medical institution recognizes that it will not be able to treat other patients for a predetermined time. Born to the people concerned. Thereafter, for example, “hospitalization”, “return home”, “upstream transfer”, “downstream transfer”, and “death” are selected as the return information.
  • the external terminal recognizes that the procedure is busy for a predetermined time (for example, 1 hour) due to treatment.
  • a predetermined time for example, 1 hour
  • the input information is not only recorded in the DB of the database server 202 as medical information, but also can be shared in real time by a plurality of medical institutions, emergency services, and other related parties.
  • the hospital side input screen includes “brain / consciousness”, “digestive organs”, “trauma”, “CPA (cardiopulmonary arrest)”, “others”
  • Various input screens can be selected, and it is possible to select and input predetermined medical information for each disease.
  • the statistics server 204 automatically displays a predetermined medical quality index (clinical index), daily report, monthly report, display report on a map, and the like based on the acquired time stamp and registered information.
  • a predetermined medical quality index clinical index
  • daily report daily report
  • monthly report display report on a map
  • display report on a map and the like based on the acquired time stamp and registered information.
  • FIG. 38 shows an emergency patient occurrence map display screen 601.
  • each area divided into municipalities in this example, city units
  • the number of referrals of the transported patient is indicated by an asterisk, and the number of referrals can be grasped by the color.
  • the position where the stars are plotted means where the patient originated. This position is automatically specified by the GPS function of the terminal of the ambulance team.
  • the demand ratio of medical institutions is shown as a pie chart.
  • the gray scale indicates the acceptable ratio and the white indicates the unacceptable ratio.
  • the size of the pie chart itself reflects demand, that is, the number of telephone calls related to acceptance.
  • FIG. 39 shows an example of a daily report of each medical institution created.
  • a conveyance case list as a daily report for the fire department headquarters is shown.
  • the transport case list the transport No. , Suspected disease classification, awareness time, ambulance team name, age, gender, transport time, reference No. , Inquiry start time, call time, referrer, referee medical institution, ranking in list, order of inquiry, demand status, reason for referral to demand x, acceptability, difficulty, transport destination medical institution, definitive diagnosis name, treatment details Outpatient outcomes are shown.
  • the conveyance time means a required time (unit: minute) from awareness to delivery to the doctor.
  • monthly reports for each medical institution can be created. This is a statistic for each medical institution, and it is also possible to create a list of all patients who were referred to the hospital as monthly statistics. This shows monthly statistics (number of inquiries and receipts up to last month, demand ratio), cumulative this month (inquiries and receipts, demand ratio), and cumulative this year (inquiries and acceptance, demand ratio). It is.
  • Suspicious disease classification awareness time, ambulance team name, age, gender, total transport time, number of inquiries, transport destination medical institution, definitive diagnosis name, treatment details, outpatient outcome, etc.
  • Suspected disease categories include endogenous CPA, exogenous CPA, pediatric CPA, CPA and others, severe stroke 1, severe stroke 24, severe stroke 5, stroke 23, stroke 23tPA, stroke 5, SAH4, other severe consciousness disorder, chest pain, Abdominal pain with shock / consciousness disorder, abdominal pain with vital abnormalities, severe abdominal pain, massive vomiting blood, severe childhood (breathing, convulsions, 40 degrees or more, etc.), childhood mildness, other severe intrinsic, other mildness intrinsic, There are severe trauma, minor trauma, severe burn, minor burn.
  • the servers 201 and 202 determine the urgency and severity of the pathological condition based on at least the registered information and the criteria for carrying and receiving the victim determined by each local government.
  • the severity determination unit 301e is provided, the severity determination can also be performed on the mobile terminal 200 side by installing a predetermined application on the mobile terminal.
  • FIG. 40 shows a detailed configuration of such a portable terminal 200.
  • the mobile terminal 200 includes a control unit 251, a communication control unit 252, a storage unit 253, an input unit 254, and a display unit 255.
  • the control unit 251 functions as a main control unit 251a, a display control unit 251b, and a severity determination unit 251c by executing a control program.
  • the main control unit 251a governs overall control.
  • the display control unit 251b controls display.
  • the severity determination unit 251c calculates the severity of the patient based on the registered information and various indexes. For example, when the consciousness state, blood pressure, pulse rate, respiration, body temperature, SpO2, etc. are input by the ambulance team on the screen 502 as shown in FIG. 25, the severity determination unit 201e, based on the input information, It is possible to determine the urgency level of the disease state and display it on the screen.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Health & Medical Sciences (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Epidemiology (AREA)
  • Biomedical Technology (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Educational Administration (AREA)
  • Medicinal Chemistry (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Chemical & Material Sciences (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Child & Adolescent Psychology (AREA)

Abstract

本発明は救急医療システム及びサーバを提供することを目的とする。本発明のサーバは、ネットワークを介して携帯端末と通信自在なサーバであって、主制御部３０１ａと、上記端末における画面表示を制御するよう画面データを生成する表示制御部３０１ｂと、上記端末からのイベントを検出しタイムスタンプを取得するタイムスタンプ取得部３０１ｃと、情報登録を受け付ける情報登録部３０１ｄと、上記タイムスタンプ取得部３０１ｃで取得したタイムスタンプや上記登録された情報に基づいて所定の指標を作成する指標作成部３０１ｇと、上記登録された情報と各自治体で決められた「傷病者の搬送及び受入れの実施基準等」に基づいて病態の緊急度と重症度を判定する重症度判定部３０１ｅと、緊急性および重症度と各自治体で決められた「搬送対応医療機関リスト」に基づいて、各対応医療機関、特定病態が疑われた場合には、特定の病態の対応する搬送医療機関候補リストとして表示する機能を備えたことを特徴とする。

Description

救急医療管制支援システム及びサーバ並びに携帯端末
　本発明は、救急医療管制支援システム及びサーバ並びに携帯端末に関する。
　現在、救急医療の評価指標として総務省が発表する「救急車による搬送時間（通報から病院収容までの時間）」が使われる事が多い。しかしながら、この指標は救急医療の一側面をとらえているに過ぎない。救急医療はリレーに例えられるが、この指標は、救急リレーにおける第二走者のラップタイムを短くすることだけに注力しているようなもので、走者間のバトンパスワークなどを無視したものになりかねない。本来は、医学的にも「発症から治療開始までの時間」、即ちリレー走者の合計タイムが唯一の指標になるべきである。この指標を活用するためには、消防側の「発症～病院到着まで」の時間と、医療機関が持っている「病院到着から治療開始まで」の時間を統合する必要があるが、現在、救急医療情報システム（病院前）と医療機関における診療記録（病院情報システム）とではデータの統合が全く行われていないのが実状である。
　さらに、医療の高度化・専門化が進むにつれて、「当直医の専門性」によって治療できる疾患が異なってくる。例えば、同じ外科であっても、脳神経外科の専門医は腹部の手術はできないし、腹部外科の専門医は心臓の手術はできない。従って、救急医療のマッチングでは、「治療を必要とする患者」を「治療ができる病院」に搬送することは重要である。しかしながら、依然として、救急隊の中には「直近搬送（一番、最寄りの医療機関に搬送すること）」が根付いている。即ち、救急隊は直近搬送以外の尺度を持たない。同時に、救急隊は「直近搬送」をしない理由が分からない。「１０分離れているけど、Ａという疾患であれば、そちらの医療機関に搬送すべき」という明確なルールが存在しない。
　一方、昨年改正された消防法では、各都道府県に重症度・緊急度に応じた搬送基準の策定と搬送先医療機関リストの作成を求めている。この搬送先医療機関リストは、各医療機関の「立候補」で決まるべきものではなく、本来は、各医療機関の「客観的な評価」に基づくべきものである。そのためには、各医療機関が、同じ基準で「医療の質指標」を算出し、客観的な評価をしていく必要がある。
　さらに、現在、消防は市町村の事業であるため、各消防本部の情報システムが独立に運用されている。例えば、奈良県では１３の消防本部があるが、それらの間で搬送データの共有はされていない。つまり、隣の市であっても、奈良市消防の活動状況を生駒市の消防は全く分からないといった状況が生まれている。
　また、救急隊と医療機関同士の確執も問題となっている。即ち、医療機関では「受けられない傷病」に関する問い合わせを何度も受けること、少し前に救急患者を受け入れて現在多忙にも関わらず別な救急隊からの問い合わせを受けること、更には、「軽傷だから」と言って重症患者を運んでこられる等、が起こっている。これらは、直近搬送文化、各消防本部におけるデータ共有がないこと、に起因しているが、医療機関では、これらが繰り返されることで「疑わしきは断る」という文化ができあがってくる。
　さらに、医療機関同士も分断されている。即ち、医療機関も、自施設における状況は分かるが、隣の病院で今どのような患者が来院しているのか、どのような処置や手術が行われているのか、今晩入院するような重症患者がいるのか、などは分からない。従って、救急隊からの患者受け入れの依頼を断る場合にも「どこかが受けてくれるだろう」といった具合に考えてしまう医療機関が多い。
　ところで、医療機関のベッドやリソースの空き状況を医療機関が各診療科毎、或いは専門性毎に「○」「×」などで表示し、救急隊はそのサインを元に搬送先を判断するシステムを一般に応需システムと呼んでいる。しかし、現在の応需システムは、「救急治療室と離れた場所にあり入力が面倒」、「実際にはそのときの状況や患者の状態などで総合的に受入を判断するために一概に○や×にできない」、「結局、直近搬送で×であっても電話がかかってくる」・・・という事からほとんど利用されていない。例えば、ある自治体の消化管出血搬送事例をみると、応需システム上、○をつけている医療機関と、×をつけている医療機関への照会回数がほぼ同数であった。また、1日に発生した患者数より、応需システム上○をつけている医療機関が多いにもかかわらず、問い合わせに対し半数以上で受入が断られていた。
　地域に救急医療施設が少ない場合、その施設がほぼ１００％患者を受け入れることで、受入困難が発生していない施設においても、改正消防法に基づいて各都道府県が策定した「搬送実施基準」の医療機関分類（リスト）に掲載されている医療機関における医療の質指標（臨床指標）の評価や、観察基準や選定基準の精度の評価を行うためには、病院前の観察データと急性期医療機関における診療データを統合する必要がある。
　さらに、現在、各消防局・本部・組合はそれぞれに別個にデータを管理しているが、地域における救急医療の状況を適切に把握するためには、これらのデータを統合する必要があり、消防の情報レベルでの広域化が必要となる。
　このように現状で起こっているのは、救急医療全体を見通す視点の欠如に尽きると言っても過言ではない。
　ここで、特許文献１では、救急医療サーバが、患者発生前に救急搬送先の病院の受入状況を常に把握しており、救急車から救急医療申請があった時点において最適な医療機関を検索することができる救急医療システムが開示されている。
特開２００９－１８７１６７号公報
　しかしながら、以上の課題を整理すると、救急医療管制支援システムでは以下の事が実現される必要がある。
　・　質指標による医療機関ごとの診療機能、プロセス、アウトカムの見える化
　・　救急医療情報と医療機関情報の統合と診療連携状況の見える化
　・　各消防本部における救急医療情報の統合による地域全体の救急医療の見える化
　・　多忙な救急関係者の手間がかからない情報共有の仕組み
　・　重症度・救急度に基づいて適切な搬送先を決定するための意思決定支援
　・　システムの評価とＰＤＳＡサイクルを回すための情報提供
　そこで、本発明は上述の技術的な課題に鑑み、救急隊と医療機関が「同じ情報」を元に意志決定することで、納得のいく意志決定ができ、全県レベルの救急医療情報を全ての救急関係者が知ることで、状況に応じた最適の意志決定を可能とし、結果として、搬送時間や「発症から治療開始までの時間」を短縮させ、患者の予後が改善し、搬送基準や病院リストの妥当性と信頼性を定期的に評価し、改善できる救急医療管制支援システム及びサーバ並びに携帯端末を提供することを目的とする。
　上述技術的な課題を解決するため、本発明の第１の態様では、ネットワークを介して携帯端末と所定の認証の後に通信自在なサーバであって、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備えたことを特徴とするサーバが提供される。
　また、本発明の第２の態様では、携帯端末と、上記携帯端末とネットワークを介して通信自在な連携サーバと、統計サーバと、からなる救急医療管制支援システムであって、上記連携サーバは、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、上記登録された情報と各自治体で決められた所定の基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備え、上記統計サーバは、取得したタイムスタンプや登録された情報に基づいて所定の報告書を自動的且つ定期的に作成し、上記サーバの上記重症度判定部により、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御することを特徴とする救急医療管制支援システムが提供される。
　また、本発明の第３の態様では、ネットワークを介してサーバと所定の認証の後に通信自在な携帯端末あって、全体の制御を司る主制御部と、上記通信を行う通信制御部と、画面データに基づく表示制御を行う表示制御部と、出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントの入力を受け付ける入力部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、表示を行う表示部と、を備え、上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして上記表示部に表示するよう制御することを特徴とする携帯端末が提供される。
　このほか、救急隊における観察や処置の結果を搬送先候補となる医療機関と情報共有できる仕組みを提供できる。さらに、地域全体における患者の発生状況や、急性期医療機関の診療状況を関係者全員が共有できる仕組みを提供できる。そして、救急搬送された患者の診療記録を統合する仕組みを提供できる。
　本発明に係る救急医療管制支援システム及びサーバ並びに携帯端末によれば、救急隊と医療機関が「同じ情報」を元に意志決定することで、納得のいく意志決定ができ、全県レベルの救急医療の状況を全ての救急関係者が知ることで、状況に応じた最適の意志決定を可能とし、結果として、搬送時間や「発症から治療開始までの時間」を短縮させ、患者の予後が改善し、搬送基準や病院リストの妥当性と信頼性を定期的に評価し、改善できる。
本発明の一実施形態に係る救急医療管制支援システムのネットワークのイメージ図である。 救急医療管制支援システムで利用する端末と、それぞれの端末からサーバへのアクセス形態を示す図である。 接続形式と端末の形態、インターネットへの接続、利用者が対比してまとめられている図である。 この発明の一実施形態に係る救急医療管制支援システムのシステム面におけるセキュリティ対策の概要を示す図である。 本発明の一実施形態に係る救急医療管制支援システムのサーバ構成を示す図である。 本発明の一実施形態に係る救急医療管制支援システムによる処理手順を詳細に示すフローチャートである。 データベースの構成を示す図である。 患者リスト４０１の構成を示す図である。 既往症リスト４０２の構成を示す図である。 搬送リスト４０３の構成を示す図である。 患者搬送指示リスト４０４の構成を示す図である。 患者状態詳細リスト４０５の構成を示す図である。 端末側病院状態リスト作成依頼リスト４０６の構成を示す図である。 搬送救急隊員リスト４０７の構成を示す図である。 救急隊処置記録リスト４０８の構成を示す図である。 受入要請リスト４０９の構成を示す図である。 転送受入要請リスト４１０の構成を示す図である。 端末側病院状況リスト４１１の構成を示す図である。 搬送先病院リスト４１２の構成を示す図である。 受入リスト４１３の構成を示す図である。 処置詳細リスト４１４の構成を示す図である。 病院状況リスト４１５、病院スケジュール管理情報リスト４１６、病院スケジュール詳細情報リスト４１７、輪番情報リスト４１８の構成を示す図である。 重症度、緊急度の判定アルゴリズムの一例を説明するフローチャートである。 出動～現着画面５０１の表示例を示す図である。 初期分岐画面５０２の表示例を示す図である。 意識状態入力パネル５０３の表示例を示す図である。 血圧入力パネル５０４の表示例を示す図である。 脈拍入力パネル５０５の表示例を示す図である。 呼吸入力パネル５０６の表示例を示す図である。 体温入力パネル５０７の表示例を示す図である。 ＳｐＯ２入力パネル５０８の表示例を示す図である。 受入可否状況画面５０９の表示例を示す図である。 伝達項目パネル５１０の表示例を示す図である。 受入可否入力画面５１１の表示例を示す図である。 背景・搬送元入力パネル５１２の表示例を示す図である。 受入困難事由入力パネル５１３の表示例を示す図である。 病院側の入力画面６００の一例を示す図である。 救急患者発生マップの表示画面６０１を示す図である。 作成された各医療機関の日報の一例を示す図である。 携帯端末２００の詳細な構成を示す図である。
　以下、本発明の救急医療管制支援システムに係る好適な実施形態について図面を参照しながら説明する。なお、本発明の救急医療管制支援システムは、以下の記述に限定されるものではなく、本発明の要旨を逸脱しない範囲において、適宜変更可能である。
　図１には、本発明の一実施形態に係る救急医療管制支援システムのネットワークのイメージ図を示し説明する。
　この図１に示されるように、指令本部にはノートブックやデスクトップ等の情報端末１０１ａやタッチパネル式端末１０１ｂが設置されており、光ファイバ、ケーブル、ＡＤＳＬ等或いは３Ｇ携帯網を介してインターネット網１０６に接続されている。住民は、ノートブック等の情報端末１０２を用い、光ファイバ、ケーブル、ＡＤＳＬを介してインターネット網１０６に接続する。また、医療機関（事務）は、ノートブック等の情報端末１０３ａやタッチパネル式端末１０３ｂを用いて、光ファイバ、ケーブル、ＡＤＳＬ等或いは３Ｇ携帯網を介してインターネット網１０６に接続する。医師・看護師は、タッチパネル式端末１０４を用いて、ワイヤレスＬＡＮ（院内）と、光ファイバ、ケーブル、ＡＤＳＬ等を介して、或いは３Ｇ携帯網を介して、インターネット網１０６に接続する。
　実装するプログラムは、（１）主に携帯端末で利用するシンクライアント（純粋なＳａａＳ（Software As A Service）で、ブラウザ上で動かし、ほとんどのアルゴリズムはサーバ上で稼働する）、（２）リッチクライアント（フレームワークをインストールし、コンテンツを適宜、ダウンロードし、多くのアルゴリズムはクライアントで稼働する）の２種類である。双方とも特定ベンダーのネットワークの利用に拘ることなく、一般的な接続形態での接続を可能にする。但し、リッチクライアントの携帯端末は、救急隊による日常利用に耐え得る強固な構造の端末であることが望ましく、この端末で接続可能な３Ｇ携帯電話ネットワーク（例えばFOMA、WiMAX、イーモバイル等）であるＷＡＮ（Wide Area Network）を選ぶことになる。
　シンクライアントは、通常のノートブック或いはデスクトップよりのアクセスを想定しており、各種固定回線（ISDN、ADSL、CATV、光ファイバ等）のいずれでも対応可能な設計とする。但し、医療機関の多くが院内端末からのインターネットへの接続を制限している現状を考えると、医療機関内からのアクセスには、上記のＷＡＮへの接続形式も選択肢とする必要があり、CATVが主なネットワークインフラである地域では、将来的な拡張にあたってはこれらも考慮する。
　図２には、救急医療管制支援システムで利用する端末と、それぞれの端末から連携サーバへのアクセス形態を示し説明する。前述したように、救急隊・医療機関では３Ｇ携帯電話ネットワークに接続できる強固な構造の端末を利用し、その他ではノートブック・デスクトップなどのＰＣ端末の利用を想定している。将来的には、一部情報への一般住民からのアクセスを予定しており、その際には、携帯電話端末やＰＤＡ等からのアクセスも考慮する。
　図３には、接続形式と端末の形態、インターネットへの接続、利用者が対比してまとめられている。即ち、シンクライアント（Thin-Client）は、端末の形態としてはノートブックやデスクトップが採用され、インターネットへは光ファイバ・ケーブル・ＡＤＳＬにより接続する。利用者としては、指令本部、住民に好適である。一方、リッチクライアント（Rich-Client）は、端末の形態としてはタッチパネル式端末が採用され、３Ｇ携帯ネットワークを介してインターネットに接続する。利用者としては、救急隊に特に好適であり、指令本部、医療機関でも利用されるが、住民には利用されにくい。
　図４には、この発明の一実施形態に係る救急医療管制支援システムのシステム面におけるセキュリティ対策の概要を示している。同図に示されるように、この救急医療システムのセキュリティは、以下の５つのレベルで確保する。
　・　端末２００へのアクセス
　端末２００には許可を得た個人のみアクセスを許可する。例えば、IDとパスワード、バーコード、ＩＣカード、指紋などの認証システムを活用する。
　・　ＷＷＷサーバ２０１へのアクセス
　原則、ＩＤとパスワードによるアクセス制限を行う。携帯端末２００とサーバはデジタルＩＤによる認証を行う。データの送受信は全てＳＳＬで暗号化する。
　・　データベースサーバ２０２へのアクセス
　データベースサーバ２０２は、医療機関の患者データが保管できるレベルの物理的、電子的セキュリティを確保する。データベースサーバ２０２には、上記のＷＷＷサーバ２０１のＩＰアドレスからのアクセスのみを許可する。
　・　データ２０３の管理
　全ての個人特定可能なデータ（例えば、米国HIPAAのProtected Health Informationに相当するもの）は暗号化して保管する。
　・　統計サーバ２０４におけるデータの管理
　統計サーバ２０４では、全てのデータを匿名化する。元のデータと連結を可能にする連結テーブルは暗号化・アクセス制限機能を持ったＵＳＢに保管し、物理的にロックされた保管庫に保管する。
　また、この救急医療システムは、以下の汎用性・モデル性を有する。
　・　クラウドを利用することによるスケーラビリティ
　この救急医療システムは、患者のデータを保管できるレベルのセキュリティをもったデータセンターにアクセスして利用するタイプのSaaSの形態をとる。携帯端末２００のメンテナンス、ソフトウェアやコンテンツのアップデートについても一元管理を行うことで各施設におけるメンテナンスのコストを削減できる。
　・　医学的なコンセンサスに基づく共有すべき情報の標準化
　過去において様々な救急システムにおいて収集された情報は、論理ベースに基づかず、地域によってまちまちの運用であることが多かった。また、論理に基づかないため、集めたデータが活用されていない場面もあった。この救急医療システムでは、病院実績に基づいた搬送先のリストと、医学的なコンセンサスに基づいた搬送ルールを実装する。これらのリストとルールの作成は医療の質マネジメントに基く。
　・　ベンダー、ＯＳ、ハードウェアに依存しないオープンな設計
　データレベルではなく、情報レベルでの標準化を行うことで、各医療機関に導入されている医療情報システムがどのようなものであれ、「その情報を抽出するために必要なデータ」を得ることで医療情報システムのベンダーからフリーの設計が可能である。利用する携帯端末２００には、シンクライアントと、リッチクライアントを開発する。シンクライアントは一般的なブラウザで稼働する予定で、リッチクライアントも一般的なＯＳ（MacOS10.5以降、Windows(登録商標) XPあるいはWindows(登録商標)7など）で稼働するように設計する。
　次に、図５には、本発明の一実施形態に係る救急医療システムの連携サーバの構成を示し説明する。尚、この連携サーバは、図４のｗｗｗサーバ２０１及びデータベースサーバ２０２を概念上含むものである。同図に示されるように、連携サーバ３００は、制御部３０１と通信制御部３０２、記憶部３０３を有した構成となっている。制御部３０１は、制御プログラムを実行することで、主制御部３０１ａ、表示制御部３０１ｂ、タイムスタンプ取得部３０１ｃ、情報登録部３０１ｄ、重症度判定部３０１ｅ、リスト作成部３０１ｆとして機能する。主制御部３０１ａは、全体の制御を司る。表示制御部３０１ｂは、端末における画面表示を制御するよう画面データを生成する。タイムスタンプ取得部３０１ｃは、端末からの出動、現場到着等といったイベントを検出しタイムスタンプを取得する。情報登録部３０１ｄは、救急隊や医療機関等からの情報登録を受け付ける。重症度判定部３０１ｅは、上記登録された情報や後述する指標に基づいて患者の重症度を算出する。リスト作成部３０１ｆは、上記登録された情報等に基づいて本日の病院の活動状況を示すリスト等を作成する。尚、先に図４に示した統計サーバ２０４は、全てのタイムスタンプやデータをレポジトリとして保管しており、取得したタイムスタンプや上記登録された情報等に基づいて所定の指標（特性、プロセス、連携）を算出し、消防機関、医療機関へのフィードバック、及び行政や住民への情報提供を可能にする。
　以下、図６のフローチャートを参照して、本発明の一実施形態に係る救急医療管制支援システムによる処理手順を詳細に説明する。なお、救急隊の記録は、タッチパネルのボタンを押した時点でタイムスタンプとして記録される。すべての記録は「搬送先医療機関」の端末によりリアルタイムで閲覧可能である。
　住民から通報がなされると（Ｓ１）、サーバは、患者の年齢、性別、状態などのデータを移行する（Ｓ２）。このデータの移行後に、救急隊は出動する。このとき、端末の出動ボタンが押下され（Ｓ３）、サーバは出動に関するタイムスタンプを記録する（Ｓ４）。
　その後、救急隊は現場に到着すると、端末の現場到着ボタンが押下され（Ｓ５）、サーバは現場到着に関するタイムスタンプを記録する（Ｓ６）。救急隊は、現場において、患者の既往歴、現病歴、身体所見の中で「重症度・緊急度」の判定に必要なデータを記録する（Ｓ７）。この記録されたデータに基づいて、サーバにおいて、各自治体で決められている「傷病者の搬送及び受入れの実施基準等」に基づいて内部に組み込まれた重症度・緊急度判定アルゴリズムにより重症度の判定が行われる（Ｓ８）。
　サーバは、重症度、緊急度の判断と、事前に登録されている医療機関の特性とリストに基づいて搬送対応医療機関一覧を、現場からの距離および各医療機関の繁忙度でソートした形で表示する（Ｓ９）。救急隊の端末では、搬送先候補一覧が表示される（Ｓ１０）。この一覧には、当日の各医療機関の状況がリアルタイムで反映されており、多忙な医療機関を避けた連絡を行うことを可能ならしめる。救急隊は、この搬送先候補一覧を見て、医療機関に連絡をする（Ｓ１１）。医療機関は患者の受け入れに関する意思決定を行い、その結果はサーバに通知される（Ｓ１２）。サーバでは、この通知に基づいて、リストを更新する（Ｓ１３）。このように、医療機関と緊急隊は同じ情報（県内における患者の発生状況、各医療機関の多忙さ、患者の状態など）を共有しながら、最適の決断をすることになる。なお、救急隊が問い合わせた時点で、医療機関の状況によって受入困難が生じている場合、救急隊がタッチすることで、その情報を共有できる。
　こうして、救急隊は、現場を出発（現発）する。そのときに端末の現発ボタンが押下されると（Ｓ１４）、サーバは現場出発に関するタイムスタンプを記録する（Ｓ１５）。さらに、救急隊は、病院に到着する（病着）。そのときに端末の病着ボタンが押下されると（Ｓ１６）、サーバは病着に関するタイムスタンプを記録する（Ｓ１７）。
　医療機関到着後、救急隊が入手している情報は自動的にサーバから医療機関の端末に転送される（Ｓ１８）。この情報は医療機関の端末において表示される（Ｓ１９）。医療機関において、外来診断が確定した時点で、診断ボタンが押下され（Ｓ２０）、サーバは診断内容と診断時間をタイムスタンプで記録する（Ｓ２１）。さらに、処置・手術が行われた場合、処置・手術ボタンが押下され（Ｓ２２）、サーバは処置・手術に関するタイムスタンプを記録する（Ｓ２３）。そして、最終的な転帰が決まった際には転帰ボタンが押下され（Ｓ２４）、サーバは転帰に関するタイムスタンプを記録する（Ｓ２５）。また、このとき、医療機関では、搬送された患者の「診断」、「処置・手術内容」、「転帰」の３項目を入力することでデータの統合と情報共有を実現できる。これら搬送された患者への医療機関の対応に基づいて、予め決められた一定時間の間（例：一般入院対応は1時間、腹部の手術は3時間・・・など）はその医療機関が繁忙であることをサーバに記録し、関係者の間でその情報を共有すると同時に、医療機関選定用リストにその旨を表示する。
　こうして、蓄積された情報に基づいて各種の指標が作成され、その後、当該情報が共有されることになる（Ｓ２６）。こうして、一連の処理を終了する。なお、各種指標とは、搬送ルールの検証や、医療機関が適切に患者の受け入れを行っているかどうかに関するものであり、基本的なものは予めコンテンツとして実装するが、追加・更新は可能である。
　ここで、図７乃至図２２には、データベースの構成を示し説明する。
　これらの図に示されるように、データベースとしては、患者リスト４０１、既往症リスト４０２、搬送リスト４０３、患者搬送指示リスト４０４、患者状態詳細リスト４０５、端末側病院状況リスト作成依頼リスト４０６、搬送救急隊員リスト４０７、救急隊処置記録リスト４０８、受入要請リスト４０９、転送受入要請リスト４１０、端末側病院状況リスト４１１、搬送先病院リスト４１２、受入リスト４１３、処置詳細リスト４１４、病院状況リスト４１５、病院スケジュール管理情報リスト４１６、病院スケジュール詳細情報リスト４１７、輪番情報リスト４１８、がテーブル方式で蓄積されている。
　尚、図７において"１"，"０"で示したのは、１は０に対して必須のリストであるが、０は１に対して必ずしも必須ではないとのエンティティの関係を示している。
　より詳細には、患者リスト４０１（図８参照）では、患者No、患者状態区分、患者年齢、患者性別区分、患者氏名、患者生年月日、心肺停止有無区分、吐血有無区分、飲酒有無区分、搬送困難有無区分、腹痛有無区分、意識障害有無区分が対応付けられており、さらに既往症リスト４０２、搬送リスト４０３、患者搬送指示リスト４０４、患者状態詳細リスト４０５が紐付けられている。なお、患者リスト４０１の項目は、追加、削除、統合などが適宜可能である。これは、以下に述べる他のリストについても同様である。既往症リスト４０２（図９参照）では、既往症No、既往症状態区分、既往症、病院名、病院No、患者Noが対応付けられている。
　そして、搬送リスト４０３（図１０参照）では、搬送No、搬送状態区分、発生場所、現場住所、現場緯度、現場経度、出動要請日時、搬送動態区分、救急車No、患者No、出動日時、端末側病院状況リスト作成依頼No、現着日時、搬送切分区分、病着日時、病発日時、帰署日時、発生日時が対応付けられており、更に、搬送救急隊員リスト４０７、救急隊処置記録リスト４０８、受入要請リスト４０９が紐付けられている。また、患者搬送指示リスト４０４（図１１参照）では、患者搬送指示No、患者搬送指示状態区分、出動指令No、通報者氏名、通報者性別区分、通報者関係区分、覚知方法区分、携帯転送受内容、覚知日時、通報内容詳細、搬送転送区分、消防本部No、患者No、依頼元病院No、端末側病院状況リスト作成依頼Noは対応付けられており、更に転送受入要請リスト４１０が紐付けられている。
　さらに、患者状態詳細リスト４０５（図１２参照）では、患者状態詳細No、患者状態詳細状態区分、項目種別区分、ＪＣＳ、ＧＣＳ＿Ｅ、ＧＣＳ＿Ｖ、ＧＣＳ＿Ｍ、最高血圧、最低血圧、呼吸数、脈拍数、体温、ＳｐＯ２、心電図区分、左瞳孔、右瞳孔、左対光反射区分、右対光反射区分、患者Noが対応付けられている。端末側病院状況リスト作成依頼リスト４０６（図１３参照）では、端末側病院状況リスト作成依頼No、端末側病院状況リスト作成依頼状態区分、依頼元、搬送No、依頼元病院No、患者搬送指示Noが対応付けられている。搬送救急隊員リスト４０７（図１４参照）では、搬送救急隊員No、搬送救急隊員状態区分、UserNo、搬送Noが対応付けられている。救急隊処置記録リスト４０８（図１５参照）では、救急隊処置記録No、救急隊処理記録状態区分、処置日時、搬送処置区分、搬送Noが対応付けられている。
　そして、受入要請リスト４０９（図１６参照）では、受入要請No、受入要請状態区分、受入要請方法区分、受入可否区分、病院No、搬送No、患者No、病院側受入可否区分、受入要請拒否理由区分、受入要請拒否理由、受入要請拒否日時、受入要請拒否理由解除予定日時、受入要請受諾日時、受入要請受諾取消理由区分、受入要請受諾取消理由、受入要請受諾取消日時、病院側受入可否回答日時、受入取消日時が対応付けられている。転送受入要請リスト４１０（図１７参照）では、転送受入要請No、病院No、患者No、受入可否区分、受入要請拒否日時、受入要請拒否理由解除予定日時、受入要請拒否理由区分、受入要請拒否理由、受入要請受諾取消理由区分、受入要請受諾取消理由、受入要請受諾取消日時、病院側受入可否区分、病院側受入可否回答日時、転送受入要請状態区分、受入取消日時、患者搬送指示No、依頼元病院Noが対応付けられている。
　さらに、端末側病院状況リスト４１１（図１８参照）では、端末側病院状況リストNo、端末側病院状況リスト状態区分、病院No、心肺停止有無区分、吐血有無区分、下血有無区分、飲酒有無区分、搬送困難有無区分、腹痛有無区分、意識障害有無区分、病院名、病院住所、病院電話番号、診療休止中区分、次回診療開始時刻、端末側病院状況リスト作成依頼No、距離、症状徴候別医療機関選定区分が対応付けられている。搬送先病院リスト４１２（図１９参照）では、搬送先病院リストNo、搬送先病院リスト状態区分、病院No、病院名、病院住所、病院電話番号、端末側病院状況リストNo、搬送先選択区分が対応付けられている。
　そして、受入リスト４１３（図２０参照）では、受入No、病院No、患者No、受入状態区分、患者ベッドＩＤ、患者受入詳細区分、医師No、受入要請No、受入日時、救急診断名、最終診断名、受入患者転帰区分、転帰日時、転送受入要請Noが対応付けられており、更に処理詳細リスト４１４が紐付けられている。そして、この処置詳細リスト４１４（図２１参照）では、処置詳細No、処置詳細状態区分、処理区分、処理開始日時、処理終了予定日時、処置終了日時、受入Noが対応付けられている。
　さらに、病院状況リスト４１５（図２２参照）では、病院状況リストNo、病院状況リスト状態区分、待合室人数、内視鏡使用区分、手術室使用区分、カテ室使用区分、ＩＣＵ使用区分、入院満床区分、設備使用開始日時、設備使用終了予定日時、病院Noが対応付けられている。病院スケジュール管理情報リスト４１６（図２２参照）では、病院スケジュール管理情報No、病院スケジュール管理情報状態区分、診療年度、診療月、病院Noが対応付けられており、更に病院スケジュール詳細情報リスト４１７が紐付けられている。病院スケジュール詳細情報リスト４１７（図２２参照）では、病院スケジュール詳細情報No、病院スケジュール詳細情報状態区分、診療日、診療日種別区分、午前診療区分、午前診療開始時間、午前診療終了時間、午後診療区分、午後診療開始時間、午後診療終了時間、夜間診療区分、夜間診療開始時間、夜間診療終了時間、病院スケジュール管理情報Noが対応付けられている。そして、輪番情報リスト４１８（図２２参照）では、輪番情報No、輪番情報状態区分、開始日時、終了日時、対応診療科、地区、病院Noが対応付けられている。
　以下、図２３のフローチャートを参照して、重症度、緊急度の判定アルゴリズムの一例について詳細に説明する。これらの重症度・緊急度の判定アルゴリズムは医療の進歩や各種の研究結果、あるいは地域性によって異なるため、判断基準は適宜、変更、追加、削除ができるようになっている。この重症度、緊急度の判定は、サーバの重症度判定部３０１ｅにより実施されることになる。００５４?００５８では、現時点でのアルゴリズムに基づいて、判断のプロセスを説明する。
　処理を開始すると、致死性の病態（例：心肺停止状態や重症外傷）であるかどうかを尋ねる画面が現れる（Ｓ５０）、致死性の高い病態が選択されている場合には、各対応病院を搬送先とする（Ｓ５１Ａ～Ｓ５１Ｅ）。即ち、端末での画面選択に応じて、外傷性ＣＰＡ対応（Ｓ５１Ａ）、小児ＣＰＡ対応（Ｓ５１Ｂ）、ＣＰＡ　Ｃ（Ｓ５１Ｃ）、ＣＰＡ　Ｂ（Ｓ５１Ｄ）、外傷Ｃ（５１Ｅ）が搬送先として決定される。ここで、"Ｃ"とは重症であることを意味しており、"Ｂ"は中程度、"Ａ"は軽症であることを意味している。尚、これらの分類は、医療の進歩や各種の研究結果、あるいは地域性によって異なる。
　さらに、地域特性を考慮して、特定の疾患や病態における搬送先が決まっているような場合には、それぞれの対応病院が選択される。本例では、小児疾患である場合には（Ｓ５３Ａ）、小児対応病院を搬送先として決定し（Ｓ５４Ａ）、特殊疾患である場合には（Ｓ５３Ｂ）、特殊疾患対応病院を搬送先として決定し（Ｓ５４Ｂ）、母体搬送の場合には（Ｓ５３Ｃ）、母体搬送対応病院を搬送先として決定し（Ｓ５４Ｃ）、外傷の場合は（Ｓ５５）、その他の病院が搬送先として選定される。
　バイタルサイン、意識レベル、疑い疾患名と患者状態などの入力がなされると（Ｓ５６）、それらの情報に基づいて搬送先を決定する。中でも緊急性が高い状態、即ち、１）意識障害（ＪＣＳ／ＧＣＳ）の有無（Ｓ５７Ａ）、２）ショック（ＳＩが１．５以上）の有無（Ｓ５７Ｂ）、３）バイタル２項目以上の異常（脈拍、呼吸、血圧、体温、ＳＩＲＳ３項目以上）の有無（Ｓ５７Ｃ）があった場合には、各自治体で決められた重症対応が可能な「搬送対応医療機関リスト」に基づいて搬送先候補が提示される
　ここで、１）のみを満たす内因性である場合には（Ｓ５８）、その状態に基づいて、各自治体で決められた搬送対応医療機関リスト」に基づいて搬送先候補が提示される。例えば、現時点でのアルゴリズムでは、意識障害を伴う内因性疾患（Ｓ５９）、瞳孔異常がある場合には（Ｓ６０）、脳卒中Ｃが搬送先として決定され（Ｓ６２）、瞳孔異常がない場合には（Ｓ６１）、意識障害Ｂ対応医療機関が候補として表示される（Ｓ６３）。２）、３）のいずれかを満たす内因性である場合には（Ｓ６４）、バイタルの異常を伴う内因性疾患であるとし（Ｓ６５）、救命センター・Ｃ対応医療機関が候補として表示される（Ｓ６６）。１）～３）のいずれかを満たす外傷の場合には（Ｓ６７）、重症外傷であるとし（Ｓ６８）、上記同様に救命センター・Ｃ対応医療機関が候補として表示される（Ｓ６６）。そして、１）～３）のいずれかを満たさない外傷である場合には（Ｓ６９）、部位別の検討を行い（Ｓ７０）、外傷Ｂ（Ｂ１－Ｂ３）対応医療機関が候補として表示される（Ｓ７１）。
　１）～３）のいずれも満たさない内因性である場合には（Ｓ７２）、ある一定時間内（現在のガイドラインでは３時間以内だが、現在、適応が拡大中のため、変更される可能性もある）に生じた麻痺の場合には血栓溶解療法（tPA：tissue plasminogen activator）の対応となるため、脳卒中Ｃ２（ｔＰＡ）、くも膜下出血（SAH: subarachnoid hemorrhage）を疑う「過去に経験のないような強い頭痛」などの所見がある場合には脳卒中Ｃ１（脳外科緊急手術）に対応できる医療機関が候補として提示される。急性冠症候群（ACS: Acute Coronary Syndrome）疑い症状の場合にはＡＣＳネットワーク対応医療機関が、重症腹症症状の場合には腹痛Ｂ対応医療機関が、重症消化管出血の場合には消化管出血Ｂ対応医療機関が、搬送先候補として。上記のいずれにも該当しない場合、全身状態観察がなされ（Ｓ７４）、不良である場合にはＢ対応（Ｓ７５）、良好である場合にはＡ対応（Ｓ７６）の搬送先の候補が提示され、仮に搬送後に容体が急変して、重症になった場合には、速やかにＳ６２～Ｓ６６の搬送先候補を提示するようになる。
　以下、図２４乃至図３６を参照して、端末における画面遷移の一例を説明する。サーバの表示制御部３０１ｂの制御の下、端末における画面データが生成される。端末により入力された情報は、サーバの情報登録部３０１ｄに登録される。端末に表示されるリストはサーバのリスト作成部３０１ｆにより作成される。
　図２４は出動～現着画面５０１を示している。この画面５０１では、現場から病院までの経路（地図）表示領域と、患者の年齢や性別、出訴、入電、発見状況等の覚知情報の表示領域、症状に関する経過情報の表示領域が表示されており、現着ボタンも設けられている。現着ボタンが押下されると、図２５の初期分岐画面５０２に画面が遷移される。この画面５０２では、左上に緊急性の高い疾患の入力指定領域が、中央に特定疾患の入力指定領域が、右上に部位別症状入力領域が、そして下方にバイタルサイン入力領域が設けられている。バイタルサインとしては、意識状態、血圧、脈拍、呼吸、体温、ＳｐＯ２等が入力可能となっている。但し、これらに限定されないことは勿論である。
　バイタルサイン入力領域の「意識状態」ボタンが押下されると、図２６に示されるような意識状態入力パネル５０３が表示される。このパネル５０３では、ＪＣＳに関する１０項目の中から１つを選択し、不穏、失禁、自発性喪失の中から該当するものを選択し（複数選択可能）、ＧＣＳに関する、Ｅ開眼、Ｖ言葉、Ｍ運動から１つの項目をそれぞれ選び、入力完了ボタンを押下すればよい。
　バイタルサイン入力領域の「血圧」ボタンが押下されると、図２７に示されるような血圧入力パネル５０４が表示される。このパネル５０４では、測定部位を選択し、血圧の数値を入力すればよい。測定不能が押下されるまで、触知がグレー表示される。バイタルサイン入力領域の「脈拍」ボタンが押下されると、図２８に示されるような脈拍入力パネル５０５が表示される。このパネル５０５では、測定部位を選択し、脈拍の数値を入力すればよい。バイタルサイン入力領域の「呼吸数」ボタンが押下されると、図２９に示されるような呼吸入力パネル５０６が表示される。このパネル５０６では、レベル１～３の中から患者の該当する症状を選び選択することになる。この例では、レベル１では「単語のみ会話」、「チアノーゼ」、レベル２では「文節会話」、「吸気性喘鳴」、レベル３では「文章単位会話」、「労作時息切れ」が選択できるようになっている。
　バイタルサイン入力領域の「体温」ボタンが押下されると、図３０に示されるような体温入力パネル５０７が表示される。このパネル５０７では、体温の測定部位を選択し、数値を入力するようになっている。３つの数字を入力すると少数第１位まで表示されるようになっている。この他、測定環境について、低温環境下、高温環境下などの入力もできるようになっている。
　バイタルサイン入力領域の「ＳｐＯ２」ボタンが押下されると、図３１に示されるようなＳｐＯ２入力パネル５０８が表示される。このパネル５０８では、患者のＳｐＯ２（動脈血酸素飽和度）の測定部位と数値（％）を入力するようになっている。
　初期分岐画面５０２において、左上に表示された緊急性の高い疾患の入力指定領域において、内因性成人ＣＰＡ、内因性小児ＣＰＡ、外因性ＣＰＡ、ＤＮＲ対応ＣＰＡのうちの１つが指定されると、図３２に示されるような、ＣＰＡに関する受入可否状況画面５０９に画面が遷移する。この画面５０９では、発生状況（地図）、本日のリスト病院の活動状況、現在の患者の情報が表示されるようになっている。発生状況としては、現場と近隣の病院が地図上に表示される。本日のリスト病院の活動状況では、対応医療機関名と、当該医療機関までの距離、状況、診断名、重傷度、受入状況等が対応付けられて表示される。現在の患者としては、患者の年齢、性別、主訴、覚知、現着時刻等が表示される。このような画面５０９において、中央の「伝達画面」ボタンが押下されると、図３３に示されるような伝達項目パネル５１０が表示される。このパネル５１０では、基本項目として、推定心肺停止時刻、年齢、性別、ＤＮＲ対応の有無が入力され、ＣＰＡ特異的情報として、目撃者の有無、Bystanderの有無、初回心電図、ＡＥＤ、既往歴、かかりつけの医院、パスＩＤ、搬送歴、病名、搬送先、ＥＴＡ等が入力される。
　受入可否状況画面５０９において、本日のリスト病院の活動状況のリストから病院が選択されると、図３４に示されるような受入可否入力画面５１１に画面が遷移する。この画面５１１では、上方に問合せ先の医療機関名、電話番号、当直医の名前が表示され、更に中ほどに電話、背景・搬送元、受入可能、受入困難のボタンが表示される。電話ボタンが押下されると、前述した伝達項目パネル５１０が表示される。背景・搬送元ボタンが押下されると、図３５に示されるような背景・搬送元入力パネル５１２が表示される。このパネル５１２では、背景因子と搬送依頼元が入力できるようになっている。背景因子は複数選択することができ、搬送依頼元はどれか１つを選択する。医療機関等で端末が操作されて、受入困難ボタンが押下されると、図３６に示されるような受入困難事由入力パネル５１３が表示される。このパネル５１３では、受入困難事由を選択することができるようになっている。
　以上説明したように、本発明の実施の形態に係るサーバは、ネットワークを介して携帯端末２００と所定の認証の後に通信自在なサーバ２０１，２０２であって、全体の制御を司る主制御部３０１ａと、上記端末２００における画面表示を制御するよう画面データを生成する表示制御部３０１ｂと、上記端末２００からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部３０１ｃと、情報登録を受け付ける情報登録部３０１ｄと、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部３０１ｆと、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部３０１ｅとを備えたことを特徴とする。
　ここで、重症度判定部３０１ｅは、アルゴリズムで特定された緊急性の高さに基づいて緊急性の高い病態に対応できる医療機関（主に救命救急センター）を搬送先候補とし、緊急性の高さに加え、疑い疾患やその重症度を加味して搬送先候補を選定する。
　さらに、本発明の実施の形態に係る救急医療管制支援システムは、携帯端末２００と、上記携帯端末２００とネットワークを介して通信自在なサーバ２０１，２０２と、統計サーバ２０４と、からなる救急医療管制支援システムであって、上記サーバ２０１，２０２は、全体の制御を司る主制御部３０１ａと、上記端末２００における画面表示を制御するよう画面データを生成する表示制御部３０１ｂと、上記端末２００からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部３０１ｃと、情報登録を受け付ける情報登録部３０１ｄと、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部３０１ｆと、上記登録された情報と各自治体で決められた「傷病者の搬送及び受入れの実施基準等」に基づいて、病態の緊急度と重症度を判定する重症度判定部３０１ｅと、を備え、上記統計サーバ２０４は、取得したタイムスタンプや登録された情報に基づいて所定の医療の質指標（臨床指標）、日報、月報、地図上への表示報告書などを自動的に定期的に作成し、上記サーバ２０１，２０２の上記重症度判定部３０１ｅは、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、特定の病態の対応する搬送医療機関候補リストとして表示することを特徴とする。
　なお、各種指標とは、傷病者の搬送基準の検証や、医療機関の受け入れ基準の評価に関するものであり、基本的なものは予めコンテンツとして実装するが、追加・更新は可能である。
　ここで、上記携帯端末はタッチパネル式端末であってよい。なお、タッチパネル式端末には、タブレット型ＰＣやスマートフォンの如き端末が概念上、含まれることは勿論である。
　携帯端末が病院側のものであれば、診断結果等の各種医療情報を入力画面より入力可能である。ここで、図３７には、病院側の入力画面６００の一例を示す。ここでは、「心・循環」の疾患の入力画面６００を示している。同図に示されるように、病院側では、患者のトリアージ（治療優先順位を決めること）を選択する。この例では「超緊急」、「緊急」、「準緊急」、「低緊急」、「軽症」の中から受入先病院の医師等が選択を行う。受入時に救急隊により緊急として搬送された患者であっても、この選択時に、そのトリアージが見直され、病院側で診察待ちをしている患者群は、この選択されたトリアージに従って診察順が更新される。続いて、検査内容（この例では、心電図等）、診断内容（この例では、ＳＴＥＭＩ（ＳＴ上昇型心筋梗塞）、心不全、不整脈等）、治療・処置内容（ＣＡＧ（選択的冠状動脈造影）、ＰＣＩ等）が入力される。例えば、ＰＣＩとはカテーテルによる冠動脈治療を意味するが、このＰＣＩが選択されると、当該医療機関は、所定時間の間は他の患者の治療には取りかかれないと認識が別の医療機関の関係者に生まれる。その後、転帰情報として例えば「入院」、「帰宅」、「上流転送」、「下流転送」、「死亡」が選択される。例えば、「入院」が選択されると、その手続に所定時間（例えば１時間）は処置などで多忙になるとの認識が外部端末により他の関係者によっても把握される。以上のような入力がなされると、入力情報は医療情報としてデータベースサーバ２０２のＤＢに記録されるだけでなく、複数の医療機関、救急隊、その他関係者によりリアルタイムで当該情報が共有可能となる。この病院側の入力画面としては、この「心・循環」に係る入力画面６００のほかに、「脳・意識」、「消化器」、「外傷」、「ＣＰＡ（心肺停止）」、「その他」に係る各種入力画面を選択することができ、各疾患別に所定の医療情報の選択入力が可能となっている。
　ところで、前述したように、統計サーバ２０４は、取得したタイムスタンプや登録された情報に基づいて所定の医療の質指標（臨床指標）、日報、月報、地図上への表示報告書などを自動的に定期的に作成するが、以下、それらの一例を説明する。
　図３８には、救急患者発生マップの表示画面６０１を示す。図３８では、図示を省略しているが、各市町村（この例では市単位）に区分された各領域は、管轄地域内の応需割合により色分けされている。各領域には、搬送患者の照会回数が星印で示されており、その色により照会回数を把握できるようになっている。さらに、星のプロットされている位置は、患者の発生場所を意味する。この位置は、救急隊の端末のＧＰＳ機能により自動的に特定される。さらに、この救急患者発生マップ上には、医療機関の応需割合が円グラフで示されている。グレースケールは受入可能の割合を、白色は受入不可の割合を示している。円グラフ自体の大きさは、応需、つまり受入に係る電話の多さを反映している。
　図３９には、作成された各医療機関の日報の一例を示す。図３９では、消防本部向け日報としての搬送症例リストが示されている。この図３９に示されるように、搬送症例リストでは、搬送Ｎｏ．、疑い疾患分類、覚知時刻、救急隊名、年齢、性別、搬送時間、照会Ｎｏ．、照会開始時刻、通話時間、照会元、照会先医療機関、リスト内順位、照会順、応需状態、応需×への照会理由、受入可否、困難理由、搬送先医療機関、確定診断名、処置内容、外来転帰が示される。ここで、搬送時間とは、覚知から医師引渡しまでの所要時間（単位：分）を意味している。
　この他、疑い疾患区分別の患者数について、自院に照会のあった患者全てのリストを作成することもできる。これは、昨日の照会件数、受入件数、応需割合、今週の累積（照会件数、受入件数、応需割合）、今月の累積（照会件数、受入件数、応需割合）、今年の累積（照会件数、受入件数、応需割合）を示すものである。
　さらに、各医療機関の月報を作成することもできる。これは、各医療機関別の統計であり、月間統計として自院に照会のあった患者全てのリストを作成することもできる。これは、毎月の統計（先月までの照会件数と受入件数、応需割合）、今月の累積（照会件数と受入件数、応需割合）、今年の累積（照会件数と受入件数、応需割合）を示すものである。
　また、県全体の統計として、全体統計を示すこともできる。報告内容としては、「照会と搬送」に関して、全照会数、全搬送数、応需割合、１回照会、１回照会割合、４回以上の数、４回以上照会割合、全搬送時間（中央値）、全搬送時間（平均値）、３０分以上数、３０分以上照会割合等を示すことができ、「医療機関」に関して、脳卒中治療数、緊急ＣＡＧ件数、緊急手術数、緊急入院数等を示すことができる。この他、疾患別統計として、搬送Ｎｏ．、疑い疾患区分、覚知時刻、救急隊名、年齢、性別、全搬送時間、照会回数、搬送先医療機関、確定診断名、処置内容、外来転帰等を示すことができる。疑い疾患区分としては、内因性ＣＰＡ、外因性ＣＰＡ、小児ＣＰＡ、ＣＰＡその他、重症脳卒中１、重症脳卒中２４、重症脳卒中５、脳卒中２３、脳卒中２３ｔＰＡ、脳卒中５、ＳＡＨ４、他重症意識障害、胸痛、ショック・意識障害を伴う腹痛、バイタル異常を伴う腹痛、重症腹痛、大量吐下血、小児重症（呼吸、痙攣、４０度以上など）、小児軽症、その他重症の内因性、その他軽症の内因性、重症外傷、軽度外傷、重度熱傷、軽度熱傷等がある。
　ここで、本実施形態では、サーバ２０１，２０２が、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部３０１ｅを備えていたが、携帯端末に所定のアプリケーションを実装すれば、携帯端末２００側で重症度判定を行うこともできる。
　即ち、図４０には、そのような携帯端末２００の詳細な構成を示す。同図に示されるように、携帯端末２００は、制御部２５１と通信制御部２５２、記憶部２５３、入力部２５４、表示部２５５を備えている。制御部２５１は、制御プログラムを実行することで、主制御部２５１ａ、表示制御部２５１ｂ、重症度判定部２５１ｃとして機能する。主制御部２５１ａは、全体の制御を司る。表示制御部２５１ｂは、表示を制御する。重症度判定部２５１ｃは、登録された情報や各種指標に基づいて患者の重症度を算出する。例えば、救急隊により、図２５に示したような画面５０２で、意識状態や血圧、脈拍、呼吸、体温、ＳｐＯ２等が入力されると、重症度判定部２０１ｅは、当該入力情報に基づいて、病態の緊急度等を判定し画面表示することができる。
　以上、本発明の一実施形態について説明したが、本発明はこれに限定されることなく、その主旨を逸脱しない範囲で種々の改良・変更が可能であることは勿論である。例えば、現場や搬送中の観察所見に係る写真や動画を画面表示したり、音声を出力するようにしてもよいことは勿論である。
　１０１ａ，１０２，１０３ａ　情報端末
　１０１ｂ，１０３ｂ，１０４，１０５ａ～１０５ｃ　タッチパネル式端末
　１０６　インターネット網
　２００　携帯端末
　２０１　ｗｗｗサーバ
　２０２　データベースサーバ
　２０３　データ
　２０４　統計サーバ
　３００　サーバ
　３０１　制御部
　３０１ａ　主制御部
　３０１ｂ　表示制御部
　３０１ｃ　タイムスタンプ取得部
　３０１ｄ　情報登録部
　３０１ｅ　重傷度判定部
　３０１ｆ　リスト作成部
　３０１ｇ　指標作成部
　３０２　通信制御部
　３０３　記憶部

Claims (7)

  1. 　ネットワークを介して携帯端末と所定の認証の後に通信自在なサーバであって、
    　全体の制御を司る主制御部と、
    　上記端末における画面表示を制御するよう画面データを生成する表示制御部と、
    　上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、
    　情報登録を受け付ける情報登録部と、
    　上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、
    　少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備えたこと
    を特徴とするサーバ。
  2. 　上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御すること
    を特徴とする請求項１に記載のサーバ。
  3. 　携帯端末と、
    　上記携帯端末とネットワークを介して通信自在な連携サーバと、
    　統計サーバと、
    からなる救急医療管制支援システムであって、
    　上記連携サーバは、
    　全体の制御を司る主制御部と、
    　上記端末における画面表示を制御するよう画面データを生成する表示制御部と、
    　上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、
    　情報登録を受け付ける情報登録部と、
    　上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、
    　上記登録された情報と各自治体で決められた所定の基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備え、
    　上記統計サーバは、取得したタイムスタンプや登録された情報に基づいて所定の報告書を自動的且つ定期的に作成し、
    　上記連携サーバの上記重症度判定部により、緊急性および重症度と各自治体で決められた搬送対応医療機関リストとに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御すること
    を特徴とする救急医療管制支援システム。
  4. 　上記携帯端末はタッチパネル式端末であること
    を特徴とする請求項３に記載の救急医療管制支援システム。
  5. 　上記各自治体で決められた所定の基準には、傷病者の搬送及び受入れの実施基準を含むこと
    を特徴とする請求項３に記載の救急医療管制支援システム。
  6. 　上記所定の報告書とは、医療の質指標、日報、月報、地図上への表示の少なくともいずれかに係る報告書を含むこと
    を特徴とする請求項３に記載の救急医療管制支援システム。
  7. 　ネットワークを介してサーバと所定の認証の後に通信自在な携帯端末あって、
    　全体の制御を司る主制御部と、
    　上記通信を行う通信制御部と、
    　画面データに基づく表示制御を行う表示制御部と、
    　出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントの入力を受け付ける入力部と、
    　少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、
    　表示を行う表示部と、を備え、
    　上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして上記表示部に表示するよう制御すること
    を特徴とする携帯端末。
PCT/JP2011/006758 2011-01-21 2011-12-02 救急医療管制支援システム及びサーバ並びに携帯端末 WO2012098613A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/980,877 US20140025394A1 (en) 2011-01-21 2011-12-02 System for assisting control of rescuing medical services, server, and mobile device
JP2012553478A JP6052875B2 (ja) 2011-01-21 2011-12-02 救急医療管制支援システム及びサーバ並びに携帯端末

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011-011319 2011-01-21
JP2011011319 2011-01-21

Publications (1)

Publication Number Publication Date
WO2012098613A1 true WO2012098613A1 (ja) 2012-07-26

Family

ID=46515267

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/006758 WO2012098613A1 (ja) 2011-01-21 2011-12-02 救急医療管制支援システム及びサーバ並びに携帯端末

Country Status (3)

Country Link
US (1) US20140025394A1 (ja)
JP (1) JP6052875B2 (ja)
WO (1) WO2012098613A1 (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014215640A (ja) * 2013-04-22 2014-11-17 株式会社エヌ・ティ・ティ・データ トリアージシステム、サーバ装置、端末装置およびプログラム
JP2016194764A (ja) * 2015-03-31 2016-11-17 株式会社エヌ・ティ・ティ・データ 傷病者受入状況情報表示装置および傷病者受入状況情報表示システム
JP2016224570A (ja) * 2015-05-27 2016-12-28 日本電気株式会社 救急搬送支援システム、サーバ、方法及びプログラム
JP2016224571A (ja) * 2015-05-27 2016-12-28 日本電気株式会社 予後調査支援システム、サーバ、予後調査支援方法及びプログラム
JP2018077751A (ja) * 2016-11-11 2018-05-17 株式会社ビットエイジ トリアージ支援プログラム及びトリアージ支援システム
JP2018165898A (ja) * 2017-03-28 2018-10-25 日本電気株式会社 救急搬送支援装置、救急搬送支援方法及びプログラム
JP2019021179A (ja) * 2017-07-20 2019-02-07 国立大学法人千葉大学 救急出動支援システム
CN110573104A (zh) * 2017-04-27 2019-12-13 法拉普尔赛股份有限公司 用于信号产生的系统、装置和方法
JP2020197887A (ja) * 2019-06-03 2020-12-10 有限会社クレドシステム 情報処理装置、情報処理方法およびプログラム
JP2021093228A (ja) * 2017-07-20 2021-06-17 株式会社Ｓｍａｒｔ１１９ 救急出動支援システム
JP2022171873A (ja) * 2021-03-22 2022-11-11 株式会社Smart119 救急出動支援システム
CN115512820A (zh) * 2022-10-12 2022-12-23 心智医联(北京)科技有限公司 一种云智医智慧医疗平台

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140100861A1 (en) * 2012-10-09 2014-04-10 David Gerard Ledet Medical analysis application and response system
US20140129255A1 (en) * 2012-11-02 2014-05-08 James Thomas Woodson Medical Information and Scheduling Communication
US11985075B1 (en) * 2013-02-04 2024-05-14 C/Hca, Inc. Data stream processing for dynamic resource scheduling
US9607502B1 (en) * 2014-01-28 2017-03-28 Swiftreach Networks, Inc. Real-time incident control and site management
TWI514309B (zh) * 2014-09-23 2015-12-21 Viewlead Technology Company 救護系統與救護方法
CN104376409A (zh) * 2014-11-07 2015-02-25 深圳市前海安测信息技术有限公司 一种基于网络医院的分诊数据处理方法及系统
US20170228511A1 (en) 2016-02-05 2017-08-10 Novum Patent Holdco, LLC Medical Registration System
CN109428894A (zh) * 2017-06-20 2019-03-05 深圳市小氪科技有限公司 一种云救援系统
KR101960460B1 (ko) * 2017-12-06 2019-03-20 주식회사 시큐웨어 하이브리드 트리아지 태그를 이용한 재해 관리 시스템
KR101959375B1 (ko) * 2018-09-28 2019-03-18 부산대학교 산학협력단 구호소를 선택하여 선택된 구호소에 환자들을 할당하는 방법
US11908553B2 (en) * 2019-02-11 2024-02-20 Rapidsos, Inc. Apparatus and method for emergency response data acquisition and retrieval
EP3734485A1 (en) * 2019-04-30 2020-11-04 Koninklijke Philips N.V. Access to health information during emergency call
US11854676B2 (en) * 2019-09-12 2023-12-26 International Business Machines Corporation Providing live first aid response guidance using a machine learning based cognitive aid planner
CN111444300B (zh) * 2020-04-07 2022-09-02 南方科技大学 应急救助站的布局方法、装置、服务器及存储介质
EP4305638A1 (en) * 2021-03-11 2024-01-17 Zoll Medical Corporation Resuscitative care system for context sensitive guidance
CN114334101A (zh) * 2021-09-28 2022-04-12 中国人民解放军总医院第三医学中心 以预案体系为支撑的大型体育赛事突发事件应急医疗救援指挥调度系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1133001A (ja) * 1997-07-18 1999-02-09 Fujitsu General Ltd 救急医療システム
JP2005196510A (ja) * 2004-01-08 2005-07-21 Hitachi Ltd 医療機関検索システム
JP2005218851A (ja) * 2004-01-06 2005-08-18 Toshiba Corp 通信装置、ヘルスケア支援システムおよびヘルスケア支援装置
JP2009187167A (ja) * 2008-02-05 2009-08-20 Nec Corp 救急医療システム及びそれに用いる装置と救急医療用プログラム
JP2010277383A (ja) * 2009-05-29 2010-12-09 Techmatrix Corp 救急患者受入先探索システム、救急端末、医療施設端末、受入先探索サーバ及び救急患者受入先探索方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7539623B1 (en) * 2000-04-06 2009-05-26 Medical Central Online Method and a system for providing bed availability information on a computer network
US6786406B1 (en) * 2003-03-28 2004-09-07 Peter A. Maningas Medical pathways rapid triage system
US7520419B2 (en) * 2005-12-21 2009-04-21 Bml Medrecordsalert Llc Method for transmitting medical information identified by a unique identifier
US20090198733A1 (en) * 2008-02-01 2009-08-06 Microsoft Corporation Healthcare resource locator
US20110054946A1 (en) * 2009-08-31 2011-03-03 Disruptive Ip, Inc. System and Method of Patient Flow and Treatment Management
US8521125B2 (en) * 2011-05-20 2013-08-27 Motorola Solutions, Inc. Electronic communication systems and methods for real-time location and information coordination

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1133001A (ja) * 1997-07-18 1999-02-09 Fujitsu General Ltd 救急医療システム
JP2005218851A (ja) * 2004-01-06 2005-08-18 Toshiba Corp 通信装置、ヘルスケア支援システムおよびヘルスケア支援装置
JP2005196510A (ja) * 2004-01-08 2005-07-21 Hitachi Ltd 医療機関検索システム
JP2009187167A (ja) * 2008-02-05 2009-08-20 Nec Corp 救急医療システム及びそれに用いる装置と救急医療用プログラム
JP2010277383A (ja) * 2009-05-29 2010-12-09 Techmatrix Corp 救急患者受入先探索システム、救急端末、医療施設端末、受入先探索サーバ及び救急患者受入先探索方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
AKIHITO SONODA: "Experiment of Large Scale Triage with RFID Tags", TRANSACTIONS OF INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 48, no. 2, 15 February 2007 (2007-02-15), pages 802 - 810 *
KOMEI TANAKA: "Kyukyusha to Byoin o Real Time ni Tsunagi, Kyumeiritsu no Kojo o Jitsugen Mobile Telemedicine System", NTT GIJUTSU JOURNAL, vol. 21, no. 12, 1 December 2009 (2009-12-01), pages 53 - 56 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014215640A (ja) * 2013-04-22 2014-11-17 株式会社エヌ・ティ・ティ・データ トリアージシステム、サーバ装置、端末装置およびプログラム
JP2016194764A (ja) * 2015-03-31 2016-11-17 株式会社エヌ・ティ・ティ・データ 傷病者受入状況情報表示装置および傷病者受入状況情報表示システム
JP2016224570A (ja) * 2015-05-27 2016-12-28 日本電気株式会社 救急搬送支援システム、サーバ、方法及びプログラム
JP2016224571A (ja) * 2015-05-27 2016-12-28 日本電気株式会社 予後調査支援システム、サーバ、予後調査支援方法及びプログラム
JP2018077751A (ja) * 2016-11-11 2018-05-17 株式会社ビットエイジ トリアージ支援プログラム及びトリアージ支援システム
JP2018165898A (ja) * 2017-03-28 2018-10-25 日本電気株式会社 救急搬送支援装置、救急搬送支援方法及びプログラム
CN110573104B (zh) * 2017-04-27 2024-02-06 波士顿科学医学有限公司 用于信号产生的系统、装置和方法
CN110573104A (zh) * 2017-04-27 2019-12-13 法拉普尔赛股份有限公司 用于信号产生的系统、装置和方法
JP2019021179A (ja) * 2017-07-20 2019-02-07 国立大学法人千葉大学 救急出動支援システム
JP2021093228A (ja) * 2017-07-20 2021-06-17 株式会社Ｓｍａｒｔ１１９ 救急出動支援システム
JP7503313B2 (ja) 2017-07-20 2024-06-20 株式会社Smart119 救急出動支援システム
JP2020197887A (ja) * 2019-06-03 2020-12-10 有限会社クレドシステム 情報処理装置、情報処理方法およびプログラム
JP2022171873A (ja) * 2021-03-22 2022-11-11 株式会社Smart119 救急出動支援システム
CN115512820A (zh) * 2022-10-12 2022-12-23 心智医联(北京)科技有限公司 一种云智医智慧医疗平台

Also Published As

Publication number Publication date
JP6052875B2 (ja) 2016-12-27
US20140025394A1 (en) 2014-01-23
JPWO2012098613A1 (ja) 2014-06-09

Similar Documents

Publication Publication Date Title
JP6052875B2 (ja) 救急医療管制支援システム及びサーバ並びに携帯端末
Bowles et al. Surviving COVID-19 after hospital discharge: symptom, functional, and adverse outcomes of home health recipients
Etkind et al. The role and response of palliative care and hospice services in epidemics and pandemics: a rapid review to inform practice during the COVID-19 pandemic
Behar et al. Remote health diagnosis and monitoring in the time of COVID-19
Bervell et al. A comparative review of mobile health and electronic health utilization in sub-Saharan African countries
US10489554B2 (en) Computer assisted patient navigation and information systems and methods
US20090259493A1 (en) Mobile health book
Kang et al. Operating protocols of a community treatment center for isolation of patients with coronavirus disease, South Korea
US20140249850A1 (en) Critical condition module
Barbour et al. Telehealth for patients with Parkinson’s disease: delivering efficient and sustainable long-term care
Moore et al. Event detection: a clinical notification service on a health information exchange platform
Kadarina et al. Preliminary design of Internet of Things (IoT) application for supporting mother and child health program in Indonesia
Hanfling et al. A framework for catastrophic disaster response
Davies et al. Parental presence during treatment of Ebola or other highly consequential infection
Khan et al. The use of telemedicine in Bangladesh during COVID-19 pandemic
Grattagliano et al. The changing face of family medicine in the COVID and post‐COVID era
JP2023062174A (ja) 改善された医療相互運用環境システム
Zhang et al. User needs and challenges in information sharing between pre-hospital and hospital emergency care providers
Margolius et al. On the front (phone) lines: results of a COVID-19 hotline in Northeast Ohio
JP7442371B2 (ja) 患者情報管理装置、患者情報管理方法、及び患者情報管理プログラム
JP2014081751A (ja) 救急医療管制支援システム及びサーバ並びに携帯端末
Correa et al. Folding a neuroscience center into streamlined COVID-19 response teams: lessons in origami
Haranath et al. Tele-intensive care unit networks: A viable means for augmenting critical care capacity in India for the COVID pandemic and beyond
Paramonov et al. Communication between emergency medical system equipped with panic buttons and hospital information systems: use case and interfaces
Mussetti et al. COVID19 in hematological patients and telemedicine: lessons learned across Europe and the US

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11855981

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2012553478

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13980877

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 11855981

Country of ref document: EP

Kind code of ref document: A1