We need to squeeze the subjectivity out of healthcare and make it more measurable; more understandable from an algorithmic perspective. Data and math need to play a larger role in diagnosis and treatment. We're moving down this path, everywhere, so that's a good thing. A simple example is the widespread use of BMI (algorithm-based) as it relates to the diagnosis of "obesity." BMI is not perfect, but it's much better than the subjective definitions of proper body weight that my generation grew up with.
The current heartbeat of the EHR remains the subjective progress note-- and other text based reports. The progress note, though once helpful, is now the single biggest hindrance to physician efficiency in the use and adoption of the EHR. The progress note costs millions to workaround via transcription services. It's a bottleneck to closing the encounter and everything downstream that depends on that closing. It is an enormous anchor in our attempts to become more data and mathematically driven. I'd like to have a dime for every NLP project that has been funded in healthcare to overcome the subjective-objective barrier around progress notes and other text reports. Progress notes are too long to write and too long to read, and often times they are simply a summary of data from other measurable events like labs and medications. We need to change the cultural expectation in healthcare and the specific expectation of payers that the progress note is a necessary artifact of patient care-- it should become optional and applied only where history of present illness and/or diagnosis is particularly challenging, and discrete data cannot adequately tell the entire story to other members of the care team.
The problem list is simply another form of subjectivity, as currently utilized in healthcare. It's an abbreviated form of the progress note, with all the inherited variation and inability to reliably apply math or discrete analysis. In the past, I thought the problem list was going to become a breakthrough tool in healthcare, but I've seen it become yet another source of confusing information to the broader members of a care team, not a helpful tool. Problem lists have become personal versions of shorthand for the progress note-- and thus only reliably legible to the author.
If we could constrain the subjective contents of the problem list; use algorithms to populate the problem list where we can (e.g., infer diabetes from labs and meds); and apply industry-wide guidelines around its utilization, the problem list could become the most efficient way to "tell the story" of patient care, as well as become a more objective description of the clinical encounter and diagnosis, opening the door for discrete data analysis and the influence of math.
I offer these thoughts not as an IT guy trying to force a user interface on a physician, but rather as a lifelong "Information Utilization" guy who has had the benefit of exposure to many different information-intense environments.
Thursday, January 29, 2009
Tuesday, January 20, 2009
Data Warehouse Data Modeling
This is a fairly tech-ish blog entry, but given the rise of importance and number of projects related to data warehousing and business intelligence in healthcare-- which is a good thing-- I am concerned about the continued rate of costly and poorly informed decisions in the execution of those projects. A blog entry on the topic is probably worthwhile, even if a bit techie. The essence of this blog was originally posted among members of the Healthcare Data Warehousing Association (http://www.hdwa.org/).
I would caution those who are beginning the data modeling journey, and those who are relatively new to the journey and can still save themselves-- There is no single data modeling dogma which will solve your data modeling needs in an Enterprise Data Warehouse. Neither Ralph Kimball, Claudia Imhoff, nor Bill Inmon-- the oft cited "experts" in the field-- have ever had to actually live with the theories they espouse, especially in healthcare, in an operational setting over a long period of time.
Your DW data model should address three general needs and "metamodels", as follows:
(1) Data models that are essentially copies and/or denormalized versions of the production source systems, including all of their bizarre naming conventions. Some people call these "Operational Data Stores"-- whatever you want to call them is fine with me, as long as you stick to the basic principle of, "Copy the source system data. Maintain the truth and fidelity of that data, for better or worse, as you bring it into the DW." Maintaining the fidelity of the source system data is critical because, like lost fidelity in an audio recording, you can't go back once it's lost. But, as long as you have the original recording, you can do whatever you want to with the recording downstream. Data Analysts who are familiar with the typically arcane nature of the source systems will love you for giving them a better and easier place to run their queries than what they've had for the past 10-15 years in the source system environments, and they don't have to learn anything new about the data structures since you were so kind as to keep them intact.
(2) Data models that represent specialized data marts, spun off from the source system data models. These specialized data marts are driven by unique requirements-- let's say a financial dashboard or a diabetes registry or a full-fledged clinical quality improvement project-- and each of these unique data marts will also have their own unique and optimal way to model the data, including naming conventions that are customized to the Data Analysts in those unique environments. In 80% or more of the cases, most Data Analysts want simple rows and columns of data--there's a reason Excel is so beloved and there's a reason that the success of multidimensional cubes is not more widespread. In some cases, the analysis requirements might best be served by a star schema data model; or a snowflake; or a single wide and deep table with lots of redundancy, such as a row for every patient's encounter; or even a second or third normal form data model. The bottom line: Go with what works, with the simplest data model, and remember that most people will be very happy with simple rows and columns of data that they can suck into Excel for manipulation.
(3) A Master Reference data model area where you can store things for look-up (e.g., for data quality checks) like ICD-9 codes; CPT codes; SNOMED terms; LOINC terms; Drug codes; the Master Patient Index and Master Provider Index; local standards for department, facility, service line, charge codes; etc.
If you need a decent starting place to grease the wheels of your mind for a generalized healthcare data model, take a look at HL7 RIM and i2b2. They are at different ends of the data modeling spectrum-- RIM is pretty much 3NF and i2b2 is pretty much a star schema with a pinch of EAV-- but for gawd sake don't assume that either of these models will be the single data modeling approach which will satisfy all the needs that you will face in a healthcare data warehouse. Many healthcare organizations drank the Kimball Kool-Aid early in their evolution of BI and DW, and they are now discovering that they painted themselves in a corner that's going to cost a lot of time and money to unpaint.
In summary: (1) Maintain the fidelity of your source system data; (2) Design your subsequent data marts using the data model that makes sense for the analysts and reporting needs associated with that data mart; (3) Provide a robust Master Reference data model area which can be joined to your source system "Operational Data Stores" and specialized data marts.
Don't paint yourselves in a corner. Trust your common sense. Kimball, Imhoff, and Inmon know far less than you do about this topic.
I would caution those who are beginning the data modeling journey, and those who are relatively new to the journey and can still save themselves-- There is no single data modeling dogma which will solve your data modeling needs in an Enterprise Data Warehouse. Neither Ralph Kimball, Claudia Imhoff, nor Bill Inmon-- the oft cited "experts" in the field-- have ever had to actually live with the theories they espouse, especially in healthcare, in an operational setting over a long period of time.
Your DW data model should address three general needs and "metamodels", as follows:
(1) Data models that are essentially copies and/or denormalized versions of the production source systems, including all of their bizarre naming conventions. Some people call these "Operational Data Stores"-- whatever you want to call them is fine with me, as long as you stick to the basic principle of, "Copy the source system data. Maintain the truth and fidelity of that data, for better or worse, as you bring it into the DW." Maintaining the fidelity of the source system data is critical because, like lost fidelity in an audio recording, you can't go back once it's lost. But, as long as you have the original recording, you can do whatever you want to with the recording downstream. Data Analysts who are familiar with the typically arcane nature of the source systems will love you for giving them a better and easier place to run their queries than what they've had for the past 10-15 years in the source system environments, and they don't have to learn anything new about the data structures since you were so kind as to keep them intact.
(2) Data models that represent specialized data marts, spun off from the source system data models. These specialized data marts are driven by unique requirements-- let's say a financial dashboard or a diabetes registry or a full-fledged clinical quality improvement project-- and each of these unique data marts will also have their own unique and optimal way to model the data, including naming conventions that are customized to the Data Analysts in those unique environments. In 80% or more of the cases, most Data Analysts want simple rows and columns of data--there's a reason Excel is so beloved and there's a reason that the success of multidimensional cubes is not more widespread. In some cases, the analysis requirements might best be served by a star schema data model; or a snowflake; or a single wide and deep table with lots of redundancy, such as a row for every patient's encounter; or even a second or third normal form data model. The bottom line: Go with what works, with the simplest data model, and remember that most people will be very happy with simple rows and columns of data that they can suck into Excel for manipulation.
(3) A Master Reference data model area where you can store things for look-up (e.g., for data quality checks) like ICD-9 codes; CPT codes; SNOMED terms; LOINC terms; Drug codes; the Master Patient Index and Master Provider Index; local standards for department, facility, service line, charge codes; etc.
If you need a decent starting place to grease the wheels of your mind for a generalized healthcare data model, take a look at HL7 RIM and i2b2. They are at different ends of the data modeling spectrum-- RIM is pretty much 3NF and i2b2 is pretty much a star schema with a pinch of EAV-- but for gawd sake don't assume that either of these models will be the single data modeling approach which will satisfy all the needs that you will face in a healthcare data warehouse. Many healthcare organizations drank the Kimball Kool-Aid early in their evolution of BI and DW, and they are now discovering that they painted themselves in a corner that's going to cost a lot of time and money to unpaint.
In summary: (1) Maintain the fidelity of your source system data; (2) Design your subsequent data marts using the data model that makes sense for the analysts and reporting needs associated with that data mart; (3) Provide a robust Master Reference data model area which can be joined to your source system "Operational Data Stores" and specialized data marts.
Don't paint yourselves in a corner. Trust your common sense. Kimball, Imhoff, and Inmon know far less than you do about this topic.
Monday, January 19, 2009
Martin Luther King Day
Often times, we celebrate today as a day of tolerance for diversity, but tolerance is a frail description for what Martin Luther King envisioned. Tolerance for diversity is not enough. We are obliged to be grateful for it. We must be fascinated and humbled by it. In the sum of diversity in Mother Nature, we humans among that, we glimpse the sum of God's knowledge which connects us all.
Today we honor the man whose valor and Dream enabled tomorrow’s miracle. No matter what your political affiliation, tomorrow’s inauguration is undeniably amazing. In 1986—only 20 some years ago-- when this day was declared a national holiday, there were many among us who felt it unwarranted. Those feelings were largely a hangover from the discriminatory beliefs which the Day itself sought to overshadow. The path to tomorrow’s inauguration was tiled by the words and blood of a pastor from Atlanta, Georgia who found inspiration from non-violent, compassionate protest in another hero of humankind known simply by a singular name—Gandhi. It is no accident, but seems divine providence, which ensures the appearance of a person who, in the dark periods of humanity, emerges to keep the balance tipped toward good in the struggle between good and evil. Recall through history the emergence of these single individuals who appeared on stage and kept the story of God’s great experiment moving forward when violence and oppression seemed all but guaranteeing the end of good. Martin Luther King and Gandhi... Abraham Lincoln, Franklin Roosevelt, and Winston Churchill, are them too, along with many other pure souls, absent of fame or notoriety. There is great hope in the world that the man whose inauguration to President was made possible tomorrow by the man we honor today, is another such figure in another troubled period in human history.
As the colors in the palate of God’s artistry paint a picture which constantly progresses, we must embrace diversity as an invaluable clue to understanding our purpose in the Universe. Today especially, look around you. Extend a hand and offer a smile. Live The Dream. See the wonder, amazement, and beauty in the Colors of that palate. And be humbled by it all.
Today we honor the man whose valor and Dream enabled tomorrow’s miracle. No matter what your political affiliation, tomorrow’s inauguration is undeniably amazing. In 1986—only 20 some years ago-- when this day was declared a national holiday, there were many among us who felt it unwarranted. Those feelings were largely a hangover from the discriminatory beliefs which the Day itself sought to overshadow. The path to tomorrow’s inauguration was tiled by the words and blood of a pastor from Atlanta, Georgia who found inspiration from non-violent, compassionate protest in another hero of humankind known simply by a singular name—Gandhi. It is no accident, but seems divine providence, which ensures the appearance of a person who, in the dark periods of humanity, emerges to keep the balance tipped toward good in the struggle between good and evil. Recall through history the emergence of these single individuals who appeared on stage and kept the story of God’s great experiment moving forward when violence and oppression seemed all but guaranteeing the end of good. Martin Luther King and Gandhi... Abraham Lincoln, Franklin Roosevelt, and Winston Churchill, are them too, along with many other pure souls, absent of fame or notoriety. There is great hope in the world that the man whose inauguration to President was made possible tomorrow by the man we honor today, is another such figure in another troubled period in human history.
As the colors in the palate of God’s artistry paint a picture which constantly progresses, we must embrace diversity as an invaluable clue to understanding our purpose in the Universe. Today especially, look around you. Extend a hand and offer a smile. Live The Dream. See the wonder, amazement, and beauty in the Colors of that palate. And be humbled by it all.
Tuesday, January 6, 2009
Investing in Mediocrity?
As reported in a recent article in the Boston Globe, David Kibbe, a senior adviser to the American Academy of Family Physicians, and Bruce Klepper, a healthcare market analyst, sent an open letter to our new president-elect, urging caution in the rush to invest in healthcare IT. Describing current systems as "expensive, cumbersome to use, and cannot easily exchange information about patients' health histories and treatments among different hospitals, labs, and doctors' offices. If America's physician practices suddenly rushed to install the systems of their choice, it would only dramatically intensify the [tower of] Babel that already exists."
The rush to deploy current market-leading EHRs is going to lock many healthcare systems into costly and imperfect clinical processes and technology. The functional difference between today's EHRs is minimal; they are rapidly converging on achieving commodity status, as the same old ideas are recirculated through the revolving door of HIMSS and AMIA. These EHRs are a hangover from the paper chart and motivated largely from the historical position of billing compliance and malpractice risk avoidance. They unfortunately perpetuate many of the ills of healthcare, rather than solve them.
We desperately need a revolutionary new approach in the design and functionality of EHRs-- one that is motivated from a position of physician efficiency, quality of care, and patient involvement in their own healthcare management-- with billing compliance and malpractice risk avoidance a natural but transparent consequence. Sinking billions of dollars into the current EHR market will leave no money or free market incentive remaining in the healthcare system to affect the revolutionary change in EHRs that we need. We should tell the EHR vendor market-- those in existence now and those who might emerge if sufficiently prompted--we expect more. As a taxpayer, I would protest major investments or subsidies of government money in the existing EHR market-- such investments would only reward mediocrity. As a healthcare IT professional, I would despair.
We should invest our healthcare IT dollars cautiously and in proven areas of value-- in many physician offices, this could be as simple as computerized registration, scheduling, and billing which improve clinical efficiency; access to wideband Internet services and the emerging lean (and inexpensive) web-based EHRs and PHRs (e.g., Relay Health) which support computerized order entry, especially ePrescribing; and tools that integrate data from existing diagnostic systems into a single user interface for quick reference by busy physicians.
The only thing worse than deploying an EHR is replacing one. Rather than rush headlong into purchasing a mediocre EHR today, we should pause, withhold our funds, and give free market capitalism a chance to react and catch-up to the opportunity by developing a new breed of EHRs which will leapfrog current thinking.
The rush to deploy current market-leading EHRs is going to lock many healthcare systems into costly and imperfect clinical processes and technology. The functional difference between today's EHRs is minimal; they are rapidly converging on achieving commodity status, as the same old ideas are recirculated through the revolving door of HIMSS and AMIA. These EHRs are a hangover from the paper chart and motivated largely from the historical position of billing compliance and malpractice risk avoidance. They unfortunately perpetuate many of the ills of healthcare, rather than solve them.
We desperately need a revolutionary new approach in the design and functionality of EHRs-- one that is motivated from a position of physician efficiency, quality of care, and patient involvement in their own healthcare management-- with billing compliance and malpractice risk avoidance a natural but transparent consequence. Sinking billions of dollars into the current EHR market will leave no money or free market incentive remaining in the healthcare system to affect the revolutionary change in EHRs that we need. We should tell the EHR vendor market-- those in existence now and those who might emerge if sufficiently prompted--we expect more. As a taxpayer, I would protest major investments or subsidies of government money in the existing EHR market-- such investments would only reward mediocrity. As a healthcare IT professional, I would despair.
We should invest our healthcare IT dollars cautiously and in proven areas of value-- in many physician offices, this could be as simple as computerized registration, scheduling, and billing which improve clinical efficiency; access to wideband Internet services and the emerging lean (and inexpensive) web-based EHRs and PHRs (e.g., Relay Health) which support computerized order entry, especially ePrescribing; and tools that integrate data from existing diagnostic systems into a single user interface for quick reference by busy physicians.
The only thing worse than deploying an EHR is replacing one. Rather than rush headlong into purchasing a mediocre EHR today, we should pause, withhold our funds, and give free market capitalism a chance to react and catch-up to the opportunity by developing a new breed of EHRs which will leapfrog current thinking.
Saturday, December 6, 2008
The True Value of an Electronic Health Record
We still struggle to define the value and return-on-investment of EHRs, often times naively attempting to justify the investment based upon improvements to physician workflow and patient volume. The real value resides in the systemic value of the data that's collected, the data that's analyzed, and the data that is presented (or not) back to the physician at the point of care, that has been dynamically tailored for the context of the patient being treated, making it easy for physicians to do the right thing.
A few days ago, I was in a meeting with members of Virginia Mason Medical Center who were visiting Northwestern to discuss clinical analytics and process improvement. Northwestern's Dr. David Baker provided an overview of an AHRQ-funded project called UPQUAL (Utilizing Precision Performance Measurement to Improve Quality) which he is leading. I think UPQUAL is the most systemic example and role model of clinical quality improvement in an ambulatory setting that I've ever seen-- every step in the care delivery process is affected. You can Google "UPQUAL Baker Persell" and find references. Darren Kaiser, my Senior Technical Guru of All Kinds, has been a critical part of this project, too.
During a break in his presentation, Dr. Baker was speaking with members of VMMC. The conversation moved to the recent clinical study published in the British Medical Journal which indicates that prophylactic aspirin for diabetes patients without cardiovascular disease is not effective in reducing heart disease-- the risks of aspirin outweigh the benefits.
Later that week, I was browsing my bloated email inbox and came across a Change Control Summary from our Clinical Systems team, entitled "Turn off BPA for Aspirin in Diabetics." Hmmm.... I opened the message and read the description: "Unrelease BPA #92 "Consider Aspirin in Diabetes" per direction of Dr. Persell/Baker. Recent evidence suggests that this Best Practice Medical Guideline is no longer deemed a best practice. Hence, we don't want to trigger BPA recommendations when there is little benefit to patient care." Translated, this means that Dr. Baker contacted our EpicCare EHR team and asked them to turn off the Epic Best Practices Alert that reminded our physicians to consider aspirin therapy for our diabetic patients.
I talked to Dr. Baker later in the week and asked him for the background. As he described it, the General Internal Medicine physicians discussed the strengths and weaknesses of the BMJ article, and then voted in one of their regular Clinical Quality Committee meetings whether to accept the new evidence and adopt the changes in practice. They voted in the affirmative and closed the loop by contacting the EpicCare team who then changed the BPA.
From start to finish, this change in clinical protocol took about eight weeks. I think the BMJ article was published on Oct 3 and the EpicCare Change Control was implemented on Dec 5.
In various lectures and presentations, I frequently speak of this concept which I call "Mean Time To Improvement" (MTTI). It is the theoretical ability to measure the time it takes a company to recognize the need for improvement, and then take action to implement that improvement on a widespread basis. I give examples of process improvement in industries like the foreign automotive market, computer chip fabrication, PDA design, wireless cellular services, and leading retailers. The examples indicate that the MTTI among the leaders in those industries can be measured in terms of hours, days, and a few weeks. They have low MTTI cultures. Then I give examples of process improvement in the U.S. government, automotive, and healthcare sectors. There are individual heroic exceptions in each of these sectors, of course, but for the most part, the MTTI can be measured in months and years... maybe decades. For dramatic impact, I use the example in healthcare in which 17 years expired before the protocol for community acquired pneumonia (CAP) was commonly accepted and practiced.
You see where I'm headed here... in the specific case of removing Epic BPAs for aspirin therapy in diabetics with no existing cardiovascular disease, we have an example which momentarily drove the MTTI in healthcare down to levels of respectability amongst the best of other industries-- maybe even better than other industries. It exemplifies the true value of an EHR to healthcare-- if that EHR is configured and utilized up to its potential by quality-dogmatic physicians and a capable IT team.
Very cool.
A few days ago, I was in a meeting with members of Virginia Mason Medical Center who were visiting Northwestern to discuss clinical analytics and process improvement. Northwestern's Dr. David Baker provided an overview of an AHRQ-funded project called UPQUAL (Utilizing Precision Performance Measurement to Improve Quality) which he is leading. I think UPQUAL is the most systemic example and role model of clinical quality improvement in an ambulatory setting that I've ever seen-- every step in the care delivery process is affected. You can Google "UPQUAL Baker Persell" and find references. Darren Kaiser, my Senior Technical Guru of All Kinds, has been a critical part of this project, too.
During a break in his presentation, Dr. Baker was speaking with members of VMMC. The conversation moved to the recent clinical study published in the British Medical Journal which indicates that prophylactic aspirin for diabetes patients without cardiovascular disease is not effective in reducing heart disease-- the risks of aspirin outweigh the benefits.
Later that week, I was browsing my bloated email inbox and came across a Change Control Summary from our Clinical Systems team, entitled "Turn off BPA for Aspirin in Diabetics." Hmmm.... I opened the message and read the description: "Unrelease BPA #92 "Consider Aspirin in Diabetes" per direction of Dr. Persell/Baker. Recent evidence suggests that this Best Practice Medical Guideline is no longer deemed a best practice. Hence, we don't want to trigger BPA recommendations when there is little benefit to patient care." Translated, this means that Dr. Baker contacted our EpicCare EHR team and asked them to turn off the Epic Best Practices Alert that reminded our physicians to consider aspirin therapy for our diabetic patients.
I talked to Dr. Baker later in the week and asked him for the background. As he described it, the General Internal Medicine physicians discussed the strengths and weaknesses of the BMJ article, and then voted in one of their regular Clinical Quality Committee meetings whether to accept the new evidence and adopt the changes in practice. They voted in the affirmative and closed the loop by contacting the EpicCare team who then changed the BPA.
From start to finish, this change in clinical protocol took about eight weeks. I think the BMJ article was published on Oct 3 and the EpicCare Change Control was implemented on Dec 5.
In various lectures and presentations, I frequently speak of this concept which I call "Mean Time To Improvement" (MTTI). It is the theoretical ability to measure the time it takes a company to recognize the need for improvement, and then take action to implement that improvement on a widespread basis. I give examples of process improvement in industries like the foreign automotive market, computer chip fabrication, PDA design, wireless cellular services, and leading retailers. The examples indicate that the MTTI among the leaders in those industries can be measured in terms of hours, days, and a few weeks. They have low MTTI cultures. Then I give examples of process improvement in the U.S. government, automotive, and healthcare sectors. There are individual heroic exceptions in each of these sectors, of course, but for the most part, the MTTI can be measured in months and years... maybe decades. For dramatic impact, I use the example in healthcare in which 17 years expired before the protocol for community acquired pneumonia (CAP) was commonly accepted and practiced.
You see where I'm headed here... in the specific case of removing Epic BPAs for aspirin therapy in diabetics with no existing cardiovascular disease, we have an example which momentarily drove the MTTI in healthcare down to levels of respectability amongst the best of other industries-- maybe even better than other industries. It exemplifies the true value of an EHR to healthcare-- if that EHR is configured and utilized up to its potential by quality-dogmatic physicians and a capable IT team.
Very cool.
Thursday, December 4, 2008
Northwestern Enterprise Data Warehouse Milestone
In past blogs, I've alluded to the development of our Enterprise Data Warehouse at Northwestern. The "enterprise" is currently inclusive of data content from Northwestern Memorial Hospital (NMH), the Northwestern University Biomedical Informatics Center, and the Northwestern Medical Faculty Foundation (NMFF). In the future, the enterprise will hopefully include Children's Memorial Hospital, the Rehabilitation Institute of Chicago, and our affiliated private physicians.
The EDW project is complicated by the fact that all of these organizations are separate business entities, even though we serve the common mission of Northwestern University's Feinberg School of Medicine. We all report to separate governance bodies, CEOs or the Dean. The EDW project forced us to define new models for collaborating on several levels including joint financing models, human resources management, data security, project oversight and governance, identity management, etc. Data warehouse projects are inherently very political and culturally risky, no matter what the industry or organizational structure involved. I am constantly amazed and pleased at how incredibly smooth this project has progressed. It is a phenomenally positive reflection on the culture of senior leadership, myself excluded from the compliment. Since so many new models and processes were required for the project, we've had to be comfortable with route finding and learning as we progressed. This required each organization to trust one another, significantly, as each took turns leading the climb at one time or another.
The clinical research value and momentum around the EDW is growing. At last count, 36 different research projects have been served with 62 data sets, using a secure, researcher-specific work area on the EDW web portal. The majority of these requests were fulfilled in the last 12 weeks.
Today, the EDW Team released a data set which was emblematic of the "enterprise" potential and capability of the EDW. The data set combined diagnosis data from the NMH case mix system (Primes) and the NMFF EpicCare system; and free-text data from NMH and NMFF lab reports. Another noteworthy milestone in this case-- The lab reports' text data was scrubbed of patient identifiers by an open source software algorithm developed by MIT and modified by our EDW Team for use in our system.
A description of the data set is below; 18,463 patients were in the cohort. The request was prep-to-research from one of our physicians who is investigating mild versus severe cases of the flu. Our newest member of the EDW Team, Nathan Sisterson, was the analyst who programmed the query and the text processing.
"The cohort is defined as: All patients whose text reports in Epic labs match are of a type whose lab name contains “influenza”, starts with “virus” or starts with “respiratory virus”. From this subset, the cohort is narrowed to only patients whose matching lab results contained the phrases “positive for parainfluenza”, “positive for influenza”, “influenza virus isolated”, “positive influenza”, “influenza virus detected”, or “* SD” (which is always accompanied by a number indicating a positive lab result). Patients whose ICD9 codes match 488, V04.81 or 487.x in Epic or Primes are also included."
Too early to celebrate a summit, but this is very exciting stuff at this stage of the EDW project.
:-)
Dale
The EDW project is complicated by the fact that all of these organizations are separate business entities, even though we serve the common mission of Northwestern University's Feinberg School of Medicine. We all report to separate governance bodies, CEOs or the Dean. The EDW project forced us to define new models for collaborating on several levels including joint financing models, human resources management, data security, project oversight and governance, identity management, etc. Data warehouse projects are inherently very political and culturally risky, no matter what the industry or organizational structure involved. I am constantly amazed and pleased at how incredibly smooth this project has progressed. It is a phenomenally positive reflection on the culture of senior leadership, myself excluded from the compliment. Since so many new models and processes were required for the project, we've had to be comfortable with route finding and learning as we progressed. This required each organization to trust one another, significantly, as each took turns leading the climb at one time or another.
The clinical research value and momentum around the EDW is growing. At last count, 36 different research projects have been served with 62 data sets, using a secure, researcher-specific work area on the EDW web portal. The majority of these requests were fulfilled in the last 12 weeks.
Today, the EDW Team released a data set which was emblematic of the "enterprise" potential and capability of the EDW. The data set combined diagnosis data from the NMH case mix system (Primes) and the NMFF EpicCare system; and free-text data from NMH and NMFF lab reports. Another noteworthy milestone in this case-- The lab reports' text data was scrubbed of patient identifiers by an open source software algorithm developed by MIT and modified by our EDW Team for use in our system.
A description of the data set is below; 18,463 patients were in the cohort. The request was prep-to-research from one of our physicians who is investigating mild versus severe cases of the flu. Our newest member of the EDW Team, Nathan Sisterson, was the analyst who programmed the query and the text processing.
"The cohort is defined as: All patients whose text reports in Epic labs match are of a type whose lab name contains “influenza”, starts with “virus” or starts with “respiratory virus”. From this subset, the cohort is narrowed to only patients whose matching lab results contained the phrases “positive for parainfluenza”, “positive for influenza”, “influenza virus isolated”, “positive influenza”, “influenza virus detected”, or “* SD” (which is always accompanied by a number indicating a positive lab result). Patients whose ICD9 codes match 488, V04.81 or 487.x in Epic or Primes are also included."
Too early to celebrate a summit, but this is very exciting stuff at this stage of the EDW project.
:-)
Dale
Wednesday, October 29, 2008
Microsoft Gets Business Intelligence
Normally, I would not use a public forum like this blog to endorse vendors and products, so when it happens, I do so with a fair amount of deliberation and forethought. Such is the case with my opinions about Microsoft and the evolution of their Business Intelligence and Data Warehousing strategy. In short, they get it. I think it's important to share these thoughts at a time when health care is turning the corner of interest on BI, and complexity and total cost of ownership for BI still tends to be a barrier to entry. Taken in its entirety, realizing that no vendor offers a perfect solution yet, Microsoft's BI/DW product stack and execution on vision offer the best overall value currently available to health care-- and other industries, too, for that matter.
My data warehousing background is rooted in the military and national intelligence communities, which were IBM and Oracle centric. The data warehouse that my team built at Intermountain Healthcare was (is) Oracle-based. Oracle and IBM have been good to my career. My first exposure to Microsoft-centric BI came at Intel in the mid-1990s when SQL Server and Windows were still on wobbly legs. We built a BI solution at Intel to help analyze the various trade-offs between logistics product options and chip fabrication defects and throughput for the Rio Rancho production facility in New Mexico. It was a whopping 300Gbytes in size. Long story short, the "New Mexico Data Repository" was a huge success and was eventually deployed to something like 35 of Intel's sites. My colleague Rob Carpenter deserves the credit for implementing the strategy and design that I started.
The point is, I've watched closely for a number of years as Microsoft has evolved SQL Server into what is now the equivalent of Microsoft Office for Business Intelligence-- i.e., a very rich stack of products that integrate very well to deliver a complete BI solution, from the database to the desktop and web. One of the most impressive aspects of this evolution was Microsoft's willingness to completely reengineer SQL Server's foundation at least once-- arguably twice-- during this period. They caught much-deserved criticism for these overhauls and the lack of backwards compatibility with SQL Server, but it was their willingness to take the heat in the short term, while the product was young and the install base was small, in return for long-term success that is particularly noteworthy. Part of their "willingness" to reengineer SQL Server was no doubt related to cutting commercial ties to Sybase, but nonetheless, whatever their motive, the outcome was strategically invaluable. Other RDBMS vendors have not done the same and they suffer from legacy baggage as a consequence.
Despite their very impressive vision and steady execution around SQL Server and BI, Microsoft could polish their strategy even more with the addition of two more tools in their BI product stack: (1) An integrated customer/person/patient identification tool-- that's a BI problem that plagues numerous industries, especially health care; and (2) A metadata repository and browser, which is a must-have for every BI/DW system, anywhere.
If Microsoft were smart ;) they would offer Windows on the desktop and the Office Suite for free and relinquish to their eventual commoditization-- in return for the value of the desktop's integration with a company's data. That's where the future value and differentiators for Microsoft reside. It's in the data, not the desktop.
Again, my motives in sharing these comments are to facilitate a faster rate of BI adoption and success in health care. Those who know me, know that I purposely keep vendor relationships at arm's length and wouldn't accept anything closer if it were offered. Microsoft can tell you that I've given them plenty of headaches and criticisms on other issues lately, so this blog isn't about a love fest. It's about getting to a data-driven health care environment in the U.S., the sooner the better.
My data warehousing background is rooted in the military and national intelligence communities, which were IBM and Oracle centric. The data warehouse that my team built at Intermountain Healthcare was (is) Oracle-based. Oracle and IBM have been good to my career. My first exposure to Microsoft-centric BI came at Intel in the mid-1990s when SQL Server and Windows were still on wobbly legs. We built a BI solution at Intel to help analyze the various trade-offs between logistics product options and chip fabrication defects and throughput for the Rio Rancho production facility in New Mexico. It was a whopping 300Gbytes in size. Long story short, the "New Mexico Data Repository" was a huge success and was eventually deployed to something like 35 of Intel's sites. My colleague Rob Carpenter deserves the credit for implementing the strategy and design that I started.
The point is, I've watched closely for a number of years as Microsoft has evolved SQL Server into what is now the equivalent of Microsoft Office for Business Intelligence-- i.e., a very rich stack of products that integrate very well to deliver a complete BI solution, from the database to the desktop and web. One of the most impressive aspects of this evolution was Microsoft's willingness to completely reengineer SQL Server's foundation at least once-- arguably twice-- during this period. They caught much-deserved criticism for these overhauls and the lack of backwards compatibility with SQL Server, but it was their willingness to take the heat in the short term, while the product was young and the install base was small, in return for long-term success that is particularly noteworthy. Part of their "willingness" to reengineer SQL Server was no doubt related to cutting commercial ties to Sybase, but nonetheless, whatever their motive, the outcome was strategically invaluable. Other RDBMS vendors have not done the same and they suffer from legacy baggage as a consequence.
Despite their very impressive vision and steady execution around SQL Server and BI, Microsoft could polish their strategy even more with the addition of two more tools in their BI product stack: (1) An integrated customer/person/patient identification tool-- that's a BI problem that plagues numerous industries, especially health care; and (2) A metadata repository and browser, which is a must-have for every BI/DW system, anywhere.
If Microsoft were smart ;) they would offer Windows on the desktop and the Office Suite for free and relinquish to their eventual commoditization-- in return for the value of the desktop's integration with a company's data. That's where the future value and differentiators for Microsoft reside. It's in the data, not the desktop.
Again, my motives in sharing these comments are to facilitate a faster rate of BI adoption and success in health care. Those who know me, know that I purposely keep vendor relationships at arm's length and wouldn't accept anything closer if it were offered. Microsoft can tell you that I've given them plenty of headaches and criticisms on other issues lately, so this blog isn't about a love fest. It's about getting to a data-driven health care environment in the U.S., the sooner the better.
Subscribe to:
Posts (Atom)
-
This post is for my kids to read someday, but others might find this lifehack helpful, too. As bizarre as it sounds, the Air Force Of...
-
Our dear mother, Ruby Aveline Sanders, long time Durango and Dolores resident, died in the early morning of April 23, 2014 in Durango, ... -
SpaceX launched a two-astronaut crew yesterday, on a mission to dock with the International Space Station. It was the first human spaceflig...
