Jim, the stovepipes are the underlying clinical (and some clinical/administrative) packages, such as Lab, Pharmacy, V-files, PCE, TIU, Bed Control, PTF, Radiology, etc.
Many of these packages were developed years ago (I believe initially at
different medical centers, and then at different Field Offices). I also believe
that originally some of these packages had their own patient files.
All of these packages store what could be classified as results,
reports, etc in what really amount to seperate databases within the M/Fileman, environment.
"Stovepipes" in a sense.
Navigating these files/databases to do clinically relevant queries using Fileman
can be daunting at times. Think of trying to identify a simple cohort of
patients who meet the following criteria: "All female patients taking Digoxin,
with a potassium level less than a certain threshhold value".
One must jump from patient file, to some very compli cated lab files, to
the prescription file. It's probably simpler to just write a custom program to do this,
than to try to frame the query in Fileman.
Nowadays, some of these queries can be done with CPRS. But we're
talking years after it could have been available. Also I think CPRS would have
difficulty with more complex queries than my example.
For many years, here at Indianapolis, we used a system called RMRS. It
was a clinical repository, written in M, that was loosely based on the Regenstrief Medical Record system, which was originally created at the Regenstrief Institute.
At the heart of this system is a single M-based file, that stores 27
different types of clinical data in a standardized way.
It is fed its data by HL7 messages, from Vista, or, any commercial
package that sends the data in the proper HL7 format.
The file is easily queryable on a patient by patient basis, or across
the entire file, to identify cohorts of patients, as described above.
The system could even be programmed to page physicians, when laboratory
results on their patients were outside reference values.
The system was abandoned, mainly because the lead developer left the
VA, and because Vista did not contain the necessary mapping tools to map non-standard terms to standard ones in an efficient manner. Mapping them manually, was not impossible, but it was resource intensive.
These same issues have resurfaced 10 years later with the HDR, but this
time a properly resourced team of Data Standardization people has been
assembled to revisit the issue. So, we are "back to the future" in a sense.
My point is, that Vista could be much simplified, with an architecture
like this, if it were redesigned with "lessons learned" taken into consideration. It could be done in M, because after all, it has already been done once in M.
Finally, I will tell you that I am not the person best qualified to
proselytize on this system. Nor am I sure the original developer has any further interst in the system. I am simply saying that I am a fan of the architecture.
Many of these packages were developed years ago (I believe initially at
different medical centers, and then at different Field Offices). I also believe
that originally some of these packages had their own patient files.
All of these packages store what could be classified as results,
reports, etc in what really amount to seperate databases within the M/Fileman, environment.
"Stovepipes" in a sense.
Navigating these files/databases to do clinically relevant queries using Fileman
can be daunting at times. Think of trying to identify a simple cohort of
patients who meet the following criteria: "All female patients taking Digoxin,
with a potassium level less than a certain threshhold value".
One must jump from patient file, to some very compli cated lab files, to
the prescription file. It's probably simpler to just write a custom program to do this,
than to try to frame the query in Fileman.
Nowadays, some of these queries can be done with CPRS. But we're
talking years after it could have been available. Also I think CPRS would have
difficulty with more complex queries than my example.
For many years, here at Indianapolis, we used a system called RMRS. It
was a clinical repository, written in M, that was loosely based on the Regenstrief Medical Record system, which was originally created at the Regenstrief Institute.
At the heart of this system is a single M-based file, that stores 27
different types of clinical data in a standardized way.
It is fed its data by HL7 messages, from Vista, or, any commercial
package that sends the data in the proper HL7 format.
The file is easily queryable on a patient by patient basis, or across
the entire file, to identify cohorts of patients, as described above.
The system could even be programmed to page physicians, when laboratory
results on their patients were outside reference values.
The system was abandoned, mainly because the lead developer left the
VA, and because Vista did not contain the necessary mapping tools to map non-standard terms to standard ones in an efficient manner. Mapping them manually, was not impossible, but it was resource intensive.
These same issues have resurfaced 10 years later with the HDR, but this
time a properly resourced team of Data Standardization people has been
assembled to revisit the issue. So, we are "back to the future" in a sense.
My point is, that Vista could be much simplified, with an architecture
like this, if it were redesigned with "lessons learned" taken into consideration. It could be done in M, because after all, it has already been done once in M.
Finally, I will tell you that I am not the person best qualified to
proselytize on this system. Nor am I sure the original developer has any further interst in the system. I am simply saying that I am a fan of the architecture.
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
