OK, I'm boing to break this down of why I think we're letting patients down while probably boosting profits for vendors. And yes I'm a bit worked up. A 🧵 1/
https://twitter.com/HITpolicywonk/status/1572669732490465280
First, why do we care? B/c the promise of #TEFCA is that as an individual I can use an app and search for my data across all of my docs and not have to know their name or my username/password. MUCH better than we have today for patients and the whole point of a network. 2/
For individual access, patients have to be ID proofed to NIST IAL 2 by a certified CSP. All very reasonable and a much higher bar (in a good way) than we have today. 3/
During proofing a set of demographics are verified by the CSP & tied w/ the identity. You can only use verified demographics for matching to ensure you're not giving demographics for someone else. Still very reasonable policy. 4/
These verified demographics can be included in a SAML assertion today to then be used for matching w/ the token saved so it can be audited at any time. In the SOP item 2a lists the dems you must use to match the patient, a reasonable list that can all be verified by a CSP. 5/
2b lists demographics that you should use and includes some demographics that cannot be verified by a CSP (like sex and SSN) or for some like MRN can't be verified without the CSP connecting to an EHR vendor to verify it (this is where profits start to come in) 6/
2a and 2b don't read as unreasonable on their own, but then you get to #5 in the SOP. Initial read was great! They have to respond. BUT there's this one little phrase in there: based on responder policy. 7/
Based on workgroup convos, a # of us assumed this phrase was referring to match %s, so you can set a 100% match requirement for indivdiual access (a reasoanble policy). BUT now we're learning that it goes beyond the match %. 8/
It means those Shoulds in 2b can be made Musts by the data holder. So if the data holder requires it, you would have to have a CSP who can verify SSN (nearly impossible). OR a CSP who can fork over the $ to connect to EHR vendors to verify MRN. 9/
So if I just don't want to release data, I set the demographic bar so high a CSP can't meet it. Or if I want to generate new revenue, I set the bar so a CSP has to connect to my EHR and pay for the privelege. 10/
The data holder could also require a new signed token on every transaction, something that only sortof exists and will take who knows how long to bake into standards. So again, a data holder can delay this from happening. 11/
Alternatively to not delay implementation, we go w/ trust but audit. I trust that the demographics you sent me were verified but I can always audit you to find out. 12/
The reasoning on the token is ostensibly privacy/security related, i.e. we can't trust some app that was developed in my second cousin's nephew's garage even though they've signed the same contractual agreements and I could audit them whenever I want. 13/
Personally, I find this argument weak. The entire point of a trust framework and a network is that we've all agreed to the same rules so I will trust you even though I don't know you. Why have an agreement if some participants are 2nd class citizens? 14/
So where we're at is the appearance of indivdiual access with no real individual access, which is where we've been with OAuth and FHIR for years. Just ask the patient apps folks, OAuth + FHIR is not working for patients. 15/
ONC is the only org that could change this. The industry will not do this on their own b/c it doesn't benefit them. I thought #TEFCA would do it. I spent more than a year working on it so it could do it, so this is fairly disappointing. 16/
If folks have ideas on how this could get fixed to enable IAS within the next year w/o needing a username and password for every one of my docs, I'm all ears, unless you want to tweet at me that we need an entirely different framework yada, yada, yada (you know who you are) 17/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
