The most recent Senate HELP Committee hearing was OK. Pretty much more of the same. The usual Senatorial griping about "what have we gotten for our ARRA/HITECH $30 billion?" amid the other customary laments (many of them of the Policy ADHD Perfectionism Fallacy flavor).
- Boyd Vindell Washington, MD, MHCM, President, Franciscan Medical Group Chief Medical Information Officer, Franciscan Missionaries of Our Lady Health System, Baton Rouge, LA
- Timothy A. Pletcher, DHA, Executive Director, Michigan Health Information Network Shared Services, Adjunct Faculty, Department of Learning Health Sciences, University of Michigan Medical School, East Lansing , MI
- Meryl Moss, MPA, EMHL, Chief Operating Officer, Coastal Medical, Providence, RI
As reported by Health Data Management,
Senators Look to Improve EHRs from Physician PerspectiveIntreresting. Only one of the three witnesses was a physician, though.
A Senate committee on Tuesday examined how to improve electronic health record systems, focusing on the physician experience with EHRs which continue to be a source of widespread dissatisfaction.
Sen. Bill Cassidy (R-La.), himself a doctor, told the Senate Health, Education, Labor, and Pensions Committee that unfortunately physicians are spending more time entering data into EHRs and less time speaking to and examining patients. “As a physician, time is better spent looking into a patient’s eyes as opposed to clicking on a computer screen to document something unimportant to the patient but required by someone far removed from the exam room,” said Cassidy.
Tuesday’s hearing was the second in a series of hearings on developing possible solutions—either through administrative or legislative action—to address the failed promise of EHRs, which have the potential to make healthcare more efficient while also reducing costs and medical errors...
Boyd Vindell Washington, M.D., president of the Franciscan Medical Group and chief medical information officer of the Franciscan Missionaries of Our Lady Health System in Baton Rouge, La., cited increased data-entry and documentation burdens on physicians, loss of provider-patient interaction, and frustration with new meaningful use requirements as clinical workflows change. “There’s really been a lot of stress as providers try to meet these requirements.”Yes, Dr. Washington, and this ("electronic version of paper charts") is a central theme comprising the excellent, voluminous health IT work of Jerome Carter, MD at EHR Science.
To improve the physician user experience, he recommended adjusting the required documentation for billing and quality to more accurately align with new care models. “Too much effort is spent recreating the attestation and documentation check boxes that existed in the paper world, which are just no longer relevant as we switch to electronic medical records,” according to Washington, who made the case that checking boxes to show that data was reviewed or that tests were performed place unnecessary burdens on providers and do not substantially improve patient care...
Paper records are passive archives that capture information about patients and their interactions with healthcare providers. The post, From Data to Data + Processes: A Different Way of Thinking about EHR Software Design, noted the continued sway of paper-based thinking on EHR designs and public discourse. This is old news. The challenge that we currently face is re-envisioning what EHR systems are, and what they should do. As with the typewriter-to-word processor evolutionary path, the key is realizing that the ultimate goal is creating systems that truly assist caregivers, not building electronic paper records.The Use Case Factory™
What is today’s EHR equivalent of Bank Street Writer? It is an application designed with the idea that the repository is the most important system feature, and one in which the user interface is geared primarily toward data entry and validation–what I refer to as a data-oriented system. Such systems maintain the traditional mindset that, as with paper records, recording data is the main goal of those using the system, not being more productive and efficient. Systems designed in this manner lack computable internal representations of clinical concepts. They accept information from users, validate it, and submit it to the database. They contain no explicit representations of workflow, patient state, temporal progression, or other concepts critical to clinical care. As a result, adding functionality such as decision support, which encompasses all three of these factors, is problematic.
What is up with that?
If I had a a dollar for every time witness Timothy Pletcher mentioned "use case," I'd have my airfare for the next IHI Forum. In fact, "use case" appears 176 times in his prepared testimony.
I love this beaut in his PDF:
MiHIN has enjoyed success in Michigan with a unique approach known as The Use Case FactoryTM
I wrote a blog post 4 years ago entitled "Use Case."
The phrase "use case" is really simply software engineering jargon for "example," i.e., an example of how a user interacts with a software application to reach a goal.Just as we have "interoperababble," so too must we have "methodologicababble," I guess. to wit:
Use Case DefinitionLordy. Again, in plain Commoner English, a "use case" is a usage example, a scenario, not a "methodology." In Health IT, the totality of these examples comprises the EHR/HIE end-user requirements specification. Expressed equivalently, in a fundamental sense, the sum of EHR workflows is the complete operational set of "use cases" (regarding which I again refer you to my post of August 20th, 2014 pertaining to the data mining potential of EHR and HIE audit logs, via which to determine what features and functionalities actually get used).
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.
MiHIN published a 61 page PDF deck extolling their Use Case Factory™
Well, yeah. What BobbyG said (though, technically, "use case" is broader than just "data sharing," as I pointed out above). But, we gotta have our overcomplicating jargon, I know.
methodologicababble™ interoperababble™There, that's better. Now I "own" them. ;)
Somebody lookin' to go into (or otherwise capitalize on) bidness. A WHOIS search indicates that this may be a domain name "squatter" located in Germany.
Re: "methodologicababble" (™). Pedantically, "methodology" has two proper definitions:  a "system of methods," and (more rarely and abstractly),  the academic discipline comprising the study of methods. In practice, think of "methods" as "tactics" and "methodology" as "strategy." ("Strategy" is another word commonly misused.)
Whatever. I've lost the fight on "data are" as well.
BTW, great comment below the Health Data Management article cited above:
Senator Whitehouse seems to have said the magic words that we all need to listen to: "Health IT is 'critical national infrastructure that should be seen just like our highway system'. " Does anyone think that our Interstate Highway system was built by "the marketplace?"
A good solution was introduced into Congress almost 7 years ago (see below). HR6898 (2008) was strongly opposed by HIMSS on behalf of proprietary EHR vendors. Had these provisions been enacted, with implementation in an environment optimized for user-driven (and even patient-driven) innovation, we would not be having the interoperability discussion today, nor would we be struggling with "meaningful use," taxpayer-funded incentives, penalties for non-adoption, and quite likely ICD-10 conversion, and widespread physician dissatisfaction, among other things.
Note to Congress: Just do it.Nice.
"(4) FEDERAL OPEN SOURCE HEALTH IT SYSTEM-
(A) IN GENERAL- The National Coordinator shall provide for coordinating the development, routine updating, and provision of an open source health information technology system that is either new or based on an open source health information technology system, such as VistA, that is in existence as of the date of the enactment of this title and that is in compliance with all applicable standards (for each category described in paragraph (2)(A)) that are adopted under this subtitle. The National Coordinator shall make such system publicly available for use, after appropriate pilot testing, as soon as practicable but not later than 9 months after the date of the adoption by the Secretary of the initial set of standards and guidance under section 3003(c).
(B) CONSORTIUM- In order to carry out subparagraph (A), the National Coordinator shall establish, not later than 6 months after the date of the enactment of this section, a consortium comprised of individuals with technical, clinical, and legal expertise [in] open source health information technology. The Secretary, through agencies with the Department, shall provide assistance to the consortium in conducting its activities under this paragraph.
(C) AUTHORIZATION TO CHARGE NOMINAL FEE- The National Coordinator may impose a nominal fee for the adoption by a health care provider of the health information technology system developed or approved under subparagraph (A). Such fee shall take into account the circumstances of smaller providers and providers located in rural or other medically underserved areas.
(D) OPEN SOURCE DEFINED- In this paragraph, the term `open source' has the meaning given such term by the Open Source Initiative. [www.opensource.org] "
More to come...