Based on the feedback you provided via comments, those being so far:
@blunders we might have way more phone #s than email, and I'm having a
@blunders No, I believe a good deal of patients would have a phone
number in the chart. Home number more likely than cell/text number.
So, let me see if I'm able to dig myself out of the hole I made... :-)
First let me say, I know ZERO about HIPAA, though I did a quick Google for "HIPAA authentication" and while there appear to be general standards, there also appear to be no implementation specifications; or at least that I was able to find.
My take is that a patient is giving an address and phone number knowing that these channels of communication maybe used to pass medical information to them.
In real life if a nurse calls a number on chart, and the person answering says they're that person, the nurse will tell the person answering the phone the information they intended to only give the authorized person per HIPPA. On the same note, if the nurse discovers an issue with the phone number in the chart and is unable to reach the person by phone, they'll send out a notice to the address on file; opening up the chance that an unauthorized person will break postal laws, and open the information sent via mail to the address on file.
So, going on that, but again not knowing anything about HIPPA laws, case law, etc. related to authentication requirements my suggestion would be to use the number on record as the/an authentication layer done real-time knowing an end user just requested a code be given to that number that's on record in the database, either by SMS or an automated voice system.
A rough flow off the top of my head for a phone-to-web authentication system would be:
- The end user attempts to create an account.
- They enter the phone number(s) they believe are already tied to their records.
- The system checks to see if those numbers are in the database.
- If the numbers are not in the system, the user is told the other options; mail, in person, etc.
- If the numbers are in the system, the user is asked if they'd like a call or a text message sent to the number already in the system.
- The system excutes the request and the user gets the code via an inbound call/SMS to the phone they requested.
- Then the end user enters the code into a form on site site that's expecting the code from that IP/cookie session, and is validated as having access to the number on file.
A number of sites use phone verification and have FAQs on it. For example: Google and Craigslist ; though after a quick search was unable to find company that would have HIPAA oversight that uses phone verification to release records.
Also, guessing to start it'd be faster to outsource it to a service phone verification with an API, which again not knowing anything about HIPAA I'd think was fine as long as all they're doing is getting a number, passing the code back to you, and making the call.
Again, this is just me attempting to find a solution instead of just saying there is none. I'd welcome any and all feedback.
UPDATES BASED ON COMMENTS:
@blunders [...] As for phones, medical offices will generally not use
phones for anything more specific than "please call us back" without
requesting and receiving explicit approval to leave personal
information in a voice mailbox. At least that's the case with the 2 or
3 of my family's doctors where the question has come up. And when
you're at the point of clarifying phone permissions, you're at the
point (physical, live voice) of giving them the login info that
user3916 wants to pass anyway. – gowenfawr
@gowenfawr: [...] As for the "call us back"... when you call back, how
do they even know it's you. My guess is they just do that as a
professional form, than a level of authentication. – blunders