Quick and dirty JavaScript DICOMweb UID generator

I thought I’d share this tidbit code, to create UIDs (Study Instance UID, SOP Insuance UID, etc) using Javascript, primarily for use with standards like DICOMweb STOW-RS and UPS-RS.

WARNING: This is not a proper implementation, and could result in UID collisions in your repositories. Do not use in production – you should use proper UID management procedures defined in  DICOM PS3.5 B.1.

var dicomUID = '2.25.xxxxxxxxxxxx4xxxyxxxxxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
   var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
   return v.toString(10);

I put a functional example on jsFiddle.

See DICOM PS3.5 B.2 for the specification reference. The JavaScript inspiration came from an answer on StackOverflow.

dicom, healthcare API, interoperability

DICOMweb QIDO-RS vs FHIR ImagingStudy

Over the last year or two, there has been fantastic synergy between the DICOM and HL7 working groups, to harmonize the RESTful services being developed out of both standards organizations. DICOM has the DICOMweb services (of WADO-RS, QIDO-RS, and STOW-RS), and HL7 has FHIR. They both have representations of the diagnostic imaging study. They have been harmonized – but remain un-unified and distinct. To some, this may seem like a peculiar concept – why not just have one standard that works for everybody? Why not develop one interface, one method, one response, one object type?

To me, this approach of objects in both standards – is logical and perfectly justifiable. My personal, perhaps biased take comes down to one main thing – target audience. Following are the two extremes.
For the Electronic Medical Record (EMR) system, their bread and butter interoperability method is HL7. They are interested in “events”, and “observations” – i.e., patient is admitted, or patient had a diagnostic test. They know about available lab work, and happily render that information (procedure + value + unit + abnormal flag). They know about and happily render reports (straight text). They know orders. But what they don’t do, is imaging. Peering into DICOM is an entirely different beast compared to other clinical data object types. Knowing how to hang images within a study is a science (and art) all its own. EMRs want to know what studies are available, and then they can have a dedicated buddy (an image display application, such as an enterprise viewer or PACS) to render for them. EMRs may want to show thumbnails, but that’s likely about as deep as they want to go. FHIR ImagingStudy is for them – they get a high level overview in a standard they know, and let someone else dig deeper if necessary.

For the PACS Radiology system, their bread and butter interoperability method is DICOM. They work at the instance level, and build up from there. They break apart and digest DICOM headers, and render complicated multi-frame instances with thousands of parts, without even breaking a sweat. They may have knowledge about orders, but that information is tertiary and linked, at best. They have massive repositories filled with DICOM, the standard that has worked for decades. Knowing the basic metadata about the instances is simply not enough for all of the use cases – depending on the modality, the specialty, the vendor, the task – the full header information and the complete instances are needed. DICOMweb is for them – querying headers of choice via QIDO-RS and retrieving via WADO-RS – they get in-depth detail in a standard they already speak. Modalities, who typically only deal with classic DICOM, can even leverage DICOMweb with the benefit of a helping go-between service that can map their classic queries onto DICOMweb ones (i.e., via a proxy).

So those are the black and white cases. There’s a vast middle-ground, where either standard (or both) is entirely appropriate. It depends a lot on their “imaging use maturity”; software that already has an established imaging connection might choose to stick to DICOM and augment themselves with DICOMweb services. Software that is ready to be image-enabled (nurse call, patient portals, rounds) might choose FHIR. To a large extent, this is an undecided, under-discussion, case-by-case type of thing.

It is important to keep in mind – both QIDO-RS and FHIR’s ImagingStudy resource both point to WADO-RS (DICOMweb’s retrieval service) to retrieve the images or a specific rendering of them. So, for the “provider”, they will either need to implement the necessary DICOMweb services anyway, or have a buddy that already has this available to talk to. It is also important that, since both standards are built on top of technologies such as JSON and XML, can gracefully be augmented with additional data outside the standards (just add new tags; existing systems will gracefully ignore them).

Whether it is top-to-bottom or bottom-to-top, there’s value having both available for the necessary constituents. Making a PACS or VNA implement the breadth and depth of FHIR is quite heavy-handed and provides little benefit in the near future; for example, the FHIR Patient sub-resource requires information that is not available in DICOM headers and so makes it more complicated to obtain. If the information is truly needed, systems can ask the appropriate source of truth for this. Similarly, finding EMR systems that speak DICOM has historically been quite challenging and other solutions to this problem (i.e., having a image viewing application buddy) have already taken hold.

It is hard for me to say what the future will hold – I’d check out Don Dennison’s article, entitled PACS 2018: An Autopsy, as a start. If one will eventually “win”, it surely won’t happen anytime soon. What I can say, though – the very fact that we can have these conversations – it truly is an exciting time for the integrator, and a transformative one for healthcare.