Hacking at 0300

I use a lot of forms at work. The more paperless the office gets, the more paper we generate. Every school has its own physical exam form, every government agency has its own application form, every screening test is another form for the parent to fill out. And my handwriting is atrocious. So I try to get PDF copies of everything, then use PDF Escape to add text boxes that I can fill in, and an image of my signature at the bottom. But when filling them out, that still leaves a lot of either typing or cut-and-paste from the EMR (electronic medical record) of the patient's name, birthdate, address etc. There had to be a better way, and one that uses only free tools (I'm not buying Acrobat for $400).

Fortunately, Adobe Reader can run a version of Javascript, and we can use that to help fill in the form.

Every PDF includes a /Catalog object that serves as the root object of the document. Normally it just includes a reference to the array of pages, but it can include other things like Javascript to be executed when the document is opened. The syntax is convoluted; it is a dictionary containing a dictionary containing a string:

0 1 obj
<< 
  /Type /Catalog
  /Pages 0 2 R % a standard catalog entry
  /Names << % the Javascript entry
    /JavaScript <<
      /Names [
        (EmbeddedJS)
        <<
          /S /JavaScript
          /JS (
            app.alert('Hello, World!');
          )
        >>
      ]
    >>
  >> % end of the javascript entry
>>
endobj

That's complicated but the coding part is straightforward: take an existing PDF, open it in a text editor and find /Catalog and insert the boilerplate after the /Pages reference, and put in your code. PDF is smart enough to match parentheses, so as long as your code pairs them correctly (you don't have any strings like "We love smileys :)") you don't have to escape them. If you need to, escape them with a backslash. Actual backslashes in your code need to be escaped (write them as \\, since the PDF parser will read the string before interpreting it as Javascript.

This will create an incorrect PDF file, since the xref table no longer has the correct byte lengths. Adobe Reader will correct this automatically, as will PDF Escape, but they compress and otherwise munge up the code so it's impossible to further edit.

See a sample blank page that says "Hello, World".

Continue reading ‘Adding Javascript to PDF Files’ »

For the bililite webservices, I kept all the data in what I would call "standard" American medical units, centimeters for height, kilograms for weight, mmHg for blood pressure, mg/dl for bilirubin. But lots of doctors use pounds and inches, and it would be nice to allow those as well. I could have separate data entry forms for different units, but I decided it would be easier and more useful to allow units on the numbers. I could allow fractions as well (which some of my medical assistants still insist on recording; 21 5/8 instead of 21.625. My EMR blows a gasket with that, but my program would do better). And then, I could allow mixed units, like a weight of "6 pounds 5 1/2 ounces".

I didn't find anything exactly right on the web, but symcbean on stackoverflow had a clever idea for evaluating fractions: turn "2 1/2" into "2+1/2" then use eval.

Continue reading ‘Fractions and Units in PHP’ »

A depressing but absolutely correct editorial from Dimitri Christakis of the University of Washington in this month's Archives of Pediatrics and Adolescent Medicine (behind a pay wall, unfortunately, but the full reference is there).

[H]undreds of decision tools in a variety of forms—guidelines, practice parameters, prediction rules—have been generated. Some have been good, some bad; some have been validated, others not. But what they all have in common is that their overall use remains poor at best. In the meantime, those of us in academia continue to create them and those of us on editorial boards continue to vet them for methodological rigor. The cottage industry of decision tools has at least the appearance of an academic jobs program since, to clinicians in the real world, their utilities remain largely unproven [emphasis added]. For example, there are no fewer than 10 clinical prediction rules for something as common as streptococcal pharyngitis, and I would be surprised if most clinicians even use one.

The big problem is the difference between significance and importance. Significance in statistical jargon is an estimate of how likely the results are to be true (see David Sackett's article on randomized controlled trials) but it says nothing about whether the results mean anything to me in real life. A test that tells me a patient has a 50% chance of having strep throat, when before I would have guessed at 20%, may have a p = 0.0001 (the test is consistently better than chance!). But who cares? For actual clinical practice, things that affect my decision-making need to be orders of magnitude apart, not a few percent. Similarly, a new fever-reducing medicine may have reduced the temperature by 0.1 degree with a really high ?², but isn't going to make me prescribe it.

But real life is rarely so cooperative as to give you high odds ratios, so guidelines based on actual data tend to be less than useful, and guidelines with advice that can actually be implemented tend to be based on "expert opinion," which is a polite way of saying "faith." ("Experience is the ability to make the same mistakes with greater and greater confidence").

So what do we do? The academics would have us analyze every article ever published and determine our own statistics, but that's impossible. All we can do is read the reviews and guidelines and make sure we know which conclusions are solid, and treat them with respect, and which are strongly-held opinions by experts in the field, and listen politely and decide if we think we know enough to overrule them. If the guideline won't tell you the difference, throw it out.

There's still some room out there for the art of medicine.

Update: A perfect example in this month's Pediatrics (Taisan and Copp (2011) Pediatrics 127:119-128). A review of ultrasound to look for undescended testes showed that it would change the probability of an intra-abdominal testis (requiring surgery) from 49% to 64%. It doesn't matter how significant that difference is, it isn't clinically important and therefore the ultrasound is not indicated.

Part of the drudgery of medicine is all the certification and paperwork, and the petty bureaucrats who need to constantly justify their existence by creating new rules. All the rules are well-intentioned, but taken together pave the road to hell—keeping us away from our patients and actually helping people. One such well-paved path is the American Board of Pediatrics which, over the past 20 years, turned board certification from "Take a test" to "Take a test at home every 7 years" to "Take a closed-book test in a secure environment because we can't trust you, every 7 years" to "Take a secured test every 7 years, keep your medical license (even losing it for not paying taxes means you lose your certification), do Board-approved CME, get patient-satisfaction surveys, and do Board-approved quality improvement projects, every 5 years." There's no reason to believe any of this makes me a better doctor but without it, what's the Board for? But enough griping, I may write about this more later.

One of the first things I tried to do when I started at the St. Lukes Pediatric Care Center this fall was improve our asthma management and follow up, so my Quality Improvement project will be the Board's Asthma Practice Improvement Module. It's no different from what I'm doing anyway, with the added fun of filling out data forms online for the Board to adjudicate.

Asthma Management

Asthma is a growing problem in the US, and the NIH has produced a huge (4 MB) report on managing it, with lots of its own jargon. Basically it's a chronic disease that comes in attacks, which can either be in control—only occasional symptoms—or not in control—frequent symptoms. Either way, attacks are treated with rescue medicines, usually an inhaler that relaxes the muscles in the lungs. If your asthma is in control without any other medicines, then you have intermittent asthma. If not, you have persistent asthma and need control medicines to take every day to prevent attacks. The report further divides persistent asthma into grades of severity, but judging severity is inconsistent and largely irrelevant: if your control medicines keep you in control, good; if not, do something more.

Continue reading ‘Better Asthma Care through Technology’ »

My ever-unreliable AT&T 8525 finally had a permanent white screen of death and, rather than be a slave to AT&T forever, decided to get a separate PDA and phone. I bought an iPod Touch and it is a world of difference. Sync'ing it to Microsoft Outlook was automatic (which never quite worked right with Microsoft Windows Mobile!), the software is smooth and slick (everyone knows that), and it even gets daylight saving time right! ePocrates works, and there's lots of medical software out there. The only thing missing is Riley Kidometer, which I was running under a Palm emulator. It gives age-specific parameters for things like height and weight and a ton of other pediatric-relevant information. I'm getting around it with growth charts from statcoder. The only other things I need from that program are peak flows, which I am serving with the bililite webservices, and the EKG parameters. I'll have to look those up and add them to the webservices.

And having an MP3 player is cool, too.

The best part has been Apple customer service. 2 weeks after I bought the thing, I dropped my iPod on the workshop floor. The glass shattered (I know, I should use a case and not keep it in my shirt pocket when leaning over. פראקטיק שולע איז די בעסטע שולע אבער די פרייז איז זייער טייער—Experience is the best teacher but the tuition is astronomical). Made an appointment at the Apple Store, got the lecture that dropping the iPod is not covered by the warranty, and the Apple rep gave me a new iPod anyway. Unbelievable! They definitely have a customer for life now.

And restoring from backup should have been a no-brainer, but the new iPod had out-of-date system software. After plugging the new iPod in, I was offered the choice of restoring from backup. But when I selected it, I got an error message that the iPod software had to be updated first, which meant setting it up as a new iPod (one click), naming it (a few keystrokes), updating (one click), "restoring to factory settings" (one click to let the iPod know I would want to restore from backup), then restore from backup (one more click). Everything, even the placement of the app icons and the web pages I was looking at, was restored. Annoying, but not difficult.

The bane of modern medicine is the paperwork, especially for a practice like mine that is largely Medicaid. If there's anything the government loves, it's paperwork. Fortunately, most of it is available electronically. Unfortunately, most of that is in PDF form, uneditable and closed. Sometimes the bureaucrats have thought to make it a fill-in form, but usually it needs to be printed and filled by hand. With my handwriting, that's a recipe for illegible disaster.

Comes a new website to save the day: PDFescape. It's free (Google ad-supported), all javascript-based (no Flash!), and lets you upload a PDF locally or from the web, then add text or form controls wherever you want, then save it locally. Poof, instant fill-in form! It's smooth, easy-to-use and does exactly what it claims to do. All programs/webservices should work that well.

The Centers for Disease Control and the American Academy of Pediatrics just recommended that pediatricians stop using the old growth charts, based on 40 years of NHANES data, and switch to new charts from the World Health Organization, for children less than 2. The NHANES study is a survey of child health from the United States, and the original charts based on that data was descriptive: the charts showed what the distribution of heights and weights was for American children. That was used by pediatricians to define "normal," to say whether you were overweight or underweight. With the 2000 charts, they decided that kids were too heavy and that we couldn't call that "normal" anymore. So they effectively threw out all the recent weight data, and made the charts based on the 1970 distribution of weight (see page 16 of the original paper) and made the charts partly prescriptive (telling us what they thought the distribution of weight should be) and partly descriptive.

Now they've gone all the way: the WHO explicitly followed an international group of babies who were "were raised in environments that promote healthy growth", including exclusively breastfeeding to 4 months and continuing breastfeeding to 12 months, no smoking, and rich enough to be able to eat well.

I updated the bililite webservices charts to reflect the new charts, but I'm of two minds about the change. As a pediatrician following a kid's weight, I really do want to compare it to "healthy" rather than "common," so the change is for the better. On the other hand, it enshrines assumptions about what "healthy" means without good evidence that children who fall in the prescribed ranges actually live longer, healthier lives. We will get more recommendations for further restricting our children's lives in order to force them onto these graphs.

As these charts get more use, look for more press about increasing obesity, as we redefine the percentile lines downward, pushing more kids over the "overweight" 85^th percentile. It's like the AMT of biostatistics!

I usually don't blog about medical stuff here, but Allie Brosh's comments about the Wong-Baker pain scale are perfectly on-target. The Joint Commission accredits health care organizations and comes up with intrusive, well-intended but largely pointless standards that the rest of us have to uphold. A sort of "unfounded mandate." One of these is the requirement that we document pain levels in every patient on a scale of one to ten. For pediatric patients, we have this "FACES" scale that starts from a big smile and doesn't even get to a frown until number six. I like Allie's much better.

And her comment about not eating red food when you're sick is absolutely right. Never give your kid red popsicles when they've got a stomach bug; you'll just rush into the ER worried that they're throwing up blood.

A simple walkthrough to use the Engauge Digitizer to pull values off a "printed" graph

There's a far more complete manual that comes with the download, but these are the steps I used to generate the data for the webservices graphs. It assumes you've got a black and white image of the graph, with continuous lines for the data and orthogonal gridlines, and linear axes.

Continue reading ‘Engauge Digitizer Tutorial’ »

I wanted to add Down Syndrome growth charts to the bililite.com webservices, but as far as I can tell, the charts are available only as images in the AAP's guidelines (and the original paper; subscription only). The often-cited growthcharts.com has charts, and Greg Richards was generous enough to share his data with me. However, some of the data are from a different study, and he got his data from the original charts the old-fashioned way: with pencil, ruler, and a blown-up copy of the paper. Nothing wrong with that; that's how I got my numbers for the bilirubin chart, but I wanted all my charts to match the AAP's.

So how to get the numbers off the graph? I emailed the lead author of the original paper, but haven't gotten any answer. I can pull the graphs as gif's from the PDF of the paper (thanks to OpenOffice.org and Sun's PDF importer; Adobe's reader seems to get more limited with each upgrade). I was afraid I would have to digitize the graph by hand; I read the cool article on Sudoku recognition and figured I could learn about Hough transforms to get the graph, and 2-D Fourier transforms to remove the gridlines, then blob detection to find the lines. Turning pixels into measurements would be the trivial last step. Sounds like fun, if I had an infinite amount of free time.

Luckily, I found Engauge Digitizer. With almost no time reading the manual, I had it removing gridlines, digitizing the curves on the graph, and exporting values at x-values that I selected into CSV files. It was close to easy. Not quite automated, but with only 4 graphs to digitize, I was done in half an hour. Highly recommended. With my remaining free time, I'll write a quick tutorial so I don't forget what I did.