Considerations

1. Image class, with settings like:
   
   1. SQL URL, a string, example: sql://root:123@localhost/openmrs
   2. table, a string, example: obs
   3. column, a string, example: value_complex
   4. and a handler to get images, a block of code, method or function.
2. the module would serve DICOM images in browser, displaying:
   
   1. image in jpeg, or png
   2. image metadata
3. Image would have properties like:
   
   1. obs_id, that would allow to know whose patient images belongs to
   2. metadata:
      
      1. modality
      2. date
      3. more to be added...
   3. examples of code:
      
      1. image = Image.find(patient_id: 1) # gets image which patient has id 1
      2. image.patient # gets patient image (OpenMRS one)
      3. image.obs[ervation] # gets the obs
      4. image.order # gets obs order
      5. image.encounter # gets order encounter
      6. image.visit # gets encounter visit
   4. examples of URL:
      
      1. http://www.mainsite.com/openmrs/rest/v1/images/1
      2. Note: I would like to ommit /rest/v1/ part because it is part of implementation details, it could be something like:
         
         1. http://www.mainsite.com/openmrs/images/1, latest version by default, please CONTINUE READING
         2. and if you want to use a specific API version: http://www.mainsite.com/openmrs/images/1?version=1
         3. due that http://www.mainsite.com/openmrs/images would disorganize OpenMRS API, Radiology Module could be mounted for example at http://www.mainsite.com/radiology/
      3. whatever be the root path, these are image search examples with parameters:
         
         1.  /images?id=1&patient_id=1&uuid=...&modality=ultrasound&date=dd-mm-yyyy&date_2=dd-mm-yyyy
         2. more examples to be added...
         3. Note: dcm4chee would not be used!!!
         4. Note 2: we would also have /images/1

Workflow

1. Referring physician creates an order
2. Pending...