Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fschiettecatte opened this issue Sep 26, 2017 · 8 comments
Open

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

fschiettecatte opened this issue Sep 26, 2017 · 8 comments
Milestone

Comments

@fschiettecatte
Copy link
Contributor

fschiettecatte commented Sep 26, 2017

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
Copy link
Member

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

@Relequestual
Copy link
Member

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

@fschiettecatte
Copy link
Contributor Author

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
Copy link
Member

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

fschiettecatte added a commit that referenced this issue Sep 26, 2017
Update for supporting multiple email addresses in the `email` field, see issue #148 .
@fschiettecatte fschiettecatte added this to the v1.2 milestone Sep 26, 2017
@jxchong
Copy link
Collaborator

jxchong commented Sep 26, 2017

@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
Copy link
Contributor Author

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
Copy link
Collaborator

harindra-a commented Sep 27, 2017 via email

@Relequestual
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants