search

ga4gh / mme-apis

Documentation for the MatchmakerExchange APIs
https://github.com/ga4gh/mme-apis
34 stars 19 forks source link

Formalize 'mailto:' format in 'href' field #148

Open fschiettecatte opened 6 years ago

fschiettecatte commented 6 years ago

We need to formalize the 'mailto:' format in the 'href' field. 'mailto:' as specified only supports one email address, however some sites are currently overloading this to include multiple, coma-delimited, email addresses, for example:

We should formalize this in a 1.2 release so that the spec reflects the reality in the field.

(See Issue #128 for background information)

Relequestual commented 6 years ago

mailto: already supports multiple emails, delimited by comma. The problem (as I understand) the new email field only supports a single email address.

Relequestual commented 6 years ago

By using a mailto: link, you're implying https://tools.ietf.org/html/rfc6068

fschiettecatte commented 6 years ago

Right you are, I did not check the RFC on this, only the Wikipedia page.

So I would amend my original suggestions, making email address comma-delimited feels icky, I would suggest we use an array for multiple email addresses.

Relequestual commented 6 years ago

@fschiettecatte Sounds like a plan.

@jxchong in your use case, would you want to group emails by type of contact? I fully expect we wouldn't want to show patient emails in our system, but we may consider providing the clinicians emails if provided.

Looking at the specification, I think contact assumes a single person, which is why we have a single name. I was about to suggest grouping the emails by role, but the role of the person is already defined in the same objet.

name : The human-readable name of the person or organization that the user is contacting with the provided URL.

roles : A list of roles of the contact person.

I think that means we can't really do what's being proposed in 1.x without causing confusion.

I think we HAVE to wait for 2.x, and turn contact into an array.

Thoughts?

jxchong commented 6 years ago

@Relequestual we could group emails by type of contact in the future but it's not so critical right now since patient-initiated requests aren't allowed over MME for policy reasons anyway. I think it's more important to just have some sort of supporting for providing multiple email address that belong to clinicians so that if there's one lead clinician + geneticist + lab scientist, they can all be included in any correspondence.

fschiettecatte commented 6 years ago

One way to handle this would be to turn the contact into an array and designate the first one in the array as primary contact. I would also be tempted to redefine the href as a bona-fide http|https url and the email to a single email address.

The scheme we are proposing for 1.2 is because we have only one contact.

harindra-a commented 6 years ago

I like François's idea of making "contact" into a list/array, though not crazy about implicitly defining the first on the list as the primary. Preferably we would have a "primary" boolean field in the contact-entry object that can be set to "true" when such?

Yeah, redefining href as a bona-fide https/http and email to a single email makes perfect sense when we switch to above design of contacts.

Best, Harindra

On Tue, Sep 26, 2017 at 5:40 PM, François Schiettecatte < notifications@github.com> wrote:

One way to handle this would be to turn the contact into an array and designate the first one in the array as primary contact. I would also be tempted to redefine the href as a bona-fide http|https url and the email to a single email address.

The scheme we are proposing for 1.2 is because we have only one contact.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ga4gh/mme-apis/issues/148#issuecomment-332344506, or mute the thread https://github.com/notifications/unsubscribe-auth/AOf2_I_JfZKTqtYCJn5u4JUnQ2lfQM_Xks5smW9egaJpZM4PkYZt .

Relequestual commented 6 years ago

One way to handle this would be to turn the contact into an array...

Essentially, this is what I was thinking too.

Preferably we would have a "primary" boolean field in the contact-entry object that can be set to "true" when such?

This sounds OK, but I expect we would always want to show all clinicians (or email all clinicians) associated with the patient. For DECIPHER, we only allow for one user to be a clinician for a patient.