Configurable printing – critical look

Development
1

In the past there were several attempts at printing reports like Patient Summary Module or Clinical Summary Module. Both are no longer supported in favor of Reporting Module.

We’d like to collect your feedback and suggestions regarding printing. Is it working well? Is is easy, convenient to use? Is anything missing? How to improve it?

Printing use cases:

  1. Export the full content of the medical record (one visit)

    Target recipients: The Court in charge of treating a complaint against the medical staff

  2. Export a summary of the patient record

    Target recipient: other medical services that will receive the patient and that need to be informed of all relevant components in the treatment history.

  3. Export a referral form

    Target recipient: the patients themselves after discharge, to leave them with a reminder of the key information, such as diagnosis and allergies, and the treatment plan in case a follow-up and/or a medication is needed.

As a sample ideas what printing could do we can look at old requirements found on OpenMRS Wiki.

Configurable Clinical Summary

Objectives

  1. Clinical Summary Template function :

    Users (Doctors) should be able to select concepts to define the template for a clinical summary.

  2. It can be implemented as

    1. Tag in HTMLForm (example: A tag to display a table of lab results)

    2. A wizard like tool , where the user can choose the different concepts and ordering of the concepts in the form

    3. An ideal solution will be to have a WYSIWYG editor, which combines the wizard concept as well as the formatting concept

Optional

  1. The doctor may decide to include specific “Encounters” that are important to create a final template of clinical summary

  2. The doctor may save this template , so that it can be used by other doctors.

  3. (I am not sure if these nice to have can be implemented easily)

Some specific Requirements (from Joaquin):

  1. There should be a button to print the summary which shows just the summary and not the entire page

  2. Should be able to show observations that have been entered for the patient

    1. Can choose whether it’s the first or last chronologically, the lowest or highest, or all, as is done in the reporting and reporting compatibility module

  3. Should be able to select to view or not view the last 5 to 10 encounters

    1. Should be able to select how many are displayed

    2. Should have an option to choose if the encounter name is a link that takes you to the form

  4. Should be able to place graphs of any numeric concept as in the Graphics tab in the Patient Page

  5. Should be able to show patient flags

  6. Should be able to select to show which program the patient is in (as in the Description tab in the Patient page)

  7. This should be an additional tab in the patient page, and not a link in the patient summary as in the current Patient Summary Module

  8. There should be a default view which should be able to be set depending on the user’s role, though if the user has the modify clinical summary privilege they should be able to change it. This change should only affect their view.

    1. If the user is able to edit the clinical summary, they should also be able to save it in a template which another user can upload to their page to have the same view. This assumes that it would be a system with the same data dictionary

Patient Summary Requirements

  • Provide a means for modeling the data (schema) for one or more patient summaries separately from the output

  • Provide a means to render to multiple output formats for the same summary model

  • Efficiently produce a patient summary for a single patient

    • Provide an interface for previewing any patient summary quickly for a specific patient

    • Configure that a patient summary for a single patient can automatically render in a new patient dashboard tab

    • Configure one or more patient summary documents in a list accessible from the patient dashboard

    • Support for a printable patient summary (e.g. render with no header or footer, and integrate with printer)

  • Produce a batch of patient summaries for a Cohort of patients

    • Support doing this ad-hoc

    • Support doing this via a scheduled process for off-peak hours

    • Support producing a zip file containing one output document per patient

    • Support producing a separate output document per patient, saved to a particular location on disk

    • Support producing a single output document containing several concatenated patient summaries

  • Support a wide range of data elements

    • Include Obs for a particular Concept for a patient (all, last N, lowest/highest N, for a date range or x days/months)

    • Include Encounters for a patient (limited by type, last N, all, linked to form page)

    • Include particular output if a data value matches a certain conditional expression (e.g. a patient flag)

    • Include current program enrollment data for a particular Program

  • Support built-in summary functionality

    • Graph a particular data element that is a date/value pair over time

    • Produce a table of data elements

    • Support translations so that one summary template can be written to support multiple languages

  • Support nice/easy authoring tools

    • Allow the user to edit the summary template and to see a preview of their changes easily as they work

  • Support personal summary customization

    • Allow users with the appropriate privileges to tweak a provided patient summary and save a personal version that they see instead
1 Like
2

Many thanks for sharing these objectives and recommendations. I’ve reviewed them against the current Visit Summary Requirements (link)—our initial focus will be provider-facing.

  • Alignments: Several of your points resonate with our requirements: (1) displaying clinical observations with filtering (though our suggestion is narrowed to printing the last visit summary), (2) print preview functionality (excellent suggestion), and (3) starting simple and iterating. Take a look at our mockup (link) to see what we’re envisioning for the initial work (and this is also based on the inputs from implementers).

Cost considerations: Considering resource and cost constraints, we’ve began with a compact summary - changes will be made incrementally based on real-world usage and community input.

3

@michaelbontyes @jnsereko @dkayiwa @dkigen @ibacher What’s your view on this one? We’d greatly appreciate your feedback since we are currently preparing our technical specification of printing feature for the MSF.

4

What i have so far seen, works, but complicated, even for developers. Do you plan to develop the ideal solution of a WYSIWYG editor, which combines the wizard concept as well as the formatting concept?

5

To me, the biggest issues to work out are:

  1. Who are we envisioning designing these “printed” documents? Implementers? System administrators? Developers?
  2. What formats are we anticipating supporting?
  3. How flexible should the layout options be?
  4. What white-labeling options exist for the printed documents?
  5. What kinds of documents are in scope for this work? What are out of scope?

I’m not really convinced that there’s a single buildable “printing” feature that will meet every use-case. Instead, I’d tend to think about an EMR needing to be capable of generating certain types of documents and printing is one way in which these documents might be delivered.

That said, from your sort of mini-list of documents, the clearest thing that’s missing is a “discharge summary”, i.e., something that explains to a patient the care they received and any next steps they need to take. The main difference between this a “summary of the patient record” is that it is specific to a visit and the intended audience is the patient themselves.

Apart from that, we also need to print any bills or receipts. We probably need to be able to print some kind of prescription both for med and non-med orders as well as referrals. It may be useful to be able to construct general patient instruction documents that can be printed as needed.

6

Thank you all for your input so far.

I’d like to ask you what do you think about using external tool for creating report designs. Something like Jaspersoft® community edition. In short it would allow to use external application Jaspersoft Studio to design reports. It is backed up by Jaspersoft Community which provides Knowledge Base, Documentation, Forum. e.g. Creating a New Report.

I believe this could make crating reports more user friendly. As right now OpenMRS UI has configuration pages for reports but only in legacy views. You can see all report related views by going: O3 → System Administration → Legacy Admin. And you also need to know what you’re doing as it’s only raw text input, no preview or any hints.

What do you think about this idea?

7

Are you trying to revive the Jasper Reports Module?

8

I didn’t know about Jasper Reports Module. Do you know what’s the story behind it? Why was it abandoned?

9

I think the developer who used to maintain it lost interest in doing so. https://svn.openmrs.org/repo/openmrs-modules/jasperreport/