Medical facility communications topology

A technique for exchanging data between networked medical diagnostic systems of a medical institution is provided. The diagnostic systems may include imaging systems, data management systems, monitors, and so forth, connected to an internal network of the institution. A data communications control system is connected to the internal network and receives data from the systems, transmits data to a remote service provider via an external network, and routes data received through the external network back to the diagnostic systems.

FIELD OF THE INVENTION

The present invention relates generally to information infrastructures for hospitals, clinics, and other medical institutions. More particularly, the invention relates to a technique for exchanging information within a medical facility via an improved topology linking various equipment and networks into a data exchange infrastructure.

BACKGROUND OF THE INVENTION

Medical institutions and facilities offer an increasingly wide range of services and procedures to meet the needs of their patients and staff. Hospitals, clinics, and other medical institutions may include simple single-office clinics, or large integrated establishments comprised of a wide array of cooperating departments and facilities. Moreover, even smaller clinics may be partially or fully integrated into a larger institution at a single location, or geographically disbursed from one another. In all of these cases, information technology is becoming a key component in the exchange of data and services needed to carry out the mission of the facilities.

In a typical clinic or hospital, for example, a radiology department may dispose of various types of imaging systems, including magnetic resonance imaging (MRI) systems, computer tomography (CT) systems, ultrasound systems, x-ray systems, and so forth. Certain of these systems may be stationary, while others may be moved around the facility as needed. A radiology department informational system (RIS) may be interconnected with these various imaging systems to coordinate their operation, as well as to facilitate their review of images by radiologists and diagnosing physicians. In certain institutions, these various pieces of equipment may be interconnected in a network, typically in a local area network (LAN) architecture.

In addition to radiology equipment, various other equipment within a medical facility may be monitored or networked at a departmental or institutional level. Patient monitors, for example, may offer some degree of networking capability, allowing patients to be tracked and their physiological condition to be monitored remotely. Patient records, accounting records, and the like may similarly be associated in different individual systems, with certain of the information being cross-referenced in a hospital information system (HIS).

While certain of the equipment within a hospital or other medical institution can be designed to function completely independently of other equipment or service providers, many individual systems or subsystems are now designed to interactively communicate information with outside components. For example, in the diagnostic imaging field, individual systems are now commonly equipped with a modem by which they may transmit and receive image data, service information, reports, and so forth. In certain instances, operations personnel may log on to a network, such as the internet, or a virtual private network, to transmit and receive data directly from the imaging system. Other equipment within an institution may be similarly equipped for data communication, either individually or via a departmental work station or similar interface.

While individual networks within a medical facility may function adequately for most purposes, they pose certain problems on the level of coordination and delivery of data, and may strain the infrastructure of the institution. Depending upon the type of connections provided, for example, medical diagnostic imaging systems may each require a separate communications line to insure connectivity when needed. In a typical setting, these communication lines are conventional telephony cables which must be installed and maintained for the individual systems, even when the systems are not logged on to a network or transmitting data. When data is transmitted to or from individual pieces of equipment or individual LAN's of an institution, separate accounting may be required, and interface components must separately route the data to and from each system or piece of equipment connected to a LAN. Again, this procedure may require separate connection procedures via dedicated lines, adding not only to the overall cost of the system and infrastructure, but adding substantial time and additional steps to the data interchange process.

While some progress has been made toward linking individual networks and systems of medical institutions, further improvements are needed. There is a particular need, at present, for a technique which would permit and coordinate the exchange of data among internal systems and networks of a medical facility, and with external resources, such as service providers. The need extends both to relatively small institutions or clinics, which may have a few pieces of medical diagnostic imaging equipment, to large integrated institutions in which entire departments may be served by outside resources and communicate with those resources completely independently from one another under present schemes.

SUMMARY OF THE INVENTION

The present invention provides an improved data communications topology for a medical institution designed to respond to these needs. The technique of the invention offers rapid and effective data exchange within the institution, and facilitates transmission of data to a remote service provider, and routing of data from such a service provider to designated diagnostic systems of the institution. The technique may be equally well applied to existing facilities having partial or fully networked environments, and to institutions upgraded to offer such networking capabilities.

In accordance with the technique, a plurality of client diagnostic systems are connected to an internal network of the institution. A data communications control system permits data from the systems to be accessed via the internal network. The data may include service requests, requests for programs and software, requests for documentation and training materials, and so forth. The data is then transmitted to a remote service provider as needed, through a reduced number of connections and data transmission sessions. Data from the remote service provider is received by the control system and is distributed to designated diagnostic systems as desired. The technique offers enhanced connectivity, facilitates data access and transfer, and provides for improved interconnectivity of devices and systems of the institution.

DETAILED DESCRIPTION OF THE INVENTION

Turning now to the drawings, and referring first toFIG. 1, a data communications system, designated generally by the reference numeral10, is illustrated for transmitting operational data or parameters from a series of medical diagnostic systems to a remote service or data provider. The system also permits interactive exchanges of data, service requests, software, and so forth between the systems and the remote service provider as described more fully below. As illustrated inFIG. 1, system10generally includes a medical diagnostic facility12which is linked to a remote service or data provider14. The facility12may include a single location or site16, or additional cites18, which may be geographically local to or remote from site16. In such cases, the additional sites may generally be interconnected with site16via a facility network.

Within facility12, an internal network20provides a mechanism for data communications between a series of medical diagnostic systems, which where desired may be provided in groups or departments22, such as floors, wards, specialized treatment or diagnostic areas, and so forth. A series of medical diagnostic systems, referred to herein generally as clients24, are coupled to network20either through permanent network connections, or through temporary network connections. Thus, while some or most of the clients24may be stationary, certain of the clients may be mobile, allowing the client or asset to be utilized in a desired location, and to be coupled to the internal network once positioned at the desired location.

As used herein, the term medical diagnostic system should be understood to include a wide variety of equipment, systems and subsystems. By way of example, medical diagnostic systems may include diagnostic imaging systems designed to produce useful images of patient anatomies in accordance with particular physics or modalities. Other medical diagnostic systems may include patient monitors, sensors, transducers, and other signal-generating or feedback devices. Moreover, the medical diagnostic systems communicating in accordance with the present technique may include information management systems, workstations, image and data viewing stations, and so forth.

By way of example, inFIG. 1, a series of medical diagnostic imaging systems are illustrated in one group. In practice, this group may be physically or logically associated with a radiology department or clinic. In the embodiment illustrated inFIG. 1, these systems include a magnetic resonance imaging (MRI) system26, a computed tomography (CT) system28, an x-ray system30, and an ultrasound system32. These systems all preferably comprise client diagnostic systems for the present technique. As will be appreciated by those skilled in the art, each of these imaging systems is configured to produce useful image data based upon particular physics of their respective modality. As noted above, certain of these systems may be mobile, such as ultrasound systems which may be relocated to a desired room or examination area and connected to network20at that area or upon return to a base station.

By way of further example, in the embodiment illustrated inFIG. 1, the client diagnostic systems also include a series of data management stations. As indicated by reference numeral34, then, the clients may include a radiology department informational system (RIS) designed to manage the production and flow of image data in conjunction with imaging systems26,28,30and32. A hospital information system (HIS)36provides additional data, patient, financial, and other support for the operation of facility12in accordance with generally known techniques. Finally, a picture archiving and communication system (PACS)38provides for storage, processing, access and archiving of data files produced by the diagnostic imaging systems.

Each of the client diagnostic systems is coupled to network20for exchanging data with a remote service or data provider as described below. In heretofore known data exchange techniques, certain of the client systems may be equipped for independent exchange of operational or parameter data as required for servicing, maintenance, analysis, accounting and similar needs. In accordance with such techniques, an independent connection could be established between the assets and a remote service provider, such as via an independent modem connection as illustrated for ultrasound system32inFIG. 1. In accordance with the present technique, although certain of the systems may continue to permit such direct connection, the client diagnostic systems need not be capable of such separate connectivity. Rather, data may be exchanged between the systems and a remote service or data provider via network20.

In the presently preferred embodiment, network20comprises a high-speed internal network, such as an Ethernet network. In current embodiments, the network may be a 10 Mb or a 100 Mb network exchanging data in accordance with a standard data exchange protocol, such as TCP/IP. Of course, other internal network architecture and standards may be employed.

The communications system further includes a data communications control system (DCCS)40which is coupled to network20for receiving or accessing data from the client, and for exchanging data with one or more remote service or data providers. The DCCS40is thus coupled to external communications circuitry, such as a modem42and a satellite decoder44. Modem42, and any additional modems as desired, may be of any suitable type, such as a 56 kb/s modem in accordance with present technology, a cable modem, or any suitable external network communications interface. Decoder44may similarly be any suitable satellite or wireless interface, such as an IRD of the type available from Scientific Atlanta of the United States. As described more fully below, the use of parallel media for transmitting and receiving data permits the DCCS40to optimize the use of available bandwidth in data exchanges between the facility and the remote service provider. By way of example, modem42may provide bandwidth of 56 kb/s, while decoder44offers a considerably broader bandwidth, such as 500 kb/s.

The data communications to and from facility12are provided by an external network link46routed to modem42, and by a satellite link48routed to decoder44. External network link46is coupled, such as via conventional telephony cables, optical fibers, or otherwise, to a network50, such as a wide area network. Network50may be any suitable type of network, however, including virtual private networks, or the Internet. Isolation and protection of the integrity of the information system of facility12may be assured by one or more firewalls52. Satellite link48, which also generally forms part of the external network for communicating data to and from the facility, functions to receive data relayed via satellite54, or through ground-based repeaters, transmitters, and so forth.

Data from facility12is exchanged with a service provider14through the external network connections described above. In general, remote service provider14may include a principle site56, and additional cites58, interconnected through open or proprietary networks. Remote service provider14, by way of example, may include a facility or facilities for receiving data and service requests from the medical diagnostic facility on a subscription or contract basis. Services, data, training, technical assistance, and other information may then be provided to the subscribing facilities through the network connections and in accordance with the techniques described below. In the illustrated example, remote service provider14includes its own internal network, such as an Ethernet-based local area network.

A series of clients or systems are interconnected via the network for exchanging data both internally and with the medical diagnostic facility. By way of example, a service system, designated generally by reference numeral62, is provided for receiving and processing service data, such as service requests, protocol requests, questions, and so forth. Service system62may also be equipped for scheduling regular or special service calls, providing reports and analysis of operational or parameter data, and so forth. In the illustrated example, remote service provider14also includes an automated support center as represented generally at reference numeral64. The center may perform a variety of 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 may be fully automated, requiring little or no operator intervention. Data collected in accordance with the routines executed by the ASC are stored and made available upon demand. Remote service provider14may also include various electronic commerce systems66designed to provide data, receive orders, process orders, and perform accounting and financial transactions upon request from the medical diagnostic facility. An educational unit or system68may further be provided for offering educational or training programs, providing manuals or documentation, and so forth.

While certain of the systems of the remote service provider may be configured for direct link to one or more medical diagnostic facilities or diagnostic systems, in the illustrated example, they are configured for communication with the diagnostic systems over the internal network60and through a communications interface70. Communications interface70will typically include a data router, and other hardware and software for appropriately addressing data received from the medical diagnostic facility to one or more of the internal systems of the remote service provider, and for directing communications from these systems to the medical diagnostic facility. Interface70communicates the data via one or more modems72, and via a satellite transmitter74. Where desired, further network or satellite links may be provided to specific systems of the remote service provider such as a transmitter76provided for the educational unit68. Each of the communications devices is coupled to a data link, including a fresh data link78for modem72, and satellite links80and82for transmitters74and76, respectively. The data link78preferably protects the integrity of the network and data of remote service provider14via one or more firewalls84or similar protection devices.

The system topology illustrated inFIG. 1permits data to be exchanged interactively between the medical facility and the remote service provider. As discussed below, the data may be exchanged at the initiation of the medical diagnostic facility, or of systems within the facility, via DCCS40. Alternatively, communications may be initiated by the remote service provider, such as to respond to data or service requests, to access or acquire data from the diagnostic systems through the DCCS, or to provide various services, including instructional materials, training sessions, and so forth, via the external network links.

FIG. 2illustrates an exemplary configuration for DCCS40, including its associated peripheral devices and software suite. In the illustrated embodiment, DCCS40includes a central processing unit86, which may comprise a commercially available microprocessor within a general purpose or application-specific computer. The CPU is coupled to a variety of hardware and functional circuitry to carry out the functions described herein. For example, as shown inFIG. 2, the CPU is coupled to a communications interface88to transmit and receive data via the external network as described above, and to similarly transmit and receive data with the diagnostic systems via the internal network. Thus, communications interface88may coordinate communications through one or more modems42coupled to the data link46. The satellite decoder44similarly channels data through the DCCS via satellite link48. An additional network interface90, such as an Ethernet interface, permits the exchange of data via the internal network20of the facility.

In addition to these communication components, DCCS40includes memory circuitry92and additional support components. Memory circuitry92may include any suitable memory, such as disc drives, random access memory, read-only memory, dynamic random access memory, optical storage, and so forth. Memory circuitry92stores both software routines executed by the DCCS, as well as data collected by the DCCS for transmission to the remote service provider, and data received from the remote service provider for distribution to designated or addressed diagnostic systems of the facility. A backup system94is preferably provided for periodically creating archive versions of selected files, routines, collected data, and so forth. One or more peripheral interfaces, as designated generally at reference numeral96, is provided for receiving input signals from an operator interface, and for displaying data and outputting data as desired. In the illustrated embodiment, such peripheral devices include a computer monitor98and printer100as output peripherals. Input peripherals may include a conventional keyboard102, mouse104, and any other suitable input peripheral devices.

While certain software applications and utilities may be stored and executed on various clients of the facility, particularly within the imaging systems, the RIS, the HIS, and the PACS, DCCS40preferably independently executes a variety of applications to perform the data communications functions assigned to it. These applications, designated generally by reference numeral106inFIG. 2, are preferably stored in memory circuitry92, and executed by CPU86. Alternatively, certain of the applications may be resident elsewhere, and completely or partially executed by other data processing circuitry. The applications106will generally include a variety of commercially available application routines, and may further include customized routines executed by the CPU. A software suite108is therefore available for execution by the CPU, both automatically, on a regularly scheduled basis, or in response to operator prompts or prompts from the remote service provider.

Application routines, designated generally by reference numeral110inFIG. 2, may include software for collecting data from the diagnostic systems, storing such data, transmitting data to the remote service provider, and routing data from the service provider to designated systems. In the embodiment illustrated inFIG. 2, software suite108includes database software for associating collected data from the diagnostic systems in a relational manner. Such data preferably includes the identification of the systems, their locations, utilization data, as well as a variety of parameter data useful in determining the operational state of the system and the possible need for service. As will be appreciated by those skilled in the art, in the case of diagnostic imaging systems, a wide variety of operational or parameter data may be stored directly at the individual diagnostic systems and may provide extremely useful indications of the performance of the systems, and possible future service needs.

Software suite108preferably also includes server software, such as Windows NT server software from Microsoft Corporation of Redmond, Wash., as well as web server software. The server software permits the DCCS to function as a server, both for the internal clients and for external clients or users. Browser software is also preferably included, permitting an operator, through the operator interface devices of the DCCS, to log on to sites, such as on the Internet to request information and data, transmit service and data requests, and so forth. In the preferred embodiment, the browser software may also function on the DCCS to permit interactive interfacing directly at one or more of the diagnostic systems, particularly the diagnostic imaging systems. Routing software is also functional on the DCCS to permit data packets received from the remote service provider to be appropriately transmitted to designated diagnostic systems within the facility via the internal network.

Additional applications of software routines are also preferably included on the DCCS, including diagnostic and service routines, and interactive service routines. These routines, which may include an interactive service platform, permit service requests to be generated, preferably via a web browser interface for immediate of delayed transmission to the remote service provider. These applications also preferably permit the receipt of reports and service data back from the remote service provider in an interactive fashion. Reporting software on the DCCS permits reports to be generated, particularly reports relating to communications activities logged as described below. Security routines may be executed as part of the software suite, preferably to verify the integrity of data transmitted and received via the DCCS, and to limit access both to the internal network from outside users, including the remote service provider, and access to remote websites or providers from the clients coupled to the internal network.

Asset management applications preferably also run on the DCCS to enable various business, financial, and management functions to be performed, preferably in coordination with similar functions performed by the RIS and HIS. In the illustrated embodiment, for example, transactional and accounting routines may be operational, such as to maintain an accounting for remote services utilized by the facility, any charges or fees associated with such services, similar accounting for any electronic commerce transactions performed, and so forth. An asset tracking routine may provide for analysis of locations and availability of specific clients or assets, particularly of mobile clients which may be traced through the internal network to specific locations.

The components of the software suite illustrated inFIG. 2and discussed above, may include various commercially available applications software packages, or software which is created specifically for the facility or application. In general, however, any application-specific software may be readily developed by those skilled in the art, without undue experimentation. In the presently preferred embodiment, commercially available software applications included in the system and executed by the DCCS include database software available from Oracle Corporation of Redwood City, Calif., multimedia software available from Eloquent Systems, Inc. of North Vancouver, British Columbia, web server software, such as Netscape Enterprise software available from Netscape Communications of Mountain View, Calif., and browser software, such as software available from Microsoft Corporation of Redmond, Wash., or Netscape Communications.

FIG. 3illustrates general flow of data within the overall system topology illustrated inFIG. 1. As shown inFIG. 3, two-way data flow is provided between the DCCS40and the various clients24, and other networked systems, such as the RIS34, the HIS36, and the PACS38. As noted above, clients24preferably include medical diagnostic imaging systems which are linked to the remote service provider through the DCCS for interactive data and service needs. DCCS40also communicates data to and from memory circuit92, which in the diagram ofFIG. 3may include databases, both local to the DCCS and at various networked nodes of the facility.

Within remote service provider14, data may be exchanged between interface70and the various systems and subsystems, such as those described above, as service system62, ACS64, electronic commerce systems66, and educational units or systems68. Each of these systems may include other networked systems or stations, such as work stations112which, through the service system62permit applications engineers to access diagnostic system data, address specific service needs and requests, and so forth. One or more databases114and116are preferably linked to the systems of the remote service provider to permit parameter and operational data to be stored relationally, and retrieved as desired for analysis, reporting, invoicing, and so forth. It should be noted that the components of the remote service provider, including the systems illustrated inFIG. 3, may exchange data either locally or through a wide variety of network configurations, including configurations permitting one or more of the systems and databases to be located in geographically distant locations from one another.

The data exchanged internally within the medical diagnostic facility and the remote service provider are then exchanged via the external network links between these facilities. In the illustrated embodiment, these network links include the satellite links48and80, routing data through a satellite54or land-based circuitry, as well as a wide area network as defined by links46and78, and network50.

The data communications technique and components described above permit access to and exchange of data in accordance with a variety of routines. Logical steps in certain of these routines are illustrated inFIGS. 4-9.

Referring toFIG. 4, a first routine permits service and data requests to be formulated at the diagnostic facility for transmission to the remote service provider. The service request routine, designated generally by reference numeral200, begins at step202where a client of the facility generates a data request. In the present context, such data requests may include a wide range of service, data, software, and similar requests. Specifically, for medical diagnostic imaging systems, these requests may include descriptions of specific problems occurring at the system, requests for imaging protocols for software, operational inquiries, and so forth. However, similar requests may originate in networked clients, such as internal training services of the facility, such as for multimedia training materials which may be transmitted through the DCCS as described below. It should also be noted that the data request may be formulated at diagnostic systems which include software running locally for the request formulation, or through applications running on the DCCS and accessible through the diagnostic system. At step204, these requests are transmitted to the DCCS. At step206, the requests are screened and any license verification may be performed, such as to determine whether the requesting diagnostic system is currently licensed for the type of request made.

As indicated at step208inFIG. 4, service or data requests may be generated directly at the DCCS40. Such requests may be formulated through the operator interface components of the DCCS, preferably through an interactive interface, such as a web browser or other graphical user interface. It should be noted that the ability to generate data and service requests directly at the DCCS offers significant advantages over existing techniques for interactive service of diagnostic systems. For example, where the installed base of equipment in a medical facility is not or cannot be equipped for direct communication via an external network, the equipment can nevertheless be coupled to the DCCS via the internal network. Moreover, many medical diagnostic systems and devices are not equipped for operator interface so as to permit formulation of service and data requests. However, the ability to generate such requests directly at the DCCS allows such systems to be included in an overall service provision scheme. Following generation of the request at step208, the screening and license verification functions of step206may be performed as indicated inFIG. 4.

At step210inFIG. 4, the data included in the request is parsed, such as to identify the requesting or designated diagnostic system, specific problems or issues to be addressed, an operator or clinician formulating the request, and so forth. At step212, this information is logged in the memory circuitry of the DCCS. At step214the request is placed in a cue for transmission to the remote service provider. Where a connection session is currently taking place, the request may be transmitted at the earliest communications window available, as indicated at step216. Where necessary, transmission at step216may require the initiation of a connection session. In the presently preferred embodiment, such connections may be initiated either by the DCCS, or by the remote service provider. Where desired, receipt and transmission of the request is confirmed back to the designated diagnostic system as indicated at step218. Moreover, where additional client data is necessary to address the request, this data may be retrieved as indicated at step220. Such data may include particular configurations or parameter settings which may have been in place during an imaging sequence, for example, data streams produced by an imaging system or monitor, service history data, and so forth.

The requests formulated in accordance with the logic ofFIG. 4are transmitted via the external network to the remote service provider.FIG. 5illustrates exemplary logical steps in handling such requests. The handling procedure, indicated generally by reference numeral250, begins with receipt of the request at step252. At step254an acknowledgment message may be formulated by the remote service provider, such as through an automatic return messaging routine, and sent back to the DCCS for informing the facility that the request has been received and is being handled. Such acknowledgement may include additional details regarding the handling, such as reference numbers, dispatch numbers, handling schedules, and so forth. At step256, data from the request is parsed for logging by the remote service provider. The parsing performed at step256may include parsing for similar data to that reviewed at step210ofFIG. 4, such as for an identification of the requesting or designated system, identification of the facility, service subscription data, and parameter or operational data necessary for reviewing and addressing the request. At step254, license or accounting records stored within a database of the remote service provider are accessed and updated to make note of the request. Depending upon the desired accounting structure, the request may be handled under an existing contract or subscription, on a warranty basis, on a pay-per-use basis, or otherwise.

As noted above, depending upon the type of request transmitted from thee medical diagnostic facility, its handling by the remote service provider may assume various modes. As indicated at step260ofFIG. 5, the request is addressed within the service provider for handling, such as for automatic handling, or for intervention of a service engineer. In either event, it may be necessary to obtain additional data from the system to properly address the service request. In the case of medical diagnostic imaging equipment, such additional information may include raw or processed image data files, system configuration parameters and settings, and so forth. As indicated at step262, such data may be retrieved through the external network, DCCS, and internal network of the facility. Once sufficient information has been accessed to address the request, the requested data, reports, analysis, and so forth may be then transmitted from the remote service provider back to the designated medical diagnostic system through the DCCS, or directly back to the DCCS where the request originated there. The transmissions at step264may include a wide range of data. For example, the data may include configuration parameters, suggested troubleshooting steps, electronic messages, electronic documentation, software upgrades, protocols, and so forth. Where necessary, a field service engineer may be dispatched, as indicated at step266inFIG. 5for additional follow up. The field service engineer dispatched at step266may address the request either in person or remotely, such as through telephone or other connections from the remote service provider.

As noted above, responses to requests from the medical diagnostic facility may be transmitted through alternative media, such as a wide area network and a satellite link. The logic ofFIG. 5illustrates one embodiment for processing such transmissions in response to requests. While various media may be employed for this purpose, in a presently preferred embodiment the media have significantly different transmission rates or bandwidths, enabling certain types of transmissions to be made through a first type of connection, such as the wide area network, with more demanding or specific transmissions being made through a higher bandwidth medium. Various approaches may be adopted for deciding which of the media will be employed for the transmission. For example, the remote service provider may manually or automatically select a media depending upon the requirements or preferences of the medical diagnostic facility. Moreover, specific types of transmissions may be made over one medium or the other, such as streaming media transmissions which may require substantial bandwidth, may occupy a link for substantial periods of time, or may be particularly susceptible to interruption or network delays.

In the presently preferred embodiment, the selection of the wide area network or the satellite link is made based upon a category of data or transmission. Thus, at step268ofFIG. 5, the category is reviewed and one of the available media is selected. By way of example, multi-media presentations, training sessions, and similar data categories are transmitted through the satellite link, while more conventional data transmissions are made through the wide area network. Depending upon the transmission category, then, the medium is selected as indicated at either step270or276. The transmission is then scheduled as indicated at step272or step278. In the case of training sessions, for example, the transmission may be scheduled for a later date and time, with the designated diagnostic system being a specific location, training room, or other client of the diagnostic facility. Finally, as indicated at either step274or280, the scheduled transmission is made through the selected medium.

FIG. 6indicates exemplary control logic for receiving and processing transmissions back from the remote service provider to the diagnostic facility. This control logic, designated generally by reference numeral300, begins with receipt of the data transmission at step302. This receipt is through the DCCS, such as in an ongoing data transmission session. At step304, the data received is parsed to identify at least the designated or addressed diagnostic system. At step306the data is forwarded from the DCCS to the designated system via the internal network of the facility. It should be noted that step306may include storing all or part of the data, or information derived or parsed from the data in the memory circuitry of the DCCS, or in another database of the facility. At step308the receipt and communications exchange is logged by the DCCS.

Where required, alternative procedures for the receipt and processing of data may be implemented as indicated inFIG. 7. The alternative receipt steps indicated generally by reference numeral350, may be desirable, for example, in the receipt of digital data via satellite links, with the data being routed through the DCCS for distribution. In particular, such satellite communications systems, or other alternative media, may not require two-way communication. Accordingly, certain of the information for addressing the data may be transmitted in parallel through the other medium, particularly through a wide area network. Thus, at step352, a handshake routine is executed between the DCCS and the remote service provider to insure appropriate connectivity and the ability to exchange the necessary information. At step354, an authentication procedure may be performed to insure that the transmission session via the parallel medium conforms to the request and to the transmission schedule. At step356, the recipient address is identified and confirm, such as to insure that the transmission channel is appropriately tuned or selected, and that the client or diagnostic system is identified within the facility. At step358, the transmission is received and demodulated, filtered, or otherwise processed. As indicated at step360, the data received via the parallel medium may require additional processing, such as to packetize the data for transmission over the internal network. Following such processing, the data is distributed to the designated system. The communication sequence and transmission is logged as indicated at step362.

In addition to the interactive exchange of service and other data, the present technique permits the acquisition of operational and parameter data from the medical diagnostic systems which are clients of the internal network of the facility via a streamlined procedure.FIG. 8illustrates exemplary steps in this procedure, through control logic designated generally by reference numeral400. In general, the procedure enables the data to be acquired or collected from the networked diagnostic systems through the DCCS, and transmitted from the DCCS to the remote service provider. In heretofore known approaches to providing service to medical diagnostic systems, such data was typically acquired through direct connection to a desired diagnostic system, requiring a large number of connections to be made independently and placing substantial demands on infrastructure, both within the facility and at the remote service provider. Moreover, where diagnostic systems were not equipped for connectivity directly to the remote service provider, little or no information could be obtained, particularly directly from the system.

In the present approach, information may be obtained through several different processes, initiated both automatically and manually. In the exemplary logic ofFIG. 8, the data acquisition process may begin with initiation of an automatic polling routine at step402. This routine would be executed by the DCCS which contacts each networked system, or designated systems from which data is desired, on a preestablished schedule. By way of example, the schedule may include periodic data acquisition throughout a 24 hour period, or less frequent acquisition. Depending upon the routine and schedule, the clients are contacted at step404ofFIG. 8. At step406the data is accessed, such as by retrieval from memory circuitry of the client diagnostic systems. At step408the data may be filtered, such as to determine whether complete or incomplete information is acquired, to parse data which is not desired, such as patient-specific data, and so forth. At step410, the data is recorded, such as in the memory circuitry of the DCCS.

As an alternative to the polling process described above, certain data may be collected upon occurrence of a specific event in the diagnostic system or within the facility. For example, where certain of the systems of the facility are mobile, connection of the mobile system to the internal network may cause the DCCS to execute the data acquisition routine for the newly-connected system. Thus, as indicated at step412ofFIG. 8, the specific system or asset may change a state, such as establishing or renewing a connection to the internal network. At step414, then, the system is accessed and desired information is transferred from the system to the DCCS. By way of example, to permit asset tracking, asset management, productivity analysis, and other functions, the location of mobile assets may identified and recorded for later use, or to permit the facility personnel to track the assets.

The data acquisition sequences may also be initiated by a manual request, as indicated at step416inFIG. 8. The manual request may be input via the operator interface components of the DCCS, such as to access and display performance, utilization, and other characteristics or parameters of the networked systems. In response to the manual request, the designated system is accessed, as indicated at step418, and the desired data is located and transmitted from the device memory as indicated at step420.

To facilitate transmission of acquired data to the remote service provider, the acquired data is preferably stored locally at the diagnostic facility, and transmitted to the remote service provider in one or more data communication sessions. Such sessions may be scheduled for convenient times, such as during off-peak hours, nighttime hours, weekends, and so forth.FIG. 9illustrates steps in exemplary control logic, designated generally by reference numeral450, for transmitting the data once acquired at the facility.

Referring toFIG. 9, the data transfer is first scheduled as indicated at step452. As noted, this schedule may be established for convenient times, both for the diagnostic facility and for the remote service provider. It should be noted, however, that such data transfers may be initiated by operator intervention, where desired. As indicated at step454, a connection is then established between the diagnostic facility and the remote service provider. The connection may be initiated by either the facility or the remote service provider, the remote service provider being the preferred initiator in the present embodiment. Also, at step454, the remote service provider prompts the transfer of the data, such as through a communications routine stored at both the DCCS and the remote service provider. In response to the prompt, the data is accessed from the medical facility memory or data repository and transferred to the remote service provider as indicated at step456. During or following the transfer, any desired parsing, filtering, and other processing are performed as indicated at step458. In particular, the transferred data is preferably parsed to identify the individual diagnostic systems originating the data, and to separate operational and parameter data for the individual systems from one another. The data is then stored, preferably in relational databases, for later retrieval and analysis. Finally, at step460, the data transfer session is logged, preferably both at the diagnostic facility and at the remote service provider.