JP2001236421A - Communication management method and device for medical facility - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technology, which manages data exchange among medical diagnostic equipment and systems 24 to 38 and a remote service or a data provider 14. SOLUTION: A data communication control system 40 comprises a data processing circuit 86 and interfaces 52, 44 and 90 for internal networks 20 and 22 of a medical institution 12 and an external network 50. Data are exchanged in the institution between the control system and network-connected diagnostic device via the internal networks 20 and 22. The data are sent and received by the control system 40, which communicates with the remove service provider 14. The control system is able to implement a server function and a router function, and also store data from the diagnostic system and service provider.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention relates generally to the field of medical diagnostic institutions and systems, and to the management of data exchange between such institutions and systems and external service providers.

[0002]

BACKGROUND OF THE INVENTION Medical institutions and facilities offer an ever-increasing range of services and procedures to meet the needs of their patients and staff. Hospitals, clinics, and other healthcare facilities may include simple single-office clinics or large integrated facilities consisting of a wide range of collaborative departments and facilities. In addition, smaller clinics may be partially or completely located in a single location, or may be integrated with larger institutions that are geographically dispersed. In all these cases, information technology is becoming an important component of the exchange of data and services needed to fulfill the mission of the facility.

For example, in a typical clinic or hospital, the radiology department may use a magnetic resonance imaging (MRI) system,
There can be various types of imaging systems, including computed tomography (CT) systems, ultrasound systems, X-ray systems, and the like. Some of these systems are fixed systems, while others can move around the facility as needed. A Radiology Information System (RIS) can be interconnected between these various imaging systems to coordinate the operation of those systems and to facilitate review of images by radiologists and diagnostic physicians. In certain institutions, the various devices described above may be interconnected in a network, usually a local area network (LAN) architecture.

[0004] In addition to radiation equipment, various other equipment in a medical facility can be monitored or networked at the department or institutional level. For example,
Patient monitoring provides some network connectivity so that the patient can be tracked and its physiological status monitored remotely. Patient records, accounting records, etc. can also be related in different individual systems, with certain information being cross-referenced within the Hospital Information System (HIS).

While certain devices within a hospital or other medical institution can be designed to function completely independently of other devices or service providers, many individual systems or subsystems are currently external components. Designed to communicate interactively with. For example, in the field of diagnostic imaging, individual systems currently include a modem for transmitting and receiving image data, service information, reports, and the like. In some cases, operations personnel can log on to a network such as the Internet or a virtual private network to send and receive data directly from the imaging system. Other devices within the institution also provide data communication capabilities, either individually or via departmental workstations or similar interfaces.

[0006]

While individual networks within a healthcare facility can function for most purposes,
These networks have certain issues at the level of data coordination and delivery, which can overburden the institutional infrastructure. For example, depending on the type of connection provided, the medical diagnostic imaging system may each require a separate communication line to ensure connectivity, as appropriate. In a typical configuration, these communication lines are conventional telephone cables that require installation and maintenance for individual systems, even when the systems are not logged on to the network and are not transmitting data. Separate accounting is required when data is sent to or received from individual devices or individual LANs of the institution, and the interface components route data separately to each system or device connected to the LAN. There must be. further,
This procedure may require a separate connection procedure over a leased line, adding to the cost of the entire system and infrastructure and adding considerable time and additional steps to the data exchange process .

[0007] Therefore, there is a need for improved techniques for exchanging data between medical diagnostic facilities and external resources. Also, some devices or equipment, both within individual departments and at the institution level, to route data efficiently within the institution and between the institution and external resources such as service providers, equipment maintenance providers, etc. There is a particular need for a system that provides a single point of contact for a LAN.

[0008]

SUMMARY OF THE INVENTION The present invention provides a data exchange technique designed to meet these needs.
This technique can be used with both newly designed information systems or can be retrofitted to upgrade the institution's existing infrastructure. This technique provides a data communication controller that can interconnect to a wide range of internal networks and systems within the institution and can route incoming and outgoing data between these configuration requests and external resources. The controller can be coupled to various types of media for transmitting and receiving data, including conventional open or dedicated networks, virtual private networks, and the like. Physical media for transmitting data include telephone lines, cables, satellite links, and the like. Depending on the protocol implemented by the control unit, large amounts of data can be exchanged simultaneously. The system can be integrated with various tracking and workflow management systems of the institution to further facilitate data interchange. as a result,
Accounting functions, tracking functions, monitoring functions, scheduling functions, etc. can be integrated via the control system.

[0009]

BRIEF DESCRIPTION OF THE DRAWINGS FIG. Referring first to FIG. 1, a data communication system for transmitting operational data or parameters from a series of medical diagnostic systems to a remote service or data provider is generally designated by reference numeral 1.
Indicated by 0. The system also allows the system to communicate with remote services as detailed below.
Enables interactive exchange of data, service requests, software, etc. with providers. As shown in FIG. 1, system 10 generally includes a medical diagnostic facility 12 coupled to a remote service or data provider 14.
including. Facility 12 may include a single location or location 16, or an additional location 18 that is geographically close to or remote from location 16. In that case, the additional locations can generally be interconnected with locations 16 via a facility network.

In the facility 12, an internal network 20
Is a mechanism for data communication between a series of medical diagnostic systems provided within groups or departments 22 as desired, such as floors, wards, special treatment or diagnostic areas, etc. A series of medical diagnostic systems, commonly referred to herein as clients 24, are coupled to network 20 via a permanent or temporary network connection. Therefore, the client 24
While some or most are fixed, some clients are mobile, allowing clients or assets to be leveraged where desired and coupled to the internal network once located. Can be.

The term medical diagnostic system as used herein should be understood to include various devices, systems and subsystems. For example, a medical diagnostic system may include a diagnostic imaging system designed to generate a useful image of a patient's anatomy according to a particular physical phenomenon or modality. Other medical diagnostic systems can include patient monitors, sensors, transducers, and other signal generation or feedback devices.
Further, a medical diagnostic system that communicates in accordance with the techniques of the present invention can include an information management system, a workstation, an image and data display station, and the like.

For example, in FIG. 1, a series of medical diagnostic imaging systems are shown in one group. In fact, this group is physically or logically related to the radiation department or clinic. In the embodiment shown in FIG. 1, these systems include a magnetic resonance imaging (MRI) system 26, a computed tomography (CT) system 28, an X-ray system 30,
And an ultrasound system 32. All of these systems preferably include a client diagnostic system of the present technique. As will be apparent to those skilled in the art, each of these imaging systems is configured to generate useful image data based on the particular physical phenomena of the respective modality. As mentioned above, certain of these systems can be moved to a desired room or examination area, such as an ultrasound system, and connected to the network 20 in that area or back to a base station.

For example, in the embodiment of FIG. 1, the client diagnostic system also includes a series of data management stations. As indicated by reference numeral 34, in this case, the client includes a radiology department information system (RIS) designed to manage the generation and flow of image data in connection with imaging systems 26, 28, 30, and 32. be able to. The hospital information system (HIS) 36 provides additional data, patient, financial, and other support for the operation of the facility 12 according to commonly known techniques. Finally,
Image Acquisition and Communication Analysis System (PACS) 38 stores data files generated by the diagnostic imaging system;
Prepare for processing, access and storage.

Each of the client diagnostic systems is coupled to a network 20 that exchanges data with the following remote services or data providers. With previously known data exchange techniques, certain client systems have the ability to independently exchange operational or parameter data needed for operational, maintenance, analysis, accounting, or other needs. . According to such a technique, an independent connection can be established between the asset and the remote service provider, such as through a separate modem connection as shown by the ultrasound system 32 of FIG. Although certain systems can maintain such a direct connection in accordance with the techniques of the present invention, the client diagnostic system need not have such separate connectivity capabilities. Instead, data can be exchanged between the system and a remote service or data provider via network 20.

In a preferred embodiment of the present invention, network 20 includes a high-speed internal network, such as an Ethernet network. In this embodiment,
The network exchanges data according to a standard data exchange protocol such as TCP / IP.
It is a 0 Mb network. Of course, other internal network architectures and standards can also be used.

The communication system receives or accesses data from a client and exchanges data with one or more remote services or data providers. The data communication control system (D) is coupled to a network 20.
CCS) 40. Therefore, DCCS40
Is coupled to external communication circuits such as modem 42 and satellite decoder 44. Modem 42 and any additional modems desired may be a 56 kb / s modem according to the techniques of the present invention,
Any suitable type, such as a cable modem, or any suitable external network communication interface. Similarly, the decoder 44 is also a US Scientific.
Any suitable satellite or wireless interface, such as an Atlanta type IRD. By using a parallel medium to send and receive data, as will be described in more detail below, the DCCS 40 can optimize the use of available bandwidth in exchanging data between the facility and the remote service provider. . For example, the modem 42 is 56 kb /
s, while the decoder 44 provides a much wider bandwidth, eg, 500 kb / s.

Data communication with the facility 12 is performed by the modem 4
External network link 46 routed to 2
And satellite link 48 routed to decoder 44
Provided by External network link 46
Is coupled to a network 50, such as a wide area network, via conventional telephone cables, optical cables, or the like, or otherwise. However, network 50 is any suitable type of network, including a virtual private network or the Internet.
Separation and protection of the integrity of the information system of the facility 12 is ensured by one or more firewalls 52.
A satellite link 48, which typically forms part of an external network used for data communication with the facility, receives data relayed via satellites 54 via terrestrial-based repeaters, transmitters, etc. Work.

Data from the facility 12 is exchanged with the service provider 14 via the external network connection described above. In general, the remote service provider 14 can include a primary location 56 and additional locations 58 that are open or interconnected via a dedicated network. For example, the remote service provider 14 may include one or more facilities that receive data and service requests from medical diagnostic facilities on a subscription or contract basis. Services, data, training, technical assistance, and other information can then be provided to the subscribing facility over a network connection according to the techniques described below. In the example shown, the remote service provider 14 is an Ethernet service provider.
Includes dedicated internal networks, such as base local area networks.

A series of clients or systems that exchange data internally and with the medical diagnostic facility are interconnected via a network. For example, service requests, protocol requests, generally indicated by reference numeral 62,
A service system is provided for receiving and processing service data such as questions. The service system 62 also has the ability to schedule regular or special service calls that provide reporting and analysis such as operational or parameter data. In the illustrated example, remote service provider 14 also includes an automated support center, generally designated by reference numeral 64. The center can perform various automated functions, including the acquisition or collection of operational parameters and data from the facility, as described below. In general, many or all of the functions performed by the ASC can be fully automated, with little or no need for operator intervention. ASC
The data collected according to the routines performed by is stored and available on demand. Remote service
Provider 14 may respond to a request from a medical diagnostic facility,
Various e-commerce systems 66 designed to provide data, receive instructions, process instructions, and perform accounting and financial transactions may also be included. An education unit or system 68 that provides an education or training program and provides manuals or documents and the like may also be provided.

While certain remote service provider systems can be designed to couple directly with one or more medical diagnostic facilities or systems, in the illustrated example, those systems are connected to an internal network 60 and a communication interface. 70 to communicate with the diagnostic system. Communication interface 70 typically includes a data router and other devices that appropriately direct data received from the medical diagnostic facility to one or more internal systems of the remote service provider and direct communications from these systems to the medical diagnostic facility. Hardware and software. Interface 70 communicates data via a satellite transmitter 74 via one or more modems 72. If desired, a network or satellite link, such as a transmitter 76 provided in the education unit 68, may further be provided in the particular system of the remote service provider. Each of the communication devices has a modem 7
2 and a satellite link 80 and 82 for transmitters 74 and 76, respectively.
To a data link that contains Preferably, data link 78 protects network integrity and remote service provider 14 data via one or more firewalls 84 or similar protection devices.

According to the system topology shown in FIG.
Data can be exchanged interactively between the medical facility and the remote service provider. As described below, data can be exchanged via the DCCS 40 upon activation of a medical diagnostic facility or a system within the facility. Alternatively, responding to data or service requests, accessing or obtaining data from the diagnostic system via the DCCS, and providing various services via external network links, including teaching materials, training sessions, etc. Communication can be initiated by the remote service provider.

FIG. 2 shows an exemplary configuration of the DCCS 40 including associated peripherals and software suite. In the illustrated embodiment, DCCS 40 includes a central processing unit (CPU) 86 that includes a commercially available microprocessor in a general purpose or special purpose computer. A CPU is coupled to various hardware and functional circuits that perform the functions described herein. For example, as shown in FIG. 2, the CPU is coupled to a communication interface 88 for transmitting and receiving data via an external network as described above, and also for transmitting and receiving data to and from a diagnostic system via an internal network. . In this manner, communication interface 88 may coordinate communications via one or more modems 42 coupled to data link 46. The satellite decoder 44 also receives D via satellite link 48
Redirect data via CCS. An additional network interface 90, such as an Ethernet interface, allows for the exchange of data over the facility's internal network 20.

In addition to the above communication components, DCCS4
0 includes the memory circuit 92 and additional supporting components.
Memory circuit 92 may include any suitable memory, such as a disk drive, random access memory, read only memory, dynamic random access memory, optical storage, and the like. The memory circuit 92 is a DCC
S, both software routines, data collected by the DCCS for transmission to the remote service provider, and data received from the remote service provider for distribution to the facility's designated or targeted diagnostic system. Store the data. A backup system 94 is preferably provided that periodically creates archived versions of selected files, routines, collected data, etc. One or more peripheral interfaces, generally indicated by reference numeral 96, are provided for receiving input signals from the operator interface and displaying and outputting data as appropriate. In the illustrated embodiment, such a peripheral device is a computer monitor 9 as an output device.
8 and the printer 100. Input peripherals may include a conventional keyboard 102, mouse 104, and any other suitable input peripheral.

Although certain software applications and utilities can be stored and executed on various clients in the facility, especially in the imaging system, RI
The S, HIS and PACS, DCCS 40 preferably execute the various applications independently and perform the data communication functions assigned to them. These applications, generally indicated by reference numeral 106 in FIG. 2, are preferably stored in the memory circuit 92, and
6 is performed. Alternatively, certain applications may reside elsewhere and may be fully or partially executed by other data processing circuits. Applications 106 generally include various commercially available application routines, and may also include customized routines that are executed by the CPU. Thus, the software suite 108 can be used to be executed by the CPU together on a regular schedule or automatically in response to operator prompts or prompts from remote service providers.

The application routine, generally designated 110 in FIG. 2, collects data from the diagnostic system, stores such data, and provides remote service services.
Software that sends the data to the provider and routes the data to the system specified by the service provider can be included. In the embodiment shown in FIG. 2, software suite 108 includes database software that associates collected data from the diagnostic system in a relational manner. Such data preferably includes identification of the system, location of the system, usage data and various operational parameters and various parameter data useful in determining the potential needs of the service. As will be apparent to those skilled in the art, diagnostic imaging systems store various operational or parameter data directly into individual diagnostic systems to provide a very useful indication of system performance and potential future service needs. It can be carried out.

The software suite 108 preferably includes Mi from Redmond, Washington, USA.
Windows by Microsoft Corporation
ows NT server software and web server
Includes server software such as software. The server software allows the DCCS to function as a server for both internal and external clients or users. Browser software is also preferably included with which the operator can log on via the DCCS operator interface device, for example to a site on the Internet, request information and data, send service and data requests, etc. Can be. In a preferred embodiment, the browser software is operable to directly and interactively interface with one or more diagnostic systems, particularly diagnostic imaging systems, on the DCCS. The routing software also serves to appropriately transmit the data packets received from the remote service provider over the DCCS to a designated diagnostic system within the facility via the internal network.

Additional applications of the software routines also include diagnostic and service routines and interactive service routines, preferably DC
Included in CS. These routines include an interactive service platform and allow for the generation of service requests, preferably via a web browser interface for immediate or delayed transmission to a remote service provider. These applications also preferably allow for interactive reception of reports and service data returned from the remote service provider. Reports can be generated by the reporting software on the DCCS, in particular reports on communication activities recorded as described below. The security routine preferably checks the integrity of data transmitted and received via the DCCS, and provides access to the internal network from external users, including remote service providers, and remote web access from clients coupled to the internal network. Can be run as part of a suite of software to restrict both access to sites or providers.

[0028] An asset management application is also preferably run on the DCCS, preferably with RIS and HI.
Various business, financial and administrative functions can be performed in harmony with similar functions performed by S. For example, in the illustrated embodiment, transactions and accounting routines are performed to account for remote services used by the facility, the fees associated with such services, and similar accounting for any e-commerce transactions performed. Etc. can be maintained. Asset tracking routines are specific to a particular client or asset,
In particular, the location and availability of mobile clients that can be tracked through an internal network to a specific location can be analyzed.

The components of the software suite shown in FIG. 2 may include various commercially available application software packages, or software specifically created for the facility or application. However, in general, those skilled in the art will be able to develop any application-specific software immediately without undue experimentation. In a preferred embodiment of the present invention, a commercially available software application included in the system and executed by the DCCS is California, USA
Oracle Co, Redwood City, IA
database software,
North Va, British Columbia
ncouver's Eloquen Systems,
Inc. Multimedia software from Cali
Netsc, MountainView, Fornia
Netsc from ape Communications
Web server software, such as ape Enterprise software, and Washingto
Microsoft Corpo, Redmond n
ration or Netscape Commun
Includes browser software, such as software from Ications.

FIG. 3 shows the general flow of data within the overall system topology shown in FIG. As shown in FIG. 3, bi-directional data flow is provided between the DCCS 40 and the various clients 24 and other networked systems such as RIS 34, HIS 36, PACS 38. As noted above, client 24 preferably includes a medical diagnostic imaging system coupled to a remote service provider via the DCCS for interactive data and service needs. The DCCS 40 also sends and receives data to and from the memory circuit 92, which includes databases at locations near the DCCS in FIG. 3 and at various networked nodes of the facility.

Within the remote service provider 14, data is transferred between the interface 70 and various systems and subsystems, such as the service system 62, ACS 64, e-commerce system 66, education unit or system 68 as described above. Can be replaced. Each of these systems is provided by an application technician via a service system 62 to a diagnostic system.
Other networked systems or stations, such as workstations 112, that allow data to be accessed and targeted to particular service needs and requests, etc., may be included. One or more databases 114 and 116 are preferably coupled to the remote service provider's system so that parameters and operational data can be stored relationally and retrieved as appropriate for analysis, reporting, invoice delivery, etc. To The components of the remote service provider, including the system shown in FIG. 3, may be located locally or through a variety of network configurations, including configurations in which one or more systems and databases may be geographically separated from one another. Note that data can be exchanged between

Data exchanged internally within medical diagnostic facilities and remote service providers is then exchanged via external network links between these facilities. In the illustrated embodiment, these network links are satellite links 48 and 80 that route data via satellite 54 or terrestrial-based circuitry, and wide area areas defined by links 46 and 78.
A network and a network 50 are included.

The data communication techniques and components described above allow for access to and exchange of data according to various routines. The logical steps of certain of these routines are shown in FIGS.

Referring to FIG. 4, a first routine assembles service and data requests for transmission to a remote service provider at a diagnostic facility. The service request routine, generally indicated by the reference numeral 200, begins at step 202, where a facility client generates a data request. In the present invention, such data requests include a wide range of services, data, software and similar requests. In particular, in the case of a medical diagnostic imaging system, these requests may include a description of the particular problem that arises in the system, a request for an imaging protocol for software, an operational query, and the like. However, similar requests, such as in-house training services for multimedia training materials and the like that can be transmitted via the DCCS, as described below, can also be generated within the networked client. Note that data requests can be assembled in a diagnostic system that includes software running locally for the assembly of the request, or through an application running on the DCCS and accessible through the diagnostic system. I want to be. At step 204, these requests are sent to the DCCS. At step 206, the request is screened and any license checks may be performed, such as determining whether the requesting diagnostic system is licensed for the current type of request.

As shown in step 208 of FIG. 4, a service or data request can be generated directly at DCCS 40. Such a request can be assembled via the DCCS operator interface component, preferably via an interactive interface such as a web browser or other graphical user interface. Note that the ability to generate data and service requests directly in the DCCS provides significant advantages over existing techniques for interactive services of the diagnostic system. For example, if the installed foundation of a device in a healthcare facility does not or cannot provide direct communication capabilities through an external network, the device may still be connected to the DCCS through the internal network.
Can be combined. In addition, many medical diagnostic systems and devices do not have operator interface features to assemble service and data requests. However, the ability to generate such a request directly in the DCCS allows such a system to be included in the overall serving scheme. Following the generation of the request of step 208, the screening and license checking functions of step 206 can be performed, as shown in FIG.

In step 210 of FIG. 4, the data contained in the request is analyzed to identify, for example, the requesting or destination diagnostic system, the particular fault or problem of interest, the operator or clinician who assembles the request, Is done. At step 212, this information is recorded in the DCCS memory circuit. At step 214, the request is queued for transmission to a remote service provider. If the connection session is currently running, the request is sent in the earliest available communication window, as shown in step 216. In some cases, the transmission of step 216 may require the initiation of a connection session. In a preferred embodiment of the invention, such a connection is initiated by either the DCCS or a remote service provider. If desired, receipt and transmission of the request is confirmed back to the designated diagnostic system as shown in step 218. Further, if additional client data is needed to handle the request, this data can be retrieved as shown in step 220. Such data, for example,
Data generated by the imaging system or monitor
Specific configurations or parameter settings that may have already been in the image sequence, such as streams or service history data, may be included.

The request constructed according to the logic of FIG. 4 is sent to the remote service provider via the external network. FIG. 5 illustrates exemplary logical steps for processing such a request. The procedure generally indicated by reference numeral 250 begins with the receipt of the request in step 252. At step 254, the confirmation message may be assembled and returned to the DCCS by the remote service provider, such as through an automatic return message creation routine, to notify the facility that the request has been received and is currently being processed. Such confirmation may include additional details regarding the process, such as a reference number, dispatch number, process schedule, and the like.
At step 256, the data in the request is parsed and recorded by the remote service provider. Step 25
The analysis performed in step 6 is examined in step 210 of FIG. 4, such as identification of the requesting or designated system, facility, service subscription data, and identification of parameters or operational data required to review and handle the request. Analysis of similar data. In step 254,
The license or accounting records stored in the remote service provider's database are accessed and updated to dictate the request. Depending on the desired accounting configuration, the request can be processed on a warranty basis, on a pay-per-use basis, or otherwise in accordance with an existing contract or subscription.

As mentioned above, depending on the type of request sent from the medical diagnostic facility, its processing by the remote service provider can assume different modes. As shown in step 260 of FIG. 5, the request is processed within the service provider, such as by automatic processing or by the intervention of a service technician. Either way, you will need to get additional data from the system to properly handle the service request. For medical diagnostic imaging devices, such additional information can include raw or processed image data files, system configuration parameters and settings, and the like. As shown at step 262, such data may be retrieved via the external network, the DCCS, and the facility's internal network. Once sufficient information has been accessed to handle the request, the requested data, reports, analyzes, etc. are returned from the remote service provider via the DCCS to the designated medical diagnostic system or the originator of the request. Returned directly to DCCS.
The transmission of step 264 may include a wide range of data. For example, the data can include configuration parameters, recommended troubleshooting steps, electronic messages, electronic documents, software upgrades, protocols, and the like. If desired, a field service technician can be dispatched for additional follow-up, as shown in step 266 of FIG. The field service technician dispatched at step 266 can handle the request either physically or remotely, for example, via a telephone or other connection from a remote service provider.

As noted above, responses to requests from medical diagnostic facilities can be transmitted over other media, such as wide area networks and satellite links. The logic of FIG. 5 illustrates one embodiment for handling such a transmission in response to a request. Although a variety of media can be used for this, in a preferred embodiment of the present invention, the media have significantly different transmission rates or bandwidths, so they are over a first type of connection, such as a wide area network. Some types of transmissions are possible, with more demanding or specific transmissions being performed over higher bandwidth media. Various techniques can be used to determine which medium to use for transmission. For example, a remote service provider can select certain media manually or automatically depending on the requirements or preferences of a medical diagnostic facility. In addition, demanding significant bandwidth,
It can occupy the link for a significant time interval or perform a particular type of transmission over one medium or the other, such as streaming media transmissions that may be particularly vulnerable to interruptions or network delays .

In a preferred embodiment of the present invention,
The choice of area network or satellite link is based on the category of data or transmission. Thus, in step 268 of FIG. 5, the categories are examined and one of the available media is selected. For example, multimedia presentations, training sessions, and similar data categories are transmitted over satellite links,
On the other hand, more traditional data transmissions are performed over wide area networks. Then, depending on the transmission category, a medium is selected as shown in either step 270 or 276. The transmission is then scheduled, as shown at step 272 or step 278. For example, in the case of a training session, transmissions can be scheduled at a later date and time, and the destination diagnostic system can be a specific location in a diagnostic facility, a training room, or other client. Finally, step 2
As indicated at either 74 or 280, the scheduled transmission is performed over the selected medium.

FIG. 6 illustrates exemplary control logic for receiving, processing, and returning transmitted data from a remote service provider to a diagnostic facility. The control logic is indicated generally by the reference numeral 300 and begins with the receipt of the data transmission of step 302. This reception is via the DCCS, such as an ongoing data transmission session. At step 304, the received data is analyzed to identify at least a designated or targeted diagnostic system. Step 306
The data is relayed from the DCCS to the designated system via the facility's internal network. Note that step 306 may include storing all or part of the data, or information derived or analyzed from the data, in a memory circuit of the DCCS or another database at the facility. In step 308, the exchange of reception and communication is recorded by the DCCS.

If desired, another procedure of data reception and processing can be performed, as shown in FIG. Another receiving step, generally indicated by reference numeral 350, is to receive digital data over a satellite link,
It is desirable when routing and distributing data via S. In particular, such a satellite communication system or another medium does not necessarily require two-way communication. Thus, some information for handling data can be transmitted in parallel over the other medium, especially over a wide area network. Thus, in step 352, a handshake routine is performed between the DCCS and the remote service provider to ensure proper connectivity and the ability to exchange necessary information. At step 354, an authentication procedure may be performed to confirm that the transmission session over the parallel medium satisfies the request and the transmission schedule. At step 356, the destination address is identified and verified, for example, to confirm that the transmission channel has been properly tuned or selected and the client or diagnostic system has been identified within the facility. Step 3
At 58, the transmitted data is received, demodulated, filtered, or otherwise processed. As shown at step 360, data received over parallel media may require additional processing, such as packetizing the data for transmission over an internal network.
Following such processing, the data is distributed to the designated system. The communication sequence and transmission go to step 362
Is recorded as shown in FIG.

In addition to the interactive exchange of services and other data, the techniques of the present invention enable streamlined operation and acquisition of parameter data from a medical diagnostic system that is a client of the facility's internal network. . FIG. 8 shows exemplary steps of this procedure via control logic indicated generally by the reference numeral 400. Generally, this procedure allows data to be acquired or collected from a networked diagnostic system via the DCCS and transmitted from the DCCS to a remote service provider. In previously known approaches to servicing medical diagnostic systems, such data was typically obtained via a direct connection to the desired diagnostic system, thus establishing a number of independent connections And
Both on-premises and remote service providers have resulted in significant demands on the infrastructure. Furthermore, little or no information was obtained, especially directly from the system, if the diagnostic system did not have the capability of direct connectivity to the remote service provider.

In the approach of the present invention, information can be obtained through a number of different processes that are initiated both automatically and manually. In the example logic of FIG. 8, the data acquisition process begins with the start of the automatic polling routine of step 402. This routine is a DCCS that contacts a pre-established schedule with each networked system, or a designated system from which data is requested.
Performed by For example, this schedule is 24
This may include regular data acquisition over time, or less frequent acquisitions. Depending on the routine and schedule, the client is contacted at step 404 of FIG. At step 406, the data is accessed, such as by retrieval from a memory circuit of the client diagnostic system. At step 408, the data is filtered to determine, for example, whether to obtain complete or incomplete information, or to analyze unwanted data, such as patient-specific data. Step 410
The data is recorded in a DCCS memory circuit or the like.

As an alternative to the above polling process, certain data may be collected when a particular event occurs in the diagnostic system or facility. For example,
If certain systems of the facility are mobile, the connection of the mobile system to the internal network causes the DCCS to execute the data acquisition routines of the newly connected system. Thus, as shown in step 412 of FIG.
Certain systems or assets may change state. For example, establishing or updating a connection to an internal network. Then, in step 414, the system is accessed and the desired information is
Transferred to S. For example, to enable asset tracking, asset management, productivity analysis, and other functions, or for facility personnel to track assets, to identify the location of mobile assets for later use Can be recorded.

The data acquisition sequence can be initiated by a manual request, as shown in step 416 of FIG.
Manual requests can be made, for example, by a DCCS operator to access and display the performance, utilization and other characteristics or parameters of the networked system.
Can be entered via interface components. In response to the manual request, the designated system is accessed, as shown in step 418, and the desired data is located and transmitted from the device memory, as shown in step 420.

To facilitate transmission of the acquired data to the remote service provider, the acquired data is preferably stored locally at the diagnostic facility and stored in one or more data communication sessions. Sent to. Such sessions can be scheduled for convenient times, such as off-peak hours, late nights, and weekends. FIG. 9 illustrates the steps of exemplary control logic, generally indicated at 450, for transmitting data once acquired at the facility.

Referring to FIG. 9, a data transfer schedule is first set as shown in step 452. As mentioned above, this schedule can be established at a convenient time for both the diagnostic facility and the remote service provider. However, it should be noted that such data transfer can be initiated by operator intervention as appropriate. As shown in step 454, a connection is then established between the diagnostic facility and the remote service provider. The connection can be initiated by either the facility or the remote service provider, but in this embodiment the remote service provider is the preferred source. Also, at step 454, the remote service provider prompts the transfer of data via a communication routine stored, for example, at both the DCCS and the remote service provider. In response to this prompt, the data is accessed by the medical facility memory or data repository and transferred to the remote service provider, as shown in step 456. During or after the transfer, as shown in step 458, any desired analysis,
Filtering and other processing are performed. In particular, the transferred data is preferably analyzed to identify the individual diagnostic systems from which the data originated, and the operation and parameter data of the individual systems are separated from one another. The data is then preferably stored in a relational database for later retrieval and analysis.
Finally, at step 460, the data transfer session is preferably recorded at both the diagnostic facility and the remote service provider.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the intention is not to limit the invention to the particular forms disclosed. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives which do not depart from the spirit and scope of the invention as set forth in the appended claims.

[Brief description of the drawings]

FIG. 1 is a schematic diagram of a data communication system for transmitting data from a series of medical diagnostic systems to a remote service provider or data provider.

FIG. 2 is a schematic diagram illustrating an exemplary data communication control system in accordance with an aspect of the present technique for use in the system of FIG.

FIG. 3 is a data flow diagram illustrating the paths taken by data in communicating through various components of the system of FIG. 1;

FIG. 4 is a data flow diagram illustrating exemplary control logic for initiating a service request or other data transfer between a medical diagnostic system and a remote service provider.

FIG. 5 is a flow diagram illustrating exemplary control logic for handling service or data requests by a remote service provider and retransmitting data in response to such requests.

FIG. 6 is a flow diagram illustrating exemplary control logic for receiving a transmission from a remote service provider at a medical diagnostic facility.

FIG. 7 is a flowchart illustrating exemplary control logic for receiving data over another data communication medium.

FIG. 8: System of medical diagnostic facility or remote service
5 is a flowchart illustrating exemplary control logic when polling or sweeping data to be retransmitted to a provider.

FIG. 9 is a flow diagram illustrating exemplary control logic for accessing data collected in the process of FIG. 8 that is handled and stored by a remote service provider.

[Explanation of symbols]

12 Medical Diagnostic Facility 14 Remote Service Provider 24-38 Medical Diagnostic System 26,28,30,32 Imaging System 20 Internal Network 40 Data Communication System 42,44 External Network Interface 50 External Network 54 Satellite Link 46,50,78 One data communication medium 48, 54, 80 Second data communication medium 98, 100, 102, 104 Operator interface 214, 306, 360 steps

Continuing the front page (72) Richard Lee Fromein, United States 53188, Waukesha Lynnwood Drive, Wisconsin 901 (72) Inventor Hubert Anthony Zetter United States 53186 Waukesha Gatellier, Wisconsin West 225 South 4375 (72) Inventor James Francis Colli United States 53186-2302, Wisconsin, Waukesha Calico Court 805 (72) Inventor John Michael Heinen, United States 53213 Wisconsin, Wowwatsa North 70T Street 675

Claims (18)

[Claims] A data communication management system (40) for a medical diagnostic facility (12), wherein the interface is a client (24-36) in the medical diagnostic facility (12).
A facility network interface (90) for transmitting data to and receiving data from a client; and an external network interface (42, 44) for transmitting data to and receiving data from the remote service facility (14). A data processing circuit (86) configured to route data from the remote service facility (14) to the client (24-38) within the medical diagnostic facility (12) and to transmit data from the client to the remote service facility; And a data communication management system including: 2. A facility network interface (9)
The system of claim 1, wherein 0) comprises a local area network interface (20). 3. An external network interface (4)
The system of claim 1, wherein (2,44) includes wide area network communication circuitry (42). 4. An external network interface (4)
2. The system of claim 1, wherein (2,44) includes at least two different media communication circuits. 5. The system of claim 4, wherein the media communication circuit is configured to include a wide area network (50) and a wireless data link (54). 6. A wide area network (50).
6. The system of claim 5, wherein comprises the Internet. 7. The wireless data link includes a satellite communication link (54) and the media communication circuit includes a decoding circuit (44) for converting received data into packetized data for delivery to clients (24-38). Item 6. The system according to Item 5. 8. A data processing circuit comprising: a client (24);
-38) in response to a data request from
The system of claim 1, wherein the system is configured to execute a routine (200). 9. A client (24-38) for transmitting to a remote service facility (14) by a data processing circuit.
The system of claim 1, further comprising a memory circuit (92) for storing data from the memory. 10. A client (24-
38) Operator to access data from
The system of claim 1, further comprising an interface (98, 100, 102, 104). 11. The system of claim 1, wherein the processing circuit (86) is configured to function as a server that executes the routine (110) interactively with a client. 12. Managing a data communication between a plurality of networked clients (24-38) of a medical diagnostic facility (12) and a remote service provider (14) by: (a) providing client data; Receive and client
Send the data to the remote service provider (14),
Providing a data processing system (40) acting as a server and a router for receiving addressed data from a remote service provider and distributing the addressed data to clients (24-38); (b) Data processing system (40) and client (2)
4) interface the data processing system with an internal network (20, 22) of the medical diagnostic facility (12) to exchange data with the data processing system; (c) the data processing system (40). The data processing system is connected to an external network (46, 50, 7) for exchanging data between the remote service provider (14).
8, 48, 54, 80) via an interface; and (d) a client (24-48) via a data processing system (40), internal and external networks
38) and exchanging data between the remote service provider (14). 13. The method of claim 12, wherein substantially all data communications between the clients (24-38) and the remote service provider (14) are routed through the data processing system (40). 14. A predetermined data acquisition routine (400).
Another step (40) of initiating access to client data by the data processing system (40) according to
The method of claim 12, comprising: (2,404,406). 15. An additional step (418, 420) for initiating access to client data by the data processing system (40) in response to an operator request (416) entered into the data processing system.
3. The method according to 2. 16. The method according to claim 1, further comprising the step of recording communications between the client and the remote service provider.
3. The method according to 2. 17. An external network (46, 50, 7)
13. The method of claim 12, wherein (8, 48, 54, 80) comprises at least two different data communication media. 18. The method of claim 17, wherein the at least two different data communication media include a wired link (50) and a satellite link (54).