EHR Interoperability, Part 2

The following comment was posted on the Mr HISTalk web site, in response to my earlier blog about interoperability:

"Dale, why hasn’t Health Catalyst published its data model and algorithms to the world? You want all the EHR vendors to bow down and provide their Intellectual Property to you for free so that you can make money building on it?

Where are your APIs Dale? Where is your data model published Dale? Get it published and make it available to all your competitors, other startups and innovators in general and then feel free to throw stones.

You’re just one more self interested wanna be in the healthcare start up game talking tough while holding yourself to a different standard."

This is my response:

Your comment is a little snarky, but the underlying theme has merit—I cannot expect from others what I do not expect of myself.

My blog was written as a practicing CIO, motivated by the best interests of our country, our patients, our physicians, and… get ready… EHR vendors. As evidenced by Epic’s recent decision to create an app store, I’m by no means the only person in the industry who believes that open APIs are the right thing to do for interoperability and innovation, as does the DoD. The DoD has been the historical leader of open systems in the world—ASN.1, SGML, DCE, CORBA, Ada, POSIX, TCP/IP and many others. Epic’s app store decision in light of the DoD procurement is a great recognition of that DoD legacy. The Epic app store will benefit the entire industry.

You can try to discredit my comments about interoperability by firing back at Health Catalyst, but the criticism just won’t hold up. Health Catalyst is a tiny little startup, fighting it out in the best interests of our clients, in the trenches of American capitalism. We are economic and market influence gnats on the rump of today’s EHR vendors—the same EHR vendors that have benefitted from billions of tax dollar subsidies. And when you benefit from that sort of tax money, along with that benefit comes a new level of scrutiny and accountability back to those tax payers to do the right thing. When and if the healthcare analytics market benefits from $25B in tax subsidies, the bar of national accountability will raise for Health Catalyst, too.

You would be surprised at how little influence I have on the way that Health Catalyst operates. I cannot and do not speak officially for the company. My contract with Health Catalyst stipulates that I can continue to speak, publish and blog on matters that reflect my personal opinion about the healthcare industry, which is the case in this discussion. In that context, I sit on the Canada Health InfoWay External Advisory Panel for Interoperability and that panel is in the midst of developing Canada’s roadmap for healthcare interoperability. We are hoping to help Canada avoid the ills that have plagued the US.

I will go out on a limb and offer speculation—I bet Health Catalyst leadership would love nothing more than to publish all sorts of open APIs around their platform and products. As soon as any other vendor, including EHR vendors, asked or wanted to build products around the edges of the Health Catalyst platform, Health Catalyst would open the API doors– and not out of naïve altruism, but out of common business sense. The bigger the ecosystem of products that can interact with Health Catalyst, the better for Health Catalyst and the better for Health Catalyst clients and the industry. The Health Catalyst web site is an open cookbook for analytic success in healthcare. Take a look at any other healthcare IT vendors’ web sites and compare it to Health Catalyst. We don’t even offer a login-protected portion of that web site for clients. Everything we do is in the open because that type of openess raises everyone’s game, including ours.

The only thing that Health Catalyst wants from EHR vendors is EHR data and data tags so that Health Catalyst clients can analyze their own data. It’s interoperability at the data warehousing level. I don’t see how EHR data can be considered IP that belongs to the EHR vendors. That data belongs to EHR clients and their patients, and I bet patients would like to know that their data is easy to access for analysis that benefits them clinically and financially.

I will close by asking: Is there anyone out there who genuinely believes in their heart that our national healthcare IT interoperability and innovation strategy is working? Is there anyone out there who believes that anything in my blog is asking or expecting too much of EHR vendors? I guess one person does, but would guess that most do not.

As usual, my thanks to Mr. HISTalk for providing this unique forum.

Respectfully,
Dale

Barriers to EHR Interoperability Are Contractual and Cost

The barriers to EHR interoperability are not just technical. They are contractual and cost, as well.  I’m speaking as a first-hand source of knowledge about this, as a healthcare CIO.

EHR vendors who enjoy the benefit of our tax dollars under the HITECH act are preventing interoperability-- and innovation around the edges of their EHR products by third party developers-- by placing limitations and restrictions in their contracts with clients. The vendors who are engaged in this type of exclusive behavior can point to their technology and say, "See? We can share data. We follow data sharing technical standards. Quit criticizing us." But when you look into these vendors’ contracts, the license fees associated with interoperability are cost prohibitive, and the interoperability clauses are surrounded by onerous contractual obstacles that are veiled to protect the vendors' intellectual property, yet are actually ensuring the vendors' continued stranglehold on data and preventing innovation around their products.

This behavior on the part of some EHR vendors is strikingly ironic, given the enormous success of open source, easily accessible APIs that benefit interoperability.  The more open your products are, from a software architecture perspective, the more value you accrete to your products’ intellectual property.  Open, transparent APIs create a greater dependence and ecosystem around your products, not less.

Several years ago, I sponsored a meeting with senior executives from four large EHR vendors, lobbying them to open their APIs and migrate their software engineering architecture from tightly coupled, difficult-to-modify-and-upgrade, message oriented architectures; to loosely coupled, flexible, services oriented architectures (SOA) with open, published APIs, so that my engineering teams could write innovative products around the edges of these EHR products.  We even sketched the architecture of an SOA-based EHR, along with about 20 core services-- it was easy; it is not rocket science. Within 18 months after those meetings, three of the four vendors launched formal initiatives in their companies to create more open, friendly APIs, both technically and contractually, and they’ve stayed the course.

I will never forget the response from the fourth of those EHR senior executives.  That person said, “We see ourselves as more than a database vendor.”  Meaning, of course, “Our closed APIs are a market and proprietary advantage.”  Bill Gates and Microsoft used to think the same thing about Windows, Office, and Internet Explorer.  You can see how that worked out for them when you compare what’s happened with the openness of Android, iOS, the browser market, and office suite products; and you can also see Microsoft’s amazing pivot towards open architectures and interoperability in the last few years.  SalesForce.com is the supreme example of business success based upon an open API and open culture.

One of my current colleagues, who has been deeply involved in the interoperability environment for many years, described his thoughts in an email to me, summarized below:

Current “Interoperability” standards, selected by the ONC and required by MU-S2 do not contain an adequate amount of data/data types to support the quality measurement requirements of the same MU-S2 program. This gap in data is what enables the EHR suppliers to continue the veil of “interoperability” while still protecting their proprietary intellectual property, serving the interests of the owners of these companies with little regard to what may be best for care, providers, patients or consumers.

Several EHR vendors are banning together around a new magic bullet technical standard called HL7-FHIR based on JASON technology.  While this new standard is great from a technical perspective (XML, REST, etc.), in its current form, based largely on existing HL7 v2, v3 and CDA concepts, it does NOT improve the accessibility of proprietary EHR data types, and those data types are needed for quality and cost performance improvement in healthcare.  While FHIR could be expanded to include this type of data, it appears the first efforts are focused on reinventing the technology for currently defined interoperability data types.

I’m not sure what, if anything, Congress can do at this point to fix the ills of Meaningful Use Stage 1, which, in effect, rewarded existing vendors with billions of dollars in tax money to maintain those vendors’ closed and proprietary APIs.  Decertification by ONC will become a bureaucratic mess, but I appreciate the symbolic stance taken by Congress around decertification, nonetheless. One thing that must happen—and maybe our legal courts are the only option for this—the contractual threats and cost barriers in EHR vendor contracts that stand in the way of interoperability and innovation must be removed.

Interoperability and innovation in healthcare IT are suffering, both technically and contractually, by old-fashioned, old-school thinking on the part of some EHR vendors.

And, as an outcome, our healthcare system and patient care are suffering, too. We can do better as a country, and the EHR vendors can actually profit from being more open, not suffer.

The Personal and Professional Downside to Gratitude

Gratitude has become a very mainstream trend in the last few years. That's generally a good thing, but I've come to realize that too much gratitude has had a downside in my life, both personally and professionally.  This is a giant and new insight for me, given my upbringing and philosophies of life.

I was born and raised in a family that exuded gratitude. My dear Mom and Dad lost two of their children, very early in life, to tragic accidents, but they remained strong, positive and grateful, and it carried over to their four remaining children, and innumerable grandkids, friends, and neighbors.

Every night, I go to sleep saying my 'gratefuls' not prayers. I spend the moments before drifting off, replaying the day, reviewing all the wonderful and fascinating things that occurred in my life that day. Inevitably, no matter what bad things the day held, there are always a larger number of things for which I can sincerely step back and give thanks. I love this practice and have no plans of changing it.

But...

Now reflecting back, at 55-years into life, I can see a number of situations, both personally and professionally, in which too much gratitude actually played a negative role in my life, not positive.

In abusive, unhealthy relationships, I kept expressing gratitude-- finding all the good things in those relationships-- to the detriment of my self-esteem, life potential, and happiness.  That happened twice, in significant ways.  I was simply grateful that someone loved me, even if that "love" came wrapped in psychological abuse and relationships that were clearly unhealthy. My gratitude kept me engaged in those relationships, much longer than was healthy.

In a number of business negotiations, usually involving employment compensation, sometimes also job titles and new responsibilities, I've been too grateful-- taking a very passive, trusting, selfless, and soft approach to those negotiations, but underplaying my value, skills, and contributions. In these cases, I was a combination of too grateful for the compensation or job offer, and to have any job at all, and also too humble. I failed to recognize and acknowledge the value of my own work.

It took many years for me to become aware of this tendency towards too much gratitude, and it's especially unusual that this awareness should arrive at a time when practicing gratitude is a cultural phenomenon. The popularity of gratitude in today's society is probably one of the reasons that my awareness of its downside became highlighted.

Be grateful, but be careful.  In any situation, personal or professional, if you are endlessly grateful, odds are, you are going to be a lot less likely to say, "I (or we) can do better." Don't let too much gratitude keep you in an unhealthy relationship or keep you from negotiating firmly and truthfully about your own professional value, or from improving a situation to achieve greater potential. And be prepared-- it takes courage to pull back on the reins of gratitude and declare, "Wait a second, I don't have to be grateful about this situation. There's nothing wrong with expecting a little more."

I can't believe I'm going to say this-- don't let gratitude hold you back.

When I Googled, "is it possible to be too grateful" I found a good, 11-minute video from Amie Gordon, a PhD researcher who has given this topic some very formal, academic thought:

Guiding Philosophies of Awards and Recognition Programs

Awards and recognition programs for teammates and employees are a critically important aspect of an organization's culture.  But... it's not difficult for them to have the opposite intended effect, by recognizing employees who don't deserve it, failing to recognize those who do, or losing the sincerity of the recognition altogether-- that is, going through the motions of an awards program because that's what all companies are supposed to do, and thus making the recognition seem manufactured and having no soul. It conjures images of Michael Scott at Dunder Mifflin.

My early professional upbringing in the Air Force sensitized me to the pros and cons of an awards program-- the Air Force is awash in various forms of recognition, the most obvious being medals and ribbons for achievement and heroism. They take the notion of recognition very seriously. One might think that the sheer number of medals and other awards might diminish their individual effectiveness and sincerity, but the vast majority of the time, that's not the case.  So, how does the Air Force, and other military branches, pull this off with success, balancing all of theses issues?

Below are the principles and philosophies of recognition programs that I hold dear to heart, based on what I've experienced personally and observed second hand, starting in the Air Force, and then the civilian corporate world.  I communicate these principles on a regular basis to the organizations that I'm lucky enough to lead, reminding them that no recognition program is perfect, but recognition itself is critically important to the basic human needs of feeling appreciated and respected.

1. "Praise in public, criticize in private" is one of the oldest and wisest pearls of leadership wisdom.  Ninety-nine percent of the time it is a great rule of thumb. Every once in awhile, praising in private is more appropriate, so be aware and apply that when needed.
2. The praise and recognition should be commensurate with the achievement. You can't give a Medal of Honor to everyone.  If you had fireworks everyday, the 4th of July would be just another day.
3. No recognition program is perfect. Some folks will get more than they deserve and some folks will get less than they deserve. But you can't starve a good recognition program for lack of a perfect one.
4. In recognition of the imperfections and fallibility, the best thing to do when you receive praise and recognition is to pass it on to others, and acknowledge them. Rarely, if ever, will you achieve something entirely upon your own.
5. You will, at some time, be overlooked when the recognition train goes by and you will feel slighted. That's ok. That's human nature. It happens to all of us.  When that does happen, the important thing to remember is this: It's ok to wish more for yourself. It is not ok to wish less for someone else. There's a big difference.

Quite often in life, it's difficult to find the perfect balance in a given situation. Finding the perfect balance between too much recognition and too little can also be illusive. My guiding philosophy in these situations is to err towards the side of the better mistake. In this case, I think it's better to err towards too much recognition, rather than too little, being careful not to award everyone a Medal of Honor. 

A Few Thoughts About Veteran's Day

I posted these comments on Facebook, and post them here again as my running journal of life, for our daughter, Anna Elizabeth, now 8-months old.

This is a picture of me, a young Air Force Captain, but it's really about my Dad and brother, Gene, who went before me. Dad served in WWII, Korea, and Vietnam. Gene was killed in a flight line accident at Elmendorf Air Force Base in the run up to the Vietnam War. They truly *served*.  My service pales in contrast. The United States Air Force gave me much more than I gave to it. More than anything else, it taught me quiet, deep self-confidence. If you can survive and thrive through the training and stress of the military, everything that you face in life after that is a cake walk... and oftentimes, boring. Nothing in the civilian world compares to the responsibility and trust that you are granted in the military. God bless all those young men and women who are serving today in our troubled world, especially my nephews, Kyle Nabors and Tyler Dennison.  Duty, Honor, Country.

I really appreciate all the wonderful comments and thanks... but the thanks are not necessary and make me a bit uncomfortable. Day-to-day, greater thanks should go to many others more deserving. This post is about giving thanks to the United States Air Force for what it did for me. It totally changed my life for the better, at a time in my life when I needed that help, desperately. When my Dad passed away, just a few days after I graduated from high school, I lost the anchor of my life. For whatever reason, his death stripped me of my self-confidence and identity. I was, without that anchor, completely adrift in the seas of a very confused young man, trying to find his way back to port. I struggled through college, hanging on to new role models who were a horrible influence and the worst example of manhood, imaginable. After college, the Air Force stripped my identity down even further... then rebuilt me. No mercy, no excuses, no escape. Up was the only direction that the Air Force made you feel was a viable option because so many other people and principles depended on you... YOU. There were other options of course-- you could always quit, dropout, or fade out to mediocrity-- but your mind never really believes that those are viable options. You have to keep climbing because if you don't, others will fall. 


Thank you, United States Air Force. No thanks are due me.

A Film Documentary-- From the Heart: Healthcare Transformation from India to the Cayman Islands

At the end of this blog is a link to an inspiring film documentary. If you'd rather skip the background described in the blog, feel free to scroll directly to the bottom of the page.

In the spring of 2008, I was coming to the end of a four-year commitment as CIO and chief architect of the enterprise data warehouse at Northwestern University's school of medicine, and contemplating my next career move. President Obama had recently been elected, campaigning on a firm commitment to reform US healthcare. While the reform process took place, I thought it would be a good idea to learn from the healthcare system in another country. I had a long-term relationship as an advisor and guest speaker in the Canadian health care system, so finding a position in Canada was my first inclination.

About 2 AM on a Sunday morning, I was organizing my to-do list for the week when an email arrived in my inbox from a headhunter who I rarely communicated with. In the subject line of his email was “Cayman Islands CIO.” I opened the email. In it, the headhunter wrote, “I don't represent this client, but you are the first person I thought of when I saw this posted.”  In the body of the email was a URL to a Craig’s List posting. I paused for a moment and wondered, “If I clicked on this link, is it going to drain my bank account?” I went ahead and clicked on the link. I was happy to find out that the link was valid and there was a job posting for the CIO position in the national health system, known as the Health Services Authority, of the Cayman Islands. I was very intrigued by the possibility, even though I was predisposed to the Canadian system. My resume and cover letter were up-to-date, thanks to my interactions in Canada, so on Tuesday, I quickly made a few changes and responded to the posting.

On Wednesday morning, the human resources director at the Health Services Authority contacted me through email. His name was Ronnye Etcitty, which is a common surname among Navajo Native Americans that I grew up with in southwestern Colorado. I thought that to be an unusual coincidence, but nothing more. Ronnye and I spoke on the phone that afternoon and I mentioned to him that the Etcitty name was common in the area of my upbringing. He laughed and said, “It’s common in the area of my upbringing, too—Tuba City, Arizona.” We immediately connected at a personal level on our common background. The coincidence seemed serendipitous. We made plans for me to fly down to the Cayman Islands and interview for the job. My wife and I flew down on Thursday, I interviewed on Friday, we stayed through the weekend, flew back on Monday, they made an offer on Tuesday, and we accepted the offer on Thursday. I served as CIO for three years and as a consultant for a fourth year. It was, up to that point, the most rewarding personal and professional experience of my life. The people of the Cayman Islands and my teammates at the Health Services Authority welcomed me with warmth that remains to this day. The fondness and appreciation that I have for them will last the rest of my life.

In addition to the cultural fulfillment of working in the Cayman Islands, the leadership team at the Health Services Authority, as well as the Board of Directors, were selflessly dedicated to challenging the status quo of healthcare in ways that my colleagues in the US would not entertain. The CEO of the Health Services Authority, Lizzette Yearwood is, to this day, the best all around and natural leader that I've ever seen or worked for, and if you know my background, I've been around some of the best leaders in government, military, and private industry.

About six months after I arrived in the fall of 2009, Dr. Devi Shetty and his team from Narayana Health System in India approached the government of the Cayman Islands with the idea of building a 2000 bed hospital, medical school, and long-term care facility in the Cayman Islands, in anticipation of the need for higher quality care and lower costs in the Western Hemisphere, particularly the US. I was familiar with Dr. Shetty and his work, through articles in the Wall Street Journal and other magazines. In particular, I remembered him being referred to as the “Henry Ford of healthcare” and Mother Theresa's cardiologist.

In the fall of 2010, I had the opportunity meet Dr. Shetty in person when we participated on a panel together for the Cayman Islands international healthcare conference.  He is, of course, a world-renowned cardiovascular surgeon. I expected that from what I had read about him. What I did not expect was an immediate sense of deep spirituality that surrounded him. It was immediately obvious that I was in the presence of a very, very unique human being. At the conclusion of our panel session, I leaned over to him and with sincerity, whispered into his ear, “Someday, you will win the Nobel Prize for medicine.” He laughed and humbly demurred.  If he doesn't win the Nobel Prize, it will be an unfortunate omission.

Fast-forward to the spring of 2014. Dr. Shetty and his team, in collaboration with the Cayman Islands government, Ascension Health in the US, and Gene Thompson, a prominent businessman in the Cayman Islands, opened the doors on the first phase of the project-- a 200 bed hospital, specializing in cardiothoracic and orthopedic surgery, constructed on the East End of Grand Cayman Island.

There is nothing about this documentary, nothing about what Dr. Shetty has achieved or Gene Thompson has sponsored, that cannot be replicated in the United States.  The population of the Cayman Islands is less than 50,000 people.  The per capita income is almost exactly the same as the United States.  They are geographically isolated, sitting on the edge of a 25,000 ft deep underwater canyon, making all forms of commerce, including electronic, an enormous challenge.  They have no direct taxation to support basic healthcare, much less innovative healthcare, and yet they are doing both. 

Health Catalyst funded, produced, and directed this documentary because we feel it is important to tell the story of Dr. Shetty's commitment to affordable, high-quality health care, as well as the courage to support his initiative on behalf of the people, the government, and the business leadership of the Cayman Islands. We have no financial relationship and stand nothing to gain by sponsoring this documentary. We simply believe it is a story that must be told, in hopes that it will stir a role model following in the US and throughout the world.

Please enjoy.  Healthcare Transformation From India to the Cayman Islands

Disease Surveillance With An Enterprise Data Warehouse

Introduction

We could easily justify a 30-page paper on this topic, but I don’t have time for that, so I’m going to offer a few thoughts and observations on this topic while it’s hot. I hope that others of you with similar experiences will share the same by contacting me or submitting a comment.

Here’s a summary of the current options that are available for monitoring data that could help identify disease outbreaks.  Additional details about these options appear later in the blog, and you can see in those details, the options are not great.

1.     Monitoring chief complaint/reason for admission data in Admit, Discharge, and Transfer (ADT) data streams.

2.     Monitoring coded data that is collected in Electronic Health Records (EHRs).

3.     Monitoring billing data.

Federal Meaningful Use regulations require that EHRs be able to submit syndromic data to a surveillance system, but I have a feeling that requirement is going to run into data quality problems, for the reasons described below.

Key Concepts: Data Quality and Data Profiles

One of the key concepts that underlies what I’m about to discuss in this blog is data quality.  Poor data quality translates into poor outcomes for decision-making, imprecise decision-making, and imprecise responses to a situation.  The equation for data quality is:

Data Quality = Completeness x Validity

The higher your data quality, the more precise your understanding of the situation at hand and the more precise your decisions and reaction can be to a situation. 

“Completeness” is exactly as the word implies—how complete and granular is the data you have access to, about a patient’s situation?  The metaphor that I like to use is that of a low vs. high-resolution picture.  The higher the resolution of the picture, the more detail you can see and understand about the subject in the picture. A low-resolution picture leaves you guessing about the finer details.  Highly “complete” data is equivalent to higher resolution.

“Validity” is a little more difficult to describe, but in short, it relates to the context of the situation in which the data is collected and the accuracy of the data.  If a nurse measures a patient’s temperature and enters it into an EMR, that satisfies the concept of Completeness—the data has been captured.  If that nurse enters the wrong temperature, we have a violation of the concept of data Validity.  Timeliness of data is also a dimension of Validity.  In the case of charting a patient’s temperature, if a nurse enters the correct temperature in the patient’s chart, but enters it four hours after actually taking the patient’s temperature, that data lacks temporal Validity.  To be valid, the data must be timely, relative to the decision-making or action associated with the data.

In addition to Data Quality, the other key concept is the notion of a “Data Profile” for a patient and disease type.  A simple data profile for a patient is pretty straightforward—name, gender, age, height, weight, address—those are the basics of a first pass at a data profile.  To round out the data quality of that data profile, we would also like to collect current medications, known allergies, past surgeries, family history of disease, and chronic conditions.  The next pass through the data profile is the collection of data associated with vitals and labs-- temperature, heart rate, respiratory rate, blood pressure, basic blood and urine labs.  Each additional pass adds new data points about a patient—i.e., a higher resolution picture-- and contributes to that patient’s data profile and, hopefully, the data quality about that patient, as well.

Diseases also have a data profile, based upon commonly acknowledged symptoms and, hopefully, very discrete lab results or other diagnostics, such as those from imaging.  The first symptom of Ebola is a fever, followed days later by increasingly worsening fever, bleeding, and vomiting.  Unfortunately, the initial data profile of a patient with Ebola—data profile = fever-- overlaps with hundreds of other disease states.  Without more complete and valid data—that is, a higher resolution picture-- the initial clinical data picture of Ebola looks like a multitude of diseases.  To raise the threshold of concern for declaring patient as “Ebola possible”, the next data point beyond fever, absent a pathology assessment for the virus, is a data point about the patient’s socio-physical environment prior to the onset of fever—i.e., Does this patient have a fever AND has this patient been exposed to another patient or group of patients who were Ebola infectious?  I’m oversimplifying a bit, but the precision and accuracy of the data profile is a series of these data profile AND statements.  Any time we see a pattern of Boolean statements as a tool for describing a situation, we should immediately see an opportunity for computer-assisted decision-making. 

Every healthcare system in the US should possess a generalized data profile alerting engine that is fed by an Enterprise Data Warehouse (EDW) that could, in-turn feed analytic output to the EHR at the point of care, as well as any number of other downstream data consumers, such as state and federal government. Within that alerting engine, a healthcare system would be capable of creating any number of profiles for “Patients Like This” (I notice that Epic has trademarked that phrase, but I’ve been using it, too, since about 2001). Those of you who are familiar with Theradoc can see the conceptual overlap with what I’m calling a patient profile alerting engine.  But, there are also significant differences in the concept and, especially, the implementation models.

The profiler would sit in the background, passively watching the stream of data into the EDW until the profiler reached a tipping point in its predictive algorithm, at which time it would declare, “This patient has a [%] probability of [this disease or condition].”  Declaring the likelihood of a patient with an infectious disease is not good enough, however. We must also use the alerting engine and our data to recommend the action and intervention to take following the prediction.  In the case of Ebola, the alerting engine would notify the immediate clinical team and the Infectious Disease SWAT team to isolate and sterilize everyone within contact.  At Intermountain, we called these altering engines that were embedded in the EHR and EDW, “Medical Logic Modules.” Trained teams of informaticists, clinicians, data engineers, and pharmacists would define the logic inside these modules, monitor them over time, and adjust as necessary depending upon the evolution of the data profile for the disease or condition.

Here’s a diagram of the conceptual architecture:

So, that’s the long-term goal—a patient profile alerting system attached to an EDW, configured with Medical Logic Modules, and passing that data to an EHR so that the analytics of the EDW is facilitating better decisions at the point of care. For the moment, I will avoid mentioning the contractual restrictions and technical barriers that some of the major EHR vendors place on their APIs that make this sort of architecture very challenging to implement.  If these vendors understood the commercial value of open APIs (technically and contractually), they would understand that it would increase their market share and IP, not detract from it.

Near-Term Options

So… back to the topic at hand… What do we do in the near term?  Is there anything we could do, realistically, to better track the progress of diseases like Ebola, given our existing ecosystem of information systems in healthcare?  As you can see from the options that I list below, we could do better than nothing and the existing state of affairs, but any current option has significant shortcomings.

Here are the options that are available right now, listed with their pros and cons:

1.     Monitoring ADT messages:  This option would use the chief complaint/reason for admission data in an ADT message. The advantage of this option is that it is real-time, upon presentation of the patient at a healthcare facility.  The disadvantage of this option is the lack of codified, computable data in the data stream, thus requiring some form of natural language processing. Better than nothing, but far from precise. When presenting, chief complaint is usually captured in a free text field in the registration system.  A handful of forward thinking healthcare organizations are starting to codify these chief complaints with SNOMED, using an interface terminology on the front end of that coded data so that registrars can still enter a lay term for the chief complaint that is mapped to a medically-meaningful and computable code in the background. 

The other disadvantage of this approach is simple:  a patient’s complaint does not equal a clinical diagnosis.  A complaint of fever and vomiting from a patient might infer Ebola, but only a clinician and a lab test are capable of declaring with certainty that the diagnosis is Ebola. Until that clinically valid data is available, the best you can do is be concerned, but not definite. On a technology level, the other disadvantage of this option is, the chief complaint is frequently a single field in a database, so registrars will usually only capture one complaint—“headache” or “vomiting” when there might be several symptoms.  Sometimes, the registrar will overload the data capture field with multiple complaints, separated by commas. 

If this were a good option, then HIEs or common interface engines would be capable of analyzing these ADT messages for this type of content, but there is no widespread occurrence of that in the industry because of the shortcomings to the approach.

2.     Analyzing Coded EHR and Other Clinical Data: In this option, we could monitor coded data (SNOMED or ICD) for diagnosis, labs tests and results, and diagnostic imaging. This is the most precise option available, but it is unlikely to ever be a real-time option in healthcare.  The way current EHRs are designed, the data that is entered into an EMR for a patient’s encounter is an all or nothing commitment—that is, until the clinician “closes” the encounter with all associated data and notes, that data is not made available for analytics and decision support. This is an unfortunate design and behavior because, as I mentioned earlier, there is at least some decision-making value in an incomplete, low-resolution data profile.  The alerting engine could be running in the background, looking at these clinical encounters that are only partially complete from a data perspective, whether the clinician is finished with their documentation or not.  In any case, as currently designed and practiced, it can be many hours, several days, or even a few weeks before a clinician closes a clinical encounter in an EHR.  That’s not exactly opportune for managing a rapidly expanding disease outbreak.

3.     Analyzing Coded Data From Billing Systems.  This has all the problems of option 2, and more.  It’s not unusual for revenue cycle processes and systems to take over 30 days to drop a bill. But, in the absence of an EMR, this data is certainly better than nothing for profiling.

There are other options emerging, but they are years away from being integrated into the workflow of current EHRs and clinical processes.  There have been several recent studies showing the potential for analyzing social data, such as Twitter and Facebook.  Also, analyzing consumer purchasing data is a possibility.  Several years ago, before Wal-Mart became more secretive and declared their analytics systems as their most valuable corporate asset except people, I saw a demonstration of their application that could track the sale of products across all of their stores, in near real time— sales data was available for analysis in their EDW within 9 minutes of a transaction at any of their stores, as I recall.  One of the more interesting parts of the demonstration was their ability to see the progression of influenza across the US, as inferred by the sale of over-the-counter medications.

In Summary

Our options are not great right now, but with a well-designed and flexible data warehouse, at least healthcare delivery organizations have the beginnings of an option that can improve in precision as we integrate more and more data, increasing the completeness and resolution of the picture for syndromic surveillance.

If anyone has any other ideas, options, or thoughts on this topic, I would love to hear from you.