I was part of the Pfizer COVID vaccine clinical trial in 2020. There was an app for recording some simple…
Startup CEOs and Investors: Brian Weiss
Startup CEOs and investors with strong writing and teaching skills are welcome to post their ongoing stories and lessons learned. Contact me if interested.
Are We On Fire Yet? (Or, Where’s the Data?)
By Brian Weiss
A Star(tup) is Born
Healthcare IT startups can often trace their origins to an “Aha! Moment” when a tech-savvy entrepreneur-to-be experiences the healthcare system in a significant way (often, sadly, due to the illness of a loved one) and decides, “There has to be a better way to …” (avoid allergic reactions, make sure medications are taken properly, keep track of blood sugar readings, avoid filling out the same forms over and over in the waiting room, have this doctor know what that other doctor already did, make sure they amputate the correct limb …)
Eureka! A mobile app / web application is born. It will be “just like …” (Facebook, Instagram, Google, Uber,or any other multi-billion-dollar Internet wonder) – except, “It will be perfect for …” (patients, doctors, caregiver moms, hospitals, home care …) Not to mention that it rhymes with “ACO” and runs … (on a smartphone, in a cloud, directly on your retina in the next version …)
A related family of startups, loosely termed “healthcare analytics,” often starts with an entrepreneur who is a bit older and more seasoned, has enough business savvy to “follow the money trail,” and whose neighbor’s daughter is in her last year of grad school for the third year in a row. Said neighbor’s daughter says that given a standard blood test kit, a strand of hair, and the first and third letters of someone’s last name, we can “predictive analytics” (yes, it’s a verb — I say so) anything you want about someone’s future medical conditions with proven accuracy of at least 98.7 percent on all predictions for the time period following their death.
Now Let Me Explain …
These great ideas of my younger and hipper friends are predicated on a surprisingly problematic assumption. Namely, that patients (more broadly, “consumers”) have reasonable access to electronic copies of their own healthcare data. If you’re reading HIStalk, I probably don’t need to explain to you what a silly notion that is. Why do entrepreneurs assume this is the case?
First, some of them saw the hip-HIPAA video (or something similar) from Uncle Sam Productions stating that every person in America has a right to get an electronic copy of their records from anybody that maintains such an electronic record (which I think right now is almost everyone involved in healthcare in some way, with the possible exception of Aunt Emma and her world-famous chicken soup, and it’s just a matter of time before she attests for MU Stage 1.)
Throw into the mix some intuitive modern consumer expectations and you can begin to understand (not condone, of course, just relate to in a non-judgmental way) why some of our misguided youth are jumping to the wrong conclusions.
The result is cool apps that work great, as long as everyone either (a) has the actual same clinical data as in the sample data they used in development, or (b) wants to spend a few hours every weekend updating their clinical data manually from whatever scraps of it they can get their hands on.
But fear not! Fortunately for all of us, I now have this prominent published column that one or two of these lost souls might actually read, so here’s my chance to step up to the pulpit and set everyone straight.
My Friends! Salvation is Just One Committee, Acronym, and Decade Away
So, listen up, my young, big-idea friends.
The umpteenth committee in a series that began running before most of you were born is taking care of this problem even as we speak. Like every committee in the series, it includes multiple leading vendors, multiple leading standards organizations, and multiple very experienced (from previous committees – I wonder how the first one was formed?) leading experts.
This is not your father’s Oldsmo-committee. This one (did I mention it was “leading” and “multiple?” Yes, that’s an adjective for real, so I can use it any way I want) is dedicated to one of the principles our great country was founded on (whenever the public funding well runs dry): “More acceleration without regulation.” The original cry of the Boston Tea Party before a focus group said “taxation” and “representation” worked better.
This latest committee is hipper than most, as evidenced by a name taken from Greek mythology. They’ve published a charter that makes it clear they plan to work very, very quickly, so that by 2016 we’ll have a shiny new accelerated standard and then we can figure out if and how consumer data is actually going to be made ubiquitously available with it sometime in the 2020s (is that going to be a hip decade, with a name like that, or what?) for your cool apps.
You’ve got enough seed funding to carry you until then, right?
The new standard (OK, it was actually new quite a few years ago – but not enough people were paying attention back then) is called HL7. No, ASTM CCR. No, HITSP CCD. No, SMART. No, Blue Button Plus. No, C-CDA. No,C-CDA R2.0. No, no, no — it’s called FHIR (rhymes with “liar,” but that’s the honest truth).
The Lessons of Blue Button Plus
I (virtually) know a few Argonauts and some of the other folks who have been working on FHIR for many years. They are incredible folks who are smarter, more experienced, more capable, and more all kinds of stuff than me.
Then again, so were/are the folks who worked on something called Blue Button Plus (it had a bunch of other names like ABBI — I forget more easily at my age) back in what seems like just a few months ago.
Two years ago at HIMSS, there were some slick PHR startups showing off their Blue Button Plus capabilities for fetching data from Blue Button Plus-enabled sites.
I wasn’t personally involved, but I’m told that Blue Button Plus integration meetings were a bit like dating sites with members of only one gender registered. Lots of folks wanted to be Blue Button Plus clients, but nobody was offering to be a server (you can see why I didn’t want to pin down the gender in the dating site analogy – that could get me in trouble with the whole client-server thing).
One of the poster children for Blue Button was (and still is, I believe) MyMedicare.gov. You know what special next-generation data format they use when you Blue Button (yup, another verb I created) your records for re-use? FHIR? C-CDA? CDA? CCD? JSON? XML? If you guessed “ASCII text files,” you’re our lucky winner.
And you know what? That’s actually a whole lot better than what you (can‘t) get from most sites using Blue Button Plus or SMART or any of the other standards and frameworks that promised to deliver MU2-aligned C-CDA (or similar) data with push delivery, notifications, security and authentication, and an App Store-like ecosystem.
It’s Not (Just) the Data Format, It’s the Data Availability
Now I actually know a little bit about some of these standards. Once upon a time, HL7 even contracted me to help write some of their knowledge base articles on CDA and C-CDA.
I’ll send you my rubber stamp so you can add my signature to any learned commission or task-force reports listing what’s wrong with C-CDA. It’s complicated, ambiguous, overly academic, insufficiently documented, lacking examples, has too low a validation bar in MU2. Did I mention complicated?
There’s lots more work to be done on standards. FHIR sounds great. My FHIR friends assure me that in due time it will replace HL7 v2 and CDA, and might even shorten the coffee lines at HIMSS. And I’m told that if you can figure out how to play Candy Crush, you can write a great healthcare app with FHIR.
Don’t misunderstand my feeble attempts and rancorous wit. We definitely need better standards, better guidelines for MU Stage 3, and a better 5-10-50 year strategic data interoperability roadmap for posterity.
Just sayin’ that is not what I think we need most. That honorary title belongs to…. DATA ACCESSIBILITY.
Despite all its flaws, the M2 C-CDA standard we already have is all my fellow startupers (plural noun, yup) and I need right now to do all kinds of cool stuff. Actually, we would do fine with the MU1 CCD (aka “HITSP C32 CCD”). Or the CCR that came before that. Or even the HL7 v2 messaging before that. Or Blue Button Plus, or SMART, or whatever.
But wait. Don’t developers need simple RESTful APIs for their apps (as FHIR will provide)? Of course, but we don’t need another year or two (and I’m not even getting into the debate if those are human years, dog years, or ICD-10 years) to wait for FHIR, just for that.
The translations between whatever other formats are out there and actually available today and the mobile app-ready formats developers will adopt are not the real barrier or issue. My company and many others will try to kill ourselves outdoing one another to provide those more quickly.
The main issue is what is really out there and actually available today in terms of real patient clinical data. And without belittling the importance of how many steps you took today on your way from your desk to the restroom, I mean the clinical data in the myriad of EHRs and similar that contain your more traditional health records, not the stuff from your neon fitness bracelet or your mood ring.
If application developers could reasonably get the “C-CDA over DIRECT” data promised by MU2 and Blue Button Plus from every hospital, doctor, pharmacy, lab, clinic, we’d be flying.
How can I be so sure? Because we’re almost managing today, with a lot less.
If my friends at HL7 and FHIR were shown the minimalistic JSON being returned by early-stage commercial APIs that provide patient portal data to PHR developers, they’d have a heart attack (though they probably wouldn’t know it without the correct SNOMED codes for that condition , which aren’t provided).
The data available today is a hodgepodge of formats, coding standards, semi-structured text, and whatever else you can think of. It’s not pretty, but it’s a whole lot better than what we (can’t) get (yet) from “future standards.”
It’s Not Either-Or
If you ask me (you don’t really have to, it’s my column, so I get to make up both the questions and the answers), getting ubiquitous access to data now is as important to FHIR itself as whatever else is being worked on in Argonaut projects and similar.
“Build it and they will come” works in the movies. Everyone else has to get real-world feedback and iterate to the right solution. Lessons learned from real-word smartphoning (yes, it’s a verb) by consumers with apps running off of C-CDA document data as mandated for delivery by MU2 is as important to the future of FHIR as API connectathoning (ahem) with like-minded geeks.
Of course, focusing exclusively on data accessibility with existing problematic standards, flawed policies, undefined authentication APIs, incomplete code system alignment, and all the other myriad of gaping holes still open isn’t a good idea, either. We need to be working on these issues from all angles simultaneously: standards developers, established vendors, policy organizations, regulators, providers, industry leaders, payers, consumer groups, government agencies, startups, public opinion influencers, and more.
But the funny thing about the future is that you get there a whole lot quicker if you start now.
I think we need a lot more energy and focus on just getting vendors, portal providers, MU2-attesting providers, and everyone still playing hide-and-seek with consumer clinical data to align with both the letter and the spirit of the law. Let consumers get electronic copies of their data in the app(s) of their choice — today.
With apologies to Dickens, I think I might be speaking for a few of the other orphans in the room when I humbly ask, “Please, sir, I want some more consumer-centric clinical data, now.”
Brian Weiss is founder of Carebox.
If I understand you correctly, your thesis is that we really don’t care what format the data is in, as long as we can get at it.
I wholeheartedly agree.
If you are using a modern NoSQL database, you really don’t have to do any ETL (extract, transform, load) on the data to load it, preserve its structure and make it available in XML or JSON or EBCDIC or whatever on the other side. One of the big problems is that the religion of normalization has become so ingrained that people just don’t trust, or worse, don’t know about the new schema-agnostic ways of storing data that save hundreds of thousands of hours of mind-numbing data modeling.
ETL is like a tax on data portability. If we can get rid of it, all that intellectual firepower that has been wasted on object-relational-mapping can be freed up for use in solving actual problems rather than shoehorning narrative data into rigidly defined rows and columns.
Great read – already looking forward to your next post!
This is very hard to read. The point of paragraphs is to group multiple sentences together for coherent flow of thought. This one paragraph per sentence thing is too distracting.
This is the funniest (and truest) thing I’ve read in a long time! Thanks so much!