Karen DeSalvo started as the new National Coordinator for Healthcare Information Technology on January 13, 2014. After my brief discussion with her last week, I can already tell she’s a good listener, aware of the issues, and is passionate about using healthcare IT as a tool to improve population health.
She is a cheerleader for IT, not an informatics expert. She’ll rely on others to help with the IT details, and that’s appropriate.
What advice would I give her, given the current state of healthcare IT stakeholders?
1. Rethink the Certification Program – With a new National Coordinator, we have an opportunity to redesign certification. As I’ve written about previously some of the 2014 Certification test procedures have negatively impacted the healthcare IT industry by being overly prescriptive and by requiring functionality/workflows that are unlikely to be used in the real world.
One of the most negative aspects of 2014 certification is the concept of “certification only”. No actual clinical use or attestation is required but software must be engineered to incorporate standards/processes which are not yet mature. An example is the “transmit” portion of the view/download/transmit patient/family engagement requirements.
There is not yet an ecosystem for patients to ‘transmit’ using CCDA and Direct, yet vendors are required to implement complex functionality that few will use. Another example is the use of QRDA I and QRDA III for quality reporting.
CMS cannot yet receive such files but EHRs must send them in order to be certified. The result of this certification burden is a delay in 2014 certified product availability.
Certification should focus on rigorous interoperability testing, using mature standards, in practical use cases, supported by the evidence and experience.
2. Evaluate the collective timelines of Meaningful Use, ICD10-CM, ACA and the HIPAA Omnibus Rule – Thousands of pages of regulations are hitting the industry at the same time and it’s clear that like healthcare.gov, haste will make waste.
My suggestion – extend Meaningful Use Stage 2 Year One attestation by 6-12 months (not just delay Stage 3 a year as has already been done) to enable clinicians to install certified software, redesign workflows, be properly trained, and educate their patients about the new functionality available. I realize this may be a regulatory leap, but I’ve seen new rule making done as corrective action in the past.
Although I believe ICD10-CM requires more testing (the CMS planned March testing is not enough) and most applications will not contain the clinical documentation improvement features needed for clinicians to adequately justify the new codes, most hospitals have put so much time and resources into ICD-10-CM projects that they cannot afford to extend the project beyond October 1. For ACA, re-evaluate quality measure submission requirements per point #4 below.
For the HIPAA Omnibus Rule, rethink the accounting of disclosures scope and timing.
3. Declare victory for Meaningful Use – Stage 1 of Meaningful Use was a phenomenal success. Adoption rates of good EHRs by hospitals and eligible professionals has tripled. Public health reporting and interoperability are accelerating. Awareness of security issues has markedly improved. Stage 1 was seen as a tide floating all boats. Stage 2 was greeted with less excitement. It exceeded the capacity of many organizations from a technology, policy, and workflow perspective.
It has been described as a burden that has slowed innovation, consumed industry resources, and co-opted local agendas for quality improvement projects. However, it has many benefits and those gains can be captured with enough time. By the end of Meaningful Use Stage 2, hospitals and eligible professionals will have reached a breaking point in their capacity to absorb regulatory burdens, so we have to progress beyond 2017 very thoughtfully.
If our policy goals are outcomes based, then we should offer a Stage 3 regulation which enables organizations to qualify for incentives if outcomes are achieved using IT as an enabler. We should not prescribe specific functionality for the EHR other than interoperability and security. As noted in point #1, focusing on certification and attestation for interoperability is reasonable as long as there are no “certification only” functions mandated.
We should eliminate penalties for non-compliance with Stage 3 and return EHR innovation to customers and vendors. Meaningful Use will have succeeded if we capture the gains of Stage 1 and 2, then focus on Stage 3 incentives that drive us to better outcomes, rather than penalizing providers for not checking more attestation boxes.
4. Fund pilots and research – We are on the cusp of a sea change in interoperability, population management, and clinical decision support. CCD led to CCDA which leads to FHIR for content summary exchange.
The Direct protocol will evolve to a RESTful interface using OAuth/OpenID for trust fabric creation. However, we’re not going to make the move to FHIR and REST unless pilots (followed by agile development of implementation guides) are funded to enable incremental progress. FHIR is too new and REST has too many industry skeptics. The pilots will create a tipping point which mitigates risk and enables progress.
Also, two of the great challenges in informatics – automated quality measures (QueryHealth and HQMF) and nationally curated decision support (Health eDecisions) would benefit from pilots. In point #1 I noted that we need mature standards but at present our quality measurement and decision support standards are immature.
If we pilot them and revise them, we’ll mitigate risk and can consider the use of quality and decision support standards which are optimized for purpose in future interoperability certification.
5. Continue the ONC convening function for standards, privacy/security, and hearings to capture lessons learned about adoption/implementation – ONC provides a very important and unique convening function in which issues can be discussed by multiple stakeholders. There will be an ongoing need for standards selection and revision, bridging the work of standards development organizations and clinical stakeholders.
Privacy and security policy is informed and improved through national debate of the issues. Evaluating the successes and shortcomings of the EHR related regulations is important to future refinement. I suggest that ONC/CMS limit their regulatory focus on Meaningful Use requirements related to mature interoperability standards and privacy/security (as noted above), and focus much more on bridging gaps in five key areas: a) ONC versus CMS (certification versus attestation); b) HHS versus CMS (disparate quality measure and other reporting requirements within the HHS domain); c) the government versus market (vendors and providers); d) vendors versus providers; and e) providers versus patients.
In practical terms, this would focus less on a core belief that ‘all EHRs should do X, Y and Z’ to a focus on ‘given what we are learning about an ever-evolving market (e.g., new payment models, new delivery models such as Patient Centered Medical Home, new technologies, new patient engagement models, etc), what EHR interoperability needs, quality measures, and privacy/security safeguards are needed.’
It’s a fragile time at ONC when the excitement of the ARRA/HITECH funded grant programs has passed, many people have departed, and Congress is wary of IT projects in general.
Karen is the right person for the job at this time in history, just as her predecessors were the right people for their eras. She can regain the trust of Congress, make midcourse corrections to the Meaningful Use program, and balance the burden/benefit on stakeholders. If she can rebuild a city’s health system after Katrina, she can polish those elements of the ONC strategy that experience in the marketplace has deemed to be necessary.
John Halamka, MD, is the CIO at Beth Israel Deconess Medical Center and the author of the popular Life as a Healthcare CIO blog, where he writes about technology, the business of healthcare and the issues he faces as the leader of the IT department of a major hospital system. He is a frequent contributor to THCB.
Post last updated on January 22, 2014 at 5:40pm ET.
Categories: Uncategorized
It was sarcasm, Bobby. *Whoosh*
I think the easiest way to achieve interoperability is to create Web pages for each patient. It might be politically possible to standardize these (but tough).
Another way would be to use Telnet. This would be a security nightmare, however.
You bet there is consternation over at SPM.
This ecosystem thing is a straw man and excuse to not do the right thing and put the functionality in place for patients. Data is gold. Make it available and the ecosystem will arise. Nobody is going to stand there with a catchers mitt while you make excuses to not throw the ball.
And why exactly are providers refusing to be part of the ecosystem? Is that certification’s fault, or you just refusing the “bad data” we would send you, even though you ask me for that same data in person every time I bring my daughter in for an appointment? Is it special because you typed it into your EHR?
“Besides, I thought this is proven technology that will solve all of medicine’s problems”
__
You thought wrong. It might have helped had you paid more attention.
> She is a cheerleader for IT
Takes one to know one.
> 1. Rethink the Certification Program
Where was he when it was devised? Seeking everything that he’s now calling for a “rethinking” about, perhaps? It seems the “grassroots” were indeed calling for a rethinking of certification…long ago. And being ignored.
> 2. Evaluate the collective timelines of Meaningful Use, ICD10-CM, ACA and the HIPAA Omnibus Rule
It seems the “grassroots” were indeed calling for slowing down and/or a moratorium…long ago.
> 3. Declare victory for Meaningful Use – Stage 1 of Meaningful Use was a phenomenal success.
Based on superficial metrics of adoption only a cheerleader could love.
> 4. Fund pilots and research
Hi, we do research here…throw money at us, please.
Besides, I thought this is proven technology that will solve all of medicine’s problems, hence the coerced implementation. Who needs “pilots?”
> 5. Continue the ONC convening function for standards, privacy/security, and hearings to capture lessons learned about adoption/implementation
That is, don’t dare do anything more than hold hearings and “capture” lessons, such as … GASP! …push for “meaningful” regulation.
As you might imagine John, this post is causing some consternation among the ePatients over at SPM, and for good reason. You say “There is not yet an ecosystem for patients to ‘transmit’ using CCDA and Direct, yet vendors are required to implement complex functionality that few will use: (changed & softened from your original version which was “At present there is no place for a patient to “transmit”.
Sean Nolan and his gang at Healthvault would be very surprised to find out that there was “no place to transmit”, as would Bettina Experton at Humetrix and everyone else who has built a data utility layer to receive Blue Button data. But to be fair, we can agree that that “ecosystem” is not yet large or popular
But it wont need much encouragement if we get to generallizable “download”–of which BlueButton is the lynchpin.
My concern with your criticism of “View, Download, Transmit” is that it looks like an excuse for vendors to not bother with (and lobby against) the “download” part.
I’m a user of Epic’s portal on Sutter. There is as yet no way for me to download that information. I can view but not download. If I can download, then I can probably figure out a way to transmit (or a vendor in the emerging ecosystem will do it for for me). As you are such an influential leader both with the ONC and the general HIT community, I fear that this paragraph will be used as an excuse to wriggle out of the MU2 demand for patients to participate in their care. And so I think you need to really clarify what you think vendors must be held accountable for. Which IMHO should be full download of all data…
(Note, I had a brief email back and forth with John about a comment I submitted on his blog that resulted in him softening his statement and me changing this comment. This was before the THCB editors picked up the post and put it up here on THCB)
Just cited you on my blog.
@john_halamka “Karen DeSalvo started as the new National Coordinator….
She is a cheerleader for IT, not an informatics expert…”
Great, just what the physicians who are forced to use these “tools” need: an HIT chearleader!
Many hospitals are discovering that these tools do not work as promised, do not improve efficiency, do not improve outcomes, do not reduce errors, cause new errors, and cause deaths and injuries. They have these tools turned on in the background, but the care goes on unimpeded by the sepsis posed by MU and the “tools” themselves. The best of all of what happens in these hospitals is that they still have secretariies entering the orders and communicating results as they arrive.
Cram these tools, K. DeSalvo. Comparative effectiveness can not be successful when the tools have not undergone same.
It’s interesting to read the short 1996 paper “Sharing electronic medical records across multiple heterogeneous and competing institutions.” (free, search for it) and ask: “How much has actually been achieved in 18 years of Internet progress?”
It’s time to introduce meaningful competition by giving patients (and our physicians) unhindered access to our own data. Blue Button Plus, federated ID, real-time accounting for disclosures should be the next step, before any other delays and pilots.
Over the top, John. Funny that you said nothing about safety and adverse outcomes from these devices.
As opposed to your advice, the critical matter pertains to whether these devices are safe, efficacious, and usable. Do a body count while this experiment continues.
The SAFER Guides camouflage the risks of these devices and the MU rules. K. DeSalvo and team should be aware that those are too little too late.
Parent to a complex kiddo here, and a big fan of Blue Button.
You say this often: “One of the most negative aspects of 2014 certification is the concept of “certification only”. No actual clinical use or attestation is required but software must be engineered to incorporate standards/processes which are not yet mature. An example is the “transmit” portion of the view/download/transmit patient/family engagement requirements.”
But I’ve heard again and again that 50% of us in many clinical settings have to have access to view our records, download them, and transmit them. And I have a right to my records in the electronic format I want under HIPAA.
So how exactly is this a function not required clinically? How are hospital leaders like you planning on fulfilling this if not with the Transmit that’s already built into your product, not to mention HIPAA?
And don’t tell me the products to Transmit to don’t exist yet. I experiment with every new kiddo PHR that comes out. It would be a godsend for me to be able to send her information directly into the product, and if its a godsend for me then I bet its a godsend for all other parents and the company too. Something smells here.
“If our policy goals are outcomes based, then we should offer a Stage 3 regulation which enables organizations to qualify for incentives if outcomes are achieved using IT as an enabler. We should not prescribe specific functionality for the EHR other than interoperability and security.”
__
On the (misnomer) “interoperability” side, from my recurring blog rant:
One.Single.Core.Comphrehensive.Data.Dictionary.Standard
One. Then stand back and watch the Market Work Its Magic in terms of features, functionality, and usability. Let a Thousand RDBMS Schema and Workflow Logic Paths Bloom. Let a Thousand Certified Health IT Systems compete to survive. You need not specify by federal regulation any additional substantive “regulation” of the “means” for achieving the ends that we all agree are desirable and necessary. There are, after all, only three fundamental data types at issue: text (structured, e.g., ICD9, and unstructured, e,g., open-ended SOAP note narrative), numbers (integer and floating-point decimal), and images. All things above that are mere “representations” of the basic data (e.g., text lengths, datetime formats, logical, .tiffs, .jpegs etc). You can’t tell me that a world that can live with, e.g., 10,000 ICD-9 codes (going up soon by a factor of 5 or so with the migration to ICD-10) would melt into a puddle on the floor at the prospect of a standard data dictionary comprised of perhaps a similar number of metadata-standardized data elements spanning the gamut of administrative and clinical data definitions cutting across ambulatory and inpatient settings and the numerous medical specialties. We’re probably already a good bit of the way there given the certain overlap across systems, just not in any organized fashion.
Think about it.
Why don’t we do this? Well, no one wants to have to “re-map” their myriad proprietary RDBMS schema to link back to a single data hub dictionary standard. And, apparently the IT industry doesn’t come equipped with any lessons-learned rear view mirrors.
That’s pretty understandable, I have to admit. In the parlance, it goes to opaque data silos, “vendor lock,” etc. But, such is fundamentally anathema to efficient and accurate data interchange (the “interoperability” misnomer).
Yet, the alternative to a data dictionary standard is our old-news, frustratingly entrenched, Clunkitude-on-Steroids Nibble-Endlessly-Around-the-Edges Outside-In workaround — albeit one that keeps armies of Health IT geeks employed starting and putting out fires.
Money better spent on actual clinical care.
I’m still awaiting substantive pushback. There are conceptually really only two alternatives: [1] n-dimensional point-to-point data mapping, from EHR 1 to EHRs 2-n, or [2] a central data mapping/routing “hub,” into which EHRs 1-n send their data for translation for the receiving EHR.
The complications arising from these two alternative scenarios ought to be obvious.
__
As I wrote back in November while attending the NYeC conference:
I have some lingering Interop questions. One goes to the humorous phrase proffered by one of the presenters:
“Smiling Almighty Jesus.”
The point was miscommunication resulting from information garble over time between people. The above refers to a dx of “Spinal meningitis,” which the elderly fictional patient in the slide got wrong. As it goes to HIE, this aligns with my chronic rant about a data dictionary standard. As I have observed by way of analogy:
True interoperability requires a comprehensive data dictionary standard. Without it, information can become “garbled.” That is, altered during sequential transmissions.
For example, what if you took these sentences and ran them through Google Translate from one language to another — say, [1] from English to Spanish, [2] then from Spanish to French, [3] then from French to German, [4] then from German to Greek, [5] then from Greek to Swedish, [6] then from Swedish to Portuguese, and [7] then back to English?
1. Verdadero interoperabilidad requiere un amplio diccionario de datos estándar. Sin ella, la información puede llegar a ser “confusa”. Esto es, alterado durante las transmisiones secuenciales. Por ejemplo, ¿qué pasa si usted tomó estas frases y las pasó por Google traducir de un idioma a otro – por ejemplo, del Inglés al Español, a continuación, del español al francés, después del francés al alemán, después del alemán al griego, luego del griego al sueco, luego del sueco al portugués, y luego de nuevo a Inglés?
2. Véritable interopérabilité requiert une vaste série de dictionnaire de données. Sans elle, l’information peut devenir “confus”. C’est, séquentielle modifié pendant la transmission. Par exemple, si vous avez pris ces mots et a traversé Google traduire d’une langue à l’autre – par exemple, de l’anglais à l’espagnol, puis l’espagnol vers le français, puis du français en allemand, puis de l’allemand vers grec , puis du grec au Suédois Suédois Portugais après, puis revenir à l’anglais?
3. Echte Interoperabilität erfordert eine breite Palette von Data-Dictionary. Ohne sie können die Informationen zu “verwirrt”. Dies wird sequenziell während der Übertragung verändert. Zum Beispiel, wenn Sie mir das Wort und ging durch Google übersetzen von einer Sprache in die andere – zum Beispiel aus dem Englischen ins Spanische und Spanisch in Französisch und von Französisch ins Deutsche und Deutsch auf Griechisch, dann aus dem Griechischen ins Schwedisch Portugiesisch nach dann wieder auf Englisch?
4. True διαλειτουργικότητα απαιτεί ένα ευρύ φάσμα του λεξικού δεδομένων. Χωρίς αυτά τα στοιχεία για να “σύγχυση”. Αυτό είναι διαδοχικά αλλαχτούν κατά τη μεταφορά. Για παράδειγμα, αν η λέξη και μου περπάτησε μέσα από το Google μετάφραση από τη μία γλώσσα στην άλλη – για παράδειγμα, από τα αγγλικά στα ισπανικά και ισπανικά στα γαλλικά και από Γαλλικά σε Γερμανικά και Γερμανικά σε Ελληνικά, στη συνέχεια, από τα ελληνικά στα Σουηδικά Πορτογαλικά σε συνέχεια πίσω στα Αγγλικά;
5. Verklig driftskompatibilitet kräver ett brett spektrum av data dictionary. Utan denna information till “förvirring.” Detta successivt förändras under transporten. Till exempel, om ordet och promenerade mig genom Google översättning från ett språk till ett annat – till exempel från engelska till spanska och spanska till franska och från franska till tyska och tyska till grekiska, sedan från grekiska till Svenska Portugisiska in sedan tillbaka till engelska?
6. Plena interoperabilidade exige uma ampla gama de dicionário de dados. Sem esta informação a “confusão”. Isso mudou gradualmente em trânsito. Por exemplo, se a palavra e me atravessou tradução do Google a partir de uma língua para outra – por exemplo, de Inglês para Espanhol e Espanhol para Francês e de Francês para Alemão e Alemão para o grego, depois do grego para o Português Sueco em seguida, de volta para Inglês?
7. Full interoperability requires a broad range of data dictionary. Without this information to “confusion.” This gradually changed in transit. For example, if the word and I went through Google translation from one language to another – for example, from English to Spanish and Spanish to French and from French to German and German to Greek, then from Greek to Portuguese Swedish in then back to English?
Ouch.
Pull up Google Translate, try it yourself. Pick additional languages. The results can often be quite amusing. Broadly, Google “Sapir–Whorf hypothesis.”
As it goes to HIE/”Interoperability,” what I don’t yet know is whether a CDA compliant CCD/CCR ePHI transmission arrives as “read-only,” or whether it can go from the incoming HL7 message and be parsed into the destination EHR database fields where the data can subsequently be edited (“read-write” — I would require appending a new record in order to preserve the original data).
There are HIPAA considerations here, specifically 45 CFR 164.312 (Technical Safeguards — data authentication), and requisite audit log capture. Moreover, given the lack of a single HIT RDBMS Data Dictionary standard, might ePHI undergo modifications strictly resulting from point A to point “n” sequential transmission? Now, if a HIE CDA transmission is read-only, garble concerns would be allayed, but…
I will defer to others further down in the weeds on this issue.
” Thousands of pages of regulations are hitting the industry at the same time and it’s clear that like healthcare.gov, haste will make waste.”
This is what drives physicians crazy. Let’s stand healthcare on it’s head and also pump into the system thousands of pages of regulations that mabye no one has read, or understands the impact on practices. Not only that, are these really useful tools for imrpoving patient care, or just boxes to check to get your measly payment from CMS?