The Department of Veterans Affairs Optical Patient Card Workstation E. Gomez, J.E. Demetriades, D. Babcock, J. Peterson Albany Information Systems Center Department of Veterans Affairs Frear Building, Suite 301 2 Third St., Troy, NY 12180 Tel: (518) 271-9511 Fax: (518) 472-4324
Abstract
The Department of Veterans Affairs has developed an optical patient card application which will undergo alpha testing in 1991. The optical cards are carried by patients and contain administrative, clinical, and image information. An optical patient card workstation (OPCW) will read/write these cards and pass this information to the VA Decentralized Hospital Computer Program (DHCP), the VA's health care information system. The intent ofthis work is to study the potential benefits of this technology to the VA's distributed health care network, with a large mobile patient population. It is hoped that the use of optical cards and the OPCW will enhance clinicians ability to work with a timely composite health record, and expedite the administrative workload of the medical center. Introduction The VA's DHCP system runs on 168 medical centers throughout the US. DHCP offers administrative and clinical support to the staff. with an assortment of software modules corresponding to major clinical, administrative, and ancillary services. One concern with this system is that the electronic patient record resides at each institution. When a patient receives care in more than one facility, each medical center has a corresponding record, often with little knowledge of what has happened elsewhere. This distributed patient record is a drawback to comprehensive health care and gives rise to questions concerning polypharmacy, insurance co-payments, etc. The optical patient card, with the ability to carry active pharmacy scripts, insurance history, and eligibility information, is a potential mechanism for resolving some of these issues. This need was the driving force for the VA Optical Patient Card prototype [1] developed in 1990.
50 megabytes. The technology resembles the Write Once Read Many (WORM) disks. A high intensity laser is used to create an alteration on a material substrate. A low intensity laser is used to read the marks afterwards by noting changes in reflectivity. Once the surface is altered, further changes are impossible. The VA alpha test will use cards manufactured by the Drexler Technology Corporation which offer 2.86 megabytes of storage with error detection and correction (EDAC) or 4 megabytes without EDAC. EDAC is necessary for reading and writing ASCII data but it is not required when working with binary information. The card conforms to the Drexler European License Agreement (DELA) standard. Canon Inc. has licensed the Drexler technology and offers a similar card with 2 megabytes of data with EDAC. Other vendors offer higher storage densities but have incompatible formats. No industry wide standard, like the ISO 9660 standard for Compact Disk Read Only Memory (CDROM), currently exists. The epitome comes from a patent announced by the Polaroid Corporation where 500 megabytes can be place on a 2.5 square surface for a total yield of one Gigabyte [2].
Optical Card Technology Optical cards can be readily identified by their large data capacity. Although few integrated circuit cards exceed 256 kbits of storage, optical cards range from 20195-4210/91/$5.00 © 1992 AMIA, Inc.
378
Optical Patient Card Prototype: Lessons Learned The current Optical Patient Card Workstation (OPCW) is based on earlier work with the VA optical patient card prototype. The design of the prototype was determined by the following constraints: MUMPS language compatibility, ease of integration into current medical center environment, ability to update data on cards more than once, ability to use vendor independent protocols for communications and card functions. The VA DHCP system is a MUMPS based hospital information system. The system is highly integrated and both clinical and administrative staff can access information on a need-to-know basis from any terminal. The original scope of the project was to use the card to carry information for all these services. Initial assessments found over 144 data fields which were
candidates for card storage. We must note that none of these elements is ever removed from DHCP and carried exclusively on the card. The card simply carries a snapshot of the hospital record. The first problem was how to place information on the card. Two approaches existed at that time. The first was to use system calls to the reader/writer unit from the application to read and write tracks on the card. The order and location would be under the complete control of the developer. This would allow for unique data structures which could be extremely efficient in storage. The other benefit was that a structure could be designed which would mimic the reading and writing of rewritable magnetic disks. This was based on work done by the VA on archiving on WORM disks [3]. The main disadvantage here was that the placement of data on the card would be incompatible with everyone else. The second approach was to use DOS files since the units were supplied with a DOS device driver to access the read/write unit. Although DOS is not a formal standard, it is a standard by virtue of its popularity. System calls to the hardware were still a requirement for some functions, like locking the card eject button. This was accomplished by loading a device driver which allowed calling an application programmer interface (API). The OPCW now calls the API with the use of the C programming language. The Optical Card Workstation: Design and Function The issues of MUMPS compatibility and integration with DHCP were solved by creating a front-end processor which allowed communications with a DHCP host and control of the card read and write operations. DHCP data elements were organized into a structure compatible with optical data card requirements
DHCP information is stored on the card in many DOS files with a 3 digit numeric extension. When data is changed, a new version of the file is created. This is a consequence of the WORM nature of the optical cards. A key element here is to choose appropriate file sizes to minimize space overhead. Data elements which are fairly static can be grouped together in larger files since the expectation that they will change with time is less. Our work with the patient card prototype indicates that this scheme allows for a single card to be updated every week for an entire year before it is filled.
optical card commands to the OPCW. These commands are not echoed on the screen and follow a strict sequence. Figure 1 shows the current command language implemented. Each command is prefixed by a fixed length header of 14 characters containing two consecutive tildes (- -), a four character command code, and the number of characters in the data stream that follows. Pdn U..Rml C.Mmm":
c-McAD (-UCA D)
*)U)
('- NCRD MST
*)
Mount Card
l)
r-RF1L LEN ){ FILE N) WFL LEN ) FILE N) (-' FOAT LEN ){ DATA) {
r
CFIL
)
Unmouni Card Creafe New Card Reader StatAs Read N Occwence of filoname FILE Ope fie FILE size N Actual
aose
data to write lo cwd
Irds
Image Mamagmenl Commands:
r- CAP 1) Caplur Image ad Cownvrt to PCX formad Sw. Convetd kmage to Me FILE {- ISAV LEN I ( FILE) r{- DSP LEN ) I FLE x y) Display Image FILE at position XY ICLR a rw Dilay e)
Figure
1
data is also placed on the card. Images are 256x200 PCX images converted from a TrueVision Image Capture Board (ICB). These images can be displayed on a standard 640x480 pixel VGA screen. Text is associated with the image. The difference here is that the binary image data is never transferred to the DHCP host, unlike the ASCII data which is sent to the host, it is simply displayed at the workstation. A patient identification picture is currently implemented. The optical card prototype also included low resolution radiology images which can be associated to a radiology report for greater impact. Future generations may offer the capability of transferring the image files to the DHCP host for permanent storage. The size of some of these files implies the use of high performance protocols. Tests indicate that using TCP network file transfer (NFT) will give 80 kilobytes/sec performance using a 16 bit Ethemet controller card over twisted pair. Figure 2 shows the hardware and a typical system configuration. Image
Decentralized Hospital Computer Program
Ethemet
in
Elbernet
Card Read*r6 Uni
OPC W iN 351 SX PC
The OPCW is started up on a pc workstation and it allows ANSI X3.64-1979 terminal emulation, keyboard mapping, and network communications through TCP/IP or RS232 protocols. The user logs on to a DHCP host, working normally until DHCP needs to communicate
SCSI lntewfce
Figure 2 Optical Patient Card Workstation: Operation
379
The use of the patient card has to be unobtrusive. The workstation behaves like any regular DHCP terminal. The user can maintain the usual DHCP dialogue as they perform their normal work. The card units will be alpha tested in a variety of locations: Clinic check-in areas, pharmacy dispensation units, agent cashier office, etc. These are areas where a patient normally arrives at or leaves from the medical center. One important difference between this implementation and others [4] is that data is not entered directly onto the card, rather the card receives extracts from the DHCP system. A typical VA medical center has several hundred users already entering and verifying large volumes of data. It made little sense to have data entered into the card redundantly. The card is read once upon the arrival of the patient. An image of the entire card is then available to the DHCP system where comparisons can be made on data which needs to be replaced on the card and data which needs to be incorporated into DHCP. At the end of the episode of care, all required modifications and additions to the card will be done. Some of the information has a last in first out (LIFO) "moving window.' Outpatient visits are an example. Once a patient has accumulated 5 visits, the sixth visit will displace the oldest. The original visit however, remains on the card due to the nature of WORM. System manager options exist which will allow the recovery of these past data elements for audit purposes.
The optical patient card prototype has fulfilled all of its design objectives and the OPCW is an extension of this work. The optical card will offer clinicians a composite health care record for a patient whenever they walk into any VA facility. Administrative staff will reduce workload times by using automatic functions provided to manually reenter data which has been acquired in another facility. The OPCW software uses vendor independent protocols. Although the hardware is novel, more companies are becoming involved, offering a wider variety of platforms to use. Images, an important requirement in the modem health care facility, are compatible with the OPCW. It is possible that the optical card will provide a new method for the storage and retrieval of a rich comprehensive medical record.
Discussion
References
The alpha test will begin with two medical centers where a controlled patient population can be readily identified. The two alpha test sites selected have a discrete set of patients which are regularly seen in both facilities. Additional facilities will be added to the alpha test to capture good evaluation data in the widest possible settings. The alpha test will in all likelihood last one year. During the test data will be obtained on hardware reliability, optical card reliability, patient compliance and satisfaction, and medical center satisfaction. Aside from the immediate benefits of physicians having timely and complete medical records for patients, administrative staff should also benefit. The card will be used to generate automatic visit checkin, and automatic patient record generation. These procedures can often be quite lengthy. Patient compliance in carrying the card is frequently a mentioned concern. The VA patient today carries an
[1] Demetriades, E. James; Gomez, Enrique. "Optical Patient Card Prototype Within the Department of Veterans Affairs," MUMPS Users Group Quarterly Vol. XX No. 1, pp 109-112.
380
embossed card which is used to identify them and begin the eligibility verification process required of all veterans. This established procedure gives credence that compliance with the use of the optical patient card will be high. Patient education on the importance and utility of the optical card will increase this further. Other researchers report high compliance by outpatients due to time savings [5]. Physicians who have seen the optical card prototype have reacted favorably to the ease of use and the types of information contained. Conclusion
[2] Herzberg, David (Ed.). "Reports From the Lab: Technical Developments." Optical Memory News. October 1989, p.20 [3] Gomez, Enrique; Demetriades, E. James. "Online Archiving Using Optical WORM For DHCP Systems," MUMPS Users Group Quarterly Vol. XX No. 1, pp 105-108.
[4,5] Brown, J.H.U, et al. "Evaluation of a New Patient Record System Using the Optical Card," Proceedings - Symposium on Computer Applications in Medical Care, Thirteenth Annual, pp 714-717.
Abstract
The Department of Veterans Affairs has developed an optical patient card application which will undergo alpha testing in 1991. The optical cards are carried by patients and contain administrative, clinical, and image information. An optical patient card workstation (OPCW) will read/write these cards and pass this information to the VA Decentralized Hospital Computer Program (DHCP), the VA's health care information system. The intent ofthis work is to study the potential benefits of this technology to the VA's distributed health care network, with a large mobile patient population. It is hoped that the use of optical cards and the OPCW will enhance clinicians ability to work with a timely composite health record, and expedite the administrative workload of the medical center. Introduction The VA's DHCP system runs on 168 medical centers throughout the US. DHCP offers administrative and clinical support to the staff. with an assortment of software modules corresponding to major clinical, administrative, and ancillary services. One concern with this system is that the electronic patient record resides at each institution. When a patient receives care in more than one facility, each medical center has a corresponding record, often with little knowledge of what has happened elsewhere. This distributed patient record is a drawback to comprehensive health care and gives rise to questions concerning polypharmacy, insurance co-payments, etc. The optical patient card, with the ability to carry active pharmacy scripts, insurance history, and eligibility information, is a potential mechanism for resolving some of these issues. This need was the driving force for the VA Optical Patient Card prototype [1] developed in 1990.
50 megabytes. The technology resembles the Write Once Read Many (WORM) disks. A high intensity laser is used to create an alteration on a material substrate. A low intensity laser is used to read the marks afterwards by noting changes in reflectivity. Once the surface is altered, further changes are impossible. The VA alpha test will use cards manufactured by the Drexler Technology Corporation which offer 2.86 megabytes of storage with error detection and correction (EDAC) or 4 megabytes without EDAC. EDAC is necessary for reading and writing ASCII data but it is not required when working with binary information. The card conforms to the Drexler European License Agreement (DELA) standard. Canon Inc. has licensed the Drexler technology and offers a similar card with 2 megabytes of data with EDAC. Other vendors offer higher storage densities but have incompatible formats. No industry wide standard, like the ISO 9660 standard for Compact Disk Read Only Memory (CDROM), currently exists. The epitome comes from a patent announced by the Polaroid Corporation where 500 megabytes can be place on a 2.5 square surface for a total yield of one Gigabyte [2].
Optical Card Technology Optical cards can be readily identified by their large data capacity. Although few integrated circuit cards exceed 256 kbits of storage, optical cards range from 20195-4210/91/$5.00 © 1992 AMIA, Inc.
378
Optical Patient Card Prototype: Lessons Learned The current Optical Patient Card Workstation (OPCW) is based on earlier work with the VA optical patient card prototype. The design of the prototype was determined by the following constraints: MUMPS language compatibility, ease of integration into current medical center environment, ability to update data on cards more than once, ability to use vendor independent protocols for communications and card functions. The VA DHCP system is a MUMPS based hospital information system. The system is highly integrated and both clinical and administrative staff can access information on a need-to-know basis from any terminal. The original scope of the project was to use the card to carry information for all these services. Initial assessments found over 144 data fields which were
candidates for card storage. We must note that none of these elements is ever removed from DHCP and carried exclusively on the card. The card simply carries a snapshot of the hospital record. The first problem was how to place information on the card. Two approaches existed at that time. The first was to use system calls to the reader/writer unit from the application to read and write tracks on the card. The order and location would be under the complete control of the developer. This would allow for unique data structures which could be extremely efficient in storage. The other benefit was that a structure could be designed which would mimic the reading and writing of rewritable magnetic disks. This was based on work done by the VA on archiving on WORM disks [3]. The main disadvantage here was that the placement of data on the card would be incompatible with everyone else. The second approach was to use DOS files since the units were supplied with a DOS device driver to access the read/write unit. Although DOS is not a formal standard, it is a standard by virtue of its popularity. System calls to the hardware were still a requirement for some functions, like locking the card eject button. This was accomplished by loading a device driver which allowed calling an application programmer interface (API). The OPCW now calls the API with the use of the C programming language. The Optical Card Workstation: Design and Function The issues of MUMPS compatibility and integration with DHCP were solved by creating a front-end processor which allowed communications with a DHCP host and control of the card read and write operations. DHCP data elements were organized into a structure compatible with optical data card requirements
DHCP information is stored on the card in many DOS files with a 3 digit numeric extension. When data is changed, a new version of the file is created. This is a consequence of the WORM nature of the optical cards. A key element here is to choose appropriate file sizes to minimize space overhead. Data elements which are fairly static can be grouped together in larger files since the expectation that they will change with time is less. Our work with the patient card prototype indicates that this scheme allows for a single card to be updated every week for an entire year before it is filled.
optical card commands to the OPCW. These commands are not echoed on the screen and follow a strict sequence. Figure 1 shows the current command language implemented. Each command is prefixed by a fixed length header of 14 characters containing two consecutive tildes (- -), a four character command code, and the number of characters in the data stream that follows. Pdn U..Rml C.Mmm":
c-McAD (-UCA D)
*)U)
('- NCRD MST
*)
Mount Card
l)
r-RF1L LEN ){ FILE N) WFL LEN ) FILE N) (-' FOAT LEN ){ DATA) {
r
CFIL
)
Unmouni Card Creafe New Card Reader StatAs Read N Occwence of filoname FILE Ope fie FILE size N Actual
aose
data to write lo cwd
Irds
Image Mamagmenl Commands:
r- CAP 1) Caplur Image ad Cownvrt to PCX formad Sw. Convetd kmage to Me FILE {- ISAV LEN I ( FILE) r{- DSP LEN ) I FLE x y) Display Image FILE at position XY ICLR a rw Dilay e)
Figure
1
data is also placed on the card. Images are 256x200 PCX images converted from a TrueVision Image Capture Board (ICB). These images can be displayed on a standard 640x480 pixel VGA screen. Text is associated with the image. The difference here is that the binary image data is never transferred to the DHCP host, unlike the ASCII data which is sent to the host, it is simply displayed at the workstation. A patient identification picture is currently implemented. The optical card prototype also included low resolution radiology images which can be associated to a radiology report for greater impact. Future generations may offer the capability of transferring the image files to the DHCP host for permanent storage. The size of some of these files implies the use of high performance protocols. Tests indicate that using TCP network file transfer (NFT) will give 80 kilobytes/sec performance using a 16 bit Ethemet controller card over twisted pair. Figure 2 shows the hardware and a typical system configuration. Image
Decentralized Hospital Computer Program
Ethemet
in
Elbernet
Card Read*r6 Uni
OPC W iN 351 SX PC
The OPCW is started up on a pc workstation and it allows ANSI X3.64-1979 terminal emulation, keyboard mapping, and network communications through TCP/IP or RS232 protocols. The user logs on to a DHCP host, working normally until DHCP needs to communicate
SCSI lntewfce
Figure 2 Optical Patient Card Workstation: Operation
379
The use of the patient card has to be unobtrusive. The workstation behaves like any regular DHCP terminal. The user can maintain the usual DHCP dialogue as they perform their normal work. The card units will be alpha tested in a variety of locations: Clinic check-in areas, pharmacy dispensation units, agent cashier office, etc. These are areas where a patient normally arrives at or leaves from the medical center. One important difference between this implementation and others [4] is that data is not entered directly onto the card, rather the card receives extracts from the DHCP system. A typical VA medical center has several hundred users already entering and verifying large volumes of data. It made little sense to have data entered into the card redundantly. The card is read once upon the arrival of the patient. An image of the entire card is then available to the DHCP system where comparisons can be made on data which needs to be replaced on the card and data which needs to be incorporated into DHCP. At the end of the episode of care, all required modifications and additions to the card will be done. Some of the information has a last in first out (LIFO) "moving window.' Outpatient visits are an example. Once a patient has accumulated 5 visits, the sixth visit will displace the oldest. The original visit however, remains on the card due to the nature of WORM. System manager options exist which will allow the recovery of these past data elements for audit purposes.
The optical patient card prototype has fulfilled all of its design objectives and the OPCW is an extension of this work. The optical card will offer clinicians a composite health care record for a patient whenever they walk into any VA facility. Administrative staff will reduce workload times by using automatic functions provided to manually reenter data which has been acquired in another facility. The OPCW software uses vendor independent protocols. Although the hardware is novel, more companies are becoming involved, offering a wider variety of platforms to use. Images, an important requirement in the modem health care facility, are compatible with the OPCW. It is possible that the optical card will provide a new method for the storage and retrieval of a rich comprehensive medical record.
Discussion
References
The alpha test will begin with two medical centers where a controlled patient population can be readily identified. The two alpha test sites selected have a discrete set of patients which are regularly seen in both facilities. Additional facilities will be added to the alpha test to capture good evaluation data in the widest possible settings. The alpha test will in all likelihood last one year. During the test data will be obtained on hardware reliability, optical card reliability, patient compliance and satisfaction, and medical center satisfaction. Aside from the immediate benefits of physicians having timely and complete medical records for patients, administrative staff should also benefit. The card will be used to generate automatic visit checkin, and automatic patient record generation. These procedures can often be quite lengthy. Patient compliance in carrying the card is frequently a mentioned concern. The VA patient today carries an
[1] Demetriades, E. James; Gomez, Enrique. "Optical Patient Card Prototype Within the Department of Veterans Affairs," MUMPS Users Group Quarterly Vol. XX No. 1, pp 109-112.
380
embossed card which is used to identify them and begin the eligibility verification process required of all veterans. This established procedure gives credence that compliance with the use of the optical patient card will be high. Patient education on the importance and utility of the optical card will increase this further. Other researchers report high compliance by outpatients due to time savings [5]. Physicians who have seen the optical card prototype have reacted favorably to the ease of use and the types of information contained. Conclusion
[2] Herzberg, David (Ed.). "Reports From the Lab: Technical Developments." Optical Memory News. October 1989, p.20 [3] Gomez, Enrique; Demetriades, E. James. "Online Archiving Using Optical WORM For DHCP Systems," MUMPS Users Group Quarterly Vol. XX No. 1, pp 105-108.
[4,5] Brown, J.H.U, et al. "Evaluation of a New Patient Record System Using the Optical Card," Proceedings - Symposium on Computer Applications in Medical Care, Thirteenth Annual, pp 714-717.
