More Argonaut stuff
March 7, 2015 8 Comments
Interesting article on how FHIR and Argonaut continue to gain momentum in the US.
FHIR does seem on track to become the Lingua Franca of healthcare information exchange…
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.
What is the value added of json representation w.r.t. XML?
JSON is a more natural fit for mobile and web-based solutions. Supporting both means a server will support a greater variety of clients. And with the reference implementations already transparently supporting both, it’s pretty straight-forward to implement
Lloyd, many thanks for the answer. However, I don’t see any value added. Being “More natural” depends on the point of view of the vendor. JSon and XML are not comparable technologies. XML allows a semantics and a syntactical checks, while JSon not yet (AFAIK). With web services, an intermediary can manipulate a message on their way (WS-*), while that’s not true for JSon objects.
I really see the REST and FHIR technology a giant step back in the 90’s, with a brand new syntax…
Massimiliano – why not come along to the May working group meeting which is in paris? Especially if you come to the fhir connectathon, you’ll be able to discuss these concerns with those involved with the development of FHIR…
David, thanks for the invitation. I would like to see the other way round as well: FHIR guys coming to the IHE discussion. Calls are open, and free.
Realistically, you won’t often want to use the syntactic checks supported by XML in production environments either. For one, that limits you to supporting only a single version of the specification (as new elements might be added in the future). Second, schema validation messages are extremely poor if the intent is to expose something useful or meaningful to users.
That said, if you want to use those technologies and prefer XML to JSON, you may. We support both because there are significant communities interested in both.
I don’t understand why you assert that a JSON object message can’t be manipulated in transit. There’s nothing specific to XML that allows or doesn’t allow manipulation en-route. Obviously signatures can cause issues with in-transit manipulation, but that holds for either syntax.
And if you really like the overhead of WS-*, nothing prevents you from transmitting FHIR instances there either. If your choices are v2.xml or CDA or v3 messaging in your SOAP body, you might find still find FHIR rather appealing. If you’re creating your own custom syntax, then that might be more attractive, but it will have challenges in terms of interoperability.
Lloyd,
It is a best practice to perform schema check on incoming messages. When crossing security zones, you usually perform a schema validation to prevent well known attacks such as Somorovski, Gordon (e.g., the XSW, Replay attack, rewrite attack). Syntactic checks of incoming parameters are defined into ISO 27005 as threat. Although it is relatively easy to perform adHoc checks in basic datatypes (e.g., Strings, int) in such a complex datatypes such as XML, schema validation is a big improvement on security. You won’t validate a signature over an invalid xml. Checking if a JSON object is formally correct it’s a lot of work, without a schema. Concluding, schema are made for computers, not for humans (and their expressivity is subject to user capability).
Well, in XML-based exchanges, you have the concept of Service Oriented Architecture (SOA). You have software contracts, you have SLAs, you have orchestrations, process, and a lot of interesting scientific results, which you don’t have yet (AFAIK) for REST infrastructure (as they are premature). One of the big differences between SOAs and XML-RPC is exactly that SOAs fully exploits the tree structure of the XML document. WS-Security works by re-locating specific signed (or encrypted) IDs, thus allowing intermediaries manipulation over non-signed data. JSon can have nested signed information, is it “easier”?
I don’t understand why you call “Overhead” of WS-*. Which kind of overhead? Technical? Implementation?
Thanks for this interesting discussion! 🙂
I’m not advocating not validating inbound instances, merely indicating that schema is not the preferred mechanism for performing such validation (both for inter-version compatibility reasons ans because of the poor error messages resulting). Syntactic checks are necessary and are implemented by the reference implementations provided by the FHIR reference implementations.
With REST, one of the objectives is to reduce the amount of negotiation between agreements. The orchestrations are all extremely simple – create, read, update and delete and a few simple variations. You can do SOA using FHIR for those operations that require more sophisticated orchestration.
Within FHIR, data cannot be reorganized for signature purposes. The id-idref mechanism is not supported for reconstituting information (using it *does* break schema, plus it adds unnecessary complexity). The expectation with FHIR is that the canonicalization algorithm will identify what is signed and what is not and we’re working to define standard algorithms for that purpose. They will work as well for JSON as for XML (and for RDF too).
The overhead comment is just that there’s additional volume in the instance and complexity in the WS stack that is absent from the equivalent HTTP stack. There may well be times when this additional complexity is necessary and you’re free to use WS-* with FHIR if you wish. However, most of the early adopters of FHIR have opted to stick with the base HTTP stack.