IHE Profile Proposal: Dynamic Configuration Management

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

2. Dynamic Configuration Management: Background • 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

3. Dynamic Configuration Management: Current Challenges • 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 • 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. Dynamic Configuration Management: Environment Configuration • 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 XDS Registry: 1. URL PIX Manager: PIX Manger IP Port XDS-I Actors PIX/PDQ Actors ATNA Actors Document Repository: Repository OID URL Image Document Source: DICOM WADO URL RAD-69 Server Image Document Consumer ATNA Server: IP Port

5. Dynamic Configuration Management: Proposal • 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

6. Dynamic Configuration Management: Sample XDS-I Workflow

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. Dynamic Configuration Management: Environment Configuration • The diagram below outlines the Actors in the proposed IHE Profile Configuration Manager Query Device Register Device Configuration Source Update Device Configuration (Optional) Configuration Consumer

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:

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

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. 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. Thank You