WIP: Implement the ITI-48 transaction (Retrieve Value Set, SOAP)

[qligier]

This is an implementation of the IHE ITI-48 transaction, Retrieve Value Set, for the SOAP binding only. It introduces new modules: ipf-commons-ihe-svs and ipf-platform-camel-ihe-svs (SVS for Sharing Value Sets profile). Models for request and response are introduced, along with Camel converters. The audit record messages are generated.

List of issues with the specification:

1. The format of the attribute cacheExpirationHint isn't defined in the specification. In the XML Schema, it's described as an xsd:dateTime, so the implementation supports only this format.
2. In case of an error, the NAV and VERUNK codes can't be specified as a fault code, as per SOAP 1.2 specification. Instead, in the implementation, they're specified as fault subcode (without namespace) and the fault code is set to RECEIVER SENDER.
3. In the audit record messages (consumer and repository), there's a typo in the transaction name: Retrieve Value Sets instead of Retrieve Value Set (as it's used elsewhere in the specification). The implementation uses the latter.
4. In the audit record messages for the repository, the source userID and userAlternativeID seems to be inverted. The implementation sets the endpoint URI in the userID, as it's done for the consumer side and other transactions (e.g. ITI-43).
5. In the audit record messages (consumer and repository), the destination userIsRequestor is marked as not specialized. The implementation sets it to true, as the source and human requestor(s) userIsRequestor are always false. Is that correct? Could it be false in some cases?
6. In the audit record messages (consumer and repository), the participantObjectIDTypeCode is mandatory but not specialized. The participantObjectID is always the value set OID, so the type code should be a chosen, fixed value from the value set given in the DICOM specification. The implementation uses Search Criteria (10).
7. In the audit record messages (consumer and repository), the participantObjectDetail contains the value set version and is mandatory on the repository side. In the DICOM specification, it's not a free text field but a type-value pair element. The implementation does not set this field.

I've not reported these issues to IHE yet, I don't know if they're aware of some of them.

Still to do:

• Investigate and fix the slow service creation time, aprox. 30 seconds.
• Ensure the audit messages contain the human requestor(s) when the transaction is secured with XUA.
• Ensure that no namespace is authorized in SOAP 1.2 fault subcode.
• Update IPF documentation to describe it.

[unixoid]

The long service creation time is most probably caused by the huge XML Schemas which contain ca. 27000 lines. We have had the same problem many years ago when implementing PIXv3/PDQv3 components.

[qligier]

I found the culprit. It wasn't the schema complexity but the following import in the schema:

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>

It was most probably hitting the HTTP request timeout, thus the constant 30 seconds delay.

I've nonetheless simplified the schema.

[unixoid]

FYI: we have a local copy of it in /commons/ihe/hl7v3/src/main/resources/schema.

[qligier]

It does not seem to be useful, the definitions are self-contained or come from the http://www.w3.org/2001/XMLSchema namespace, so I don't think we've a good reason to reintroduce it as a local import.

[unixoid]

@qligier: eHealth Suisse told us you need a new IPF release. No problem. But do you want this pull request to be part of it? If yes, please finalize it. :-)

[qligier]

Yes, it would be nice to start the eHealthConnector refactoring based on IPF 4.1

I've updated the only part of the code that I wanted to change but there's no urgency for this, at least on my side: we're manually including the code in one of our HUG project (so not waiting on a release), and I think SVS is out of scope of the eHC.
I've implemented as close as possible to the spec while fixing some of the issues, so it's not perfect but cannot be improved yet. I'm waiting for Lynn's answer about the specification issues and will fix the implementation once a change request is written or voted (no idea about the timeline).
So whether you want to merge it and open an issue to track IHE fixes on this or let it open and merge only when the implementation is compliant is up to you.

[unixoid]

@qligier: FYI: IPF 4.1.0 is released.