1. IHE Profile Proposal: Dynamic Configuration Management October, 2013

2. 2  Configuration of diverse devices in a clinical environment is often a costly and time-consuming process  Configuration related issues are a frequent cause of real-time interoperability issues which can cause significant down-time  With the increased number of participating devices as well as expanding environments, it is becoming increasingly challenging for systems to participate effectively by indentifying other participating devices in the environment  This presentation discusses an approach to simplify configuration management, avoid manual intervention and reduce the time invested on configuration changes in a complex interconnected environment  The approach proposed in this presentation was presented at SIIM 2012 and the feedback received has been incorporated into the solution Dynamic Configuration Management: Background

3. 3  Key Configuration Challenges:  Require the configurations for all participating actors in the environment to be maintained locally  Changes in configuration are not propagated across the environment  New systems in the sharing environments are not able to immediately interact with other participating actors Dynamic Configuration Management: Current Challenges Further Challenges for Mobile Devices:  Requires a significant configuration footprint which restricts ease of use  Requires devices to maintain a state as opposed functioning in a stateless mechanism Overall, the current environment does not support the concept of a plug and play which enables new systems introduced into the environment to start participating effectively

4. 4 Dynamic Configuration Management: Environment Configuration Image Document Source: 1.DICOM 2.WADO URL 3.RAD-69 Server Image Document Consumer Document Repository: 1.Repository OID 2.URL XDS Registry: 1. URL ATNA Server: 1.IP 2.Port PIX Manager: 1.PIX Manger IP 2.Port XDS-I Actors PIX/PDQ Actors ATNA Actors  The diagram below outlines the typical configuration information required for systems to participate in an environment which implements the XDS-I, PIX and ATNA IHE profiles

5. 5  There are some market based solutions available which provide custom implementation for addressing configuration challenges by providing a Gateway  Ideally, this functionality should be supported as a part of the ITI Technical Framework to allow vendors to conform to a standard mechanism for sharing configuration information  The proposed solution ensures that existing sharing workflows are not impacted for systems which have the ability to support and maintain static configurations  An IHE profile which defines the transactions for sharing configuration information through a well-defined set of actors and transactions will help address some of the challenges faced.  Conceptually, it is similar to the PIX profile which provides a centralized actor for reconciling patient IDs Dynamic Configuration Management: Proposal

6. 6 Dynamic Configuration Management: Sample XDS-I Workflow

7. 7 IHE Profile Requirements  In order to support a framework for managing device configurations, the profile should outline the following:  A transaction which allows an actor to register their configuration Define a schema for providing the device configuration information  A transaction which can allow actors to query for configuration related information  An optional transaction which allows actors to receive notifications for configurations which have been modified  An audit log event for recording registration and access to device configurations  Outline the security considerations for the profile

8. 8 Dynamic Configuration Management: Environment Configuration Configuration Source Configuration Consumer Configuration Manager  The diagram below outlines the Actors in the proposed IHE Profile Register Device Query Device Update Device Configuration (Optional)

9. 9 Request Format  The request format will be in the form of a simple HTTP GET request which provides the details of the actor for which the configuration details are required  The following table contains a list of the parameters which can be supported in the request: ParameterComment ActorTypeDefines the actor for which the details are required e.g., XDS Registry UIDDefines the unique identifier for the actor (optional) e.g., Repository OID, AE Title,

10. 10 Response Format The recommended response format would be in the form of an XML Structure  XDS Registry Query Response  XDS Repository Query Response <DeviceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> http://10.1.5.211/XDSRegistry <DeviceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 21231243.234234222.111232 http://10.1.5.211/XDSRepository

11. 11 Response Format  The usage of XML in the response format would also support complex responses which can potentially be extended in the future This would apply to system which have a significant configuration overhead such as DICOM systems The configuration parameters could potentially be extended in the future for additional actors in the environment

12. 12 Security Considerations  To ensure secure access to the end-point, standard security mechanisms used with HTTP can be configured HTTPS for secure communication Client certificates for authenticating the connecting systems  As HTTP is a widely supported protocol, the proposed security measures can be supported by the systems which communicate with the Configuration Manager actor  The transactions for accessing the configuration can also be audited via a corresponding audit log event A new audit log event may need to be created for these operations

13. 13 Thank You