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.

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.

We'll use the bilirubin risk levels from the AAP bilirubin guidelines:

1. Open the digitizer

   You can't use Open with... from the context menu because the program expects filenames as part of the options; you can read the manual to see how to modify the context menu. Click Import on the toolbar: and select your image file:

   

   Save your work (it's a .dig file) often. You don't need me to remind you.

2. Set the axes

   Click Axis Point in the toolbar: and click on the origin (lower left corner) of the graph and enter the x,y values for the origin in the units of the graph (not pixels!). Usually that's (0,0) but can be anything. Click on the maximum of the y-axis (upper left corner), then the maximum of the x-axis (lower right corner).

3. Remove the grid

   Select Grid Removal... from the Settings menu. Select "Remove thin lines parallel to the axes" and play with the "Minimum line thickness" until the gridlines are gone from the preview on the bottom but the real curves are still there.

   

   Now the grid is gone and digitizing the curves will be easy:

   

4. Create curves

   Select Curves... from the Settings menu. Create as many curves as you need (we have three). Give them descriptive names if you like:

   

5. Digitize each curve

   Click Segment Fill in the toolbar: . For each curve, select it from the curve menu: and click the points on the graph for that curve until it is covered with points. There's no undo command. If a wrong point is included, use the Select tool: to select the bad points and use the Delete key. To add individual points, use the Curve Point tool: . In a few clicks, you have the fully digitized graph:

   

6. Set up the export

   If you exported the data now, you'd have lots of points; probably far more than is justified from the original graph. Decide which x-axis values should be exported (the program will interpolate appropriately if the digitized points don't land exactly). Select Grid Display... from the Settings menu:

   

   The values to be specified are related by count = (stop - start)/step so you only need to specify three; select the one you don't want to specify from the Disable dropdown menu. Make sure that the start and stop values are actually in the curve; the program will happily extrapolate off the curve but it's probably not scientifically legitimate. Ignore the y axis grid lines.

   Select Export Setup... from the Settings menu. In the Points Selection section, select Intepolate Y's at gridline X's.

   

7. Export

   Click the Export icon in the toolbar: . Pick a name and you now have a CSV file with your data. Simple, no?

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.

I want to get it to parse the Accept: header, so users can leave out the file extensions, but it looks like browsers don't implement that correctly, so I'll have to keep using extensions as well.

I still need to learn more about caching and effectively using eTags and all the headers that go with it. It always makes my brain hurt.

But those of us for whom the computer is mother's milk, and whose handwriting is somewhere between chicken scratch and Linear A, we'd rather do it all online. I've been writing my admission notes for a few years with a Microsoft Word template, printing them out and putting them in the chart, with nary a problem. And the medical records department clearly used PDF's for the pages, both the blank order sheets and the preprinted, fill-in-the-blanks "standard orders" since they were available on the hospital intranet. So let's create PDF's with actual editable text boxes and check boxes (these are mockups, but they look right):

The response from medical records: not an option. It's too hard, inserting all those textboxes by hand on all those lines, and they don't "possess the very expensive software that makes this possible." They had to go to the graphic arts department to use their copy of Pagemaker. And any change means having to put all those controls back in the form again, by hand.

Never tell me something on the computer is impossible. I have teh l33t hax0r ski1z! The expensive software problem is easy to solve; OpenOffice.org Writer can generate PDF's, and a little experimentation shows that form elements are preserved. The "too hard" problem should be solvable, too; Writer is scriptable and I've scripted Microsoft Word with VBA often enough; how hard could it be?

Famous last words.

Scripting Microsoft Office is like pulling teeth; Basic is verbose and tedious, and the documentation for the object model is sparse. But scripting OpenOffice.org is like pulling teeth with your eyes closed. The documentation (the bane of all open source software) is virtually nonexistent; the macro recorder (so useful for Microsoft Office) records the user interface interactions, not the underlying object model; and there is no object browser to explore the methods and properties of each object (there is the xray tool to look at objects one at a time as part of a macro).

So I just went to the documentation wiki and dived in, spending a few hours browsing, trying to find a place to start. I'd recommend the BASIC guide and the Introduction to UNO, which is Sun's answer to Microsoft's COM and the basis for the OpenOffice.org document object model, then the BASIC Binding chapter to put them together. The documentation of the object model is near impossible to find but it's there.

You really need to be able to read Java to understand the rest of the documentation, since both the examples and the underlying concepts are in that language. I wouldn't use anything but Basic, though, since it abstracts away all the underlying interface querying and dispatching and type casting.

The code I developed is here; I'll blog about the things I learned as I get the time.