WO2007047588A1

WO2007047588A1 - A healthcare information interfacing system

Info

Publication number: WO2007047588A1
Application number: PCT/US2006/040387
Authority: WO
Inventors: Mark E. Smith; Elizabeth Hough; Catherine Britton; Kiron Rao
Original assignee: Siemens Medical Solutions Usa, Inc.
Priority date: 2005-10-14
Filing date: 2006-10-13
Publication date: 2007-04-26

Abstract

A system employs a universal intermediate record format including designated data fields accommodating data from multiple different healthcare systems (e.g., cardiology imaging Modality systems such as MR, CT scan, ECG) enabling a healthcare data processing application to adaptively and seamlessly operate using data from the multiple different healthcare systems. A healthcare information interfacing system includes an intermediate record having multiple data fields for accommodating received data from multiple different clinical systems. A data converter converts received healthcare data in a first format to a different intermediate record format and stores the converted data of the intermediate record format in the intermediate record. A repository includes data associating healthcare data items used by a healthcare information system with data fields in the intermediate record accommodating the healthcare data items for use in accessing the data items for processing by the healthcare information system.

Description

A Healthcare Information Interfacing System

This is a non-provisional application of provisional application serial No. 60/726,601 by Mark E. Smith et al. filed October 14, 2005.

Incorporated by reference herein is a Computer Program Listing, Appendix, submitted on a disk showing an XML intermediate transaction format used by multiple different healthcare systems to convey data to a healthcare data processing application.

Field of the Invention

This invention concerns a healthcare information interfacing system supporting interfacing multiple different imaging modality devices with a clinical information system and medical records.

Background of the Invention

Existing cardiology and other healthcare information systems lack adaptability and are difficult to integrate with other applications and do not readily process data from other upgraded, changed or newly added healthcare information systems. Existing cardiology applications, for example, typically require programming of code to enable interfacing with a new type of imaging or nonimaging modality device (e.g., MR, CT scan, ECG, ultrasound etc.) or different versions of the same type of imaging modality device. Not all systems follow an industry standard (DICOM is used for some Cardiology Modalities) and require substantial analysis to determine data fields that need to be supported to enable creation of an interface. In one existing cardiology application, code is incorporated to parse individual records received from an imaging modality device. This requires programming specific to each imaging Modality Device and substantial development effort for each imaging Modality system that is to be connected to a Cardiology system. In addition, development effort is needed involving use of an integration engine to configure data to a format that a Cardiology application may process. Changes to the Cardiology application are required each time a new system is to be integrated and interfaced to the application. Changes are expensive, time consuming, and involve outages. A system according to invention principles addresses these deficiencies and related problems.

Summary of the Invention

A system employs a universal intermediate record format enabling a healthcare data processing application to adaptively and seamlessly operate with data from multiple different healthcare systems (e.g., cardiology imaging and non-imaging Modality systems such as MR, CT scan, ECG) and different versions of a particular type of imaging modality. A healthcare information interfacing system includes an intermediate record having multiple data fields for accommodating received data from multiple clinical systems. A data converter converts received healthcare data in a first format to a different intermediate record format and stores the converted data from the first record format in the intermediate record format. A repository includes data associating healthcare data items used by a healthcare information system with data fields in the intermediate record accommodating the healthcare data items for use in accessing the data items for processing by the healthcare information system.

Brief Description of the Drawing

Figure 1 shows healthcare information interfacing system enabling a healthcare data processing application to adaptively operate with data from multiple different healthcare systems, according to invention principles.

Figure 2 shows an overview of a healthcare information interfacing system enabling a healthcare data processing application to adaptively operate with data from multiple different healthcare systems, according to invention principles.

Figure 3 shows an intermediate record structure employed by a healthcare information interfacing system, according to invention principles.

Computer Program Listing Appendix

A Computer Program Listing Appendix, submitted on a disk shows an XML intermediate transaction format used by multiple different healthcare systems to convey data to a healthcare data processing application as described herein, according to invention principles.

Detailed Description of the Invention

A system according to invention principles eliminates a need for change to be made to an executable clinical information application upon interfacing and integrating the application with a new third party (e.g., imaging modality) system. Specifically, a Cardiology application, for example, employs a Generic Modality Interface Record (GMIR) that enables Cardiology Modality interfaces to be easily implemented. The system employs an intermediate transaction record format that allows multiple (e.g., different types of modality device) systems to communicate information without additional application configuration or coding. For example, Cardiology application A employs an inclusive intermediate transaction record format incorporating data fields to hold and convey any data that application A needs and supports. For example, the intermediate transaction record format supports data that the Cardiology application currently supports and data it is to support in the future. An integration engine maps data from any imaging modality device to data fields in the intermediate transaction record format to be compatible with, and usable by, the Cardiology application. The intermediate transaction record format is a universal record format for Cardiology Modality devices that encompasses known data that is to be conveyed between an imaging modality device and a Cardiology system. For instance, a cardiology system (application A) currently supports known Cardiology devices including ECG devices and needs to support CT scan imaging devices in the future. Further, Cardiology application A currently supports ECG devices so the system enables data from any ECG system to be integrated with Cardiology application A without any changes to application A.

An executable application as used herein comprises code or machine readable instruction for implementing predetermined functions including those of an operating system, healthcare information system or other information processing system, for example, in response user command or input. An executable procedure is a segment of code (machine readable instruction), sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes and may include performing operations on received input parameters (or in response to received input parameters) and provide resulting output parameters. A processor as used herein is a device and/or set of machine-readable instructions for performing tasks. A processor comprises any one or combination of, hardware, firmware, and/or software. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a controller or microprocessor, for example. A display processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

Figure 1 shows healthcare information interfacing system 100 enabling a healthcare data processing application to adaptively operate with data from multiple different healthcare systems. An integration engine 40 exchanges data between different computer systems including imaging (and non-imaging) modality systems 20 and HIS 10 using network 21 by mapping data fields of modality devices 20 to data fields of intermediate transaction record 15. HIS 10 comprises a cardiology information system 19 including an application, for example. Modality devices 20 include MR imaging device 25, CT scan device 27, ECG device 30 and ultrasound device 35. Modality devices 20 may also include other modality devices such as an X-ray device and a nuclear imaging device. Integration engine 40 eliminates a need for an HIS 10 application (e.g., a Cardiology application 19), for example, to be aware of how to interface to each individual Modality device of devices 20. The HIS 10 application is aware of type of data received and the source modality device based on the location (e.g., section) of the intermediate transaction record 15 that is populated. An individual modality device sends data in a particular format (including a proprietary format) and integration engine 40 maps the data to the intermediate transaction record 15 format so that the HIS 10 application is able to receive and process it.

System 100 enables upgrades to the HIS 10 application and upgrades to systems of Modality devices 20 without the need for update to intermediate transaction record 15. This also eliminates the need to update integration engine 40 when an update to the HIS 10 application and upgrades to systems of Modality devices 20 occur. System 100 also advantageously supports DICOM compatible and non-DICOM compatible modality devices. Further, system 100 eliminates or reduces additional development costs and speeds establishment of connection and communication between the HIS 10 application and Modality devices 20. In addition, by using pre-determined intermediate transaction record 15, system 100 supports substantially all or a large majority of data elements that may be communicated between the HIS 10 application and Modality devices 20 over the lifetime of these units. In contrast, existing systems interfaces need updating with each application update in order to take advantage of new functionality.

Healthcare information interfacing system 100 includes intermediate record 15 having multiple data fields for accommodating received data from a multiple different clinical systems 20 (e.g., different imaging and non-imaging modality devices or systems). Intermediate record 15 format comprises an XML compatible data format (an XML representation of the intermediate record layout) (as exemplified in Computer Program Listing Appendix). Intermediate record 15 is partitioned into sections that have multiple data fields and are designated for holding data derived from multiple different modality devices. The multiple data fields of intermediate record 15 accommodate received data from multiple different types of imaging modality device systems. Further, the sections of different types of data of intermediate record 15 include multiple sections designated for holding data from corresponding multiple different imaging modality devices 20. Data converter 23 converts healthcare data received in multiple different formats (including DICOM and non-DICOM compatible formats) to a different intermediate record format and stores converted data from the first record format in intermediate record 15. Specifically, data converter 23 converts received healthcare data from a particular modality device in a first format to a different intermediate record format and stores the converted data from the first record format in a section of intermediate record 15.

Repository 17 includes data associating healthcare data items used by HIS 10 with data fields in intermediate record 15 that accommodate the healthcare data items. Repository 17 is used in accessing the data items for processing by HIS 10 involving parsing the data fields in intermediate record 15. HIS 10 hierarchically parses the data fields in intermediate record 15 using multiple different parsers in a preferred sequence in order to access particular types of data in a corresponding preferred sequence. Patient result data from a modality device 20 is stored in intermediate record 15 in XML format and is accessed and processed by a parser in a Cardiology application, for example, in HIS 10. The Cardiology application employs a separate parser for each modality device of devices 20 that provides data to intermediate record 15. The parsers in the Cardiology application in HIS 10 include parsers termed, Common, Cath, EP, Echo, ECG, Argus and Calcium Scoring parsers, for example. A data processor in HIS 10 uses data in repository 17 and processes and parses converted data in data fields of a section of intermediate record 15 for use by the cardiology application. The data processor hierarchically parses the information in the data fields of intermediate record 15 to identify, firstly information common to multiple different modality devices and secondly information specific to a particular type of modality device.

A Common parser is used to parse data from multiple different modality devices and processes data in a corresponding Common section of intermediate record 15. The Common parser processes data in the Common section of intermediate record 15 including Order/Service Details, Patient information, Patient ID, order ID, Associated Staff Information, Supplies information, Medications information and Study information. The Common parser determines whether an order ID sent by a modality of modalities 20 matches an order ID in the Cardiology application. If the order ID does not match, the Common parser exits without processing the acquired modality result data in the intermediate record 15 XML file. The Common parser also determines whether a patient ID sent by the modality device matches a patient ID within the Cardiology application. The Patient ID along with the order ID or a service abbreviation are used to identify the patient record in which the acquired modality result data is to be stored. The Common parser also uses Associated Staff Information in determining whether the names of staff members involved in a patient examination matches with names of staff in the Cardiology application. If they do not match, the Common parser stores an error indication.

The Common parser also updates the Cardiology application database with the details of supplies and medications employed in an examination (and that are to be re-ordered). The Common parser also stores image study information indicating an anatomical site related to a patient examination. Further, the Common parser creates database objects that are necessary for storing data from the Common section of intermediate record 15 into the Cardiology application database, depending on which parts of the Common section contain data and stores the data in the database (repository 17) as required. The Common parser also creates objects that are necessary to store the result data in the Cardiology application database and invokes a modality-specific parser.

The Common section data is parsed by the Common parser before a Cath (catheterization modality) parser is invoked. A Cath parser is used to parse data from a catheterization modality device and processes data in a corresponding Cath section of intermediate record 15. The result information derived by the Cath parser is associated with relevant database objects created by the Common parser and stores the result information in the Cardiology application database (repository 17). The Cath parser processes data in the Cath section of intermediate record 15 including Conditions, Site and Other data. The Cath parser stores data indicating conditions related to the Cath procedure and updates the Cardiology application database with the details of the conditions as required. The Cath parser identifies and stores anatomical site related information for a specific condition in a Condition related section of the Cardiology application database (repository 17) and updates the Cardiology application database with the details of the site as required. The Cath parser also updates sections of the Cardiology application database external to the Condition related section with Other data that is not relevant to the condition or the site, as required.

The Common section data is also parsed by the Common parser before an EP (electrophysiology modality) parser is invoked. An EP parser is used to parse data from an electrophysiology modality device and processes data in a corresponding EP section of intermediate record 15. The EP parser processes data in the EP section of intermediate record 15 including Conditions, Site information and Result information and creates database objects including the processed information for storage in corresponding sections of the Cardiology application database. The EP parser stores data indicating conditions related to the EP procedure and updates the Cardiology application database with the details of the conditions as required. The EP parser identifies and stores anatomical site related information for a specific condition in a specific section of the Cardiology application database (repository 17) and updates the Cardiology application database with the details of the site as required. The Result information related to the EP procedure derived by the EP parser is associated with relevant database objects created by the Common parser and stores the result information in the Cardiology application database (repository 17).

The Common section data is further parsed by the Common parser before an Echo (echocardiography modality) parser is invoked. An Echo parser is used to parse data from an echocardiography modality device and processes data in a corresponding Echo section of intermediate record 15. The Echo parser processes data in the Echo section of intermediate record 15 including Conditions, Site information and Procedure information and creates database objects including this processed information for storage in corresponding sections of the Cardiology application database. The Echo parser stores data indicating conditions related to the Echo examination and updates the Cardiology application database with the details of the conditions as required. The Echo conditions data may be replicated and correspond to different conditions of the Patient. The Echo parser identifies the database objects for a particular condition and associated identification number and stores the data in a specific section of the Cardiology application database (repository 17) using a created object. The Echo parser identifies and stores anatomical site related information for a specific site (and associated site number) for a particular condition in a specific section of the Cardiology application database (repository 17) and updates the Cardiology application database with the details of the site as required. The Procedure information derived by the Echo parser for the echo examination for a specific site (and associated site number) for a particular condition is stored in a specific section of the Cardiology application database (repository 17) and updates the Cardiology application database with the details of the site as required.

The Common section data is additionally parsed by the Common parser before an ECG (electrocardiography modality) parser is invoked. An ECG parser is used to parse data from an electrocardiography modality device and processes data in a corresponding ECG section of intermediate record 15. The ECG parser processes data in the ECG section of intermediate record 15 including Conditions and Result information and creates database objects including this processed information for storage in corresponding sections of the Cardiology application database. The ECG parser stores data indicating conditions related to the ECG examination and updates the Cardiology application database with the details of the conditions as required. The Result information related to the ECG examination derived by the ECG parser is associated with relevant database objects created by the Common parser and stores the result information in the Cardiology application database (repository 17). Other modality parsers employed by the Cardiology application using corresponding storage sections in intermediate record 15 include Nuclear Medicine, Argus and Calcium Scoring parsers.

Figure 2 shows an overview of a healthcare information interfacing system enabling a healthcare data processing application to adaptively operate with data from multiple different healthcare systems. CT scan device 20 communicates Transaction 2 incorporating multiple data fields to integration engine 40. Integration engine 40 maps Transaction 2 to intermediate record 15 based on predetermined instruction. The intermediate record 15 format includes a Common (generic) section used for data from multiple different modality devices as well as modality specific sections individually being designated for use for data from a specific modality devices. The Common section contains data common to most modality types (patient name, identifier, etc.). The modality specific section contains fields to transport known modality specific data for that specific modality. Intermediate record 15 is communicated (4) to Cardiology application 19 within HIS 10 and Cardiology application 19 performs application specific processing on the data using common and modality specific parsers.

Figure 3 indicates Common section 303, an ECG modality specific section 307 and CT scan modality specific section 309 in the intermediate record 15 structure.

Intermediate record 15 is advantageously partitioned into sections by type of data and type of modality to facilitate access to modality data by a cardiology application, for example. Data from a source Modality (MRI, CT scan, X-ray, Ultrasound, or other device) has a designated corresponding location in data fields of a generic transaction format. Integration engine 40 may use all or a portion of the data sent from a source modality at a particular time. Further, as the cardiology application matures (e.g., is enhanced or upgraded), the application may choose to use more of the data sent from a source modality without changes to the integration engine 40 interface. Intermediate record 15 supports data that is relevant to multiple individual different modality devices. Integration engine 40 analyzes incoming data from a source modality and determines corresponding designated storage data fields based on modality type and data type in response to predetermined mapping instruction. Intermediate record 15 further supports adding a newer version of a modality device as well as a new different type of modality device.

Intermediate record 15 includes substantially all or a large proportion of potential data fields likely to be needed during the life of a cardiology application even though the application, in its current state, may not support every individual modality and data type. Initially, integration engine 40 maps received modality data from devices 20 to data fields in intermediate record 15 and the cardiology application processes the fields in record 15 that the application currently supports and ignores the other data fields. In response to upgrade of the cardiology application to a version that supports more of the source modality data already present in intermediate record 15, the cardiology application is able to immediately access the data in the fields that it had previously ignored. Thereby, no integration engine 40 changes are required. Cardiology application and integration engine 40 development efforts may be performed in parallel toward a common target which accelerates modality device and cardiology application integration

The data fields of a modality specific section of intermediate record 15 transport data known to be supported by the specific modality type. As a need to support new modalities arises, new sections are added to intermediate record 15. Therefore, there is no need to update intermediate record 15 when an interface to a different vendor modality is required since intermediate record 15 supports this specific modality type. For example, CT scan data is supported by record 15 enabling an interface between a CT scan modality device provided by a first manufacturer and the Cardiology application. Intermediate record 15 also supports CT scan data provided by a second manufacturer so that no changes are required to support both manufacturers' devices if desired. In contrast, in existing systems a transaction format would need to be modified, involving change to previously provided interfaces to use the modified transaction format. Similarly, the cardiology application is able to process the complete complement of data fields in intermediate record 15 so there is no need to change the cardiology application to support new types of modality device (adding an EKG modality, for example), different versions of a particular type of modality device and modality devices of different manufacturers. In similar fashion, integration engine 40 enables backward supportability without need for interface or application change.

An exemplary structure of intermediate record 15 record format using an XML transaction format is provided in a Computer Program Listing (this is an XML representation of the intermediate record layout) Appendix incorporated by reference herein. The Appendix exemplifies an XML intermediate transaction format used by multiple different healthcare systems to convey data to a Cardiology application to update data fields within a Cardiology application database. Integration engine 40 communicates the exemplary XML format to the Cardiology application system for update purposes. The data is communicated electronically between a modality and the Cardiology application system via integration engine 40.

The systems presented in Figures 1-3 are not exclusive. Other systems and processes may be derived in accordance with the principles of the invention to accomplish the same objectives. Although this invention has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the invention. A system according to invention principles is applicable to automatically integrate a clinical application with multiple different healthcare systems including new and upgraded systems. Further, any of the functions provided in the systems of Figures 1-3 may be implemented in hardware, software or a combination of both and may reside on one or more processing devices located at any location of a network linking the Figure 1 elements or another linked network including another intra-net or the Internet.

Claims

What is claimed is:

1. A healthcare information interfacing system, comprising: an intermediate record having a plurality of data fields for accommodating received data from a plurality of different clinical systems; a data converter for, converting received healthcare data in a first format to a different intermediate record format and storing said converted data of said intermediate record format in said intermediate record; and a repository including data associating healthcare data items used by a healthcare information system with data fields in said intermediate record accommodating said healthcare data items for use in accessing said data items for processing by said healthcare information system.

2. A system according to claim 1, wherein said healthcare information system comprises a cardiology application, said intermediate record is partitioned into sections of different types of data and said plurality of data fields of said intermediate record accommodates received data from a plurality of different types of modality device systems.

3. A system according to claim 2, wherein said different clinical systems comprise different modality devices and said sections of different types of data of said intermediate record include a plurality of sections designated for holding data derived from a corresponding plurality of different modality devices.

4. A system according to claim 1 , wherein said modality device systems include at least one of, (a) imaging modality devices and (b) non-imaging modality devices and said intermediate record format comprises an XML compatible data format.

5. A system according to claim 1, wherein said healthcare information system parses said data fields in said intermediate record in accessing said data items and said healthcare information system hierarchically parses said data fields in said intermediate record using a plurality of parsers in a preferred order for accessing particular types of data first.

6. A system according to claim 1, wherein said data converter converts received healthcare data in plurality of different formats including said first format to a different intermediate record format and said plurality of different formats include DICOM and non-DICOM compatible formats.

7. A system according to claim 3, wherein said plurality of different modality devices include at least two imaging modality devices of, (a) an MRI device, (b) a CT scan device, (c) an X-ray device, (d) an Ultrasound device and (e) a nuclear imaging device.

8. A system according to claim 1 , including a data processor for using data in said repository and processing and parsing converted data in data fields of said intermediate record for use by said healthcare information system and said different clinical systems comprise different modality devices and said data processor parses said data fields of said intermediate record to identify, information common to a plurality of different modality devices and information specific to a particular type of modality device.

9. A system according to claim 8, wherein said data processor hierarchically parses said information in said data fields of said intermediate record to identify, firstly information common to a plurality of different modality devices and secondly information specific to a particular type of modality device.

10. A cardiology information interfacing system, comprising: an intermediate record having a plurality of data fields for accommodating received data from a plurality of different modality systems; a data converter for, converting received healthcare data in a plurality of different formats including DICOM and non-DICOM compatible formats to a different intermediate record format and storing said converted data of said intermediate record format in said intermediate record; and a repository including data associating healthcare data items used by a cardiology information system with data fields in said intermediate record accommodating said healthcare data items for use in accessing said data items for processing by said cardiology information system.

11. A system according to claim 10, wherein said intermediate record is partitioned into sections of different types of data and said plurality of data fields of said intermediate record accommodates received data from a plurality of different types of modality device systems.

12. A healthcare information interfacing system, comprising: an intermediate record including sections designated for holding data derived from a plurality of different modality devices, an individual section having a plurality of data fields; a data converter for, converting received healthcare data from a particular modality device in a first format to a different intermediate record format and storing said converted data of said intermediate record format in a section of said intermediate record; a repository including data associating healthcare data items used by a healthcare information system with data fields in said intermediate record accommodating said healthcare data items for use in accessing said data items for processing by said healthcare information system; and a data processor for using data in said repository and processing and parsing converted data in said section of said intermediate record for use by said healthcare information system.

13. A system according to claim 12, wherein said data processor parses converted data in said section of said intermediate record to identify, information common to a plurality of different modality devices and information specific to a particular type of modality device and said intermediate record is partitioned into said sections designated for holding data derived from a plurality of different modality devices, an individual section having a plurality of data fields.