Implementing a QIDO-RS Service

Having previously implemented a basic QIDO-RS worklist using JavaScript, I figured it would be useful to implement a QIDO-RS service to improve my understanding of the standard. For those unfamiliar with QIDO-RS, it allows web based queries for studies, series and instances - similar to C-FIND. This weekend I implemented a simple service implementation using C#, Visual Studio 2013 and ASP.NET MVC 5 WebApi. You can find the source code for this project on my github here.  

Overall I found the implementation to be fairly straightforward and it took me about 16 hours total. About 2/3 of this time was related to a) understanding the standard and b) working through various issues with Visual Studio 2013 and ASP.NET MVC 5 WebApi (neither of which I had used before).  

Here are some of my thoughts after getting this implemented:

1. I found several errors in the DICOM standard:

• Modality has incorrect tag in Table 6.7.1-2a
• Missing Study Description tag in Table 6.7.1-2
• Misspelled StudyInstanceUid on line 641
• JSON Example in F.2.1.1.2 is Invalid JSON (missing a comma between array entries)

2. The standard was difficult to understand

• It makes several references to concepts documented elsewhere (e.g. fuzzymatching,)
• It seems to be designed as a web wrapper around CFIND which therefore requires fully understanding CFIND

3. It isn't clear what functionality is required and what is optional. This may be due to it being designed as a wrapper around C-FIND and I don't have expert level knowledge of C-FIND.

4. The JSON mapping was not designed for ease of use by JavaScript developers.  From F.2 in the standard "The DICOM JSON Model follows the Native DICOM Model for XML very closely, so that systems can take 790 advantage of both formats without much retooling".  Here are some specific issues

• The attribute tag (group/element) is used as the property name in the JSON object. JavaScript code cannot use dot notation to access these properties since it is not supported for property names that do not begin with a letter. This could have easily been solved by putting a letter like x in front of the group/element.
• The inclusion of the VR field seems unnecessary since the native JavaScript type system is used.
• Putting all values in an array is awkward. It would have been better to only use an array for attributes with multiplicity > 1
• The use of Alphabetic, Ideographic and Phonetic in the PN mapping is unclear. I am sure these are documented somewhere else in the standard - but where? Having a PN value be an object instead of string is also a bit awkward.
• The casing for property names is not consistent. vr starts with lowercase letter while the others start with an uppercase letter. The most common naming convention in JSON/JavaScript is the first letter lowercase.

Overall this is a positive step forward to bringing DICOM into the world of the web but more can be done to reduce the barriers to using DICOM by developers. The best way DICOM can reduce these barriers is to make web browser and JavaScript based consumption a top priority and make it as easy to use as possible in that environment. Efforts such as the dicomWeb online documentation are very helpful and so are open source implementations of the standard.