Presentation is loading. Please wait.

Presentation is loading. Please wait.

PHINMS: Application Integration Raja Kailar, Ph.D. The findings and conclusions in this presentation are those of the author and do not necessarily represent.

Similar presentations


Presentation on theme: "PHINMS: Application Integration Raja Kailar, Ph.D. The findings and conclusions in this presentation are those of the author and do not necessarily represent."— Presentation transcript:

1 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.

2 Overview PHINMS – brief overview and history Application Integration View Summary

3 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

4 PHINMS Usage

5 What is PHINMS? (Technical Perspective) CDCs 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)

6 PHIN - Operational Environment

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

8 Application Integration View

9 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

10 Data Sharing Models ModelProsCons 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

11 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

12 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)?

13 Is PHINMS the Right Tool For You? Requirement: Secure, Reliable Messaging over Internet OptionProsCons BuildFull control over product, direction, intellectual property 1) Expensive and time consuming 2) Custom implementations may not interoperate 3) Product maintenance and support burden Buy1) 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 2) No product support burden 3) Proven solution Reduced control over product life cycle/direction

14 PHINMS - Application Interfaces

15 Sending Side - Interfacing Steps Sending 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

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

17 Receiving Interface Options

18 Receiving Interface Considerations Receiving Mode ProsCons 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

19 PHINMS - Messaging Models ModelProsConsSending 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 Messaging Gateway (Route-not-Read) Peer-to-Peer (Direct- Send)

20 Leveraging Existing PHINMS For New Data Sharing

21 PHINMS - Scaling Considerations

22 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

23 Questions?


Download ppt "PHINMS: Application Integration Raja Kailar, Ph.D. The findings and conclusions in this presentation are those of the author and do not necessarily represent."

Similar presentations


Ads by Google