Solution for Patient Report

OpenEMR Development
1

sunsetsystems wrote on Wednesday, October 03, 2012:

A client gave me the task of generating the patient report as a single PDF.  This is very desirable to speed things up (avoiding conversion of PDF documents to JPEG), to create output that can be stored as a file onto removable medium, and for clean printing of the output.

The big challenges here are merging in the patient’s PDF documents, and converting HTML to PDF format (HTML is generated by all encounter form reports as well as demographics and history).  After quite a bit of searching I found some open source PHP classes that can do this:

1. TCPDF, a class for working with PDFs.  LGPL license.
2. HTML2PDF, a class that extends TCPDF and which does what its name suggests. Also LGPL.
3. FPDI, another class that extends TCPDF and can merge PDF files into the PDF that you are building. Apache 2 License.

These classes should be very handy for working with PDFs in other parts of OpenEMR, and they are a life-saving solution for the problem described above.  Any objections to including them in OpenEMR distributions?  It would be difficult for a user to install them otherwise.

Rod
www.sunsetsystems.com

2

tmccormi wrote on Wednesday, October 03, 2012:

This problem was sort-of addressed in the code that Sherwin Gaddis provided for patient reports.  Although the code itself was not so great, the tools for PDF were good and work fine.    Take a look (again) at this branch
https://github.com/tmccormi/openemr/tree/gaddis-pdfnotes-410

Here’s the thing, we (MI2) has been working on PDF printing issues for a while and the HTML 2 PDF tools only work for very simple things and are REALLY useless for complex forms output.  I ahve posted info about using pdftk for stamping pre created PDF forms for example.

The only real way to solve this problem is to use a PDF class library and drop the HTML crap altogether for printable material, it weak and it’s ugly and it not easy to make work across browsers.  Don’t scrimp on this, write a nice looking NATIVE PDF formatted report, not just a PDF conversion of the really crappy looking HTML report we have now.

Just my two bits… thanks
-Tony

3

sunsetsystems wrote on Wednesday, October 03, 2012:

Tony, which HTML 2 PDF tools have you tried?  What I’m looking at is here and seems to be very highly rated and active.

Rod
www.sunsetsystems.com

4

tmccormi wrote on Wednesday, October 03, 2012:

We’ve tried all of them, including that one.  But the real issue is the converting a bad looking HTML output to PDF is just a useless thing do.  IF you what to do that, install any print to pdf client side tool and use that.   If you’ve got a chance to create a nice looking patient report that is produced in PDF format, write a new one from scratch and make it look like a real medical report with page headers and footers and nice graphical formatting.   Please don’t stuff the project code with a bunch more stuff to produce mediocre results.
-Tony

5

sunsetsystems wrote on Wednesday, October 03, 2012:

Changing the way it looks is a big deal and would need to be a task for some other time, when there is funding.  My goal right now is to get it into a single PDF without making it look worse, making it storable as one file, and (this is critical) making it run in seconds rather than hours when there are many patient documents!  I would hate to see the community miss out on those improvements.

Rod
www.sunsetsystems.com

6

deschel wrote on Wednesday, October 03, 2012:

In one of my future projects, I am hoping to create pdf reports of data.  I have not done much research on this yet.  But ideally I envision following Tony’s approach. 

Performing a straight conversion of html to pdf is usually not pretty.  Also, there are a lot of formatting issues.  I would think that it would result in very unpolished, unprofessional reports.  Also, would this really do much more than someone hitting the print button when they are viewing a screen?

The question is, how much less time is involved in creating pdf’s using html to pdf conversion versus creating reports direct to pdf.  If only a little more time is needed for the latter, it would be better to invest the time upfront to do this so that you can do it “right” and it would make things much easier down the road when you or others need to create other pdf reports. 

There are too many areas of OpenEMR where things were not done “right”, do you want to add to this?

I would think that there are libraries out there to help with creating pdf reports without doing html to pdf conversion.  My guess is that there are probably even libraries/code for creating pdf reports of MySQL databases.  However, I have not gotten to the stage of researching this yet.

Also, if you do it “right”, your client will be happier with the end result.  If he is reticent of spending more money, perhaps, god forbid, you can negotiate a discount on your rates to make it more enticing for him-this would be for the sake of making OpenEMR better.  This discount might not be a loss, because you can leverage this coding to get other clients/business for other people who might want to do similar things.

The lack of good pdf report/export functionality in OpenEMR is a big hole that will need to be addressed in the future.  Therefore, there should be a lot of future programming business for doing this.

-David

7

deschel wrote on Wednesday, October 03, 2012:

Tony,

What is wrong with using TCPDF to create the pdf?

It is a set of tools for creating pdf’s in general, not necessarily just for html to pdf conversions.

This might be useful for creating pdf reports of anything.  Why recreate the wheel?

Or, do you know of other pdf creation tools that might be better?

-David

8

mike-h30 wrote on Wednesday, October 03, 2012:

Is anything wrong with the current EZPDF class? I have been using the EZPDF class for custom PDF creation of CAMOS, SOAP, and forms output.

Mike

9

sunsetsystems wrote on Wednesday, October 03, 2012:

Again, this is not a project to “fix” the formatting of patient reports.  That’s a MUCH bigger task and I have no budget for that.

EZPDF won’t do for this because there is no HTML-to-PDF conversion for it and no feature to insert a PDF.

Rod
www.sunsetsystems.com

10

tmccormi wrote on Wednesday, October 03, 2012:

Rod,
I suggest you keep it for you customer for now.  I don’t think this solution is ready for prime time,
Tony

11

sunsetsystems wrote on Thursday, October 04, 2012:

Tony for crying out loud you haven’t even seen it yet.  I have code for my client to test and HTML conversion works just fine.  The PDFs look pretty much the same as the HTML.  Reports with big documents work that did not before.  Will post on github after more testing and refinement.

Rod
www.sunsetsystems.com

12

bradymiller wrote on Thursday, October 04, 2012:

lol,
I’d like to look at the code and test it out (ie. review it) first before making any real suggestions/recs…
Looking forward to seeing the code.
Another thing to be aware of is internationalization issues. You’ll note that in any place that offers pdf in OpenEMR that html format is also offered. This was done as part of the internationalization project because html automatically supports special utf8 encoded characters (such as chinese characters and even special spanish characters), while pdf does not (all special characters become garbage). Otherwise, I really have no input until I see the code and test it out.
-brady
OpenEMR

13

sunsetsystems wrote on Thursday, October 04, 2012:

OK we’re getting close!  There are 3 commits of interest, found here:

https://github.com/sunsetsystems/openemr/commits/ptrep

The HTML parser for this stuff is more sensitive to malformed HTML than is a normal browser, so we may encounter some things to fix in that regard.  But I wanted to post this up so y’all can try it out and report any problems.

Also I ended up using the FPDF class instead of TCPDF.  HTML2PDF and FPDI both work with either, and FPDF is much smaller than is TCPDF.  Hopefully this will lessen the objection to “a bunch more stuff”.  :slight_smile:

Rod
www.sunsetsystems.com

14

kevmccor wrote on Friday, October 05, 2012:

I don’t really understand the code, but it looks good.  I think I like it.   Just some commentary here.

I hope you or someone will put explanatory documentation in the file, especially custom_report.php.  It looks like the output buffer is obtained by the php function ob_get_clean() and fed to the html2pdf functions.  So there has to be a certain sequence or you will get more or less than you want. 

IMHO, the webpage in general wastes a lot of paper when printed.  Screen layout is just not the ideal format for printed layout.  Many people prefer print-outs for working, especially those who do not have a tablet surgically attached.  Also, anything that has to be printed and faxed, especially demographics and physician notes, would greatly benefit by having a clear compact print layout.

A question: Why can’t you just go through a series of database queries, append the results to a string (with some formatting perhaps, like tab, bold, etc.), and then put that through the pdf class?  Is it really a lot of coding?

Thanks

15

sunsetsystems wrote on Friday, October 05, 2012:

That’s a fair comment about documentation, though perhaps a separate document describing how to use the enhanced HTML2PDF class would be better.  Yes ob_start() combined with ob_get_clean() captures the output that would otherwise be sent to the browser, and is just an awesome tool for things like this.

When a PDF document is encountered or the end of script is reached, the HTML up to that point is captured and fed to HTML2PDF in this way.  Then for a PDF the features of the FPDI class (which I integrated into HTML2PDF) come into play, as it provides the ability to insert pages from an existing PDF file into the PDF that you are building.

What’s really nice is that the output PDF is built in a single pass, without having to use any temporary files or command line tools.  It just works.

True that screen layout is not ideal for printing.  However note there’s a separate CSS file style_pdf.css that can be tweaked to make it nicer.  I didn’t spend much time on that, basically just copied style_oemr.css and changed the fonts.

Yes, rewriting all the report logic for PDF output is a LOT of coding and design.  Note that every single encounter form would be affected.  It’s a good thing to do, but is beyond the scope of this job.

Thanks for the comments.

Rod
www.sunsetsystems.com

16

bradymiller wrote on Friday, October 05, 2012:

Hi,
Looks good to me (placed a couple issues to be fixed on github before commit). An issue for the future will be getting this to support internationalization, which can likely be done as the html2pdf v 4.x matures a bit and is discussed here:
http://www.open-emr.org/wiki/index.php/Html2pdf
-brady
OpenEMR

17

sunsetsystems wrote on Friday, October 05, 2012:

OK, I added a cleanup commit and pushed to sf.  Thanks!

Rod
www.sunsetsystems.com

18

arnabnaha wrote on Saturday, October 06, 2012:

Hi…
I tried the new PDF report in the demo site…I found that after generating the pdf, the extreme right side part of the documents gets cut off/ not shown in the adobe reader or any other pdf reader. Its kind of a problem as printing them also shows nothing there and only half of the data….

19

sunsetsystems wrote on Saturday, October 06, 2012:

Hi arnabnaha, looks like the Vitals form is throwing it off - if I leave that off it looks good.  Probably I just need to tweak the CSS for that.  Thanks for the report.

Rod
www.sunsetsystems.com

20

tmccormi wrote on Saturday, October 06, 2012:

Well FPDF is slightly better, but as you note, still has issues.   This commit does not address my concerns nor the feed back from the rest of the community.    I would appreciate it if you would actual NOT commit features where there are objections until those have been worked out.  

I stand by my suggestion that this solution is not ready and, now, should be reverted in favor of a real update to the patient report output model.   Just because a customer wants it does not make it worthy of this community project.

-Tony