Over the last few years the satellite clinical database has moved closer and closer to the longitudinal patient record with the watch-word being “interface-ability”. Yet the goal all along should be removing the need to interface at all - with the gold standard being incorporating as much data as possible into existing database standards. DICOM is of course the most venerable medical database standard of them all for binary large objects. The concept of storing multiple modality cardiology waveform data had been only a concept until recently when Mortara Instrument has pioneered the first directly interfaced DICOM compatible electrocardiograph.
Waveform Image Integration - The state-of-the-art in non-invasive diagnostic waveform portability has been pointing towards the Adobe PDF image and the ability to link to the image via embedded URL as in the IHE RID profile. This concept has merit and functionality but the very notion that a “connectathon” is required points up to the fact that a more seamless approach is desired.
HL7 – DICOM Reconciliation - In the past all workflow related to diagnostic cardiology testing has been in the HL7 realm. All the while, DICOM was aptly suited and solidly in place. While issues relating to HL7 field mapping and the newest reality of HL7 3.0 XML integration come to the fore, the Modality Work-list offers complete functionality with regard to ADT, scheduling, results reporting, and IHE compliance.
Universal Data Capture Compliance - In the current technology environment, the concept of format translators to accommodate disparate manufacturers ECG data has become a concept that some have experimented with. While the jury is still out with regard to the clinical accuracy and reproducibility of clinical data being reformatted into multiple iterations of the same record, Mortara Instrument has adopted the philosophy of seeking to provide a more common sense approach with the evolution of the DICOM diagnostic cardiology viewer/editor. Years ago, while the clinical cardiology community struggled to adopt the SCP protocol, Mortara embraced XML and ultimately created the viewing and annotation tools that power the FDA ECG warehouse to this day. Similarly, while many are placing their faith in format translators, a more logical approach would be to push for DICOM compliance from the device level.
Economic Implications - The acceptance of direct DICOM integration has a large hurdle in the form of existing cardiology “data island” infrastructure. Millions of dollars are poured every year into cardiology data management systems. One could say that the integration of diagnostic cardiology information into DICOM was inevitable save for the fact that cardiology “data islands” are big business and in fact make up the majority of non-invasive cardiology business revenue for some manufacturers. Thus, in a situation analogous to petroleum company reticence of adopting alternative fuel technologies, we might expect the more monolithic manufacturers to be slow to adopt a methodology that would benefit the healthcare provider rather than the device manufacturer.
The Road Ahead - It is acknowledged that producing the worlds first DICOM compatible electrocardiograph does not solve all of the problems with respect to merging into one clinical database, but it is a start. Just as HL7 results outbound formatters found their way into laboratory instrumentation devices after being separate PC’s, the vision of the future is the direct integration of diagnostic cardiology data from the device itself. Cerner signed a contract with Mortara Instrument last year to integrate their ECG editing program into the Cerner CV Net thus producing the first cardiovascular information system with completely integrated ECG viewing/editing/ordering. In addition to solving the problem of editing the ECG from within the EMR, it also solved the informatics problem of ECG databases vs. EMR account numbers.
The ECG Bar Code Dilemma - All ECG databases, being databases after all, have to index off of one number, be it SSN, or medical record number. EMRs on the other hand for the most part save for the VA CPRS and Meditech utilize account numbers that change every time a patient is admitted. Therefore if you try to use a bar code reader on an ECG machine, its virtually useless. The account number that you would scan from a patient in a hospital using, say, an SMS system would not be viable for pulling up an ECG record in say, a MUSE system. There are three ways to approach this: You can throw away the bar code readers, and print the secondary ID code on the ECG. This is what everyone does today. Or you could develop a master patient index (MPI) to cross-correlate the static number (SSN, etc) with the account number. Or you could do what the Cerner system does and utilize DICOM modality worklist to generate the orders. In this manner the EMR and the ECG database are speaking the same identifier number. Given that CV Net generates the billing and does not have to translate HL7 billing transactions (since it is speaking to itself), the problem is solved. Im sure we will hear much more in the near future of the utilization of Modality Worklist for diagnostics test such as Holter and stress as Modality Worklist also provides the concept of scheduling.
HL7 – DICOM Reconciliation - In the past all workflow related to diagnostic cardiology testing has been in the HL7 realm. All the while, DICOM was aptly suited and solidly in place. While issues relating to HL7 field mapping and the newest reality of HL7 3.0 XML integration come to the fore, the Modality Work-list offers complete functionality with regard to ADT, scheduling, results reporting, and IHE compliance.
Universal Data Capture Compliance - In the current technology environment, the concept of format translators to accommodate disparate manufacturers ECG data has become a concept that some have experimented with. While the jury is still out with regard to the clinical accuracy and reproducibility of clinical data being reformatted into multiple iterations of the same record, Mortara Instrument has adopted the philosophy of seeking to provide a more common sense approach with the evolution of the DICOM diagnostic cardiology viewer/editor. Years ago, while the clinical cardiology community struggled to adopt the SCP protocol, Mortara embraced XML and ultimately created the viewing and annotation tools that power the FDA ECG warehouse to this day. Similarly, while many are placing their faith in format translators, a more logical approach would be to push for DICOM compliance from the device level.
Economic Implications - The acceptance of direct DICOM integration has a large hurdle in the form of existing cardiology “data island” infrastructure. Millions of dollars are poured every year into cardiology data management systems. One could say that the integration of diagnostic cardiology information into DICOM was inevitable save for the fact that cardiology “data islands” are big business and in fact make up the majority of non-invasive cardiology business revenue for some manufacturers. Thus, in a situation analogous to petroleum company reticence of adopting alternative fuel technologies, we might expect the more monolithic manufacturers to be slow to adopt a methodology that would benefit the healthcare provider rather than the device manufacturer.
The Road Ahead - It is acknowledged that producing the worlds first DICOM compatible electrocardiograph does not solve all of the problems with respect to merging into one clinical database, but it is a start. Just as HL7 results outbound formatters found their way into laboratory instrumentation devices after being separate PC’s, the vision of the future is the direct integration of diagnostic cardiology data from the device itself. Cerner signed a contract with Mortara Instrument last year to integrate their ECG editing program into the Cerner CV Net thus producing the first cardiovascular information system with completely integrated ECG viewing/editing/ordering. In addition to solving the problem of editing the ECG from within the EMR, it also solved the informatics problem of ECG databases vs. EMR account numbers.
The ECG Bar Code Dilemma - All ECG databases, being databases after all, have to index off of one number, be it SSN, or medical record number. EMRs on the other hand for the most part save for the VA CPRS and Meditech utilize account numbers that change every time a patient is admitted. Therefore if you try to use a bar code reader on an ECG machine, its virtually useless. The account number that you would scan from a patient in a hospital using, say, an SMS system would not be viable for pulling up an ECG record in say, a MUSE system. There are three ways to approach this: You can throw away the bar code readers, and print the secondary ID code on the ECG. This is what everyone does today. Or you could develop a master patient index (MPI) to cross-correlate the static number (SSN, etc) with the account number. Or you could do what the Cerner system does and utilize DICOM modality worklist to generate the orders. In this manner the EMR and the ECG database are speaking the same identifier number. Given that CV Net generates the billing and does not have to translate HL7 billing transactions (since it is speaking to itself), the problem is solved. Im sure we will hear much more in the near future of the utilization of Modality Worklist for diagnostics test such as Holter and stress as Modality Worklist also provides the concept of scheduling.
No comments:
Post a Comment