This thread is for the discussion of the gsoc project Radiology Reporting Enhancement. This talk thread is dedicated to discuss and understand the requirements of the project in details.
Hi @teleivo
Here is a summary of the discussion i had with @judy. We were trying to come up with the objectives for this summer so that i can adjust my timeline appropriately. We decided that first
We will create a radiology dashboard. The dashboard will
- query the PACS server(dcm4chee) for all images
- Retrieve their DICOM metadata and display them on the dashboard
- Support filtering to create a new worklist
- Enable search for a specific patient and at each line allow user to claim report for a specific patient from the worklist.
More about the objectives can be found at https://docs.google.com/document/d/17u8kwEk-2D47ZsfSy_WM5LdpIuXwPm9LAQuoOSbQHHA/edit
Currently i am working on wireframes for the dashboard and doing some research about DICOM and how to convert MRRT templates into openmrs schema. @teleivo i would like your input on these so that i may start ticketing them.
1 Like
Hi @ivange94,
I am all for the radiology dashboard! That’s a great place to start.
I just dont think that we should implement the first 2 points and especially that this DICOM -> PACS communication area should not be within your projects scope. My opinion is that your focus should be on reporting and reporting templates (@judy). This will be enough work for sure.
Just for perspective: this module should extend OpenMRS so it has capabilities of a radiology information system RIS. The RIS will be the “driving” system. Patients are entered there, imaging orders placed. These orders are sent to the PACS (via HL7) which takes the patient and imaging procedures and serves this data to the imaging modalities (via DICOM Modality Worklist). The imaging modality (if it supports it) sends updates (DICOM MPPS) to the PACS about the state of the imaging procedure (IN PROGRESS, DISCONTINUED, COMPLETED). The PACS forwards these updates to the OpenMRS radiology module where radiologists can see the state of the procedures and write reports once images are available.
The module still has some issues in the workflow described above but my opinion is that this should not be part of your project.
Not sure if you already use this wireframing tool, but if not try it out:
I am going to make a few simple sketches myself tomorrow and write small tickets so you can get started 
As a little side note: if you talk about worklist you should be more specific as this has a special meaning in the context of DICOM (see DICOM Modality Worklist). I think you mean a reporting worklist for the radiologist so he/she see’s the imaging procedures that need reporting.
2 Likes
I actually started working the mockups just yesterday due to exams. Here is a snapshot of what I have so far. Its not yet complete but it portrays the workflow I have in mine. I would like your input to know if am working in the right direction. 
1 Like
Hi @ivange, can you please create a gitrepo with the sketches or maybe some other means so we can all extend on them?
Hi @teleivo I created the GitHub repo, https://github.com/ivange94/radiology-reporting-mockups and added you and @judy as collaborators.
Hi @michael
Dear @ivange94,
good job on the wireframes!
I just created a branch with updated wireframes, please have a look at them: GitHub - ivange94/radiology-reporting-mockups at teleivo
my main change is that I would make tabs for orders, reports, templates like you see here:
Separates the work the specific roles (physician, data clerk, radiologist) are doing. We should also be able to only show the tabs the user has privileges for. I think this is cleaner. What do you think @judy?
(you can see an example of how to create tabs in the openmrs/patientDashboard.form)
First issue: create the “Radiology” menu entry like “Reporting” has it which initially leads to the http://localhost:8080/openmrs/module/radiology/radiologyOrder.list [RAD-247] Create radiology menu entry - OpenMRS Issues
Next issue: create the orders tab like you see it in the wireframe above and restructure the views/urls as you see them in the wireframe’s. https://issues.openmrs.org/browse/RAD-248
You can start working ASAP on RAD-247. If you need anything, dont hesitate to ask us.
Together with @judy we will then work out the details of the “Reports” and “Report Templates” tabs and views.
1 Like
@teleivo i looked at the changes to the mockup and it looks good. [quote=“teleivo, post:8, topic:6171”] Together with @judy we will then work out the details of the “Reports” and “Report Templates” tabs and views. [/quote]
Cool so when should we have the meeting. I will be free today from 19:00 UTC, will this be okay for you and @judy ?
We can use the openmrs channel on uberconferrence. I see today’s design forum is currently open but don’t whether its too late to request for it. If you guys will be available at that time i will request for it ASAP.
sorry not available at this time, only available until 15pm UTC today. do others talk on the openmrs channel on uberconferrence for gsoc purpose?
just wanted to tell you that I am on telegram now. So if you like you can send me messages also there on the openmrs channel if you want to chat once in a while to get better and instant feedback. Just let me know and dont hesitate to ask! We dont want you to waste time if you get stuck, just tell us 
After exploring the xforms module for a while (still to work with htmlform entry), i told you that each template will be stored in the filesystem as xml files and when a report is created another xml file will be created that holds the data entered when a report is saved. But i think that would be creating too much xml files and also the MRRT templates are in perfectly valid hmtl, so converting them to xml to store in the system and then when rendering in the webapp, try to make them look like html forms again might be a little too much work.
So i propose that we have a model “ReportTemplate” that holds all the properties of the template specified in the MRRT document and an extra field to hold the body content of the MRRT template as a string. This way we can store the template inside a table like “radiology_report_template” and later if this template needs to be exported as an MRRT template or an XML form we can easily do so by reading the property entries from the database and also rendering it will be very easy because we can always pass a template object to the view and the view will have access to all properties that will dictate how to render the template.
Now here is where XML files will be created, after a report has been authored, we will create an XML file that will hold the values entered in the report.
I would really like your input on this and the general community too especially @dkayiwa and @mogoodrich as i can see from modulus that they are the owners of xforms and htmlform entry modules respectively.
Update: Storing the body content of the template(which is html code) inside the db might not necessary be a good idea. We might just keep the mrrt html file inside the file system and only convert it to xml when needed to share it with other components in OpenMRS.
Dear @ivange94,
http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_MRRT.pdf is the go to guide and our main requirements doc for this project.
Main points
- I am in favor of creating a domain object ReportTemplate.
- I think we should store the templates and probably also the reports on the filesystem (since the filesystem is designed for storing larger objects) and only metadata in our database with a link to the filesystem. See MRRT doc it nicely shows what metadata it needs (from this we can find the properties for our POJO and the database)
- I think we should store our templates in html5, since see MRRT “Closed Issues #1” excerpt:
We reviewed RFD and XForms as possible alternative to HTML5 and they were judged less appropriate. HTML5 (HTML Standard) was selected because, like radiology templates, it strikes a balance between expression of coded content and 175 description of a user interface and the related data capture methods. HTML5 is increasingly used as a method for displaying clinical images, facilitating the construction of multi-media reports in the future
the only thing I dont know is whether we can use module htmlforms for it. Does it support the html5 components we need? You need to check this against the MRRT doc. And as far as I know when using htmlforms it will validate the user entry against OpenMRS concept ranges, … how does this show in the html? The issue here is if you try to import an external report template from lets say radreport.org, would that work? Or not because its not valid according to the htmlforms? @dkayiwa and @mogoodrich do you have some input or expertise for us?
- We should follow the MRRT in creating REST services for creating, querying, adding report templates. This is why we need the metadata stored in the DB, so we can provide these REST services. MRRT nicely shows what needs to be supported. You can also check out the REST service of RadReport and test a little with for example chrome postman extension
TODO
Goal would be to create a ReportTemplate via REST and subsequently query it for example just by its template UID in the beginning. This means you need the java object, spring dao, service and rest on top. We can then also create a Tab in the legacy UI of the radiology module to create new and see existing templates.
In my opinion you can start by creating the ReportTemplate object extracting necessary properties from http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_MRRT.pdf and creating necessary services for it.
@judy any input on our goals and my proposed plan?
1 Like
made some commits to handle the above, commented on RAD-272 stating what i have done and what is left. Code committed at RAD-272 Provide support radiology report templates
I’m not done though. I’m still to handle the xml script part of the mrrt template file. I was hoping you could share some light on how that will be stored inside the template object.
@teleivo I am not so tied to the actual style of implementation and you approach is acceptable to me …
@judy have you used https://open.radreport.org/ and its TRex editor? I am wondering if we should focus our efforts on importing/use of templates for reporting (java API + REST) and leave the creation of templates as optional. If most radiologists would get their templates from somewhere else.
thread for html parsing
Yes I have used it
I agree we can focus on the importing only but we need to ensure that the parser checks that it’s a valid mrrt form
Great! Totally agree with validation. The good part is that radreport has so many good examples we can test against. And since radreport has a REST api we could even implement an extra test, like a release/smoke test that imports a configurable amount of templates from radreport. This would be a good say to test against reality