Radiology Service

As describes in Default Service section, the FHIR resources which contain "RAD" as "serviceCategory" will be handle by the Radiology Service.

Users can create own handlers and register them with using Spring framework for the module in order to use them. But they have the flexibility of designing how to store/map a FHIR DiagnosticReport into OpenMRS data structures. In Radiology Service Handler, it's using Encounter as the main type to store the metadata of a DiagnosticReport. Then other FHIR resource fields are stored as OpenMRS Encounter properties and OpenMRS Obs. In order to store multiple Obs, it's using OpenMRS Obs Groups which use tree structure to store multiple Obs.

Workflow

Radiology Service handler is handling incoming request in a different manner. When the RadiologyHandler gets a GET request, first it searches for matching resource in the OpenMRS storage. If it's not able to find the given resource, then OpenMRS FHIR module makes client request to a specified external FHIR server and retrieve matching FHIR DiagnosticReports in  OpenMRS storage and response back to the user with received FHIR DiagnosticReports.

FHIR DiagnosticReport Mapping

ServiceCatogory > EncounterType

Encounter Type is used to differentiate "RAD" serviceCatogory from other serviceCatogories. Thus it's required to create an EncounterType in OpenMRS and configure FHIR module to use it.

Issued > Encounter's DateTime

Issued filed has one to one mapping with FHIR DiagnosticReport and it's stored as Encounter's DateTime value.

Subject > Encounter's Patient

Subject filed can be represent in Patient, Device, Group and Location. But in current implementation, it's only accepting FHIR Patient resource. It creates a OpenMRS Patient using FHIR Patient and store under Encounter's Patient.

Performer > Encounter's Provider

Performer filed can be represent in Practitioner and Organization. But in current implementation, it's only accepting FHIR Practitioner resource. It creates a OpenMRS Provider using FHIR Practitioner and store under Encounter's Provider.

Result > Obs Group

Result field can contain zero to many Observations. These FHIR Observations can map into OpenMRS Obs. In order to store multiple Obs, it uses Obs Groups.

ImagingStudy > Obs Group

ImagingStudy field can contain zero to many Observations. These FHIR ImagingStudy can map into OpenMRS Obs. In order to store multiple Obs, it uses Obs Groups.

ImagingStudy (Obs) 0..*
  - Patient : Person
  - uid : uuid
  - accession : AccessionNumber
  - numberOfSeries : Get Size of Series of Obs
  - numberOfInstance : ? Answer to the concept
  - clinicalInformation : comment
  |
  |--> Series (Obs) 0..*
         - modality : ?
         - uid : uuid
         - numberOfInstances: ? Answer ot the concept
         - url : comment
          |
          |--> Instance (Obs) 0..*
                 - number : ?
                 - uid: uuid
                 - sopclass : ?
                 - type : ?
                 - title : ?
                 - content : Complex Obs

PresentedForm > Complex Obs

PresentedForm represent zero to many FHIR attachments. These FHIR Attachments can store using OpenMRS Complex Obs. Also it uses Obs Group to store multiple Complex Obs.