#WIREFRAMESKETCHER ALTERNATIVE HOW TO#

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.ĭear is the go to guide and our main requirements doc for this project.

Update: Storing the body content of the template(which is html code) inside the db might not necessary be a good idea. I would really like your input on this and the general community too especially and as i can see from modulus that they are the owners of xforms and htmlform entry modules respectively. 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.

#WIREFRAMESKETCHER ALTERNATIVE HOW TO#

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. 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. 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. Hi 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. WireframeSketcher is a rapid wireframing tool that helps quickly create wireframes, mockups and prototypes for desktop, web and mobile applications. Not sure if you already use this wireframing tool, but if not try it out:Įclipse Plugins, Bundles and Products - Eclipse Marketplace WireframeSketcher Wireframing Tool The module still has some issues in the workflow described above but my opinion is that this should not be part of your project. 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 imaging modality (if it supports it) sends updates (DICOM MPPS) to the PACS about the state of the imaging procedure (IN PROGRESS, DISCONTINUED, COMPLETED). 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).

Patients are entered there, imaging orders placed. This module should extend OpenMRS so it has capabilities of a radiology information system RIS. My opinion is that your focus should be on reporting and reporting templates ( This will be enough work for sure. 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. Hi am all for the radiology dashboard! That’s a great place to start.

Wireframesketcher alternative