2

I am implementing a FHIR Server able to receive Resources on both formats (XML/Json). In order to make it simple an consistent, my idea is to internally work just with XML and to translate Json request to XML and vice versa, but although it works with some sample Json documents, it does not work with FHIR Json resources. The main reason is that FHIR Json resources does not have a "root" element, so the XML conversion tool does not create a proper output XML.

A FHIR Json observation resource is like;

{"resourceType": "Observation","id": "example",...}

And with a root element it should be 

{Observation:{"id": "example",...}}

I am aware it's not mandatory for a Json document to have a root element, but ¿if most XML<->Json converters work better in that scenario and FHIR accepts both formats, why not defining FHIR Json resources with a root element? specially when it seem that some initial DSTU used that approach.

Thanks

Marti Pàmies Solà
  • 611
  • 1
  • 6
  • 12

3 Answers3

2

The decision was made to make the JSON the way the JSON people wanted and the XML the way the XML people wanted and to forgo the use of off-the-shelf converters. Using the off-the-shelf converters resulted in syntaxes that one group or the other or both hated. Everyone has to deal with the instances. Custom converters only need to be written once. In any event "why does the specification do things the way it does" is probably not in-scope for Stack Overflow - better to raise it on chat.fhir.org.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • Adding to what Lloyd said: If you can use Java or .Net libraries, please take a look at the official FHIR libraries that contain excellent parser/serializer methods, so you don't have to do all the work again. – Mirjam Baltus Jul 18 '18 at 10:39
  • Lloyd and Mirjam, thank you so much for your response. I'll have to deal with trying to integrate some FHIR libraries into my Application Server (Tomcat+Axis2) or find another solution to keep my implementation coherent no mater if the request comes in XML o Json. – Marti Pàmies Solà Jul 19 '18 at 06:21
0

You are running against a restriction of XML which JSON does not have. Because you only need the XML for internal use, and you use JSON anywway for interoperability, you might as well wrap your incoming JSON in a root element and remove it when exporting to JSON. I don't think that will cause many lines of code or performance lost.

If you want to change the behaviour of FHIR regarding to this, you better address this somewhere else then Stackoverflow which purpose primarly is to hand over practical solutions.

Best regards

Bert Verhees
  • 1,057
  • 3
  • 14
  • 25
  • Hi Bert, sure it won't cause two many line of code, but I asked how to done it at this questions (https://stackoverflow.com/questions/48587430/axis2-json-support-jettison-bad-xml-conversion) but I still do not have any answer. Finally I was able to find a solution thanks to WSO2 people, and this is the reason why I like to share it with the community (not asking a new question) – Marti Pàmies Solà Jul 26 '18 at 14:02
  • You are asking a question (you even say thanks), but the question should not be on StackOverflow, because it is about why FHIR is defined as it is. StackOverflow is not a discussion board about FHIR or other standards, but it is a help-forum for programmers. So your question should not have been here at all. – Bert Verhees Jul 27 '18 at 05:11
-2

The may challenge for our company regarding this issues is how to manage FHIR JSON requests without changing our back-office technology(Tomcat+Axis2). Before being able to work with official FHIR libraries, I should be able to access JSon request form Axis. If it could be useful to some one working with FHIR and Axis, at the following question I explain who I implemented it Axis2 JSon Support (Jettison) bad xml conversion.

Thks.

Marti Pàmies Solà
  • 611
  • 1
  • 6
  • 12