Federated Directory Services Brief Profile Proposal for 2009/10 presented to the IT Infrastructure Planning Committee J. Caumanns, O. Rode, R. Kuhlisch, FHGISST 07 October 2009

IT Infrastructure Planning Committee The Problem Physicians spend 20% of their time searching for informationPhysicians spend 20% of their time searching for information... so do their information systems... so do their information systems –the patient wants to authorize Dr. Meier, what’s the OID to put into the policy? –the PDQ request must be encrypted for privacy reasons; what is the public key of the respective service? –now that I’ve got the OID of the repository, what’s the URL? –the patient was referred to the cardiology at Charite. What’s the -Address to send them the latest lab results? –Dr. Meier informed me on his new phone number. How can I ensure that all departments update their files respectively?

IT Infrastructure Planning Committee Use Case With all distributed EHR systems we have the problem ofWith all distributed EHR systems we have the problem of –technically linking the logically decouples pieces –retrieving certificates of services and persons –discovering appropriate IDs to write into policies Challenge:Challenge: –link a new repository with a registry and make its address and certificate known to all users –assign a permission to a hospital department –discover authentic and up-to-date contact data for a certain person

IT Infrastructure Planning Committee Federated Directory Services

IT Infrastructure Planning Committee Integration of Directory Schema

IT Infrastructure Planning Committee Sample: Find Service URL by OID

IT Infrastructure Planning Committee Sample: Client -> local FDS ###### # REQUEST FROM (FDS Client, Heart Inst.) TO (FDS, Heart Inst.) ###### <searchRequest dn="ou=Services,o=Charité,c=de,dir=IHE Service WP,dom=Charité" scope="singleLevel" scope="singleLevel" derefAliases="neverDerefAliases"> derefAliases="neverDerefAliases"> </searchRequest>

IT Infrastructure Planning Committee Sample: Local FDS -> Domain FDS ###### # REQUEST FROM (FDS, Heart Inst.) TO (FDS, Charité) ###### <searchRequest dn="ou=Services,o=Charité,c=de,dir=IHE Service WP,dom=Charité" scope="singleLevel" scope="singleLevel" derefAliases="neverDerefAliases"> derefAliases="neverDerefAliases"> </searchRequest>

IT Infrastructure Planning Committee Sample: Domain FDS -> Domain LDAP ###### # REQUEST FROM (FDS, Charité) TO (directory, IHE Service White Pages ) ###### <searchRequest dn="ou=Services,o=Charité,c=de" scope="singleLevel" scope="singleLevel" derefAliases="neverDerefAliases"> derefAliases="neverDerefAliases"> </searchRequest>

IT Infrastructure Planning Committee Sample: Domain FDS <- Domain LDAP ###### # RESPONSE FROM (directory, IHE Service White Pages) TO (FDS, Charité) ######<searchResponse> VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4= VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4= </searchResponse>

IT Infrastructure Planning Committee Sample: Local FDS <- Domain FDS ###### # RESPONSE FROM (FDS, Charité) TO (FDS, Heart Inst.) ######<searchResponse> <searchResultEntry <searchResultEntry dn="cn=RecordRegistry,ou=Services,o=Charité,c=de,dir=IHE Service WP,dom=Charité"> dn="cn=RecordRegistry,ou=Services,o=Charité,c=de,dir=IHE Service WP,dom=Charité"> VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4= VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4= </searchResponse>

IT Infrastructure Planning Committee Sample: client <- Local FDS ###### # RESPONSE FROM (FDS, Heart Inst.) TO (FDS Client, Heart Inst.) ######<searchResponse> <searchResultEntry <searchResultEntry dn="cn=RecordRegistry,ou=Services,o=Charité,c=de, dir=IHE Service WP,dom=Charité"> dn="cn=RecordRegistry,ou=Services,o=Charité,c=de, dir=IHE Service WP,dom=Charité"> VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4= VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4= </searchResponse>

IT Infrastructure Planning Committee Proposed Standards & Systems DSML v2 to query (LDAP) directoriesDSML v2 to query (LDAP) directories –LDAP2UDDI adaptors available from industry IHE PWP as basis and referenceIHE PWP as basis and reference –RFC2798 (inetOrgPerson), RFC2256 (X500 user schema) IHE ATNA for FDS AuthenticityIHE ATNA for FDS Authenticity IHE White Paper on Cross-Community Information ExchangeIHE White Paper on Cross-Community Information Exchange Alternatives to discuss (in January....):Alternatives to discuss (in January....): –OMG IS (former EIS) –UDDI

IT Infrastructure Planning Committee Scope of the Profile Upper Directory Tree structure (more or less implied)Upper Directory Tree structure (more or less implied) Client and P2P query transactions (DSML v2)Client and P2P query transactions (DSML v2) Registration of FDS for a certain domainRegistration of FDS for a certain domain security issues (mainly ATNA)security issues (mainly ATNA) Schema forSchema for –Services (Vasil‘s Profile Proposal) –Organisations –Personnel (should be PWP)

IT Infrastructure Planning Committee Discussion Editor: Fraunhofer ISSTEditor: Fraunhofer ISST Editing support by: Swisssign, ELGA, iSoft, ISProEditing support by: Swisssign, ELGA, iSoft, ISPro Estimated Effort: MediumEstimated Effort: Medium Prototype implementation as “proof of concept” at Fraunhofer ISSTPrototype implementation as “proof of concept” at Fraunhofer ISST integration with eCR v1.4 (2010) planned and agreed with industry; deployment into running eCR pilot projects and running networks late 2010integration with eCR v1.4 (2010) planned and agreed with industry; deployment into running eCR pilot projects and running networks late 2010