IHE Profile Proposal (Short) by Joshreed

VIEWS: 6 PAGES: 2

									IHE Profile Proposal (Short)
1. Proposed Profile: Federated Service White Pages (FSWP) Proposal Editor: Andreas Kassner (IHE Germany), Jörg Caumanns (eCR Consortium) Date: 02.09.08 Version: 1.3 Domain: IT Infrastructure Technical Framework 2. The Problem
Federated medical organizations provide electronic services for each other. Speeded up by the ongoing activities in electronic health cards in many European countries there will soon be a vast diversity of health resources offered by insurance companies, hospitals, regional health networks, etc. For both - resource users and resource providers - this leads to two closely related problems: – Resources must be located (e. g. by autonomous services). Especially in federated scenarios it is not sufficient for a service to know that a requested resource exists at a certain node. Further information like resource identifiers and security policy requirements must be acquirable. A strict standardization of all of these attributes for each resource type is not sufficient as this would prevent a provider from running his own security and administration policies. Services and nodes must be trustworthy. This can best be verified by using credentials (e. g. certificates) which are stored in an adequate directory (i.e. LDAP). From both an operative and a cost perspective a solution where providers are able to maintain their own credentials are to be preferred.

–

For ensuring the independency of each organization within a federated healthcare network and for keeping operative costs low it is important to avoid centralized directory services. As a consequence of denying centralized directories, each organization must maintain information on its resources (e. g. nodes, services, and certificates) in its own directory and provide them in a standardized way. This proposal requests a profile which provides access to directory information on eHealth resources.

3. Key Use Case
A patient has got a personal health record that is provided by a regional healthcare network which makes use of the XDS.b integration profile. A resident physician who wants to place a new medical document into the record uses the ProvideAndRegister transaction on one of the network’s XDS DocumentRepository actors. Even though both nodes are secure nodes in the sense of ATNA the physician providing the data cannot be sure that the remote node really is the desired document store as long as he cannot verify that service’s credentials. Using the proposed integration profile his IT system could first retrieve the service’s node certificate from the provider’s trusted service directory and then establish an ATNA session by verifying that the remote node is the holder of this certificate.

4. Standards & Systems
Like the PWP profile, the requested profile should be based on existing directory standards. Web service standards should be used for trust establishment and communication (e. g. by further profiling the Web Services profile of the HL7 v3 Transport Specification). A mechanism should be defined for linking directory services in a peer-to-peer manner such that a service can retrieve information about remote resources without having to know the addresses and certificates of all service directories. It should be described how this profile can be used in conjunction with ATNA node authentication and higher layer service authentication mechanisms. The distribution and trust mechanisms specified for the proposed profile should be applicable to PWP as well without changes in the already defined transactions. The use of DSML and / or SPML should be considered.

5. Discussion
IHE specifies a profile for personnel white pages (PWP) which is not adequate for information on other resources than employee attributes. Especially requesting service credentials and policies is a common task though. ATNA only allows for node authentication while there often is a requirement for service authentication as well (e. g. in conjunction with SOAP and WS Security). Even though there recently is no integration profile for service authentication and transportation security a profile which solves the problem of trust establishment in federated environments is a prerequisite for any further development in this area. A concrete application area is the German electronic Case Record (eCR) specification, where a completely decentralized architecture was a demand from all participating co-operation partners. It is to be discussed whether other eHealth co-operations identified similar requirements, e. g. in order to link already existing regional networks.


								
To top