Friday, October 11, 2013

DAF Transport

Some initial thoughts on DAF "transport" layers:
  • For syntax, we have ER7, XML and JSON.
  • For Transport, we have SMTP, REST, SOAP/HTTP, and MLLP that are existing choices in various IHE profiles.  
  • For Node authentication and encryption we have just TLS, but we really don't need to be able to replace that component.  
  • For authentication/authorization we have IUA, EUA, and XUA.  
This is 4 * 1 * 3 * 3 = 36 different combinations.  We don't need to address all combinations.  Some make sense and others do not.

If you are working in a REST framework, your syntax will be JSON or XML.  Few other choices make sense.  For that, EUA or IUA would be where I'd go for authentication/authorization.  XUA is really designed for the SOAP stack.

If you are working in a SOAP framework, your syntax will most likely be XML.  I can't imagine someone using SOAP trying to parse ER7 or JSON.  You have a couple of choices for your XML.  Could it be FHIR, HL7 V3, HL7 V2, or ebXML.  This is an area where we have to apply some critical.  All of these are reasonable choices, but, why would you want to use FHIR with SOAP?  And while there are deployments of V2 messages using XML in SOAP, this is again, not really a platform combination that I'd see being terribly viable.

If you are working in SMTP, your syntax is really going to be about MIME, and inside that, well, you could have an XML attachment or a collection of things (e.g., an XDM ZIP file).  You will secure the content using S/MIME.  The query/response pattern is not a very common one with SMTP, but it has been done by many mailing list management packages, where a simple query can be submitted to the list server in the subject line, and the e-mail you get back is the response.

If you are working in MLLP, your syntax will most likely be ER7 or XML, and semantics would come from HL7 V2.  EUA is really the only choice for authentication as far as I can tell, but I'll have to check.  There may be some ways in which XUA could be supported here.  It might be amusing to translate ER7 notation into JSON via a more direct route, but that's already been done much better by FHIR.  There are a few cases where V3 has been communicated using MLLP, but this is a rare bird hardly ever seen in the wild.  A few known instances exist in captivity.

TransportSyntaxSemanticsAuthentication/
Authorization
Encryption
MLLPER7HL7 V2EUATLS
MLLPXMLHL7 V2EUATLS
SOAPXMLHL7 V3/ebXMLEUATLS
SOAPXMLHL7 V3/ebXMLXUATLS
RESTXMLHL7 FHIREUATLS
RESTXMLHL7 FHIRIUATLS
RESTJSONHL7 FHIREUATLS
RESTJSONHL7 FHIRIUATLS
SMTPXMLMIMES/MIMETLS and S/MIME

This isn't quite as bad at the previous set of choices.  The only choice not presently supported somewhere by IHE is V2 Semantics with XML Syntax.  There's a lot more nuance and detail to cover.

1 comment:

  1. > would you want to use FHIR with SOAP

    Because you have skills and infrastructure using soap, and because you have other services sharing content with the soap that use FHIR? (Looking ahead, of course, no one yet has stuff already using FHIR). A number of people have asked me about FHIR and soap, so the interest is there.

    ReplyDelete