Formalize 'mailto:' format in 'href' field

[fschiettecatte]

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:

• ‘mailto:[email protected],[email protected]’

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]

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

[Relequestual]

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

[fschiettecatte]

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]

@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]

@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]

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]

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 < ***@***.***> 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 <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOf2_I_JfZKTqtYCJn5u4JUnQ2lfQM_Xks5smW9egaJpZM4PkYZt> .

[Relequestual]

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.