JP2001216422A - Method and device for acquiring data from medical diagnostic system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide technology for acquiring the operation or parameter data of plural medical diagnostic systems 24-38. SOLUTION: This technology is provided with a procedure for accessing the desired data through internal networks 20 and 22, to which the systems are connected. A date communication control systems 40 acquires data and can store the data in a data repository 92 of a medical institution by partially processing and filtering them. The repository can store the date in a data base or the like in a relational form. A control system periodically makes a contact with a remote service provider 14 and transmits one part of or all the data. With this technology, necessity to connect each of systems and the service provider is reduced and data can be easily collected inside the institution and transmitted to the service provider later.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates generally to the field of medical diagnostic systems, such as imaging systems, monitors, and similar devices in medical diagnostic facilities and institutions. More particularly, the present invention relates to techniques for collecting, collecting, and storing data from another networked diagnostic system, and then transmitting the data to a remote service provider for analysis and other processing.

[0002]

BACKGROUND OF THE INVENTION Medical diagnostic facilities, including clinics, hospitals, outpatient facilities, and the like, typically utilize a variety of diagnostic systems and devices. For example, a clinic or hospital may have several different imaging systems in one or more radiation departments or various wards. In some cases, the device is completely independent or not interconnected with other devices in the engine. In some cases, certain devices may be incorporated into a data communication network within the institution to exchange data as appropriate. However, with the latest technology,
There is a relatively limited level of system integration.

[0003] Due to the extremely demanding schedule and specialization of medical diagnostic facilities, maintenance providers and maintenance personnel perform the necessary steps to monitor the system and maximize its productivity and availability. Often have a contract. In the traditional approach, field service personnel actually visit contracts or affiliates to verify the condition of the equipment,
Instruct the necessary operations to keep the device in good working condition. However, data reflecting the operating state of such a system can be collected remotely. For example, in one available system, a modem is provided on the subscribing system, and the system is contacted periodically to access and download stored data and use it to assess the status of the system. it can. Based on an automated or manual review of this information, preventive maintenance can be directed, reports generated, and other feedback provided to the agency to maximize system productivity.

[0004]

Although automated data access for the maintenance and operation of medical diagnostic equipment is extremely useful and productive, current methods of acquiring data need further improvement. For example, while relying on individual modems and similar communication devices to contact individual systems, a large number of individual connections would be required to access and transfer the desired data. Although connections can be scheduled at convenient times, such as late at night, when the system is relatively idle, the number of individual contacts required for an automated data acquisition method is still a potential bottleneck in processing.

Another drawback of existing data acquisition techniques for operation is the inability to contact systems that do not have a communication interface or the necessary infrastructure. For example, telephone connections may not be available in certain individual systems, or even if such other lines are available, maintaining those lines can be quite costly. In addition, many existing and newly installed systems do not have independent modems or other interface software or software to connect to external service providers.
In such cases, no data is available from the system, or incomplete data is only very sporadically available.

[0006] Therefore, there is a need for improved techniques for obtaining operational data from medical diagnostic systems. In particular, there is a need for techniques that can be used within large and small facilities, including headquarters and satellite offices, and between departments within a particular facility. Finally, there is currently a great need for techniques that can collect large amounts of relevant data from medical diagnostic systems while reducing the need for separate connections and data access sessions.

[0007]

SUMMARY OF THE INVENTION The present invention provides a data acquisition technique designed to address these needs.
Although this technique can be applied to a variety of environments, it is particularly suited to procedures for acquiring data from medical diagnostic imaging systems and other devices in a networked medical diagnostic facility. This technique can be used in various facility topologies. In a particularly preferred embodiment, the facility's internal network serves as the basis for collecting operational parameters of networked systems and devices. The collected data is stored, partially processed, integrated, filtered, or otherwise managed before being stored in the facility's data storage. The data communication control system coordinates data collection. In a single or series of data acquisition sessions, the collected data is transferred from the facility to the remote service provider, which further processes and analyzes the data for maintenance, reporting, accounting, etc., or It can be used in other ways.

[0008]

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.

Also, 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 is a 10 Mb or 100 Mb network that exchanges data according to a standard data exchange protocol such as TCP / IP. Of course, other internal network architectures and standards can also be used.

The communication system is a data communication control system (D) coupled to a network 20 that receives or accesses data from clients and exchanges data with one or more remote services or data providers.
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.

Although certain remote service provider systems can be designed to couple directly to 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.

With 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 the 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 a facility, particularly in an 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, shown generally at 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.

[0027] The 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 above 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 in 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

The data exchanged internally within the medical diagnostic facility and the remote service provider are 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, etc. 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 noted above, depending on the type of request sent from the medical diagnostic facility, its processing by the remote service provider can assume various 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 described 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 wide
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 can 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 a remote service provider, the acquired data is preferably stored locally at a 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 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 (20)

[Claims] 1. An internal network of a medical institution (2)
0, 22) coupled to a plurality of medical diagnostic systems (24
Performing a data access routine (400) to obtain parameter data from .38); (b) storing the parameter data in a medical institution data repository (92) (410); (C) establishing a data link between the medical institution (12) and the remote service provider (14) via the external network (50) (454); Transmitting data (456).
2) A method of obtaining parameter data from a plurality of medical diagnostic systems (24 to 38). 2. A data access routine (400).
Is a data communication control system (40) of a medical institution (12)
The method of claim 1 performed by 3. The system of claim 2, wherein at least one of the diagnostic systems is configured to transmit data to the remote service provider only via the data communication control system. Method. 4. The method of claim 1, wherein the data link is established (454) by a remote service provider (14). 5. The method according to claim 1, wherein the data link is established via a wide area network (50). 6. The method of claim 5, wherein the wide area network comprises the Internet. 7. The transmission (456) of the parameter data to the remote service provider (14) is performed by the remote service provider (14).
The method of claim 1, initiated in response to a prompt from a provider. 8. The method of claim 1, wherein the diagnostic system comprises a plurality of medical diagnostic imaging systems (26, 28, 30, 32). 9. Another step (45) in which the remote service provider receives the parameter data, processes the data, and stores the processed data for subsequent retrieval.
The method of claim 1, comprising 8). 10. The method of claim 9 wherein the data is processed to analyze the specified diagnostic system parameter data and are cross-referenced in at least one database maintained by a remote service provider. The described method. 11. A plurality of diagnostic systems (24-38).
An internal data communication network (20, 22) coupled to the diagnostic system; and a diagnostic system (24 to 24) coupled to the internal network (20, 22) via the internal network (20, 22).
Access the operation data received from (38) (40)
6), store the operation data (410), and store the operation data in the remote service provider (1)
A system for acquiring operation data from a plurality of diagnostic systems, including a data communication control system (40) configured to transmit (454) operation data to (4). 12. The system according to claim 11, wherein the data communication control system accesses the operational data according to a predetermined data access routine. 13. The system of claim 11, wherein the diagnostic system (24-38) includes a plurality of medical diagnostic imaging systems (26, 28, 30, 32). 14. A medical diagnostic imaging system (26, 28,
14. The system of claim 13, wherein (30, 32) includes at least two different imaging modalities of the imaging system. 15. The system of claim 11, wherein at least one of the diagnostic systems (24-38) is configured to transmit operational data to the remote service provider (14) only via the data communication control system (40). System. 16. The data communication control system (40) configured to initiate a connection session with a remote service provider (14) via an external network (50) and transmit operational data via the external network (50). The described system. 17. The system of claim 11, wherein the data communication control system transmits the operational data to the remote service provider in response to a prompt from the remote service provider. 18. The system according to claim 11, wherein the internal network (20, 22) comprises an Ethernet network (20). 19. An external network comprising: a wide-area network;
The system according to claim 11, comprising a network (50). 20. The system according to claim 19, wherein the external network comprises the Internet.