Providing
an
Integrated Clinical Data View in a Hospital Information System that Manages Multimedia Data
Ruth E. Dayhoff, Daniel L. Maloney, T. James Kenney, Ross D. Fletcher Washington Information Systems Center Dept. of Veterans Affairs, 8403 Colesville Road, Suite 200 Silver Spring, Maryland 20910 (301) 427-3700 Abstract
The VA's hospital information system, the Decentralized Hospital Computer Program (DHCP), is an integrated system based on a powerful set of software tools with shared data accessible from any of its application modules. It includes many functionally specific application subsystems such as laboratory, pharmacy, radiology, and dietetics. Physicians need applications that cross these application boundaries to provide useful and convenient patient data. One of these multi-specialty applications, the DHCP Imaging System, integrates multimedia data to provide clinicians with comprehensive patient-oriented information. User requirementsfor crossdisciplinary image access can be studied to define needs for similar text data access. Integration approaches must be evaluated both for their ability to deliver patientoriented text data rapidly and their ability to integrate multimedia data objects. Several potential integration approaches are described as they relate to the DHCP Imaging System.
are made, stained, and read. Images of those slides are stored with the surgical pathology data as part of the patient's record. The treating physician, the bronchoscopist, and the pathologist would like to see all of the images and text data that are associated with this bronchoscopy procedure, without having to navigate
multiple applications. As another example, a bone marrow biopsy is done by the hematology subspecialists (see Figure 2). Two specimens are obtained. One is sent to the pathology laboratory for examination. The second is used for special staining in the hematology research laboratory. Images are captured from each of these specimens, but they are stored with
Need for Integration across Medical Specialties Medicine typically divides its records into departmental categories such as lab results, pharmacy prescriptions, xrays, pathology slides, etc. Medical information systems have followed this pattern, with separate systems or modules for each hospital department. Physicians on the other hand need to view all of their patient's data in an integrated way that reflects its many interrelationships. This need for applications that cross departmental boundaries has become quite apparent as the VA's DHCP Integrated Imaging System combines images with patient text data [1,2]. The following are two examples of physicians' needs for cross-department image access.
During a bronchoscopy procedure a suspicious area is found (see Figure 1). The bronchoscopist captures an image of the gross in situ pathology and adds it to the medicine application's bronchoscopy procedure data. A biopsy is performed through the bronchoscope. The specimen is sent to the pathology laboratory, where slides 0195-4210/91/$5.00 C) 1992 AMIA, Inc.
S01
Figure 1 A procedure such as a bone marrow biopsy might produce multiple specimens sent to different laboratories, generating multiple data objects.
text data from separate DHCP packages -- laboratory and medicine respectively. When the treating physician views the images associated with this procedure, both sets of images should be available for comparison. The VA is fortunate to have an integrated hospital information system which is based on a central set of software development tools and allows any of its data to be made available to any of its applications subsystems. Unlike many private hospital systems composed of subsystems produced by multiple vendors and running on different hardware and software platforms, the DHCP system operates on interoperating hardware running the same software, with control of all data structures from a single data dictionary [3]. DHCP includes many functionally specific applications subsystems, such as the laboratory, pharmacy, radiology, or administration packages. A few DHCP applications were designed to meet multi-disciplinary needs, such as the medicine package which spans a number of medical subspecialties. Recently, the order entry/result reporting and health summary packages have been built to span existing functionally specific applications.
Figure 2 A medical procedure such as a bronchoscopy can result in numeric, text, or image data, and may generate further data associated with another examination.
Clinical Data Views
All medical data, including textual data, can be thought of as objects that combine in various ways to create larger objects (see Figure 3). For example, the numeric values, textual report, and images are each objects by themselves, and they combine to form a larger object pertaining to a bronchoscopy procedure. These larger objects in turn combine to create even larger objects such as visit records. Hospital users need at least three different types of views of these data objects: patient-oriented clinical data views, departmental specialty views, and management views.
constitute a set. Chest xrays consisting of two films (PA and lateral) are a set. In displaying images for the physician, it is not adequate to manipulate sets of images from separate applications sequentially. It must be possible to place an image or images from each set on the same screen for comparison or overlay them if necessary. That is, images should be treated as elements of the patient's record, and their use in displays should not be restricted based on the application or subsystem from which they came. There may be logical links between images, either to group elements of a set or to group elements across sets. The physician wants to see both images and corresponding text data simultaneously. The medical record containing images, as well as other medical data, fits well into an object-oriented paradigm.
The clinical data view requires access to images and text data in a number of ways. For example, there are situations where the physician needs to see: o all images of a particular patient o all images pertaining to a particular visit or procedure, including images pertaining to biopsy specimens or simultaneous procedures o all images of a particular type within a time period o the critical images from each procedure o all images related to a particular diagnosis of a patient o all images in the hospital information system related to a particular diagnosis (across patients) The images pertaining to each procedure or study
Integration Approaches At the present time, a number of researchers are wrestling with questions related to the display of a patient-oriented record [4,5]. This may be because networking technology has finally advanced to the point where it allows certain types of integration [6]. Application software has progressed enough that functionally specific subsystems
502
clik
_
w_wo 'io _*_ J_l
A----
*
'Opp.=
d
....- -.7
lol
.mdhmwilmftmmmdwadft p1wommunft
Figure 3 All medical data, including text and image data, can be thought of as objects that combine in various associations to create larger objects. are useful, and users begin to project new needs. However, many groups are finding the costs and effort involved prohibitive.
may "store" data either by reference to its location on the network or by containing its actual value. This approach allows the flexibility to adjust the replication of data by data item to achieve acceptable access times. As hardware and network speeds change, it allows particular data items to change from "data by value" storage to "data by reference" storage or vice versa. Virtual data (data stored by reference) can be used from within a subsystem or an integrating structure.
Typically, HIS's store data in subsystems based on administrative divisions within the hospital, such as laboratory, pharmacy, radiology, and medical administration. These subsystems may reside on separate hardware or they may be implemented with different software and data structures, or both. The DHCP system uses the same hardware, software environment and DBMS for the entire hospital system, but subsystems often use somewhat different data structures. The physician needs a longitudinal patient-oriented view that presents data from each of these packages on the same screen.
Multimedia data constitutes an important part of the patient's clinical record. With the recent technology advances in multimedia data storage and display, it is clear that HIS's will need to handle a variety of data in the future. Therefore, a successful integration approach must be able to manage multiple data types.
This integration can be achieved in several different ways:
Option 1: Data may continue to be stored primarily in functionally specific data structures. Various indexing schemes [9] or a metadictionary [4,8,9] may be used to provide rapid user access to data. Option 2: If data access does not meet the users' needs for rapid access, data may be duplicated in a central location in another format [6].
Option 3: A combination of these may be achieved by using a "virtual database" [5] or "virtual data." A virtual database serves the function of a metadictionary in providing access to any data on the system. However, it
Images represent an extreme type of data, and are useful in defining the necessary capabilities of an integration approach. Image data is stored as objects that are individually quite large. The need to store images on multiple media types, such as magnetic and optical disks [10], makes storage of the data by value in a number of subsystems impractical (option 1). Because image data is stored in large aggregates, image display entails very little overhead related to locating the data. Display times are relatively long for each image object, approximately 1000 times as long as to remotely access a text data node across a network. Therefore, the integration option 2 -duplication of image data in a central location - is not desirable because of the high storage costs and the low
503
I
relative overhead for access. We have used the virtual data approach of the third option -- storing image data by reference (or pointer) 'virtually' in the specialty subsystems and accessing these image objects across a high speed network. The same virtual storage can be used by integrating structures or as part of a virtual database. inage Integration with the VA's Hospital
Information System The VA has extended its database management system to support the management of image and other multimedia data. A production prototype system is currently operational in the Washington VAMC. Image modules include cardiology, pulmonary medicine, surgical pathology, gastrointestinal endoscopy, rheumatology, and hematology with radiology, nuclear medicine, surgery, ophthalmology, and dermatology expected soon. The VA's medicine package provides the initial integration step for text as well as image data. The package provides for the entry, editing and viewing of data for a large number of medical tests and procedures. Printed reports can be produced for all procedures. The medicine package currently has five modules including cardiology, pulmonary medicine, gastroenterology, hematology, and pacemaker, with a sixth module, rheumatology, currently in testing. Renal/dialysis, infectious disease, endocrinology, and dermatology modules are to be added in future versions. Images can be captured either through a separate menu option available on each subspecialty menu or through the packages' various enter/edit options. To integrate the medical subspecialty data for the treating physician, the medicine package provides a helpful patient summary feature which presents a short summary of all procedures that a patient has received. Summary image abstracts are presented simultaneously [11]. The medical patient's record is longitudinal. All procedures stored on the computer are available to the physician, and are presented in reverse chronological order. The patient summary can also be sorted by medical procedure type or be limited to one particular procedure type (such as catheterization, colonoscopy, etc.). A physician desiring more detailed information about a particular procedure may 'drill down" (a simple list selection for more specific information) to obtain the full procedure report with high resolution images. In order to support these specialty specific and crossspecialty integrated views, several data structures are used. The main database uses procedure type as the
504
primary key and a unique patient number as the secondary key. Procedure date/time is stored as data, along with measurements, results, descriptions, and image
references. The database has two major indices: (1) to access procedure-specific data, there is an index by procedure type, procedure date/time, and medical patient id number; and (2) to produce the integrated patient summaries, there is an index by medical patient identification number, reverse chronological visit date/time, and procedure type.
Inage Storage in an Object File The VA's DHCP hospital information system is based on a common database management system with an active data dictionary. This MUMPS-based system called VA FileMan provides the necessary support for complex object models as described by Khoshafian and Abnous [12], including "the ability to store sets of atomic values, tuple-valued attributes, sets of tuples, and object identity. " It forms a powerful basis for an object-oriented database management system to store single or sequential images, and ultimately other multimedia object types [2]. To relate these objects to the patients' other data, an image field is added to each application. This field references one or more image that is stored in an object file [13]. An object type file and a storage location file serve as support files to the object file. The Object File: The object file is used to store the necessary data for each object. Each object has a natural language name which the user assigns. Depending on the object type, the object will either have: o a filename and logical location on the network (e.g. single image, graphics) o a multiple field called "object group" which contains entries which point back to the object file (e.g. image series or tiled abstract display) o a set of data points and text (e.g. overlay) o executable code (e.g. pause, clear screen)
Additional identifying information specific to the application is stored in the object file. This includes: patient identifier, procedure identifier, date/time of collection, collector, whether the object is of key importance, a short and a long text description of the
object. Location File: Because the Imaging System uses a distributed environment, an object may be stored on one or more of the network storage devices. These include multiple magnetic file servers, one or more optical
jukebox, and possibly additional network devices that are accessed through a gateway [ 1]. The logical location attribute of the object file provides a mapping facility for This allows a rapid software physical devices. reconfiguration in the event of a failure of one of the system components. Additional fields in the location file are used to indicate the storage device(s) on which the object resides or the method of access across a gateway.
Object Type File: Objects of various types are handled by the Object Type File. These include: still images, image groups, image overlays, executable code, and graphics. An object, such as an image series, may actually consist of multiple objects (still images). In this case, the object group multiple field is used to point to a series of images in the object file. Each object type has associated methods (code) for performing certain actions. For example, there must be methods for capturing and storing images, displaying images, and creating image abstracts. These methods handle any variations due to hardware type. The group type is used to combine multiple objects of the same or different types to create complex objects. Display of text data in the patient summary also uses an object-oriented approach. There is a procedure file which includes the name of each procedure, its file number, and the name of the MUMPS routine (method) to be executed to display the text summary. Thus the physician gets both a text and image summary of the patient's procedures. Use of references to the object file by the specific applications in conjunction with integrating structures provides many of the types of physician access described above.
Conclusions The DHCP Imaging System is a production prototype which serves to illustrate the needs for cross specialty image data access and integrated display. Images are currently being stored by reference as part of patient's medical procedure records and surgical pathology reports. The object files have been implemented in this test environment and have proven useful. The storage of image data is constrained by its characteristics in different ways from text data. This means that its primary storage in specialty subsystems should be virtual. A central image repository is a service to these other subspecialty data structures. When designing schemes for integration across functionally specific subsystems, it is important that the approach
505
handle all types of data access including image and other multimedia objects.
References 1. Dayhoff RE, Maloney DL. Providing Image Management and Communication (IMAC) Functionality as an Integral Part of an Existing Hospital Information System, Proc Medical Imaging IV Conf, SPIE, 1990. 2. Dayhoff, RE, Maloney DL, Kuzmak, PM. Experience with a MUMPS-Based Hospital Information System with Images, Proc MUMPS Users Group, 1991, pp. 53-56. 3. Dayhoff RE, Maloney DL, Kuzmak PM. Examination of Architectures to Allow Integration of Image Data with Hospital Information Systems, Proc SCAMC 1990, pp. 694-698. 4. Friedman C, Hripcsak G, Johnson S, Cimino J, Clayton P. A Generalized Relational Schema for an Integrated Clinical Patient Database, SCAMC 1990, pp. 335-339. 5. Margulies D, McCallie D, Elkowitz A, Ribitzky R. An Integrated Hospital Information System at Children's Hospital, SCAMC 1990, pp. 699-703. 6. Lorins Harold. Aspects of Distributed Computer Systems, 1990. 7. McDonald CJ, Blevins L, Tierney WM, Martin DK. The Regenstrief Medical Records, MD Computing Vol 5, 1988, pp. 34-47. 8. King C, Holland Z, Bloom S. Using Networking Technology with the CO-WRITER Query/Report Generator, MUG Quarterly XIX(3): 41-42, 1989. 9. Webster S, Morgan MM, Barnett GO. Medical query language: flexible access to a standard MUMPS database, MUG Quarterly XVI(4), pp. 9-11, 1987. 10. Kuzmak PM, Dayhoff RE, Maloney DL. Management of the Storage of Digitized Images from a MUMPS Environment, Proc MUMPS Users Group, 1991, pp. 65-67. 11. Dayhoff RE, Maloney DL. Interacting with Images in a Hospital Information System, Proc MUMPS Users Group, 1990, pp. 129-133. 12. Khoshafian S, Abnous R. Object Orientation: Concepts, Languages, Databases, User Interfaces, Ch 7: Object Oriented Databases, John Wiley&Sons, pp 257-321 13. Maloney DL, Dayhoff RE, Multimedia Object File Design for Medical Images, Proc MUMPS Users Group 1991, pp 57-60.
an
Integrated Clinical Data View in a Hospital Information System that Manages Multimedia Data
Ruth E. Dayhoff, Daniel L. Maloney, T. James Kenney, Ross D. Fletcher Washington Information Systems Center Dept. of Veterans Affairs, 8403 Colesville Road, Suite 200 Silver Spring, Maryland 20910 (301) 427-3700 Abstract
The VA's hospital information system, the Decentralized Hospital Computer Program (DHCP), is an integrated system based on a powerful set of software tools with shared data accessible from any of its application modules. It includes many functionally specific application subsystems such as laboratory, pharmacy, radiology, and dietetics. Physicians need applications that cross these application boundaries to provide useful and convenient patient data. One of these multi-specialty applications, the DHCP Imaging System, integrates multimedia data to provide clinicians with comprehensive patient-oriented information. User requirementsfor crossdisciplinary image access can be studied to define needs for similar text data access. Integration approaches must be evaluated both for their ability to deliver patientoriented text data rapidly and their ability to integrate multimedia data objects. Several potential integration approaches are described as they relate to the DHCP Imaging System.
are made, stained, and read. Images of those slides are stored with the surgical pathology data as part of the patient's record. The treating physician, the bronchoscopist, and the pathologist would like to see all of the images and text data that are associated with this bronchoscopy procedure, without having to navigate
multiple applications. As another example, a bone marrow biopsy is done by the hematology subspecialists (see Figure 2). Two specimens are obtained. One is sent to the pathology laboratory for examination. The second is used for special staining in the hematology research laboratory. Images are captured from each of these specimens, but they are stored with
Need for Integration across Medical Specialties Medicine typically divides its records into departmental categories such as lab results, pharmacy prescriptions, xrays, pathology slides, etc. Medical information systems have followed this pattern, with separate systems or modules for each hospital department. Physicians on the other hand need to view all of their patient's data in an integrated way that reflects its many interrelationships. This need for applications that cross departmental boundaries has become quite apparent as the VA's DHCP Integrated Imaging System combines images with patient text data [1,2]. The following are two examples of physicians' needs for cross-department image access.
During a bronchoscopy procedure a suspicious area is found (see Figure 1). The bronchoscopist captures an image of the gross in situ pathology and adds it to the medicine application's bronchoscopy procedure data. A biopsy is performed through the bronchoscope. The specimen is sent to the pathology laboratory, where slides 0195-4210/91/$5.00 C) 1992 AMIA, Inc.
S01
Figure 1 A procedure such as a bone marrow biopsy might produce multiple specimens sent to different laboratories, generating multiple data objects.
text data from separate DHCP packages -- laboratory and medicine respectively. When the treating physician views the images associated with this procedure, both sets of images should be available for comparison. The VA is fortunate to have an integrated hospital information system which is based on a central set of software development tools and allows any of its data to be made available to any of its applications subsystems. Unlike many private hospital systems composed of subsystems produced by multiple vendors and running on different hardware and software platforms, the DHCP system operates on interoperating hardware running the same software, with control of all data structures from a single data dictionary [3]. DHCP includes many functionally specific applications subsystems, such as the laboratory, pharmacy, radiology, or administration packages. A few DHCP applications were designed to meet multi-disciplinary needs, such as the medicine package which spans a number of medical subspecialties. Recently, the order entry/result reporting and health summary packages have been built to span existing functionally specific applications.
Figure 2 A medical procedure such as a bronchoscopy can result in numeric, text, or image data, and may generate further data associated with another examination.
Clinical Data Views
All medical data, including textual data, can be thought of as objects that combine in various ways to create larger objects (see Figure 3). For example, the numeric values, textual report, and images are each objects by themselves, and they combine to form a larger object pertaining to a bronchoscopy procedure. These larger objects in turn combine to create even larger objects such as visit records. Hospital users need at least three different types of views of these data objects: patient-oriented clinical data views, departmental specialty views, and management views.
constitute a set. Chest xrays consisting of two films (PA and lateral) are a set. In displaying images for the physician, it is not adequate to manipulate sets of images from separate applications sequentially. It must be possible to place an image or images from each set on the same screen for comparison or overlay them if necessary. That is, images should be treated as elements of the patient's record, and their use in displays should not be restricted based on the application or subsystem from which they came. There may be logical links between images, either to group elements of a set or to group elements across sets. The physician wants to see both images and corresponding text data simultaneously. The medical record containing images, as well as other medical data, fits well into an object-oriented paradigm.
The clinical data view requires access to images and text data in a number of ways. For example, there are situations where the physician needs to see: o all images of a particular patient o all images pertaining to a particular visit or procedure, including images pertaining to biopsy specimens or simultaneous procedures o all images of a particular type within a time period o the critical images from each procedure o all images related to a particular diagnosis of a patient o all images in the hospital information system related to a particular diagnosis (across patients) The images pertaining to each procedure or study
Integration Approaches At the present time, a number of researchers are wrestling with questions related to the display of a patient-oriented record [4,5]. This may be because networking technology has finally advanced to the point where it allows certain types of integration [6]. Application software has progressed enough that functionally specific subsystems
502
clik
_
w_wo 'io _*_ J_l
A----
*
'Opp.=
d
....- -.7
lol
.mdhmwilmftmmmdwadft p1wommunft
Figure 3 All medical data, including text and image data, can be thought of as objects that combine in various associations to create larger objects. are useful, and users begin to project new needs. However, many groups are finding the costs and effort involved prohibitive.
may "store" data either by reference to its location on the network or by containing its actual value. This approach allows the flexibility to adjust the replication of data by data item to achieve acceptable access times. As hardware and network speeds change, it allows particular data items to change from "data by value" storage to "data by reference" storage or vice versa. Virtual data (data stored by reference) can be used from within a subsystem or an integrating structure.
Typically, HIS's store data in subsystems based on administrative divisions within the hospital, such as laboratory, pharmacy, radiology, and medical administration. These subsystems may reside on separate hardware or they may be implemented with different software and data structures, or both. The DHCP system uses the same hardware, software environment and DBMS for the entire hospital system, but subsystems often use somewhat different data structures. The physician needs a longitudinal patient-oriented view that presents data from each of these packages on the same screen.
Multimedia data constitutes an important part of the patient's clinical record. With the recent technology advances in multimedia data storage and display, it is clear that HIS's will need to handle a variety of data in the future. Therefore, a successful integration approach must be able to manage multiple data types.
This integration can be achieved in several different ways:
Option 1: Data may continue to be stored primarily in functionally specific data structures. Various indexing schemes [9] or a metadictionary [4,8,9] may be used to provide rapid user access to data. Option 2: If data access does not meet the users' needs for rapid access, data may be duplicated in a central location in another format [6].
Option 3: A combination of these may be achieved by using a "virtual database" [5] or "virtual data." A virtual database serves the function of a metadictionary in providing access to any data on the system. However, it
Images represent an extreme type of data, and are useful in defining the necessary capabilities of an integration approach. Image data is stored as objects that are individually quite large. The need to store images on multiple media types, such as magnetic and optical disks [10], makes storage of the data by value in a number of subsystems impractical (option 1). Because image data is stored in large aggregates, image display entails very little overhead related to locating the data. Display times are relatively long for each image object, approximately 1000 times as long as to remotely access a text data node across a network. Therefore, the integration option 2 -duplication of image data in a central location - is not desirable because of the high storage costs and the low
503
I
relative overhead for access. We have used the virtual data approach of the third option -- storing image data by reference (or pointer) 'virtually' in the specialty subsystems and accessing these image objects across a high speed network. The same virtual storage can be used by integrating structures or as part of a virtual database. inage Integration with the VA's Hospital
Information System The VA has extended its database management system to support the management of image and other multimedia data. A production prototype system is currently operational in the Washington VAMC. Image modules include cardiology, pulmonary medicine, surgical pathology, gastrointestinal endoscopy, rheumatology, and hematology with radiology, nuclear medicine, surgery, ophthalmology, and dermatology expected soon. The VA's medicine package provides the initial integration step for text as well as image data. The package provides for the entry, editing and viewing of data for a large number of medical tests and procedures. Printed reports can be produced for all procedures. The medicine package currently has five modules including cardiology, pulmonary medicine, gastroenterology, hematology, and pacemaker, with a sixth module, rheumatology, currently in testing. Renal/dialysis, infectious disease, endocrinology, and dermatology modules are to be added in future versions. Images can be captured either through a separate menu option available on each subspecialty menu or through the packages' various enter/edit options. To integrate the medical subspecialty data for the treating physician, the medicine package provides a helpful patient summary feature which presents a short summary of all procedures that a patient has received. Summary image abstracts are presented simultaneously [11]. The medical patient's record is longitudinal. All procedures stored on the computer are available to the physician, and are presented in reverse chronological order. The patient summary can also be sorted by medical procedure type or be limited to one particular procedure type (such as catheterization, colonoscopy, etc.). A physician desiring more detailed information about a particular procedure may 'drill down" (a simple list selection for more specific information) to obtain the full procedure report with high resolution images. In order to support these specialty specific and crossspecialty integrated views, several data structures are used. The main database uses procedure type as the
504
primary key and a unique patient number as the secondary key. Procedure date/time is stored as data, along with measurements, results, descriptions, and image
references. The database has two major indices: (1) to access procedure-specific data, there is an index by procedure type, procedure date/time, and medical patient id number; and (2) to produce the integrated patient summaries, there is an index by medical patient identification number, reverse chronological visit date/time, and procedure type.
Inage Storage in an Object File The VA's DHCP hospital information system is based on a common database management system with an active data dictionary. This MUMPS-based system called VA FileMan provides the necessary support for complex object models as described by Khoshafian and Abnous [12], including "the ability to store sets of atomic values, tuple-valued attributes, sets of tuples, and object identity. " It forms a powerful basis for an object-oriented database management system to store single or sequential images, and ultimately other multimedia object types [2]. To relate these objects to the patients' other data, an image field is added to each application. This field references one or more image that is stored in an object file [13]. An object type file and a storage location file serve as support files to the object file. The Object File: The object file is used to store the necessary data for each object. Each object has a natural language name which the user assigns. Depending on the object type, the object will either have: o a filename and logical location on the network (e.g. single image, graphics) o a multiple field called "object group" which contains entries which point back to the object file (e.g. image series or tiled abstract display) o a set of data points and text (e.g. overlay) o executable code (e.g. pause, clear screen)
Additional identifying information specific to the application is stored in the object file. This includes: patient identifier, procedure identifier, date/time of collection, collector, whether the object is of key importance, a short and a long text description of the
object. Location File: Because the Imaging System uses a distributed environment, an object may be stored on one or more of the network storage devices. These include multiple magnetic file servers, one or more optical
jukebox, and possibly additional network devices that are accessed through a gateway [ 1]. The logical location attribute of the object file provides a mapping facility for This allows a rapid software physical devices. reconfiguration in the event of a failure of one of the system components. Additional fields in the location file are used to indicate the storage device(s) on which the object resides or the method of access across a gateway.
Object Type File: Objects of various types are handled by the Object Type File. These include: still images, image groups, image overlays, executable code, and graphics. An object, such as an image series, may actually consist of multiple objects (still images). In this case, the object group multiple field is used to point to a series of images in the object file. Each object type has associated methods (code) for performing certain actions. For example, there must be methods for capturing and storing images, displaying images, and creating image abstracts. These methods handle any variations due to hardware type. The group type is used to combine multiple objects of the same or different types to create complex objects. Display of text data in the patient summary also uses an object-oriented approach. There is a procedure file which includes the name of each procedure, its file number, and the name of the MUMPS routine (method) to be executed to display the text summary. Thus the physician gets both a text and image summary of the patient's procedures. Use of references to the object file by the specific applications in conjunction with integrating structures provides many of the types of physician access described above.
Conclusions The DHCP Imaging System is a production prototype which serves to illustrate the needs for cross specialty image data access and integrated display. Images are currently being stored by reference as part of patient's medical procedure records and surgical pathology reports. The object files have been implemented in this test environment and have proven useful. The storage of image data is constrained by its characteristics in different ways from text data. This means that its primary storage in specialty subsystems should be virtual. A central image repository is a service to these other subspecialty data structures. When designing schemes for integration across functionally specific subsystems, it is important that the approach
505
handle all types of data access including image and other multimedia objects.
References 1. Dayhoff RE, Maloney DL. Providing Image Management and Communication (IMAC) Functionality as an Integral Part of an Existing Hospital Information System, Proc Medical Imaging IV Conf, SPIE, 1990. 2. Dayhoff, RE, Maloney DL, Kuzmak, PM. Experience with a MUMPS-Based Hospital Information System with Images, Proc MUMPS Users Group, 1991, pp. 53-56. 3. Dayhoff RE, Maloney DL, Kuzmak PM. Examination of Architectures to Allow Integration of Image Data with Hospital Information Systems, Proc SCAMC 1990, pp. 694-698. 4. Friedman C, Hripcsak G, Johnson S, Cimino J, Clayton P. A Generalized Relational Schema for an Integrated Clinical Patient Database, SCAMC 1990, pp. 335-339. 5. Margulies D, McCallie D, Elkowitz A, Ribitzky R. An Integrated Hospital Information System at Children's Hospital, SCAMC 1990, pp. 699-703. 6. Lorins Harold. Aspects of Distributed Computer Systems, 1990. 7. McDonald CJ, Blevins L, Tierney WM, Martin DK. The Regenstrief Medical Records, MD Computing Vol 5, 1988, pp. 34-47. 8. King C, Holland Z, Bloom S. Using Networking Technology with the CO-WRITER Query/Report Generator, MUG Quarterly XIX(3): 41-42, 1989. 9. Webster S, Morgan MM, Barnett GO. Medical query language: flexible access to a standard MUMPS database, MUG Quarterly XVI(4), pp. 9-11, 1987. 10. Kuzmak PM, Dayhoff RE, Maloney DL. Management of the Storage of Digitized Images from a MUMPS Environment, Proc MUMPS Users Group, 1991, pp. 65-67. 11. Dayhoff RE, Maloney DL. Interacting with Images in a Hospital Information System, Proc MUMPS Users Group, 1990, pp. 129-133. 12. Khoshafian S, Abnous R. Object Orientation: Concepts, Languages, Databases, User Interfaces, Ch 7: Object Oriented Databases, John Wiley&Sons, pp 257-321 13. Maloney DL, Dayhoff RE, Multimedia Object File Design for Medical Images, Proc MUMPS Users Group 1991, pp 57-60.
