Attribute for the Direct address

[dcsillag....@gmail.com]

I'm looking for which attribute in the HPD schema should contain the Direct address(es) for a given HCProfessional/HCRegulatedOrganization.  HCProfessional has an attribute named 'mail' which is (according to table 3.58.4.1.2.2.2-1, bottom of page 49): "Intended for general purpose email communication".  Though there is also the bit in HPDElectronicService's hpdServiceAddress attribute which says "The electronic service address possibly in URI or email address form".  Now HCRegulatedOrganization doesn't appear to have this 'mail' attribute, and so I've assumed it's the latter.  Is this correct?

Drew Csillag
MedAllies

[Greg Carver]

I haven't seen anything terribly firm on the subject, but my preferred interpretation is that "mail" should be a standard smtp mail address, not a direct address.

This leaves encoding direct address as an electronic service, which you note is vaguely defined in the IHE HPD spec.  One place you could turn are some proposals from InteropWG.org:

http://www.interopwg.org/Statewide%20Send%20%20Receive%20Technical%20Specifications%20Appendix%20-HPDPlus%20Implementation%20Guide_v1.pdf

Sections 2.2.1 and 2.2.2 provide guidance, and provide actual samples of an electronic service filled out at the end, eg:

DN:hpdServiceId=1,ou=Services,dc=hpd,dc=org

objectClass: top

objectClass: HPDElectronicService

hpdServiceAddress:dire...@direct.com

hpdServiceProtocol:SMTP

hpdServiceType:Direct

hpdServicePayload:CCD^PDF

hpdServiceId:1 

It's worth noting this documentation is based around HPDPlus, which was an offshoot of IHE HPD, so the schema's may not 100% align.

--
You received this message because you are subscribed to the Google Groups "ihe-hpd-implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-hpd-implemen...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Carver]

There is also this example from the pdti project:

https://github.com/siteadmin/pdti/blob/a3fb8d230e069be0c4dc9d9e6bb9d2d74f1d21bc/pdti-ldap/src/test/resources/META-INF/ldap/data/hpd_plus_test_data_1.ldif#L335

dn: hpdServiceId=4,ou=Services,o=dev.provider-directories.com,dc=hpd

objectClass: top

objectClass: HPDElectronicService

hpdServiceAddress: thomas...@direct.service1.com

hpdServiceId: 4

hpdCertificate: MIICqjCCAZKgAwIBAgIJAMd5Vfs3Eo6kMA0GCSqGSIb3DQEBBQUAMA0xCzAJBgNV

 BAMTAm1rMB4XDTEzMDUwMjE0MzMyNVoXDTIzMDQzMDE0MzMyNVowDTELMAkGA1UE

 AxMCbWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGHnk7g0gS4JmD

 s1mNjsHFFEMuHmTtIvIPWbjsnbZRcy4teJE4D5/EShMQiOaujNO1mg6ib4hnEXPQ

 9q1sQhFg/5lC0Xwq3LGy7t9NlmRjrNKxejCYE04QptAK5vGg8dK3jcsfMEmHHxoo

 nx38HpC24PvTJgY+efwBxTDQrZu3rMw2Jr/QERT6pbQEZbpsr0+ZizLv2C/mweE6

 2pGcKCA2WEffetL+qtoN3RWWagxSYx/jjJdT6UGn3KLEhoNSVm6LidmbKx4AwAys

 YjfOPF8m06pF0khTlXMLyw6LyKwUYMpHSRmmlA6tyjUAsF9Cy+hY4VLPWXaNK6ru

 zH+s5BBHAgMBAAGjDTALMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEFBQADggEBABPF

 45byPxZ9z78YBPE6IbYkxuY1dEt05ZP5YsKS76M7m9OYUryaPcWvt1ctdV2oJbJ+

 9vEVwDOKxD6gkLd1oIsw2nD9U3YYtHrcej2ytw3XcA+okzUoNVPblGTUSF7dMuc3

 MyQPhnIt6iOZKuzRDG1Ruk4XHyXHc1sngsHp/THKsCjz+rZlgjlX4iatPAhz30Fn

 BVZ7UVeAKftcDwpBdggJxvEAoEGvRpm7X8OlqQI2jmm/Oxlw70mjCZTzJFtOFOJf

 homCEiQXSz/4tobOgw66ooBNWUd7f5MfAhquBV2/kDK5bnbOGJ30vzHBj9CUf8tT

 flVoSO0cwbuGBddusEU=

hpdIntegrationProfile: DirectProjectSMTP

hpdContentProfile: C32

[Moehrke, John (GE Healthcare)]

Hi,

 

It has been a while since I worked on the Direct spec, and you likely would get a better answer on the direct mailing lists.

 

My understanding is that the direct email address is treated simply as an email address. So yes, it would be found in the email element. It is differentiated because you can find a certificate with that email address, where the certificate meets the requirements of Direct including chaining to a valid trust anchor. This second step is critical, regardless of where you find the email address. It doesn’t matter if a custom element holds the email address or if it is treated as just any other email address, the only way to know that it truly is a Direct address is to find a certificate that qualifies.

 

John

[Greg Carver]

So you would advocate for using mail + userSMIMECertificate to store direct address info?  Since since both fields are multi- I'm not clear how you would disambiguate which certificate belongs to which mail account.  Surely they're not interchangeable, so you need to communicate the pairing precisely.

Also, to Drew's question this would only work for individual providers since organizations don't have a mail attribute available.  In the interest of consistency for hpd clients, I think the simplest answer is to always pair direct addresses+certificates into the hpdelectronicservice tree.

The spec says "mail" is "intended for general purpose email communication".  I'm inclined to say since a specific certificate is required to communicate with it, we left general-purpose territory.

[Moehrke, John (GE Healthcare)]

Again, you are asking a US Realm question (Direct and S&I Framework), on an International mailing list (IHE)… You might get better results by referring to Direct specifications, and addressing the Direct community. The questions you are asking are not HPD questions.

 

Then again, the Direct specifications are not much help here. Direct seems to not have completed any formal documentation of the LDAP model. But I do see that their reference implementation have release notes that indicate the use of userCertificate, not userSMIMECertificate. It is possible that the format of UserCertificate is more appropriate.

 

yet the S&I Framework, which I thought took over for “The Direct Project” ; has  a document

http://wiki.siframework.org/file/view/Certificate%20Discover%20for%20Direct%20Project%20Implementation%20Guide.pdf

see page 10…

 

You must pull each cert found in userCertificate and read the content. Most likely there is only one… But YES, you must have certificate manipulation capabilities. Which you must have anyway, as there is no way to do Direct without it.

[Eric Heflin]

Hi Drew/all.  I think we need to create a draft US National Extension clarifying this and other issues related to how we will use HPD in the US.  In this case I think we need a way to discern between a Direct email address and other types of email addresses.   Does that make sense to you?

--

[Drew Csillag]

That makes sense to me. 

Also, FWIW, Greg's interpretation appears to match mine.  In the case of HPDElectronicService, since there is the attribute hpdIntegrationProfile: DirectProjectSMTP, this would seem to be the way that we detect a Direct address vs. some other flavor of email address, though I don't know if DirectProjectSMTP, as a value is in a spec anywhere, or if it's just a convention embedded in the original HPD test data.

[Greg Carver]

John:

I'm not sure why you think this is the wrong forum to address the question.  This is about how we IHE HPD implementers  like IHE HPD to encode Direct addresses.

Thanks for the link to Direct certificate discovery guide. That clarifies they have simply invented their own solution (which of course is their prerogative).  It's use of ldap appears in no way compatible with the IHE HPD specification.  If Direct wants to propose a standard that fits within the confines of IHE HPD great, but I don't hear them talking about that, so we're still back to the original question.

Eric:

Someone needs to propose a common approach. I'm less concerned about who sponsors the spec, or even what the conclusion is, just that we all decide on something -- for the sake interoperability and all that.

Drew:

The IHE spec just says values for hpdIntegrationProfile and hpdContentProfile are "defined through local configuration". Perhaps this is where a US National Extension like what Eric is suggesting would come in.

[Moehrke, John (GE Healthcare)]

Well, Direct and S&I Framework predate the work on HPD… so you can’t say they didn’t follow HPD, it is more like HPD didn’t follow them…

 

I would advocate against inventing a new way to do this. It is already hard to get off-the-shelf solutions to work with Direct. Further specialization for Healthcare and Direct simply makes it harder to implement. Unless that is your goal.

 

If there was a National Extension, then yes this would be the place to document it… but as indicated these two specifications have never been very well aligned. This in spite of great effort by Karen and others to try to keep them aligned.

 

John

 

From: ihe-hpd-im...@googlegroups.com [mailto:ihe-hpd-im...@googlegroups.com] On Behalf Of Greg Carver

Sent: Wednesday, April 01, 2015 1:30 PM
To: Drew Csillag

[matthew...@esacinc.com]

Hello. I worked on the PDTI project (link to the github project above), which understood the hpdServiceAdress to be the place where a Direct address would go. In fact, any electronic service address would go in there, whether it is a Direct address, a CONNECT endpoint, or anything else. That is why it is a URI. The mail attribute for individual provider/HPDProvider is an artifact of the LDAP underpinnings of the data model (it comes from the LDAP InetOrgPerson and how the HPDProvider was built up from existing LDAP objects) and was not intended to hold the Direct address. Both Organizations (aka HPDOrganization) and Individuals (HPDProvider) can own Direct addresses (as noted above) and the HPDElectronicService object holds that information, and this is why both of those provider objects point to any number of HPDElectronicService objects.

The Certificate Discovery IG was also mentioned. The Direct Cert Discovery process is completely separate from getting certificates and endpoint information in HPD. In Cert Discovery, one must already know the direct address to which they wish to send information. Direct Cert Discovery was designed to be a process by which one could find a public key certificate by knowing ONLY the Direct address, and not other demographic information 

HTH, Matt

[nagesh....@drajer.com]

Here are my two cents:

Direct was designed to work without requiring implementers to implement HPD Schemas/attributes in their LDAP (in case they use LDAP to publish directaddresses/certs), hence their reference to LDAP mail and userCertificate attributes.

Also in the context of HPD we are discussing relationships between orgs/individuals which can be used to identify an individual's electronic address (i.e direct ) at an organization following the schema of HPDProviderMembership / HPDElectronicService address as mentioned in this thread. This contextual information however is not addressed by Direct, where the recipient's Direct address is discovered/known out of band and the relationship between the individual and organization if known to the sender is not leveraged as part of the electronic communication.

So I think we are really left with supporting both unless we want all Direct implementers to implement HPD schemas for their backend to store addresses/certificates. (which wont happen, because remember they may just use DNS for certificate discovery). However we could make a National Extension proposal saying something like the HPD implementation capturing direct addresses should capture it in both places to ensure compatibility between Provider Information Consumer actors and the Direct actors.

Finally we should propose changes to HPD as a CP , If we need to add missing attributes (mail, orgcertificate) to HcRegulatedOrganization to keep these 2 different specs aligned. 

[Karen Witting]

When HPD was developed the Direct email address was meant to go into hpdMedicalRecordsDeliveryEmailAddress.  Then when HPDPlus was born we adopted their approach as well.  And Direct chose their own way, so now you have three ways, two supported by HPD and one by Direct.  Hopefully everybody knows this all but just figured I’d put in my tiny 2 cents on it.

 

From: ihe-hpd-im...@googlegroups.com [mailto:ihe-hpd-im...@googlegroups.com] On Behalf Of Greg Carver

Sent: Tuesday, March 31, 2015 1:54 PM
To: Drew Csillag

[Alan Viars]

Should there be an OID defined for this? 

Alan Viars