Stream: implementers
Topic: Is email guaranteed to exist in Patient object?
Abhas Arya (Dec 31 2020 at 06:27):
My app allows patients to authenticate using their Epic accounts (MyChart). However, is an email address guaranteed to exist within the Patient entity returned by Epic's API? Judging by these docs: https://fhir.epic.com/Specifications?api=931 it doesn't seem that this is guaranteed. I was hoping to represent patients in a database with an email address as a primary key, but can't do that unless email always will exist.
Frank Oemig (Dec 31 2020 at 09:37):
I would say that patient.telecom is mustSupport, also with emails in their example. But from the specs I cannot tell whether email will always occur. Since that belongs to an individual to provide that I would not trust in the existence.
@Amit Popat ?
Amit Popat (Dec 31 2020 at 09:42):
A lot of folks don’t have emails or don’t want to share emails with providers. Someone that is using a MyChart account has a higher likelihood of having an email, though I’m not sure that is guaranteed since as a patient I have all the right to not provide my email to my physician office. @Cooper Thompson , any additional thoughts?
Frank Oemig (Dec 31 2020 at 10:15):
Thanks @Amit Popat this is what I meant.
Cooper Thompson (Dec 31 2020 at 23:55):
Also, many patients may share an email address. My parents just have one email they both use. Also, pediatric patients (especially newborns) very likely won’t have their own email. If they have one on file it would be their parents.
Cooper Thompson (Dec 31 2020 at 23:56):
I’ve dealt with systems that used email as a primary key and it was a disaster. I’d recommend against it.
Cooper Thompson (Jan 01 2021 at 00:00):
And lastly, the user that logs in to MyChart and is using you app may not be the patient. They could be a caregiver or parent of the patient who has proxy access. And multiple people may have access to the same patient (e.g. mom and dad both have access to their kids records).
Frank Oemig (Jan 01 2021 at 09:14):
IMO, a primary ID should always be internal. But you can - and should - associate as many details as possible.
And what about switching an email address...
Last updated: Apr 12 2022 at 19:14 UTC
