Getting DICOM SR values into an EMR
JSON, REST API, DICOMweb, XML, HL7 v2, FHIR — what the options are and how to choose.
Why SR values do not go into an EMR as they are
A DICOM SR (Structured Report) is a DICOM object that holds measurements and findings as a tree. The values are in there, but the same measurement can have a different structure and name depending on the device, model, and software version, so an EMR often cannot read it directly.
As a result, SR content usually reaches the EMR only as a PDF or an image, and using the values themselves means repeating integration work for each device. The first step is to convert the SR into a form that other systems can read and pass it on, and there are several such forms.
Comparison at a glance
| Method | How it works | Good fit when | Watch out for |
|---|---|---|---|
| JSON | Represent the SR content as JSON | You are building a new integration or processing values yourself | Field names and structure must be agreed on |
| REST API | Send the converted JSON over HTTP to an EMR or an intermediate server | The EMR accepts REST requests | Authentication, retries, and error handling must be designed |
| DICOMweb | Retrieve the SR over HTTP from a PACS or similar store (WADO-RS) | The PACS supports DICOMweb | Tag-number based, so extra interpretation is needed |
| XML | The XML representation of DICOM, or an existing XML-based integration | You already exchange data as XML | Verbose and hard for people to read |
| HL7 v2 | Convert into result messages such as ORU | The hospital interface engine is built around HL7 v2 | Mapping design and interface engine setup are needed |
| FHIR | Convert into resources such as Observation and DiagnosticReport | The EMR supports FHIR | Mapping design is needed; HL7’s SR-to-FHIR mapping guide is not yet an official release |
Each method in more detail
JSON
The form that most systems read most easily. DICOM also has a JSON representation (PS3.18 Annex F), but it uses tag numbers as keys, so an extra step is needed to read and organize measurement names, values, and units before an EMR can use them.
REST API
Send the converted JSON to the HTTP API of an EMR or an intermediate server. It is simple to implement, but you need to decide how to handle authentication, resending after a failure, and preventing duplicate sends.
DICOMweb
If a store such as a PACS offers a DICOMweb service, you can retrieve the metadata of an SR instance over HTTP as JSON (application/dicom+json) or XML (application/dicom+xml). It is the standard route, but moving what you retrieve into the form your EMR uses is separate work.
XML
The DICOM standard has an XML representation (the Native DICOM Model in PS3.19), and DICOMweb supports it as well. Choose it when you need to match an environment that already exchanges XML.
HL7 v2
A message format widely used by hospital interface engines. To carry measurements in a result message, you need to agree on a mapping that decides which value goes into which field.
FHIR
Represents a measurement as an Observation and a report as a DiagnosticReport, for example. HL7 is developing a mapping guide from DICOM SR to FHIR resources (the DICOM SR to FHIR Resource Mapping IG), but only a pre-release version is published, so check its latest status before relying on it.
How to choose
- The EMR can receive JSON over REST → JSON + REST API
- The PACS offers DICOMweb → retrieve with DICOMweb, then organize as JSON
- The hospital interface engine is centered on HL7 v2 → convert to HL7 v2
- The EMR supports FHIR → convert to FHIR
- You already integrate with XML → keep XML
A note about patient information
A real SR may contain patient information. When you use a tool that takes an SR, first check where the file is processed. The SyncSR demo processes files only in the visitor’s browser and does not send them to SyncSR servers. How to verify this
What SyncSR does today
- Available now: upload an SR file in the demo and see it as JSON in its original structure, without changing values, units, or names.
- In preparation: an on-premise agent and SDK. We currently accept demo use and beta applications.
- Reviewed based on demand: other formats such as REST delivery and FHIR or HL7 output.