PHINMS: Application Integration Raja Kailar, Ph.D. The findings and conclusions in this presentation are those of the author and do not necessarily represent the views of the Centers for Disease Control and Prevention/the Agency for Toxic Substances and Disease Registry.

Overview PHINMS – brief overview and history Application Integration View Summary

What is PHINMS? (Business Perspective) Secure, reliable message transport Used by PH agencies to send data to CDC Applications using PHINMS include: BioSense, ELR, LRN, NBS, HCN, NHSN Some states using PHINMS internally: NYS, NYC, MN, OK, CA 4-year old product deemed “mission critical” by CDC

PHINMS Usage

What is PHINMS? (Technical Perspective) CDC’s implementation of the ebXML 2.0 messaging standards Runs on Windows, Linux, Solaris (platform independent) Can be used by any application that can write and read database tables (language independent)

PHIN - Operational Environment

PHINMS – Typical Message Flow State Public Key (Encrypt) State State Private Key (Decrypt) Lab HL7 Internet HL7 Proxy Server PHINMS Receiver PHINMS Sender DB Q DB Q DMZ Firewall Firewall

Application Integration View

Overview Provide guidelines for business and technical decisions on messaging Analyze application interfacing considerations Explore ways to leverage messaging infrastructure to satisfy new data sharing needs

Data Sharing Models Model Pros Cons Centralized Repository Accuracy (real time updates) Scalability Single point of failure Security Distributed Repositories with Query/Response Accuracy Autonomy (data ownership) Privacy Application level tight coupling Reliability Distributed Repositories with Messaging Application level loose coupling Autonomy, Privacy Data latency

To Message Or Not To Message? When to message? Periodic, un-attended data exchange Data latency acceptable When not to message? Data latency not acceptable (synchronization needed) Manual confirmation is necessary

What Are Your Messaging Requirements? Is there a need for automated B2B data sharing? Is sensitive data being shared via the Internet? Is guaranteed delivery of messages important? Do you have a mix of small / large agencies (some with only “outbound” connections to Internet)?

Is PHINMS the Right Tool For You? Requirement: Secure, Reliable Messaging over Internet Option Pros Cons Build Full control over product, direction, intellectual property 1) Expensive and time consuming 2) Custom implementations may not interoperate 3) Product maintenance and support burden Buy 1) Quick return on investment 2) No product support burden 1) Cost 2) No control over product life cycle/direction 3) Proprietary implementations may not interoperate with other products Use freeware (e.g., PHINMS) 1) Low investment, high returns 3) Proven solution Reduced control over product life cycle/direction

PHINMS - Application Interfaces

Sending Side - Interfacing Steps Interface Usage Database Queue Create Database Record in transport-queue with Payload and Meta-data File Descriptors 1) Drop file in “outgoing” directory 2) Create file descriptor File-system Folder (new) 1) Create “Folder-Map” (map folder to addressing information) 2) Drop file to folder, and transport uses the properties in the Folder map to send file

Sending Interface Considerations Interface Option Pros Cons Database Queue (preferred) 1) Ease of maintenance 2) Queue Viewer (Console) 1) Dependency on DBMS 2) Requires ODBC/JDBC programming File descriptors 1) DBMS not needed 2) Simpler programming 1) Harder to manage File-system folders (new) 2) No added programming 1) Queue management more complex 2) Higher disk space use

Receiving Interface Options

Receiving Interface Considerations Mode Pros Cons Synchronous (e.g., Servlet) Processing level response on same connection (no delays) Not reliable (timeouts) Harder to trouble-shoot / maintain Asynchronous (e.g., DBMS or JMS Queue) Reliable, Scalable, Easier to trouble-shoot/maintain No processing level response

PHINMS - Messaging Models Peer-to-Peer (Direct-Send) Messaging Gateway (Route-not-Read) Model Pros Cons Sending Application Interface Gateway 1) Single security model 2) Simple deployment 3) More dynamic collaborations 1) Scalability 2) Single point of failure 3) Asynchronous only 1) Address information of Gateway and Recipient 2) Encryption with Recipient key (not gateway key) Peer-to-Peer 1) Scalable 2) Private 3) More reliable 4) Synchronous and Asynchronous models 1) Complexity 2) Many security models, infrastructures 3) Static collaborations Address/encryption information of Peer node

Leveraging Existing PHINMS For New Data Sharing

PHINMS - Scaling Considerations

Summary Data sharing needs determine suitability of messaging, architecture and tools PHINMS is a “pluggable” component that enables secure/reliable data sharing Many public health organizations have PHINMS Can leverage infrastructure for new data sharing As usage goes up, need to scale up your infrastructure

Questions?