I’m a few weeks short of the 1 year anniversary of my departure from federal service. I loved my time in Washington, and loved the people, the passion, the sense of purpose, and of course the focus on doing what’s right for the nation. What was intended to be a 1-2 year adventure became a 3 years of commuting to DC from my home in Albany, New York.
Stepping away from government has given me the opportunity to get back to the front lines of the intersection of information technology and health. Notice that I didn’t say “health care.” Sure – “care” is part of what happens – but isn’t the goal to minimize the care that’s necessary – and maximizing health? Glad you agree.
Until my 1 year anniversary, I’m prohibited from “engaging in certain activities on behalf of persons or entities.” Here’s the rule, in case you’re curious. This is why I can’t testify or even engage in the FACA hearings or workgroups, call my former colleagues on the phone and give them unsolicited advice on policy matters, etc.
CMS has issued an RFI on how it implements regulations for MACRA. I can’t submit comments (see above). But since I still have first amendment rights – I can post my comments here. Feel free to plagiarize when you post YOUR comments. 😉
Here is how I’d answer a few of the questions:
Under the MIPS, what should constitute use of CEHRT for purposes of reporting quality data?
MIPS should leverage the ONC’s certification program for purposes of reporting quality data. If the capabilities required for MIPS are not represented in the suite of capabilities for which products can be certified under ONC’s program, ONC and CMS should work together to create new certification opportunities under that program. Anything other than this would be confusing, costly, and complex. CMS may be considering the creation of a separate program. What a waste that would be. Please please please don’t do that.
Instead of requiring that the EHR be utilized to transmit the data, should it be sufficient to use the EHR to capture and/or calculate the quality data? What standards should apply for data capture and transmission?
I’ll answer an edited question – since “utilized” is used incorrectly in this sentence (who does the copy editing at CMS?) and as it is expressed – the monolithic EHR is assumed to be present. But that should not be the case. ONC has evolved their terminology toward “health IT” and CMS should do the same where possible. Yes – due to the reference of “EHR” in the laws (both HITECH and MACRA) – this isn’t always possible – but perhaps we can get congress to fix that with a little wordsmithing. (How about it, Colin and Alicia? )
Edited question: “Instead of requiring that health IT be used to transmit the data, should it be sufficient to use health IT to capture and/or calculate the quality data? What standards should apply for data capture and transmission?”
a) Health IT can and should be used by providers and provider organizations to capture and calculate quality – as tightly or loosely coupled as such organizations might be – including but not limited to BPCI awardee conveners, CPCI affiliates, ACOs (all shapes and sizes), ICNs, regional cooperatives such as a New York PPS (under the NY DSRIP program), states, RHIOs, HIEs, IDNs, MA joint ventures, etc.
b) The standards to be used for the reporting of such quality calculations should be QRDA III.
c) In the case of quality data transmission, QRDA I should be used.
d) Quality data capture (from health IT – to a quality aggregation/calculation entity) should leverage QRDA I. Health IT should be certified for the capture of data elements – as defined by ONC – referenced in the Data Elements Catalog and the Value Set Authority Center @ NLM – as is currently the case. Don’t break a good thing.
e) Outcome measures rather than process measures should be preferentially selected.
It’s been a few months that I’ve been writing this. Well, not quite writing it. Crafting would be more like it. In my head. Over and over. Today I needed to write it.
The waves of sadness we have felt the past few days are calmed by an undercurrent of peace.
We know that dad was ready to go. He had talked about it for weeks. He wanted his life to be rich and full and warm and happy right up until the instant he departed. And it was.
I’ve wanted to capture the message. The message that dad sent me for fifty two years, and which I hope can be heard by you – those of you here sharing this time with us – and especially his grandchildren: Molly, Sam, Charlotte, Rosie, Max and Zoe. Listen up – I’m translating Pete here for you, kids. It’s good stuff.
His message was always implicit. It’s not what was said – it’s what was unsaid. And didn’t need to be said. It’s what was done – without fanfare or any quest for recognition – because he loved doing it. Whatever it was.
Today you will hear the vignettes from our family: the funny episodes, the touching courtship of my mother, the track & field success, the rich and beneficent psychiatry career. These are the papier mache.
So I’ll offer some chicken wire, and I’ve even got a mnemonic for you. I’m a fan of Sesame Street – as was dad – so we’ll start with the letter “E” – the first letter of his rarely used middle name. Right there in your program – if you want to follow along. Elliott.
E – Engaged. In his wonderful book, Graceful, Seth Godin contrasts the “tourist” from the “traveler.”
“It’s not the cameras or the colored shirts. It’s the eyes – that dart back and forth – alert for threats, clearly closed to anything that might cause change. It’s OK to notice, but if you [live life] as a tourist – you’ll return as you went – unchanged … The engaged one, the graceful actor in an unfolding play, will open themselves to the world they’ve bought a ticket to, knowing full well that they will be changed.”
Engagement. Dad was always engaged. He sought not to change others to meet some arbitrary model. He engaged with people, science, language, comedy, literature and music – not to influence – but to be influenced. Like dad, I seek to be a traveler rather than a tourist. To be changed, rather than to change. Thank you dad.
L- Listen. Dad knew how to really listen. Listen in a way that validated without judgment, reflected without direction, and motivated without urgency. A few weeks ago, I told dad an affirming story about this wonderful skill he had passed on to me. I was teaching residents and medical students in the hospital in 1998 or so. We were in the emergency department, called there to admit a patient to the hospital who "refused to go home." We found a 40ish woman, lying on her side in the room. The medical workup was entirely normal. A family member had recently been admitted to the hospital for appendicitis. She was scared that she might have appendicitis as well. After we listened to her story, I asked her what else was going on in her life, how she was feeling, what troubled her the most about her situation, and how she was handling it all. I asked her if she would like to go home, and she eagerly agreed that this was the best course of action. On our way out of the ER, the doc exclaimed: "How did you do that!?" "I was in there talking to her for 30 minutes!" “Well,” I replied, “I listened." Dad taught me that. Thank you dad.
L – Love. This one’s hard. I’ll make it short. Love the people, love the places, love the music, the nature, the color of the sky at that special moment, the waves as they crash into the beach. Dad loved so many things and so many people. Most of all, Dad loved mom. Courted away from a football player in high school (or so goes the story I choose to remember), lured 3000 miles to Cambridge for marriage, mom and dad shared and traded the pilot/co-pilot seats for fifty-seven incredible years from Boston to San Francisco to Cambridge to Newton, and annual ventures to Italy and finally back to San Francisco. The growing children always felt unwavering love and support from our parents – even through the hurdles of adolescence and young adulthood that try the patience of all parents. I never had even an inkling that dad disapproved of me. Never. Ever. I think that’s part of what love is. Thank you dad.
L – Learn. (The silent third L in "Elliot.") Dad loved to learn. He was always – up to and including the very last day of his life – learning more about people, the physical world, music, spirituality, and of course – by extension – himself. No opportunity to learn would be missed. The process, more than the content or the result, was exciting to him. He didn’t learn in order to achieve a pinnacle of knowledge – so that he could leverage it in some way to “win” over others. Learning – for the sake of learning – was his passion.
A few weeks ago, he found a copy of a book called The Canon by Natalie Angier. He consumed it with such energy and excitement! I learned from him about the trilobites – 17,000 species of extinct arthropods that are fossilized and have taught us so much about our past. Trilobites died 250 million years ago – yet they're still teaching us.
He was also fascinated by the story of the Sea Squirt. Here's what he read aloud to me:
“The sea squirt is a mobile hunter in its larval stage and thus has a little brain to help it find prey. But on reaching maturity and attaching itself permanently to a safe niche from which it can filter-feed on whatever passes by, the sea squirt jettisons the brain it no longer requires. Brains are great consumers of energy, and it is a good idea to get rid of your brain when you discover you have no further need of it.”
He LOVED the sea squirt! He loved LEARNING about the sea squirt! So fascinating. "good idea to get rid of your brain when you discover you have no further need of it.” So cool. So funny. He adored the sea squirt. Me too! Thank you dad.
I – Introversion. Albert Einstein wrote: “I am a horse for a single harness, not cut out for tandem or teamwork.”
Like Einstein, dad was an introvert. As am I. My siblings inherited the "extrovert" gene from mom. (Lucky them – High school is so much easier for extroverts!) Dad's introversion always calmed me – reminded me that I had permission to want to be alone – to need to enjoy things quietly and by myself or with a very small number of others. Dad's introversion reminded me that there was nothing wrong with seeking solitude. Thank you dad.
O – Observation. Dad observed everything. Always watching, seeing things others didn’t notice – in a book, in music, in people, in a landscape, in art. He saw the virtue, the achievements, the unique goodness that makes everything and everyone important. Thank you dad.
T – Tenacity. Dad was focused, tenacious, and determined to do what must be done. We see this in his track and field successes at Lowell High and Harvard and beyond. We see it in his long, successful professional career – and of course we see it in his graceful, Engaged, Listening, Loving, Learning, Introverted, Tenacious final push across the finish line. Dad was, in his final weeks – his true self in every way. He died as he lived – without struggle or anger, without judgement, without fear.
T – Tender.
Elliott – dad's middle name:
Even before dad’s illness, I would start my speaking engagements with a picture of an apple near the base of a tree.
I would describe the careers of my father – and his father: psychiatrists whose work was focused on helping others succeed.
No – I'm not a psychiatrist. I'm a family physician, health IT nerd, former federal servant – but my goal is identical to that of my dad – and his dad before him .. and perhaps .. it's YOUR goal too: without judgment, assumption, bias or personal agenda, help others be their best.
And it’s amazing how a set of simple principles can cause humans to be so influential. Without trying to be influential at all.
Thank you, dad. Thank you. Thank you. I will miss you every day, and I am grateful for what you have given – to carry with me forever.
From my run this morning. We humans love the beach. The end of land. The beginning of ocean.
Dad's traverse is complete. He did it his own way. Of course.
To be published in various newspapers ..
Arthur Elliot (Pete) Reider, MD
Arthur Elliot (Pete) Reider, MD, died peacefully at home in San Francisco of lymphoma on Thursday August 13th 2015. Janet Sampson Reider, his wife of 57 years, and all three of his children were by his side. Dr. Reider and Janet divided their time for the last few years between their family home in Newton Massachusetts, a home in Vermont and San Francisco where they grew up.
A graduate of Harvard Medical School, Pete married Janet, his high school sweetheart, in the spring of 1958 after graduating from Harvard College. Janet and Pete met when they were 13 years-old, and Janet recalls how he *chased* her up the path at a Sunday school picnic, thus initiating the courtship. They began their married life in Cambridge, as Pete entered medical school.
A retired psychiatrist, Pete had a rich and rewarding professional life, earning the respect and gratitude of hundreds of patients, as an intern at Mt. Zion Hospital, as chief resident at Mass Mental Health Center, and in private practice in Cambridge and Newton.
Pete was a lifelong runner and fan of track and field. At Harvard, he ran cross country and was the captain of the Men’s Track and Field Team. He was a record holder in the mile run with time of 4:11, the 2 mile with a time of 9:21.8, and cross country. He was voted to the Harvard Athletic Hall of Fame and named a member Men’s All-Time First Team All-Ivy League Cross Country Team for both the 1957 and 1958 seasons. Coach Bill McCurdy said that Pete “was one of the toughest little men he has ever known, and that he fought fatigue like a mortal enemy.” Among Pete’s greatest joys was cheering on sons Jacob and Matthew, and grandchildren Sampson, Molly, and Charlotte as they continued the great Reider running tradition.
Pete was the son of Dr. Norman Reider, a renowned psychoanalyst, and Mrs. Louise Reider. Born in Topeka Kansas, he spent his early childhood in New York City, before moving to San Francisco, where he attended Lowell High School with Janet. With Janet at his side, Pete enjoyed travel, music, books, science, Red Sox games, the New Yorker magazine, and sharing his quick wit and love of learning with his grandchildren. Pete enjoyed a tradition of taking grandchildren on trips to Venice and never missed a graduation, play, concert, track meet, soccer game or birthday celebration. He was the best Grandpa on the planet.
Always curious, Pete took to writing short stories and poetry in recent years. Stepping Stones, a book of his poetry and fiction, notable for its quirky humor and characters, was published in 2014. Sharing his love of knowledge with others, Pete taught courses in the blues, humor in literature, and creative writing at BOLLI, the Osher Lifelong Learning Institute at Brandeis University.
Pete leaves behind his beloved wife Janet; his children Jacob Reider and his wife Alicia Ouellette, Suzie Reider and her husband Brian Smith, Matthew Reider and his wife Alison Cohen; grandchildren Molly Reider, Sampson Reider, Charlotte Reider-Smith, Rosie Reider-Smith, Max Reider, and Zoe Reider; his brother Jonathan Reider, brother-in-law John Sampson and his wife Sharon Litsky; sisters-in-law Deborah Green, Louise Sampson and Leah Reider, as well as dozens of beloved in-laws, cousins, and friends.
Lots of news/talk about ICD-10 these days. Most organizations are spending time and money training care providers on it. Software developers are busy implementing it – often by changing diagnosis selection search menus from ICD-9 to ICD-10.
They're missing a fantastic opportunity.
ICD-9-CM and ICD-10-CM are administrative coding systems. They're used to code diagnoses. Clinicians have (unfortunately) been forced to learn many ICD-9 codes and are being told that we need to shift to ICD-10. Some of our colleagues are hoping that they can just use ICD-9 and "someone else" will convert ICD-9 to ICD-10 but of course this can't happen. ICD-10 is much more granular, and often requires additional information. It's like the vet requiring one to specify your animal's breed: ICD-9 allowed for "dog, cat, aardvark." ICD-10 requires: "Golden Retriever, Persian, O. a. lademanni ." Nobody can translate to the more precise term if you hadn't recorded sufficient information in the first place.
"But how can we avoid ICD-10? That's the title of your blog post!" You say. "How? Why?" ICD-10 (and ICD-9) are administrative coding systems, weren't designed by or for clinicians. We don't think that way. There are (much) better alternatives. When ONC made SNOMED-CT required for recording diagnoses in certified EHRs in 2012 (effective for the 2014 certification criteria) I thought it would be obvious that the combination of SNOMED-CT for recording of diagnosis – combined with the free ICD-10 to SNOMED CT mapping tools that NLM published at the same time would meet the needs of organizations to RECORD SNOMED-CT and yet DELIVER ICD-10 to those who required it – primarily CMS and other payers. Why capture SNOMED-CT and then (again) capture the same information in ICD-10? I was sure that everyone would "get" the hint. Commercial solutions like IMO and HLI offer even more elegant methods of capturing interface terms (terms that are customized to the user) and then mapping to the proper code: SNOMED-CT for clinical data recording and transmission, and ICD-for administrative transactions.
It wasn't obvious. Many (but not all) health IT developers ignored the opportunity to insulate clinicians once and for all from administrative codes. Hospitals and other care delivery organizations spent millions on consultants to develop and implement training and "go-live" strategies to teach clinicians ICD-10. I implored folks in both communities to think past the veneer of the federal regulations, read the preamble of the ONC Certification criteria (where we explained much of this) and think outside of the box. Innovation? Nope. Folks have read only the veneer of federal regulations from both CMS and ONC, avoided creative thinking, and implemented solutions that check the regulatory box, blame the feds for it, and impose massive pain on a generation of clinicians.
It could have been avoided.
Naysayers will insist .. "but what about the extra information that ICD-10 requires such as laterality?" And my answer is that this information can and should be captured without ever exposing a clinician to an ICD-10 code. Some organizations are already doing this. Some EHR developers are already doing this. If yours isn't, then you should ask them why not.
The requirement is that ICD-10 be delivered. There is no requirement that ICD-10 be entered into the computer (or paper) by the clinician. When I order a diagnostic test such as imaging or blood work, those doing the testing will likely require ICD-10 so that they can pass it along to those who will pay them for the service (I say "may" because again – the requirements of them are to pass along ICD-10 to those who will pay. But they have passed on this burden to the clinician without careful thought: they, too could insulate the clinician from the burden and perform the translation from a clinical question ("why is this test being ordered?") to a billing transaction ("what is the ICD-10 code for which this test was ordered?") Technology should capture the diagnosis in a terminology that I understand – MY language (HLI, IMO or SNOMED-CT) and if additional data is required – I should always be prompted for it – in the most elegant manner possible. The information that I capture can/should then be stored in the patient's problem list if it's not already there (and of course if it IS already there – it should be offered as an initial selection to avoid replicating work that was already done!) and then translated in the background into the administrative code. This should be opaque to the user. Accessible? Yes – sure. Just as I can "view source" in my browser to see the HTML. But really – who wants to do that? Not me (most of the time). Not you. Nor will I need to see the ICD-10 code 99% of the time.
Don't burden your clinicians with ICD-10! Avoid it. Yes you can. And you should. Anything less is irresponsible. Yes – some Who have been "educated" by high-priced consultants will ask for it. But you shouldn't give them a faster horse. Give them what they need.
It’s hard to hear a pitch, listen to a speech, or read blogs without hearing/seeing a claim that some cool new thing is distruptive. Most innovations are sustaining innovations. Here’s a good checklist for whether something is a disruptive innovation (via this post in HBR):
Does the product either target overserved customers (by offering lower performance at a lower price) or create a new market (by targeting customers who couldn’t use or afford the existing product)?
Does it create “asymmetric motivation,” meaning that while the disrupter is motivated to enter higher performance segments over time, existing players aren’t motivated to fight it?
Can it improve performance fast enough to keep pace with customers’ expectations while retaining its low cost structure?
Does it create new value networks, including sales channels?
Does it disrupt all incumbents, or can an existing player exploit the opportunity?
Does it disrupt all incumbents, or can an existing player exploit the opportunity?
For the low-low price of $4500 (that's $500 per page) you can buy this 9 page report on how the athenahealth-BIDMC alignment is evidence that cloud-based information technology will form the basis of tomorrow's health IT solutions. Obviously, I've not read the report. It's not clear if Bernie Monegan has either, but she's written an article about it, which has generated some buzz on the Internet in recent days. (One wonders about a relationship between HIMSS – which owns Healthcare IT News – and ICD – but I don't recall that there is one) ..
Let me save you $4500.
Where the data lives doesn't make this new. SMS (which became Siemens and of course is now Cerner) hosted hospitals' data in their data center in Malvern 25 years ago. Call that a "cloud" in 2015 parlance, but a hosting facility is a hosting facility.
Yes – there are some differences. Traditional hosting is single-tenant. The server(s) are dedicated to a given facility, and they're mirrored to a redundant facility for disaster preparedness. The server looks, acts and feels like is in the hospital basement rather than in some data center in a secret mountain in Colorado – and there is a (virtual) dedicated wire that goes from the hospital to the data center. The CIO can tour the data center and the guy with a pocket protector can point to "your" servers – and there they are – lights blinking away, fans whirring.
And "cloud" these days invokes a multi-tenant model. One big data bucket, and one big application layer, with a technical architecture that separates patients and providers in a way that privacy and security are managed well, but that eliminates redundant hardware and software. The data and the software services are distributed logically and often physically. There isn't one server where "your" data lives. It's everywhere – inherently redundant. athenahealth and PracticeFusion are obvious models of this in the ambulatory domain, while RazorInsights and iCare are examples of acute care products like this.
This isn't the interesting part of "3rd platform" for health IT. Yes – it's self-evident that distributed computing, mobile endpoints, and "loosely coupled" services will be part of the future health IT infrastructure. Ho-hum. The rest of the world has been there already for a half-decade. Hosting your own Microsoft Exchange server in 2016 will be akin to driving a Chevy Nova. Health care will catch up. Slowly. We'll see initial progress in the value based primary care settings: Iora Health, Chen Med, Oak Street Health, and Qliance are already adopting entirely new care models – with entirely novel health IT platforms to support these models.
After value based primary care, we'll see innovation in the LTPAC space. They are relative non-consumers of health IT, and therefore represent a unique breeding ground for innovation and creative applications of technology.
The unique feature here isn't that the tools will "live in the cloud." What's unique is that the tools will be centered around the goals of the individual rather than the goals of the care delivery organization.
We chose careers in health care because we wanted to have impact. To help. To make the world a better place. Atul Gawande’s wonderful book, Being Mortal, reminds us that the profession of medicine has failed miserably at doing what is in fact most important: understanding the goals of individuals, and helping us navigate that path. Together. The book isn’t about death. I had actually avoided it initially – worried that it was. It’s about our pervasive and persistent inability to do what’s right in health care, and tells a handful of stories about some amazing people who are breaking with tradition and doing what’s right – with impressive results.
As I read the book – I pressed “replay” on vignettes from my career as a family physician, a parent, a software developer, a federal servant, and a son. I ask myself how I fared in this context. When I supported a patient’s decision to decline a medication that I thought would help them feel better, was I helping or hurting? If I “took a strong position” on immunizing children, was I alienating parents from the care delivery system altogether, or “holding firm” on a “scientific fact?” When I helped to create regulations that explicitly expressed certification requirements for health IT systems, was I protecting the public interest, or stifling innovation? The answers, of course, are foggy. What was the “right” answer for one individual may be different from what is right for another. What's "essential guidance" for one software company may be "prescriptive regulation" to another. One size does not fit all.
What's the 3rd platform? It's the individual. Designing our systems (not just our IT systems) in a way that helps us discover the priorities of each individual, and then adapt to support them. Driverless cars? Of course. Just tell me where you want to go. Technology is an essential component of the solution. But humans define where we are going.
ICYMI, a bill was introduced last week from the office of Representative Burgess (R – TX). Here’s a link to the pdf of the bill. It’s clearly just an early version – with many gaps and many invitations for enhancement, but it’s an important lens on how Congress views the opportunities ahead for health IT.
If we view this in the context of the five Senators’ blog post last week in Health Affairs, we can surmise a few things:
a) Congress understands that health IT is complicated.
b) Congress understands that the majority of hospitals and care providers have adopted health IT. This is, as they say, a “good problem to have.”
c) Since the systems have been adopted, it has become clear that causing them to interoperate seamlessly is much more difficult than many people expected.
Let’s parse the Burgess bill first.
a) The bill attempts to redefine interoperability as:
“does not block access.”
b) The bill proposes to disband the Health It Policy Committee and the Health IT Standards Committee and create a new FACA – with its membership entirely managed by Congress – guide HHS on the definition of interoperable health IT systems.
c) The bill proposes to impose penalties on those who fail to comply with the definition, and requires providers and hospitals to attest that they do not block interoperability.
d) There is no mention of other capabilities or standards to which systems would be held, but the Secretary would, it seems, be able to define them.
a) Unfortunately, “access” and “interoperability” are different concepts. There is already a very good definition of interoperability that has been adopted beyond health care: the Institute of Electrical and Electronic Engineers (IEEE) provides the generally accepted definition of interoperability, at least from a technical perspective. It defines the term as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” See IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries (New York, NY: 1990). (My emphasis on “exchange” and “use” added above.)
HHS has adopted this definition – as has (with some modification) the FCC.
But let’s look past this to see if we can understand what Representative Burgess was aiming for – and see if we can help address the problem he’s aiming for. The problem he’s trying to solve is real: we buy health IT systems and then they don’t just talk to each other! Why didn’t this “meaningful use” thing make them work like that?
Good question. $30B later – the systems don’t talk to each other easily. They’re not “plug and play” and we expected that they would be. Is it because there wasn’t a good enough definition of “interoperable?” IF we somehow mandate “access” in all forms, will this solve the problem?
You can access your bank account – but that’s not because it’s interoperable. That’s because the bank made it accessible. You can withdraw money from an ATM because your bank (and your money) is interoperable. You can exchange and use your information in the bank. It is also (we hope) manage there in a form that is safe and secure. The technical standards that banks and others in the finance industry use are well defined, and while this is complex in finance – it is hundreds-fold more complex in health care. Finance moves information that is – in various forms – multiples or fractions of a penny. Health IT systems move information that is much less clearly expressed. ONC’s interoperability roadmap is a good start, but as the Five Senators wrote in their blog post – it lacks the specificity that we now need to move ahead. One could of course argue that a roadmap isn’t the place for specificity. The regulations are where specificity will be found, and these are likely to be released in proposed form in the coming weeks.
b) The existing FACAs could be better – but they don’t need to be ripped out and replaced. The HITPC and the HITSC should be better coordinated with NCVHS, as the bill implies. ONC’s management of these FACAs has been a bright spot: they are very transparent, open, collaborative and engaging. I’d suggest that Congress needs to pay more attention to the very frequent meetings convened by these FACAs so that they can better understand the great value that they add.
c) Penalties for health IT systems that are not compliant with interoperability expectations does make sense. But we had better be sure that the definitions are clear and flexible. I don’t expect that Representative Burgess wants to curtail innovation, but that is exactly what will happen if there is a strict regulatory framework imposed on a definition of interoperability that holds civil penalties above it like a guillotine. Consider that the MOST interoperable/safe/secure form of money is probably bitcoin. Bitcoin can – by definition – be exchanged and used. Indeed – these two verbs are buried deeply in the DNA of bitcoin. Yet the standard tools that are used to exchange pennies and dollars are not used (or even necessary) to store, exchange and use bitcoin. So a definition of an interoperable money exchange system would not likely be met by bitcoin. A banking system that offered consumers a method of banking bitcoin certainly would lack some of the security safeguards that other systems have – but this is because the security safeguards necessary for traditional banking systems aren’t at all necessary for bitcoin banking – since bitcoin is fundamentally more secure.
So if innovators in 2021 dream up incredible methods of (safely, securely, privately) exchanging and using health information, we would want the regulations to anticipate and allow for such creativity and not stifle it.
While Rep. Burgess’ bill offers that the Secretary would have the freedom to modify the suggestions of the
Vik and Al's post on THCB was e-mailed to me this AM with a request for a comment. My reply:
I completely agree. And I completely disagree.
I agree with Zeke (and the research he cites) that the "physical exam" is useless. Indeed, when I was a full-time family physician, I would refuse to discuss/schedule an "annual physical."
But Al and Vik have conflated the "annual physical" with a proactive interaction between a care provider and an individual. Notice that I didn't say "physician" (it need not be a physician) and notice that I didn't say "patient" as we need not think of ourselves – all of us – as flawed or "in need of care" in some way. We're individuals and not patients.
But planning our health, just as planning our finances, or planning our home/car/helicopter maintenance schedules sometimes requires the assistance of a person who has more training or expertise than the individual.
Appropriately managed, this is a regular event, which adds value as the foundation of a trusting collaborative relationship between an individual and a member of a care delivery team.
Just as we needn't gather evidence that parachutes save the lives of humans who fall out of airplanes, we needn't gather evidence that this relationship is important. Yes – text messages, e-mails, activity trackers, wifi scales and video chats are all appropriate adjuncts for the (ideally rare) face-to-face interaction. But they're adjuncts. Not substitutes. We do need time together because we're humans. A physical exam? No. of course not. A "check-in" every year or three? Absolutely.
It’s time to stop calling them EHRs. Yes – we also need to stop calling them EMRs. In 2011, ONC discussed the difference between the two terms, but I think that conversation missed the point: whethere it’s “medical” or “health” that is the focus, these aren’t (shouldn’t be) RECORD systems at all. We need to expand our expectations from CRUD to something that we really need: smart tools that help us collaborate toward improving health for individuals. In November, when I floated this concept, I was teased (corrected?) for focusing on terminology and missing the point that we need EHRs to do more than just store data.
But it’s more than just terminology. Our words mean a lot. A “record” system is for storage of records. It saves information. Our expectations will always focus on storing and retrieving information. That’s the core of the design. But in other industries – we’ve seen migration from information store/retrieve to intelligent platforms that anticipate our needs. Does storage occur? of course it does. But storage of information is the byproduct of collaboration and not the goal.
Let’s call it health IT – or even better – “IT for health.”
This appeared in my e-mail today. It’s an ad for some article that was supposed to prompt us to think about IT from a different perspective. Should IT be delivered from a clinician-centric approach? How is that new? I suppose it’s better than a “CFO-centered approach,” but we deserve even better. As an industry, we've lost focus on our priorities. The needs of the individual are getting lost in a maze of fee-for-service motivated check-boxes and auto-generated drivel. What's the foundation of IT that's best for a patient? THAT’s what should be delivered.