IHE-Profile-Proposal-Brief_2009-2010_Federated-Directory-Service-v06

Document Sample
IHE-Profile-Proposal-Brief_2009-2010_Federated-Directory-Service-v06 Powered By Docstoc
					                        IHE Brief White Paper Proposal – 2009-2010
   Integrating the
Healthcare Enterprise


  This document is the first step in the IHE annual planning cycle. Interested persons and organizations are encouraged
  to submit proposals for consideration. In Step One, Brief Profile Proposals are collected and reviewed. If a proposal is
  accepted for further consideration, the profile submitter will be asked to complete a second more detailed document for
  further Committee review. We ask that this Brief Profile Proposal not to exceed two (2) pages in length. Thank you
  and please direct questions to secretary@ihe.net or to the primary Planning Committee point of contact as listed in the
  Call for Profiles email that included this document. Completed proposals should be sent to the Domain Planning Co-
  chairs as listed on the Call for Nominations email; please also cc: secretary@ihe.net. Thank you for your interest and
  support of IHE.


                                          Federated Directory Service (FDS)
             Proposed Profile
                                          Raik Kuhlisch, Jörg Caumanns (Fraunhofer ISST)
    Proposed Editor
                                          11. Oct. 2009
    Date
                                          0.2
    Version
                                          IT Infrastructure Technical Framework
    Domain



                 The Problem              <Summarize the integration problem. What doesn’t work, or what needs to work.>
    Co-operation in healthcare demands the ability to exchange attributes of the acting partners. For instance, a physician who is
    going to admit a patient to a hospital might need the address of the hospital (e.g., e-mail), its digital certificate (e.g., for
    encrypting the referral letter), and the OID of the responsible department (e.g., for granting access for a health record). This
    holds as well for intra-domain as for inter-domain co-operation scenarios. In today’s health care IT, local (intra-enterprise)
    directory services are well established and used. However, since the provision of health care is often not localized to one
    enterprise and involves a potentially high number of different enterprises, a mechanism is required to address and retrieve
    objects and their attributes from all involved partners. Therefore, means need to be provided in order to extend the local intra-
    enterprise and intra-domain functionalities to fully address federated healthcare domains (e. g. XDS affinity domains). This
    should happen in a way that any healthcare organization is able to manage its own directory in order to ensure high accuracy
    at low operational costs.
    Demands for a respective solution have been expressed by the German electronic Case Record consortium, the Austrian
    electronic health record task force (ELGA), and by a preliminary study on the future Swiss national healthcare infrastructure.
    iSoft and ISPro announced to support editing work with experts and are highly interested in a pilot implementation.




                                          <Describe a short use case scenario from the user perspective. The use case should
                Key Use Case              demonstrate the integration/workflow problem.

    OID Query: After a surgery a hospital sets up an electronic case record for a patient. The hospital, the patient’s family doctor
    and the referring specialist should be granted access rights. In order to generate the respective security access policy, the
    hospital’s administration needs to know the identifiers (e.g., OID, certificate serial number) of participating physicians.
    This use case reflects one of the major practical problems for health record infrastructures that build upon policy based access
    control (e. g. electronic Case Record, and ELGA). Recently, all participating actors of the regional healthcare network have to
    be registered with a single, central directory service (There is no business model on how this central directory service can be
    kept up-to-date.).
    Address Resolution: The cardiologic department at a hospital prepares a discharge letter that is to be posted to the patient’s
    family doctor. When searching for the doctor’s address, the administrative staff recognizes that the hospital information
    system, the CRM, and the SAP administrative system keep different addresses for a person with the same name.



  Template v2.01 – June07                                                                                       Printed: 5-Apr-12
             [Brief] Profile Proposal                                                                               Page 2




                                        <Describe a short use case scenario from the user perspective. The use case should
         Key Use Case                   demonstrate the integration/workflow problem.

 Contact Data Query: While prescribing a medication with high risks for side effects, a physician consults the patient’s
 medication record. He recognizes that another physician prescribed the same medication two years ago but the patient cannot
 remember so. He wants to get in contact with this physician. All the information he can get from the medication record is the
 physician’s name, profession, and OID.
 Certificate Retrieval: National regulations in many European countries require that an electronically transmitted doctor’s letter
 is encrypted in a way that only the identified receiver is able to decrypt it. In order to encrypt the letter, the sender has to
 discover the encryption certificate of the receiver.
 Yellow Pages Query: A patient is to be referred to an endocrinology specialist for an urgent lab test. The referring physician
 needs to get the contact data of close-by endocrinologists departments in order to ask whether one of them can perform this
 test in their own lab.



    Standards & Systems
 The following standards and technologies should be considered.
         The underlying directory services should be based on LDAP to allow for a standardized querying language of the
          directories, since LDAP-directory-services are widely-spread in organizations.
         DSML v2 should be used for phrasing directory queries. It is widely supported by a range of common directory
          servers and it is easy to use in conjunction with web services standards.
         The principle of the Federated Directory Service should be aligned to the ideas described in the Cross Community
          Information Exchange White Paper.
         The opportunity of an (optional) EIS-interface should be considered.
         The means of ATNA should be used in order to provide basic security, recommendations for finer grained access
          control (XUA profile, IHE White Paper on Access Control) should be given



           Discussion
 The FDS White Paper is aimed at defining a solution for interconnecting existing intra-domain directory services in order to
 allow users to issue cross-domain search requests for subject data (e.g.,attributes related to healthcare professionals,
 hospital departments, and e-Health services). By using the DSML standard as an interface for federated directory gateways,
 existing LDAP and DSML directories can be linked. This allows for a seamless migration of PWP and future IHE ITI directory
 profiles from local services to cross-domain services. As DSML can be bound to SOAP, the proposed technical solution is in
 line with the ITI SOA strategy and can be used in conjunction with ITI’s transferable authentication claims (XUA) and
 authorization means (recent white paper on access control). This would result in a consistent infrastructure of domain
 services that can be used by specific healthcare applications.
 The FDS approach for networking directory services has already been proposed for the last IHE ITI cycle but was rejected
 because of complexity and technology risks. During the last year Fraunhofer ISST launched a diploma thesis on this issue
 together with the Free University of Berlin to investigate on existing approaches and possible standards based solutions. A
 solution on LDAP and DSML v2 has been implemented as a proof-of-concept. This prototype will be integrated with the
 electronic Case Record framework to demonstrate the seamless integration with typical cross-domain health record use
 cases.




    <This [Brief] Profile Proposal must not exceed 2 pages in length>




Template v2.01 – June07                                                                                     Printed: 5-Apr-12

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:4/5/2012
language:English
pages:2