Combining IHE transactions : Orchestration or Choreography?

Integrating the Healthcare Enterprise (IHE) has gained tremendous momentum in the past few years. Started as a Healthcare Information and Management Systems Society (HIMSS) and Radiological Society of North America (RSNA) workshop in October 1998 with only 15 participants including AGFA, Cerner, Fuji, GE, HP, Philips, Siemens, the IHE initiative has more than 400 members worldwide. It is composed of healthcare professional associations, government agencies, Health Information Exchanges (HIE), healthcare providers, IT and consulting companies, trade, educational, standard and research organizations. IHE provides a standards based-interoperable framework to share and exchange information between healthcare organizations across networks.

Combined with the latest technology and well established standards (HL7, DICOM, IDC9/10, LOINC, W3C), clinical data can then be securely and privately accessed and transmitted locally between network endpoints (e.g. within the same hospital between the practices and a lab). IHE profiles can also be used across Health Information Exchanges (HIE) of Regional Health Information Organization (RHIO), or a state level (e.g. an individual state in the US, Canada or Europe), or at the federal level (e.g. the US Nationwide Health Information Network or NwHIN). As a result, there is a strong need to integrate and combine individual IHE profiles end-points to form “hub of hubs” or “network of networks” to support health information exchange between the participating nodes entities.

Because IHE transactions are most likely to be offered as web services, combining those transactions can be done following Service Oriented Architecture (SOA) and Service Oriented Computing (SOC) principles.

Conventional middleware distributed system infrastructures (e.g. JMS) are generally not sufficient or flexible enough to mediate, transform, federate and route messages from and to web services.

Enterprise Application Integration (EAI) goes one step ahead, trying to separate the applications from the web services end-points. EAI usually employs a centralize service broker for this, a set of connectors and an independent data model. Services can then send and subscribe to receive messages to and from the broker. However, this very centralized approach requires a large amount of up front development and business process design for the connectors, as well as high cost of maintenance in general. Enterprise Service Buses (ESB) is an infrastructure that leverages EAI principles.


Orchestration

Like EAI, orchestration uses a centralized approach. Web services orchestration is realized through Business Process Execution Language (BPEL) that describe the collaboration and interaction between the web service participants.

Business workflows, states, actions, events, control flows and exception handling can be specified. Messages can be received and sent directly from and to WSDL ports. Results received asynchronously from web services can be combined to create new messages. Usually BPEL workflows are created and updated with visual design tools.

There is often an overlap between orchestration engines and Enterprise Services Buses (ESB). Vendors now also offer BPEL design on top of more generic EAI mechanisms enabling true orchestration for ESBs.


Choreography

Choreography is more distributed and collaborative in nature and uses the Web Service Choreography Interface (WSCI) specification and the WSDL description files to represent the flow of messages exchanged between the Web services involved.

Choreography seems more flexible than orchestration since it does not rely on a central element that could become a bottle neck and seems to offer more complex interaction potential between web services. However, choreography has some drawbacks including the necessity for all web services to be aware of overall business process workflow. WSCI itself does not specify the definition and the implementation of the mechanism to implement the message exchange.

In addition to this, performance can be an issue if high volume message transactions between the end-points peers are not handled properly.

Moreover, there is no clear responsibility for the overall workflow leading to legal issues related to monitoring and maintenance.


Orchestration vs Choreography

Orchestration also has the advantage to be a much more mature integration technology than choreography. For these reasons, most of the state-wide health information exchange networks in the US employ a Service-Oriented Architectural (SOA) model that is implemented through an Enterprise Service Bus (ESB) orchestration.

In addition to this, web service orchestration offers much more than just technical benefits:

• Organizational: standardization, narrow gap between business analysts and developers;
• Managerial: risk reduction, lower costs, more flexibility;
• Strategic: IT resilience, delivery time reduction, less technology lock-in;
• Technical: portability, reuse, interoperability of tools, less complex code, better maintainability;
• Operational: efficiency, automation, higher level tasks management.

When deployed on high performance platforms such as SOA software appliances, orchestration solutions are easy to test, extend and maintain.

• More on this topic to be published as part of the following paper: Andry F., Wan L., HEALTH INFORMATION EXCHANGE NETWORK INTEROPERABILITY THROUGH IHE TRANSACTIONS ORCHESTRATION, 5th International Conference on Health Informatics (HEALTHINF 2012).

cURL tests harness and TLS

In a previous post, I have explained how to use cURL to test harness REST based Web services. One thing I did not described was how to add Transport Layer Security (TLS) in your tests. In other words, how to successfully test REST Web services over HTTPS?

The cURL manual describes a certain number of options that can be used. One of the most convenient option is -k or --insecure. It allows curl to  perform  "insecure" SSL connections and transfers. All SSL connections are attempted to be made secure by using the CA certificate  bundle  installed by  default. So if you SSL connection does not require client side authentication it is a very quick way to test your web service over SSL:

  curl -k https://www.acme.com/api/version


Another useful option can be used if in conjunction to SSL, you need to compress your payload via GZIP for example to optimize the transfer of large messages. In this case, you will use the option -H or --header that will help you specify custom headers to your request:

  curl -H "Accept-Encoding: gzip,deflate" -k https://www.acme.com/api/users/list


Notice in that case that the -k or --insecure option is always placed just in front of URL.

Of course, other headers such as the one described previously can be combined:

  curl -c ./cookies.txt --data-binary @login_password.json -H "Content-Type: application/json" -H "Accept-Encoding: gzip,deflate" -k https://www.acme.com/api/users/token

Medication Adherence - How technology can help?

Looking for ideas to reduce the rise of health care cost? Easy! Ask patients to swallow their medication!

According to recent studies, the lack of prescription medication adherence cost between $250 and $300 billion annually, including $100 billion in hospitalization. For example, it is estimated that in the US 89,000 deaths annually are due to non adherence to anti-hypertensive treatments. This problem is particularly acute for patients with coexisting conditions who take a variety of medications sometimes prescribed by different physicians.

Obviously doctors and pharmacists have a critical role to encourage patients and caregivers to administrate medication correctly and rigorously.

Cost is not necessarily the main factor: even when drugs are free, adherence rate is 60% in the US and only %50 in developed countries. In other words, improvements in co-payments structures will only partially improve adherence. Another area of possible improvement will be the use of fee-for-service model.






Another way to improve medication adherence is the proper use of specific technologies:

Here are some suggestions:

• the integration of practice EMRs systems and pharmacies via HIE solutions (a lot of practices are still using paper).

• accurate and Electronic Health records (EMRs, and PHRs) that help verify drug, herbs, supplements interactions and countraindications. The meaningful use guidelines go in this direction.

• wider use of medication home delivery (recognized as a way to save cost by introducing better competition) 

• electronic monitoring systems coupled with personalized counseling has shown improvement in medication adherence rates to patients

• online incentive programs (e.g. provided by the employers) to promote prevention, quality of life and best practices in therapy. It is recognized that financial incentives and other rewards when well designed and targeted can improve adherence (smaller and higher reward frequency is usually more efficient than big and sporadic rewards).

• advances in personalized medicine can help taylored medication intake and increase medication adherence

•  screening and assessment tools (e.g. patients with chronic conditions could be screened for depression leading to poor medication adherence).

• new high-tech integrated devices including:
• Home devices such as the well known high-tech Japanese toilets which provide urine analysis, blood pressure, weight and body temperature
• Radio Frequency Identification (RFID) based wireless sensor device can help track drug taking compliance
• Wireless pills organizers designed to simplify medication management and improve adherence
• Personalized wearable sensors such as the latest electronic temporary tattoo

With the amount of money at stake, I am sure there is a large number of companies, including start-ups, who are working hard on this problem. So stay tune!

Finally, we have to keep in mind, that other factors including lifestyle, psychological issues and health literacy play an important role as well. And these are not negligible!

How to test secure web services with soapUI - part #2

In  a previous article I described how to specify signature and encryption for outgoing Secured Web Services request.

1. SAML

In this second article I will talk about SAML and incoming Secure Web Service responses.

If you are using SAML 1.X then you just need to add a SAML 1.X assertion in the corresponding window.
You may have to add a timestamp as follow:

In this example, we specify 10,000 milliseconds (10 seconds) for the life time of the Timestamp:

SAML 1.X assertions are copied and pasted in the SAML tab:

Of course, if you combine signature and encryption with SAML 1.X. You can those to the configuration tabs as well.

For SAML 2.0, the only option you have for this version of soapUI is to add it manually to the WSSE section of your SOAP request:

2. Incoming Secure Web Service 
Responses


Setting up incoming secure Web services responses encrypted and/or signed is easier than for outgoing request:

1) Make sure that you have Keystores / Certificates tab set - You probably have done that earlier as described in part #1 of this article.
You verify the signature with public key contained in the server's sender certificate/store and your private key to decrypt what the other server sends you.

2) Create an incoming WSS configuration (e.g. my_config_from_server_A) that will decrypt the incoming SOAP requests coming from server A:

You specify that you want to use your keystore to decrypt the message and the server's certificate/store to verify the signature of server A
(theses should appear in the drop box for each field):

3) Last, you want to specify that you are using the incoming configuration for each request:

Enjoy!

Problem initializing the class javax.crypto.SunJCE_b with soapUI ?

Last week, I have decided to download and  install the lastest soapUI PRO version 4.0 from Eviware.
I have been using soapUI for some time to test secure SOAP Web services using SSL/TLS as well as encrypting and signing the SOAP payload.

However when I tried to use my existing projects I end-up with the following errors in my soapUI log:

Wed Jun 22 11:43:05 PDT 2011:ERROR:java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
   java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
    at javax.crypto.KeyGenerator.a(DashoA13*..)
    at javax.crypto.KeyGenerator.(DashoA13*..)
    at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
    at org.apache.ws.security.message.WSSecEncrypt.getKeyGenerator(WSSecEncrypt.java:701)
    at org.apache.ws.security.message.WSSecEncrypt.prepare(WSSecEncrypt.java:228)
    at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:291)
    at com.eviware.soapui.impl.wsdl.support.wss.entries.AddEncryptionEntry.process(AddEncryptionEntry.java:311)
    at com.eviware.soapui.impl.wsdl.support.wss.OutgoingWss.processOutgoing(OutgoingWss.java:157)
    at com.eviware.soapui.impl.wsdl.submit.filters.WssRequestFilter.filterWsdlRequest(WssRequestFilter.java:58)
    at com.eviware.soapui.impl.wsdl.submit.filters.AbstractRequestFilter.filterAbstractHttpRequest(AbstractRequestFilter.java:37)
    at com.eviware.soapui.impl.wsdl.submit.filters.AbstractRequestFilter.filterRequest(AbstractRequestFilter.java:31)
    at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:133)
    at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:123)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

A quick search on the web told me to check if my some of my security setup in my JRE was properly configured.
For this it was recommended to check the security directory under the lib folder (.\Java\jre6\lib\security):

I also checked the content of the content of the jar file ./Java/jre6/lib/jce.jar which should contain the missing class in question:  javax.crypto.SunJCE_b

However everything looked fine. Even though my JRE was almost up-to-date, I finally managed to fix this issue by upgrading my java JRE to the latest version!

How to test secure web services with soapUI - part #1

Recently I have been involved in a SOA project which goal is to orchestrate  IHE integration profiles SOAP web services (XCPD & XCA) using an enterprise service bus (ESB).

The security characteristics of these web services include digital certificates for transport level security two-way transport layer security (TLS),  message level security (encryption and digital signature) as well as single sign-on (SSO) based authentication using SAML 2.0 assertions.

One of the challenges was to find a tool we could use to create test harness for these web services, but also to simulate and mock some of these same services during development and testing.

For this I used soapUI. Overall it was not too complicated, except the support for SAML 2.0 since the current version of soapUI (4.0) only supports SAML 1.1 out-of-the-box.

Initially security features on the XCPD web service were  turned off so we could test the basic SOAP web service functionalities. For this a new soapUI project was created by introspecting the XCPD service Web Services Description Language (WSDL) file:

To make the initial project simple, no test suite has been created and the initial operation has been re-labelled "RespondingGateway_XCPD" and its sample request has been modified to query a specific test patient (Joan Hunter) and renamed XCPD_PATIENT_JOAN_HUNTER:

The test is done by submitting the request to the XCPD end-point:

This returns in the response window the XCPD response.

In the next steps, we will setup all the security features for querying our XCPD service :

• digital certificates for transport level security two-way transport layer security (TLS)
• message level security (encryption and digital signature) as well as single sign-on (SSO) based authentication using SAML 2.0 assertions.

The SAML 2.0 assertion will be described in the part two of this post.

1. TLS setup

First we need to indicate that we are using SSL on top of HTTP for the transport layer. For this we need to setup the client keystore via file/preference/SSL settings (from the machine where soapUI will run):

2. Message level security

Probably the first thing you want is to specify your keystores and certificates if you decide to have mutal secure communication. You will use your private key from your key store (my_key_store.jks) to sign messages you send and decrypt the payloads you receive, and you will use specific server public key/certificate (a_another_server_keystore.jks) to encrypt the SOAP messages you send and verify signatures you receive. The server with whom you have secure mutual communication will do the reverse.

The soapUI message level security configuration for SOAP (WS-security) can be setup by selecting our soapUI project XCPD_Tests, right-click and select Show Project View and then add using the sign + in the out-going WS-Security configuration :

 
























You then specify your configurations (e.g. my_config_to_server_A) for outgoing messages and similarly to ingoing messages.

Here how you would define a configuration in the Outgoing WS-security Configurations tab:

1. add a signature tab a
2. add an encryption tab (is you also use SAML 1.1 you would also add a SAML tab and a timestamp tab before adding the signature and the encryption).

2a. Signature

In the Signature tab, you specify:

• the keystore that contain the private key to sign the messages you are going to send (usually your private key - expect if you want to mock another server)
  
• the alias for the key to use for signature
• the certificate password
• the key identifier type (none, binary security token, X509 certificate or subject key identifier)
• the signature algorithm (e.g SHA256)
• the signature canonicalization
• the number of certificates used to sign
• the parts you want to sign (e.g. the content of the body of namespace http://www.w3.org/2003/05/soap-envelope)
  

2b. Encryption


In the Encryption tab, you specify:

• the public key of the server you are sending your SOAP messages to
• the alias for the key to use for encryption
• the certificate password
• the key identifier type (none, binary security token, Issuer Name and Serial, X509 certificate, subject key identifier, Embedded KeyInfo, Embedded SecurityToken Reference, Thumbprint SHA1 Identifier)
• an embedded key name (if any)
• an embedded key password (if any)
• a symmetric encoding algorithm
• a key encryption algorithm 
• the encryption canonicalization
• the number of certificates used to sign
• the parts you want to encrypt (e.g. the content of the body of namespace http://www.w3.org/2003/05/soap-envelope)

And finally, last but not least, you need to specify for the request which outgoing security configuration you want to choose. In our case we have defined only one configuration: my_config_to_server_A at the project level. To select the configuration, click on the Auth Tab at the bottom of the request window, select in the drop-down Outgoing WSS field your configuration. Create and configuring incoming Secure Web Services will be very similar.

You are now ready to test your SOAP Web Service with soapUI!

In  part #2 we will look how SAML can be added to the mix.

How to test harness REST web services with cURL

cURL is a very convenient command line tool to send and retrieve data using the URL syntax. It supports a large number of protocols: HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, LDAP, LDAPS, DICT, TELNET, FILE . IMAP, POP3, SMTP and RTSP.

I have been using cURL for quickly and conveniently testing RESTFul APIs.

Since I am doing most of my development on Windows platforms, I am using cURL in conjunction with Console, a Windows console window enhancement tool.

 First you need to download and install cURL for your platform (windows, Linux ect). Then you can do a quick test by accessible the home page of your favorite web site:

This should display the HTML content of the home page. At this point I would suggest to look at the documentation to see what you can do with cURL including the FAQ.

I usually use simple test harness such as 'curl http://www.acme.com/api/versions' if you REST API exposes available versions.

You can then start to do more sophisticated tests such as authentication credentials from files (in my case I use a JSON data structure to automatically authenticate to my web service), saving cookies on files (using the the -c option):

curl -c ./cookies.txt --data-binary @login_password.json -H "Content-Type: application/json"  http://www.acme.com/api/users/token

With my JSON file as follow: {"login":{"username":"user1","password":"StrongPassword1"}} 

The cookie in my case contains a session token that I can reuse between each cURL calls. In the next call I read the cookie (via the -b option):

curl -b ./cookies.txt http://www.acme.com/api/users/userid1234567890/orders

The output of the command can be saved in a file using the option -o or redirecting our output:

curl -o google.html www.google.com

or

curl www.google.com > google.html 

Enjoy!

In my next post on this topic, I will explain how to use SSL/TLS and specify GZIP headers to your cURL requests.