This post is a continuation; Part 1 is at this link. In this post, I describe a examine the question: When it comes to EHRs, whose satisfaction is important?
Someone commented that EHR “satisfaction is in the eye of who? The physician? patient? government? business?... I only hope it is the patient that wins out.” This comment is intimately tied to the question: Who should gain the most VALUE/BENEFITS from EHR/health IT use?
I contend that if they improve clinical outcomes and quality-of-life (through prevention and treatment), while they contain or lower costs to providers/clinicians and prices to consumers/patients (i.e., increasing value/benefits to the providers and receivers of care), then our society (and species) wins in the long haul. A business model that focuses on short-term gains for “me & mine,” rather than on realizing a longer-term vision that focuses on the common good, inevitably harms consumers and those who care for them.
Beneficiaries of this dysfunctional business model are manufacturers, politicians, lobbyists, providers, consumers and others who line their pockets by “gaming the system” through all sorts of unscrupulous (and at times illegal) tactics. Some might conclude that this is just “the American way,” but based on the huge waste of money and resources in the in the UK's health IT system (NHS IT system one of 'worst fiascos ever'), I believe it’s a consequence of capitalism that has lost its way, along with its sense of virtue.
I contend that the underlying cause of our broken healthcare system is our pathologically mutated form of capitalism —a term coined by John Bogle, named by FORTUNE magazine as one of the four giants of the 20th century and by TIME magazine as one of the world's 100 most powerful and influential people—which he said is a “fundamentally a blight on our society…It says something very bad about American society…ultimately, the job of capitalism is to serve the consumer. Serve the citizenry. You're allowed to make a profit for that. But, you've got to provide good products and services at fair prices…What we've done is have…a pathological mutation of capitalism” (see this link).
The rational way forward with regards to EHRs, I contend, is for clinicians to demand health IT tools that enable them to increase value to the consumer and demand fair compensation for doing so (Pay for Value). These tools should be low cost, flexible, ever-evolving, interoperable, and highly useable & useful for the clinician, patient, and researcher/informaticists. It should combine the best (and simplest) methods for data entry, analytics, decision support, and presentation (display), as well as secure transport and storage. They should also be efficient and accommodate workflows (including referral point-of-care, and mandatory reporting processes), and they should include the capabilities that include clinical concept parsing & processing (i.e., tools that improve the use of clinical notes and aid in inductive and deductive reasoning). In addition, they should provide ongoing risk-adjusted information to clinicians about their individual patients and population (cohort) outcomes.
The use of innovative EHR add-ons (companion applications) is a sensible way forward, even though EHR vendors may resist for business reasons that run contrary to the goal of increasing value for patient and provider, which is not surprising as per Bogle’s criticism and the need for "real capitalism, not crony capitalism that we have now in many industries, especially healthcare.” And while EHRs should be able to incorporate information directly from patients, it should also be able to associate and substantiate it with clinical technicalities.
These capabilities are simply way too much for any EHR today, but they can be achieved over time through collaboration that expresses our views and needs, embraces creative destruction, and suppresses regulatory capture that increases complexity, cost, and inefficiency.
Wednesday, November 06, 2013
This post is a continuation; Part 1 is at this link. In this post, I describe a examine the question: When it comes to EHRs, whose satisfaction is important?
Tuesday, October 29, 2013
This post is a continuation; Part 1 is at this link. In this post, I describe a vision of an ideal EHR system that can developed today.
Based on the complaints about EHRs, one can conclude that there would be increased satisfaction if EHRs are thought to be a component of an all-encompassing HIT system. This next-generation computerized system would manage clinical information, as well as administrative data, in a way that increases provider efficiency, enables providers to deliver high-value (cost-effective/safe/quality) preventive and acute care and rewards them for doing so, assists patients/consumers in taking better care of themselves (self-maintenance), and promotes population health.
So, imagine coming together to build a novel EHR-based HIT system that continuously improves clinical and economic outcomes by (in no particular order):
• Capturing clinical information accurately and automatically at point-of-care in real time in a way that requires little effort and workflow change
• Clearly presenting—to clinicians and patients—the biomedical, psychosocial (biopsychosocial) and economic information they need to: (a) bridge the knowledge gap (http://wellness.wikispaces.com/The+Knowledge+Gap) ; (b) make wise prophylactic, diagnostic, and treatment decisions; and (c) promote patient-centered cognitive support (http://curinghealthcare.blogspot.com/2009/06/meaningful-use-clinical-decision.html)
• Enabling networks of collaborators to: (a) perform clinical research in the field and lab through the streamlined collection, sharing, and analysis of large quantities of diverse clinical data; (b) build evolving health science knowledgebases with for clinical research, which transform this knowledge into evidence-based practice guidelines/protocols/pathways; (c) promote the continuity and coordination of care; (d) share observations, lessons learned, and best practices; and (e) effectively run PCMHs and ACOs
• Integrating sick care with well care (see http://wellness.wikispaces.com/Tactic+-+Well-Care+Sick-Care+Integration)
• Provides useful business intelligence
Part 5 examines the question: When it comes to EHRs, whose satisfaction is important?
Saturday, October 26, 2013
This post is a continuation; Part 1 is at this link.
In this post, I discuss what's needed to make EHRs more satisfactory and answer questions about my claims.
What’s needed is a paradigm-busting shift in which clinicians and software developers collaborate to create tools that are truly clinically useful and promote (rather than destroy) efficiency. We can start by redefining Meaningful Use – see my blog post at http://curinghealthcare.blogspot.com/2009/05/defining-meaningful-use-of-health-it_02.htmlI then answered a question about my claim that over-reliance on XML and Web services is a big problem with HIT standards:
I'm not saying that XML can't work; just that XML is being over-used. When data sets are rather simple or XML is used for sending messaging operation instructions for web service, I have no problem with it. But when it comes to representing complex data, as in a CDA-based document or a complex form definition file, XML sucks!
Here’s why: When you use XML in such cases: human readability is a joke, verbosity is huge, and parsing requirements and complexities are immense. It also forces conceptual incongruities just to keep data in hierarchies when such parent-child relationships are unnecessary. See http://curinghealthcare.blogspot.com/2009/12/dueling-data-formats.html and http://c2.com/cgi/wiki?XmlSucks.In fact, I’ve seen XML-related complexities bring the Query Health initiative to its knees (see http://curinghealthcare.blogspot.com/2012/08/disruptive-innovation-in-health-it-path_8.html).
I fought against this "let's use XML for everything" mentality since the mid-90's, but to no avail. Now the crap is hitting the fan!
Bottom line is that there are much easier/simpler and more rational ways to represent complex data than XML, even hierarchical data. We've got to start busting maladaptive paradigms.
Regarding the web services issue, I have no problem with this architecture for the most part, but bringing SOAP and RESTful into the DIRECT Project, and relying on them exclusively in other Federal initiatives, adds similarly increased complexity, as well as vulnerability, as I discuss at http://curinghealthcare.blogspot.com/2012/07/oncs-direct-project-in-defense-of.html.
What we need is a hybrid approaches that balances web services and XML with simpler elegant methodologies.
These issues came to a head during the standards-making process at the S&I Framework Structured Data Capture (SDC) initiative where I fought for the inclusion of a much simpler approach to capturing data using electronic forms, but was voted down by the community (see http://wiki.siframework.org/Canddiate+Standards+List+Feedback). To their credit, however, they are allowing our team to pursue a pilot (on our own dime) even though it will demonstrate use of technology/methods that aren’t fully compliant with the implementation guide they are developing.
In any case, the kind of change we need isn't going to happen by EHR industry lobbyists or the Feds ... As I said before, it's got to be led by clinicians and researchers working closely with creative software developers (including nimble EHR/HIT vendors) who focus on designing and deploying clinical tools that are truly useful and useable.In part 4 at this link, I discuss a practical vision of a next-generation EHR system that can be built today, which addresses the many criticisms of what is happening today.
This post is a continuation; Part 1 is at this link.
The next issue turned to who should ultimately control a patient's data. Should it be the patient (patient access control), provider/clinician, care team/ACO/PCHM, HIE/gov't/CMS?
Here's what I wrote:
Some believe patients should have granular control of who gets to see their health data and, if de-identified and aggregated for population health research, that the patient should be compensated financially for authorizing such use of their data.
Concerns about PHI privacy and gov't control are certainly warranted and, I agree with Randall, that legacy systems have been incapable of doing what's needed to give patients peace of mind that storing their PHI in the cloud provides a high enough level of privacy protection. We cannot achieve the Triple Aim unless we have wide deployment of a secure, low-cost, always available, and simple way to exchange data from EHR to EHR, EHR to PHR, EHR to Population Health and After Market Surveillance repositories (with de-identified data), and from Person to Person (patient to clinician, clinician to patient, and clinician to clinician).
A pub/sub, loosely-coupled, mesh node network, with identity management and endpoint-to-endpoint encryption, is one way to achieve this.The next issue raised is whether the actual goal of healthcare reform is to make it fail. I responded by saying:
I've heard from more than one person that current healthcare reform efforts were designed to fail. While I'm not sure about that, I AM confident that the cost, complexity, inefficiencies, and insecurities built into current implementation regulations are too big NOT to fail.
Nevertheless, the underlying goals of ARRA HIT--to improve care quality and contain costs/prices (i.e., increase value to the consumer)--are absolutely essential. We have a real big problem if all the spending and hassles are just a manipulation to funnel taxpayer's money into the coffers of certain big corporations under the guise of helping the common good.
As such, I believe physicians and other clinicians, researchers/informaticists, and HIT developers have a duty to participate in loosely coupled collaborative networks focused on ensuring that the HIT being developed is designed and used to improve patients' health and wellbeing, to minimize the burden and maximize the competency of providers, and to reward delivery of high value care.I then went on to describe my experiences as a committed member of the government's HIT standards bodies:
Having been involved over the past few years in a half dozen HHS/ONC technical workgroups that determine EHR/HIT standards, my associates and I have been like David facing an arena of Goliaths. I've been dealing with the biggest EHR vendors, as well as Federal contractors and agencies. It's been a very frustrating and enlightening experience. We entered the arena with the faint hope that the powers-that-be would compare our simple, low-cost, highly capable, disruptive innovations to the complex, convoluted, expensive mainstream technologies currently being adopted.
What we’ve found is that the standards-making process is rife with regulatory capture in which new standards are built on top of old standards without due consideration of modifying those standards in light of new and better technologies. Simplicity, efficiency, and usability are an afterthought. The result is an extraordinarily complex set of monolithic processes that few (if any) can implement and few are willing to use.
Examples include, in no particular order: (a) an over-reliance on XML data representations and Web services, (b) long delays due to HL7 voting processes, (c) changes to DIRECT taking it from what was supposed to be one step above the fax to a convoluted amalgam of HISPs that make PHI vulnerable with exposure to man-in-the-middle attacks, (d) incestuous relationships between vendors and ONC that block innovation from “outsiders,” (e) reticence to deal with difficult clinical workflow issues, and (e) the natural tension between making huge leaps in EHR system capabilities and the “let’s just keep crawling until we can walk” mentality. The result is that money continues to be spent with dismal progress in enabling HIT to increase value to the consumer while enabling and rewarding providers for delivering such value.It seems to me that most of these problems are due to business strategies and tactics supported by regulatory capture; it is not a technology issue, per se.
In part 3, at this link, I elaborate about the problems identified above.
For the past few days, I’ve been involved in a very good conversation at LinkedIn HIMSS titled: Can we turn EHR dissatisfaction around?
Here’s a comment from person that struck a chord:
It took the doctor 2 minutes to dictate as opposed to 30 minutes to use speech, edit and/or type. In addition, if the text is not edited in most cases except for those of you have it down perfect, you get crappy documentation that is (oh my goodness) actually used down the road to treat a patient. I can also introduce you to several law suits filed due to the poor documentation of a physician who refused to edit his dragon speech and just let it go into the chart. I can also introduce you to a neurologist who spends 4 ADDITIONAL HOURS a day documenting in an EHR. He has been at it for over a year so apparently this brain surgeon is an idiot who can't be trained. All of your responses to this, even the "this is off topic" are very revealing as to one source of the problem. Like typical programmers, no one wants to hear they have a bad design or the product actually needs more work.
So, to stay on topic, "Can we turn it around?" yes but only when you listen to the experts in the field you are dealing with - medical record specialists and physicians - they seem to be the people you have left out of the equation.
I'm a clinician (clinical psychologist) and HIT software inventor/architect/developer with 33 years’ experience in both areas. What I've noticed is that programmers routinely rely on healthcare subject matter experts regarding product content, the same is often not true regarding workflow adaptation, usability and usefulness issues.
It's relatively easy to create databases and forms for data entry and presentation, but it's quit difficult to construct the inputs and outputs in ways that streamline workflows, integrate and organize complex interdisciplinary data in clinically meaningful manner, generate clinically useful information that supports decisions at point of care, and present that information in ways that promote knowledge and understanding that to greater value to the consumer/patient.
Herein lies the problem, imo, and it is where disruptive innovation is sorely needed!
Unfortunately, such creative destruction is often hindered by governmental regulatory capture in which big bucks direct the regulators who dictate the rules that constrain innovation, focus on appeasing big business, and drive up complexity and cost.A short while later, Randall Oates, MD posted a comment that ended with:
It is time for more enlightened physicians to step up and assist/collaborate the transitions to processes generating EHR notes that are more clinically useful, while meeting basic billing/legal/reporting needs of others as well. Otherwise, physicians have to mainly blame themselves for systems that don't meet their needs.To that I replied:
Randal, I'd to add to your excellent statement: "...and present, in a concise integrated view, the relevant interdisciplinary information needed to support their clinical decisions, at point of care, that is focused on continually improving outcomes and care value.
For past year and a half, I've been volunteering my time in a Federal workgroup (WG) called the 360X initiative and work alongside Cerner, Epic, and several other large EHR vendors and HIEs on implementing closed-loop referrals. In the WG, I'm a "little guy" offering novel ideas and methods to the "big guys."
I sincerely believe that the clinical and technical folks in the workgroup do want to improve their products, despite the fact that I have had to repeatedly insist that instead of focusing on doing the minimum; we focus on dealing with the big, complex issues, especially regarding workflows.
I'm also involved in several other Fed workgroups that create HIT meaningful use standards. What I've noticed is a general tendency to keep things complicated, while at the same time, minimizing the scope of their efforts. Many times, when I’ve tried “push the capabilities bar” higher--and even offered innovative ways to do it)--I’ve heard the phrase: “We should first crawl and then walk before we try to run.” Unfortunately, after all these years, when it comes to enhancing EHR systems' clinical usefulness and security, there's too much crawling under the "low bar," and a general aversion to trying to "leap over the high bar."
I believe there are many reasons for this and they mostly relate to the “business layer” supported through regulatory capture by HHS/ONC.
After three decades of HIT involvement, I’ve come to the conclusion that what we need is to transform EHR products into “EHR systems” (a term I helped add to the Fed’s lexicon and workgroup charters). These EHR systems would be enhanced through integration with low cost, easy-to-use “companion applications” that fill in gaps in EHR usability, usefulness, interoperability, and protection of PHI.
The companion apps are likely to be disruptive innovations created by loosely-coupled collaborative networks of small nimble companies and individuals with diverse backgrounds and experiences, who share, discuss, evaluate, and continually evolve models (types of apps) focused on different use cases and types of end-users.[Continued in Part 2 at this link]
Saturday, September 21, 2013
On the Commonwealth Fund blog at this link is a new post titled: "Should "Value" Be the New Mantra in Health Care?"
Value is a complex issue that brings into light the notion of cost-effectiveness and how to compensate providers who demonstrate a commitment to high-value care via Pay for Value (P4V) models.
I contend that a firm focus on value is the ONLY way to solve the daunting problems plaguing healthcare delivery. If we don't, costs will continue to rise without corresponding quality improvements, and cost reductions will likely result in worse care outcomes.
Friday, September 20, 2013
Patients and nursing home residents have a legal right to obtain copies of most portions of their medical records. Yet at least some nursing homes are very reluctant to give competent residents their information. My question is: Why?
The benefits of providing such access to residents (and their families) include:
- Gaining resident (and family's) feedback as to errors in the record
- Enabling resident (and family) to share that information with others for second opinions and advice
- Increasing trust between resident and nursing home staff
- Respecting resident's wishes
- Providing a greater transparency
- Complying with Federal regulations.
For example, some nursing homes create policies that residents must follow to gain access to their medical records, such as signing a paper, but they do not make such policies readily known to residents and staff. Instead, staff is told to say things to the resident such as: "You need a doctor to see your chart so s/he can review the with you" instead of disclosing that the resident could simply sign a piece of paper and obtain their records for a few cents a page (assuming the staff person even knows about the paper-signing process).
Now I'm not talking about obtaining a psychotherapy session note, which may not be appropriate for certain residents to see, but rather something like obtaining a copy of a radiology report or medication orders.
Why does this happen? Is there something to hide? Is it an issue of power and control? What should be done about this?
Saturday, April 27, 2013
In this eighth post of the series on disruptive health IT (see this linkto start from beginning), I examine a key element that EHRs systems need, and a EHR good companion application should provide Patient-Centered Support (PCCS).
Here's a brief explanation of PCCS and what a PCCS-enabled EHR system would do:
- Clinicians have a “virtual patient” in mind—a conceptual model of an actual patient that reflects their understanding of the patient’s problems and needs
- This virtual patient model (VPM) consists of multiple submodels reflecting the interaction between biomedical and psychological subsystems in the real patient
- New findings—raw data—are used to refine the VPM
- PCCS-enabled software provides clinical decision support by:
- Simulating and predicting the likely reaction of the VPM to different care interventions
- Identifying the interventions most likely to benefit the actual patient
- Without PCCS-enabled software to help make decisions, clinicians may:
- Spend considerable time and energy searching and sifting through all the raw data
- Have to integrate ill-structured, uncertain, and potentially conflicting information
- Experience information overload, confusion, uncertainly and doubt
- With PCCS-enabled software, a clinician:
- Has much less cognitive burden
- Makes decisions supported by deeper &; clearer understanding of the patient
- Can stay focused on implementing the patient’s care plan
- Patients should also have a version of PCCS software available.
- A novel, robust software development platform that uses off-the-shelf software tools to create and continually evolve next-generation analytical decision models
- A communication architecture that promotes collaboration in loosely coupled social networks
- The means to combine the development platform and communication architecture to provide:
- “Technological glue” that connects companion app components via the CP Split method
- “Model ecology networks” in which teams of collaborators build, share, evaluate, and evolve analytical decision models, which they may sell.
I'll have more to say about the alliance in subsequent posts.
Thursday, April 11, 2013
In this seventh post of the series on disruptive technology (see this link) to start from beginning), I describe the technical capabilities of whole product “companion applications” that can bridge the gaps in today’s EHRs and PHRs, thereby enabling them to fulfill their potential for increasing healthcare value.
There are at least five areas of EHR and PHR functionality that whole product companion applications can substantially improve:
1. Data Capture, Storage and Integration
Able to manage and integrate an unlimited variety (types) and quantity of data for every patient—over his/her entire lifetime—using existing and/or new standards
- Images (e.g., x-ray, MRI, CT, ultrasound)
- Structured data from EHRs, PHRs and other sources
- Semi-structured data
- Artificial Intelligence (AI) and Inferential logic
- Integrate with clinical decision support systems (see this link)
Information exchange with global interoperability using:
- Mesh networks of asynchronous pub/sub nodes
- Direct Project e-mail with end-to-end encryption file encryption
- Identity Quality Assurance (IDQA)
- Easy and inexpensive to use and maintain
- Streamlines workflows
- Provides simple and intuitive user interface
- Delivers useful information targeted to different user roles and types of users
- Accommodates user functional limitations, intellectual and knowledge capabilities, etc.
Monday, April 01, 2013
In this sixth post of the series on disruptive technology (see this link to start from beginning), I will present an overview of the capabilities and deficiencies of today's EHRs. In my next post, I will show how a novel whole product solution, consisting of EHR Companion Applications, can bridge the gaps that prevent today's EHRs helping to increase healthcare value.
Current EHR Capabilities
Current EHR Deficiencies
- Difficult to use and not interoperable. “The recent analysis was sharply critical of the commercial systems now in place, many of which are hard to use and do not allow doctors and patients to share medical information across systems” [reference]. “Providers continue to use workarounds to deal with perceived inadequacies of their electronic health records…such as difficulty in finding data and complex order entry processes” [reference].
- Fail to coordinate care and accommodate workflows. “Knowing all the different participants in the patient’s care team…and coordinating and integrating their electronic activities is what successful EHRs must handle with ease…Most existing EHRs…have…done a poor job [and] must...accommodate more fluid workflows that can change potentially daily or weekly based on the demands of new participants” [reference].
- Cause information overload. “EHRs often contain unnecessary or excessive information that "clutters the 'big picture' of patient care" and increases risk to patients…often you can't see the forest for the trees” [reference].
- Immature clinical decision support. “[T]he first generation of CDS [Clinical Decision Support] tools…in…EHR systems, has not lived up to expectations…[They cause] alert fatigue and [fail to] optimize [clinical]workflows” [reference]. “[F]uture generations of CDS tools will…be more tailored to both patients and physicians” [reference]. “[Additional R&D] is recommended…to bridge the gap between the promise and realization of [guided personalized medicine]” [reference].
- Does poor job with patient education and shared decision-making. “…health education materials delivered by EHRs are ‘rarely…understandable and actionable for patients’ who have low health literacy” [reference]. “Implementing shared decision-making isn't as easy as it sounds…the IT systems used…lacked capabilities to flag patients as candidates for decision aids or to track patients through the process” [reference].
Tuesday, March 26, 2013
First a brief update: In my absence from this blog for the past six months, I’ve been busy participating as a committed member in four Federal health IT workgroups; developing the next major revision of our referral manager/clinical messaging application; participating in a variety of discussions about innovation; and building relationship with diverse groups of people. While I continue to do these things, I’m now like to resume posting where I left off …
In this fifth post of the series on disruptive technology (see this link to start from beginning), I discuss our plan to build an alliance of clinicians, researchers, informaticists, model builders, technicians (software architects and developers) and others who will collaborate to build a robust disruptive innovation that fills the significant gaps in today's health IT.
Let's start with our mission and vision statements.
Our mission is to solve seemingly impossible challenges facing healthcare today. We will provide a disruptive innovation that increases care value using a “whole product solution."
What is a Whole Product?
Awhole product is a generic (or core) product augmented by everything needed for a customer to have a compelling reason to buy (see Figure below). In Health IT, the core product is a certified Electronic Health Record (EHR). Whole products are built through partnerships. Our whole product solution will be a disruptive innovation that transforms the entire health IT industry.
We plan to develop two whole product solutions:
- A clinician-facing EHR Companion Application that uses databases, spreadsheets, e-mail and other technologies in radically new ways, along with other products and support services. An EHR that connects with our Companion Application will becomes a full function EHR System. These EHR Systems, in turn, will have many important capabilities that current day EHRs lack (to be discussed in my next post) and lead to substantial increases in healthcare value.
- A patient/consumer-facing PHR Companion Application that has a cutting-edge personal health record (PHR) at its core, augmented with health games, advanced decision and education tools, and other patient engagement software. This will create the first PHR System.
Our vision is to help increase healthcare value by enabling EHR and PHR Systems to:
- Deploy advanced evidence-based decision support tools
- Foster interdisciplinary collaboration and the seamless coordination and continuity of care
- Provide interoperability between disparate systems
- Accelerate the emergence and diffusion of knowledge and understanding
- Foster patient-centered care with a whole-person orientation
- Improve use of resources
- Increase workflow efficiencies
- Reduce variability in care quality and access
- Advance patient engagement and improve patient education
- Strengthen patient privacy and data protection
- Promote public health and preparedness
- Support clinical research and use of “big data” (link1, , link3)
- Take advantage of remote sensors and portable devices
- Survive in disasters and operational when the Internet and other networks are unavailable.
Initially, we will offer our whole product offering to (a) early adopters, including technical enthusiasts who love examining new technologies and visionaries who share our vision and (b) expert buyers who understand its benefits and advantages. At the same time, we will continue our efforts with the Office of the National Coordinator for Health Information Technology (ONC) and seek participation in pilot projects. The feedback we receive along the way will help us continually improve the product and testimonials will help us promote it.
In my next post, I examine the gaps in EHR functionality that the proposed Companion Applications will fill..
Wednesday, August 08, 2012
In this fourth post of the series (see this link to start from beginning), I discuss my eye-opening experience volunteering for the technical workgroup of ONC’s (Office of the National Coordinator for Health IT) Query Health initiative. I’ve been averaging several hours a week working with the group since Sept 2011, have been openly critical of their technical approach, and have presented prototypes of our disruptive innovation for their consideration.
In November, a month after joining ONC’s Query Health Technical Workgroup (TWG), I introduced our first prototype for Query Health. It consists of a pair of desktop spreadsheet-based programs (apps) that enable a requestor (the entity who wants certain patient data from providers’ EHRs) to create an SQL database query (a specialized language for updating, deleting, and requesting information from databases). This disruptive innovation is then able send that query, via a Direct Project e-mail attachment, to recipients who use a corresponding app behind their firewall to extract the data the requestor wants (i.e., the data “payload”) from the EHR (i.e., the “source database”). The recipients then send the payload, via Direct Project e-mail, back to the requestor. Although the prototype works, it was rejected by TWG members because it required that the requestor app know the schema (i.e., structure) of the source database before the SQL query could be run.
To address that issue, we began working on a second prototype a few months later, which was completed in March 2012. This new prototype is very different from the first because it uses Excel PowerPivot software to consume standardized CCR/CCD XML files (CCR defined, CCD defined that are generated by EHRs. This disruptive technology then calculates the results. In a typical query, these results consist of a few numbers (which could be a challenge to compute):
- The denominator indicating the target population, i.e., the total number of patients in the EHR database meeting certain criteria (e.g., patients in a certain age range with a diabetes diagnosis, who take medication for it, and have been hospitalized in at least one time in an acute inpatient hospital or ED within a certain time period OR had at least two outpatient or non-acute inpatient encounters during that time period)
- The numerator indicating the number of patients in the target population for whom a specific event occurred during a certain period of time (e.g., having an hemoglobin A1c lab result greater than 9 percent)
- And possibly exemptions and exclusions indicating the number of patients in the target population that have not been included due to certain predefined reasons.
Our solution performs the query, calculates the numbers, and is able to return the results to the requestor via Direct e-mail.
We wrote about our prototypes on the Query Health wiki at this link and included videos and links to downloads.
During a subsequent TWG meeting, I then requested permission to present our second prototype to the group. Despite being the only implementation that actually works, I was not allowed to inform others about it because we did not comply with the Query Health approach (standards and specifications).
The TWG leaders would not change their approach even though, months earlier:
- We posted to the group’s wiki a page detailing the changes to their approach we require in order to qualify as a viable Query Health solution and
- I objected to the approach during the consensus voting then dropped my objection after being convinced via an offline conversation with group leaders that the approach is flexible enough to allow novel “overlay” implementations.
Without diving deep into the technical details, here’s the situation today: Not a single query has been done by the TWG using their current approach, nor will any be done in the foreseeable future. A half year ago, however, our successful disruptive solution completed one of the most demanding queries—the NQF 0059 clinical quality measure for diabetes control—yet it remains forbidden to be seen or discussed by the TWG!
So, what has the workgroup been doing all this time?
Well, several TWG members have been working for months to develop three complex XML translators. As best as I can understand, these translators are required by two web-based tools—i2B2 and hQuery—that have been developed with Federal monies and that have relationships with certain TWG members. The decision to use these tools, along with the PopMedNet Portal for data transport (also developed with gov’t grants), was made at a face-to-face meeting in Washington DC in Nov 2011 (I did not attend; I was informed of their decision via a private follow-up phone call). These tools are supposed to work in conjunction with the translators to change various forms of XML code into other forms of (XML) code.
The first translator is called the “intermediate translator.” It was conceived because the Health Quality Measures Format (HQMF) XML code was just too complex to be transformed into procedural code (like SQL) for executing a query. This translator is supposed to reduce the complexity of HQMF XML; they’re still working on it. The second translator is supposed to transform the XML from the first translator into the procedural code; I do not believe much has been done with this yet. And the third is supposed to translate the query payload into Quality Reporting Document Architecture (QRDA) XML code; still waiting for its construction. And all of this is supposed to conform to the Health Level Seven (HL7) Clinical Document Architecture Release 2.0 (CDA). Oh, forgot to mention one more thing, also needed is a “Query Envelope” to facilitate the secure exchange of queries and results.
Now that’s what I call COMPLEX!
A few other things to consider:
- It appears that the organization responding to a Query Health request must do all sorts of complex mapping before the query can be run.
- I'm not yet convinced that, if & when all this work is done, the current TWG approach will be successful since there are still difficult mathematical computations that must be done to complete the Query Health process.
- Several people in the workgroup, including myself, gave a NO vote to the HQMF consensus round 1 and here’s a link to my critique of HQMF XML, which explains why XML is not right data model for Query Health.
- The TWG is not focusing on using Direct Project protocols for transmitting queries and results.
- There are several Query Health pilot projects underway, even though the primary tools necessary for a compliant implementation have not yet been developed.
I contend that disruptive innovation is required to bring about meaningful change!
Our disruptive Query Health solution has NONE of the complexities I discussed above, and it works! To implement our approach, all that’s needed on the requestor and responder ends is a desktop or laptop computer loaded with MS Excel and the free Excel PowerPivot add-in. To make our solution Direct Project compliant, just add MS Outlook that operates in conjunction with our partner HISP. Best of all, IT WORKS!
Addendum: Here's an article from 4/22/13 that confirms what I said above.
My next post (within a few weeks), will examine a disruptive innovation business strategy we’re about implement that is consistent with our vision of how to reform healthcare sensibly and sustainably
Monday, August 06, 2012
In my previous posts (see this link for the first post in this series), I discussed the nature of a disruptive innovation, as well as my joy — and grief — with the ONC’s Direct Project and (S&I) Framework programs. On the one hand, I’ve been pleased and encouraged by increased government transparency and (at least verbal) support of true health IT (HIT) innovation. On the other hand, I've been disheartened by troubling issues involving decision-making, ballooning complexity, closed social networks, and restraint of trade attempts, as well as frustrated by efforts to dismiss disruptive innovation.
I presented an example of one such troubling issue, which I experienced firsthand, in my previous post. It relates to the Direct Project’s rules and regulations (called “specifications and standards”) that enable groups of vendor HISPs (health internet service providers) to knowingly engage in practices that are anti-competitive (restraint of trade), innovation inhibiting, and undermine the purpose of the Direct Project whose goal is to enable everyone to use simple and secure HIT that’s better than using a FAX machine (see this link). Although the HISPs' business strategy runs counter to the Direct Project’s goal, their tactics are being condoned by government officials. The reason: The HISPs are not breaking the rules, even though those same HISPs helped create those rules! So, instead of fixing broken rules, our leaders turn a blind eye and say that what they’re doing is OK. Well, it’s NOT OK!
Note that my views are from the vantage point of a small business whose efforts to gain acceptance for a disruptive technology has been repeatedly frustrated despite the fact that (a) literally everyone who sees our HIT in action is amazed by our capabilities and ingenuity, and (b) no one disputes our claim that we offer a viable solution to many daunting challenges facing meaningful healthcare reform.
When we became involved with ONC--volunteering our time and knowledge--we hoped that our gov’t would be delighted with our novel HIT because it is what they said they wanted, i.e., simple, secure, inexpensive, efficient, and convenient solutions for sharing patient information. We soon began to realize, however, that powerful influences in the private sector, which include corporations with gov’t ties, had different ideas. In an attempt to control the marketplace, they appear to deploy a strategy aimed at establishing HIT specifications and standards that (a) foster complexity and inefficiency resulting in costly, difficult to build products and (b) allow business agreements that block competition.
For example, we have faced resistance from HISPs since our novel peer-to-peer messaging architecture is the only Direct Project implementation that: (a) securely exchanges e-mail and attachments having end-to-end encryption (i.e., data are protected in transit and where stored) and (b) enables individuals to share individuals (not just organizations), thereby ensuring that everyone involved in healthcare, including patients, are all using compliant software…[that sends messages addressed to] the individual-for-no-other-eyes [as per this link and being discussed at this link].
In addition, Direct Project standards fail to duly consider disruptive HIT. For example, we are the only vendor (to my knowledge) using desktop tools (MS Outlook and Excel) that provide certain capabilities the standards assume HISPs would provide via web-based services in the cloud. From our vantage point, these standards do nothing but add incredible complexity to our straightforward approach (examples of this added complexity is doing DNS certificate lookup instead of LDAP only and doing XD* transformations). Since we are forced to comply with those standards, we had to team up with a new type of HISP that allows us to continue using our elegant approach and avoid much of the imposed technical complexity we don't want nor need.
In retrospect, we’re not surprised that the Direct Project has been resistant to our disruptive technology and unaccommodating to our needs. After all, that’s what to expect when disruptive innovations are introduced to mainstream markets. This conclusion is supported by Keith W. Boone in a recent post to his blog; Keith is a self-described “standards geek” for GE Healthcare and a long-time participant in gov’t initiatives, including the ones mentioned above. Here’s what he wrote:
A healthy IT marketplace would favor disruptive innovations (simple products and services that initially serve the bottom of a market and then move up to displace established competitors) for improving patient engagement, communication, and care coordination. Improved population health obtained at a lower cost would result … When disruptive innovators attempt to commercialize their innovations within the established value network in the industry — essential trying to cram it in the back plane of the competition … — that system will either reject it ... or co-opt the potential disruption, forcing it to conform to the existing value network in order to survive. The idea that disruptive innovations can fit into the current healthcare value network … ignores this key point … The real challenge is not providing disruptive technology in Health IT, but rather, in providing a new value network in health care that will enable disruptive innovation. When that happens, the new value networks will have the necessary technology to support it, and indeed, the current EHR industry will either adapt, or die.So, can disruptive innovations be integrated into the value network of the current healthcare market? Well, if our country had created a rational healthcare value network, then good disruptive technologies would be welcomed with open arms.
But with our current healthcare system, this is obviously not the case. Instead, disruptive innovations must create new, more sensible value networks and markets that focus on transforming the system in ways that benefit the patient, reward the provider for delivering high-value care, reduce complexity, increase security, and save money. And that's what we are focused on doing.
In my next post, I’ll present my mind-boggling experience with the ONC Query Health initiative.
A value network is a marketing concept that describes the social and technical resources (supply chain) within and between businesses. They account for the overall worth of products and services, including the collection of upstream suppliers, downstream channels to market, and ancillary services that support a common business model within an industry. The kind of value network that the healthcare system needs focuses on bringing increased value to healthcare patient (consumer) and reward providers for delivering high-value care.
- The green box refers to three types of data required to build the information and knowledge people need for increasing value across the supply chain. The education data refers to formal and informal ways that people share their knowledge, ideas, and experiences. Research data, on the other hand, is used in controlled clinical trials, outcomes and performance studies, various types of biosurveillance (e.g., post-market drug and device, public health), preferred clinical guideline development, and other types of research. Technology data refers to the date collected by EHRs and other health IT tools, as well as streamed through durable medical equipment.
- The five blue boxes refer the transformation of the data using a variety of HIT tools and clinical processes that promote the kinds of knowledge and understanding that fosters more effective and efficient care (services and products). They include (a) use of evidence-based guidelines, personalized care plans, decision support tools, and communication networks; (b) methods of information sharing and care coordination; and (c) patient empowerment. Each activity (process) in the blue boxes supports value by requiring quality handoffs and continuous measurement, assessment, feedback and acceptance at each breakpoint (the gap between each activity) to ensure value creation via continuous quality improvement (CQI).
- The red box on the bottom refers to the technological, psychological, economic, and regulatory factors that promote or inhibit value to patient by influencing (driving or impeding) the blue box processes. Some of the key influences are listed in the box.
- The purple box represents good patient outcomes; it is the desired result of using the data, tools and processes to increase value to the patient. The curved purple arrow pointing to the Data Types box indicates the need to provide data about the process, influences and outcomes of care across the entire supply chain via continuous feedback loops. The blue box activities and their related influences that help achieve the goal of higher quality at lower cost are reinforced; those that do not are modified or eliminated.
This CQI solution does not strive for zero defects (no errors of omission and commission) because perfection assumes infinite resources and knowledge, both of which are unrealistic. Instead, it is based on the Michael Porter’s value chain model, which assumes defects (errors) will occur and, therefore, we had better accept some reasonable level of tolerance, reconcile mistakes and poor outcomes, and strive to ensure ever-better outcomes at reasonable cost for a given condition.
Ensuring patient access to high-quality healthcare at reasonable cost through the value-driven CQI solution requires adherence to these critical process transformations:
- Supporting value for each primary activity through quality handoffs (the transfer of information, as well as authority and responsibility, during transitions in care across the continuum) along with ongoing measurement, assessment, feedback, and acceptance at each breakpoint (the gap between each primary activity).
- Assuring that all infrastructure or support activities (a) promote a seamless support relationship that benefits the primary activities, (b) avoid impeding the primary activities, and (c) follow CQI rules for each component across the entire healthcare spectrum.
- Operating with awareness of current healthcare system shortcomings that focuses on areas with quality improvement is warranted.
- Addressing the problems associated with defining quality in real time versus retrospective analysis, for both individual patient and aggregate data.
- Focusing on root cause identification to determine the factors preventing clinical outcome and cost improvement, instead of playing a “blame game,” which only exacerbates the problem.
Wednesday, August 01, 2012
In my previous post, I defined what disruptive innovation is and why it's important to healthcare transformation. I will now discuss my experiences over the past year with attempting to introduce a disruptive health IT innovation to the Federal Government.
I was delighted when I first found out that the Obama Administration was making good on its promise to increase transparency into the inner working of our gov't by opening to the pulic several programs administered by the National Coordinator of Health IT (ONC). ONC was looking for volunteers to join workgroups aimed at developing rules and regulations for the exchange and use of protected health information (PHI). Input from innovators was encourged time and time again as evidenced by the Fed's Care Innovation Summits, Meaningful Use and Health Care Innovations Conference, Digital Government Strategy, "open government" initiative to drive rapid innovation, and more. Government transparency and support for true innovation aimed at improving patient care. WOW...Love it!!!
I found out about two such programs last year and jumped in with both feet. One is the Direct Project, which is focused on using secure e-mail to exchange PHI. The other is the Standards & Interoperability (S&I) Framework, which is focused on "enabling harmonized interoperability specifications to support national health outcomes and healthcare priorities, including Meaningful Use and the ongoing efforts to create better care, better population health and cost reduction through delivery improvements." Each of these programs has various communities of volunteers who collaborated in many different workgroups and sub-workgroups. They establish use cases, standards, specifications, and reference implementations based on the specification; they also run pilot studies. I personally spent most of my time focused on sharing my knowledge, skills and novel technology with the Direct Project and the S&I Framework's Query Health Technical workgroup.
Although I've met some fine people during these meetings and gained useful knowledge, I've been frustrated by the programs' decision-making process, ever-growing complexity, closed social networks, and fear of disruptive innovation. The following situation exemplifies some of my concerns.
An article in InformationWeek last month, titled “ONC Releases Guidelines for Direct Clinical Messaging,” discussed some state-contracted health information service providers (HISPs) make secret deals to create and control data silos in an attempt to block competition within the Direct Project. These tactics not only stifle innovation and choice, but they also defeat the purpose of the program.
To me, the most troubling thing is that these anti-competitive (restraint of trade) and innovation-busting practices have been condoned by gov’t officials! Let me explain …
According to the article (bold added for impact):
ONC has issued guidelines for the more than 40 statewide health information exchanges (HIEs) that have launched or are starting services that use the Direct Project secure messaging protocol.In addition, a blog post by John Moehrke at this link quotes an ONC release sent to the HIE grantees:
The guidelines are designed to ensure that state-contracted health information service providers (HISPs)--private companies that route Direct messages between providers or between providers and patients--allow information to flow within and across states. The ONC document also spells out how HISPs should comply with the Direct protocol and accompanying policies for trusted, secure data exchange.
[However, no rules exist] for sending messages [between people using]…different HISPs…some HISPs have [thus] started making one-on-one agreements with other HISPs to exchange Direct messages [even though] ONC says that ‘such peer-to-peer legal agreements are expensive and time-consuming to implement and are cumbersome to monitor and enforce. They are not a long-term basis for scalable trust.’
…[Nevertheless, some] HISPs will continue to make side agreements with one another—and [Erica] Galvez [community of practice director in ONC's state HIE programs] sees nothing wrong with that. If the HISPs comply with guidelines and the applicability statement, and consider themselves business associates…they certainly could enter into one-off agreements. If they do, I'd hope that they'd use these guidelines as the basis for that so they have a consistent, level playing field across HISPs.’
The ultimate goal of Direct, according to Galvez, is to provide a national standard for clinical messaging so that providers can easily push messages and attachments to each other and to patients. To the extent that HISPs create their own information silos, she noted, they defeat the purpose of the program.
ONC has found that many...HISPs...are deploying Direct in a way that proactively enables exchange within a given HISP’s boundaries while not offering mechanisms or supporting policies that enable exchange with other HISPs. Such limitations effectively block providers using different HISPs from exchanging patient information. In effect, HISPs are creating 'islands of automation using a common standard.'John then goes on to say that the release states that HISPs "should" do things differently, but criticizes ONC for failing to state that they "must" change their ways.
This whole thing bothers me! Here are my questions/issues:
WHY is it OK for HISPs to defeat the purpose/goal of the Direct Project, regardless of whether they "...comply with guidelines and the applicability statement, and consider themselves business associates"?
Shouldn't the guidelines and statements be changed to assure the purpose of Direct is upheld in light of this troubling issue?
More in my next post.
Tuesday, July 31, 2012
In this next series of posts, I’m going to focus on my
experiences with introducing disruptive innovation in health information technology (HIT).
I trust you'll find these discussions both enlightening and troubling.
Let’s start with defining the concept of disruptive innovation and its importance to healthcare.
What’s Disruptive Innovation
There are several types of innovation as depicted in figure below:
- Sustaining innovation delivers gradual improvements like enhancing software processes; it brings about gradual evolution rather than a revolutionary change. It does not create new markets or value networks, but rather only evolves existing ones with better value, allowing the firms within to compete against each other's sustaining improvements. Sustaining innovations may be either "discontinuous" (i.e. “transformational" or "revolutionary") or "continuous", "i.e., "evolutionary.
- Disruptive innovation (as defined by Clayton M. Christensen) turns the conventional paradigm of the market on its head, not by improving on competitors’ offerings, but by actually reducing functionality. That is, disruptive innovations make products simpler and less costly. This wreaks havoc within many industrial sectors, where, sensing opportunities at the bottom of the market, large companies will frequently choose to ignore it, dismissing it as “not competing in their space.”It helps create a new market and value network, and eventually goes on to disrupt an existing market and value network (over a few years or decades), displacing an earlier technology. They are generally technologically straightforward, consisting of off-the-shelf components put together in a product architecture that is simpler, more convenient and less expensive than prior approaches. They offer a different package of attributes valued only in emerging markets remote from, and unimportant to, the mainstream.
What’s the Importance of Disruptive Innovation in Healthcare?
Disruptive innovation can play a significant role in solving our healthcare crisis by challenging the status quo.
Make no mistake: the U.S. health care industry is in crisis…Health care delivery is convoluted, expensive, and often deeply dissatisfying to consumers…We believe that a whole host of disruptive innovations, small and large, could end the crisis—but only if the entrenched powers get out of the way and let market forces play out. If the natural process of disruption is allowed to proceed, we’ll be able to build a new system that’s characterized by lower costs, higher quality, and greater convenience than could ever be achieved under the old system…Attempts to use regulation to stave off disruptive attacks are quite common…Unfortunately, regulators are inclined to be...protective of the entrenched professions and institutions in health care…The links between those institutions, federal and state regulators, and insurance companies are strong; they are wielded to preserve the status quo…Government and health care industry leaders need to step forward—to help insurers, regulators,… hospitals, and health professionals work together to facilitate disruption instead of uniting to prevent it. If they do…health care providers will realize the opportunities for growth that come with disruption—because disruption is the fundamental mechanism through which we will build a higher quality, more convenient, and lower cost health care system. If leaders with such vision do indeed step forward, we will all have access to more health care, not less.In my next post, I discuss my personal experiences of how government regulators and HIT vendors respond to the introduction of disruptive HIT innovations.