The clinic was open for the first of the two days it will be open during my stay in Xela. It was a pretty crazy scene — a line going to the end, if not around the end, of the block.

We had Isabel, the local intake/registration person, working with my sister Shelley to do registrations, after which the patients were sent to Jorge, who war running triage. Dr Meg Sullivan treated the pediatric patients, while Irv and one of the local doctors handled the adult patients. Within a half hour or so, the makeshift waiting rooms upstairs and downstairs in the clinic were packed with waiting patients. One thing I did notice was that the children were remarkably well behaved — much more so than children their ages in the United States.

American Airlines, never striving to be the speediest in baggage recovery, still hasn’t delivered the bag containing the primary server. As I haven’t had any actually setup or installation work to do, I spent my time alternately documenting methods, coding some pieces for FreeMED which would handle some of clinic’s various registration and triage functions, taking pictures for fundraising use, and doing basic gopher tasks for the doctors and nurses. It’s a little disconcerting that we aren’t able to get people trained up on the system yet, but it’s just going to have to wait until their server comes in.

Another hurdle is the wiring. There isn’t really any “modern” electrical wiring, in that most of the circuits aren’t grounded at all. Most look like they barely have any sort of insulation over their conductors. The clinic has a little bit of money for supplies and such things, so we may end up having a UPS purchased to attempt to shield the servers from the somewhat inconsistent wiring and power grid there. The laptops can probably function with simple surge protectors, since they have their own sort of “UPS” through the use of their batteries.

Well, apart from an emergency colo flip for work (which I’ve been up until a little after midnight local time performing), I’m looking to get some shut-eye, as we’re heading out to the pueblos early tomorrow morning. I think that I’m going to be a little less useful than I have been in the clinic, but hopefully I can glean some further “best practices” and workflow in such a way that I can make it easier for the docs to do their jobs.

Update for those who were waiting for pictures: I’m in the process of uploading some pictures from the POP-WUJ clinic to a Flickr set, so check my Flickr account early Wednesday morning or so to see the first batch.

I ended up passing out on top of the sheets in the hotel due to the tired state in which I arrived, but today was full of plenty of excitement and activity.

We walked down to the clinic after breakfast from the nice people at Casa Mañen. The clinic is, to my knowledge, the only permanent free clinic in Xela, and has a few permanent staff members in addition to the volunteers who come down with the “medical brigades” (as Jonathan calls them). I spent the majority of the morning organizing components and parts for the systems after American Airlines confirmed that they found our primary server and that it would be here Tuesday morning (tomorrow). My sister Shelley went with me, as my Spanish is just about as good as my Greek (which is to say, non-existent). We were able to ride the “micro buses” to take us out to purchase a SIM card for the T-mobile Android phone which my sister-in-law loaned me for the trip, as well as scoring some replacement parts and some webcams.

As a quick aside, if you’re looking for Ubuntu support for the “Manhattan USB Webcam”, don’t. It uses the gspca driver’s pixart_pac7311 driver, from what I can divine, but the USB ids aren’t present in the stock driver, so it’s going to be a fairly painful process to get support worked in, especially since the gspca is in the mainline kernel now …

Getting back to the day’s events — We were lucky to have taken the microbuses, at a bargain rate of 1.25 quetzals a person, since it started raining again. I, of course, had no rain gear, but my backpack is/was waterproof, so the laptop and camera remained safe. Everyone was amazingly friendly, even to the point of walking us to a store when we didn’t understand their directions. I also tried to be friendly with a few of the feral dogs, but they mostly kept their distance, probably because I didn’t give them any food. Better that way, Natasha wouldn’t be very happy with me bringing home another dog.

In the afternoon, we set up the four donated workstations in the clinic, but rearranged them to function as inventory collection workstations for the pharmacy for some short term data collection, mostly due to the clinic being open and overbooked on Tuesday. We used Google Docs to create a quick and dirty web form with some simple constraints as a frontend to a shared spreadsheet for drug collection. This was done since we still don’t have the primary server, and I decided on “bulk loading” the drug data into the system later on, to save entry time.

I have learned a great deal from the clinic staff and volunteers about not only clinic and pharmacy work, but also about some of the problems with operating in conditions which are less than optimal, including so-called “distance medicine” work in extremely rural areas. Tuesday, I’m planning on observing the clinic operation to see if I can streamline any parts of the interface to help facilitate ease of workflow and smooth adoption a little. Wednesday, we’re headed to the pueblos outside Xela so that I can watch the distance medicine teams, and attempt to figure out the best way to bring in data (as well as provide access to data) in extremely remote and poorly connected areas.

I’m struck with just how much I have in common with the doctors, nurses and other volunteers here in Xela; they all seem to have a pervading sense of need for social justice and feel that a little effort can make a difference. I wish there were more people willing to staff places like this.

In comparison, there are shops here selling American goods and foods at prices that are on parity, considering the exchange rate to dollars, with what they would cost in America. Then I realize that the average pay here in Xela is something like 35 to 40 quetzals … a week. (That’s something like five American dollars.) Once you start to think about that, the social support systems in America don’t really seem that bad. We spend a lot of our time taking for granted things like even and well maintained sidewalks, relatively clean air through use of emission controls, and even basic animal control… Guess you don’t miss them until you visit a place that doesn’t have them.

As part of setting up the POP-WUJ Clinic in Xela, Guatemala with an electronic medical record, I have headed down with a team of ten other volunteers to the city of Xela in western Guatemala. I’m going to document the trip and the work we’re doing down here by a series of daily blog entries chronicling our trials and tribulations setting up and installing FreeMED there. I’ll post pictures as soon as I get the chance to upload them to Flickr.

Day One: Planes, Trains, and Automobiles

We left Connecticut last night around 11:00-11:30pm, and picked my sister up in upper Manhattan a few hours later. Along with us were a few Rackable Systems servers, kindly donated by SGI and some laptops donated by my employer, as well as an assortment of donated medications and medical supplies. Shelley flew out on a separate airline from us, but we all ended up arriving in Guatemala City around 12:15 pm local time.

From there on in, we took a chartered bus/van the 170 km from Guatemala City to Xela, through the mountains. It’s pretty poor in a lot of these areas, but what struck me as odd were the armed guards at convenience stores and banks, as well as the razor wire surrounding those same banks. There were also a lot of stray dogs, some in packs, some idly following people around looking for scraps. The “chicken buses” were old US school buses which had received chrome and paint jobs, usually packed with riders, even to the point of having the overflow spilling out the doors. Our driver Pedro was very nice, and took us to a restaurant on the “Intra American Highway”, which served delicious food.

American Airlines lost one of the bags, unfortunately containing the primary server. I’m planning on deploying the workstations we brought with us and doing any additional wiring which may be required. After that, if the bag hasn’t surfaced, I’ll promote what was supposed to be the redundant backup server to the role of being the primary EMR server and will proceed with the remaining steps of our installation. The POP-WUJ crew is able to give me help doing translation work for the EMR, as well as fleshing out the necessary functions of their day-to-day workflow. Hopefully, we can fine-tune the system to work like a well-oiled machine.

It looks as though choosing Rackable Systems is going to pay off, as I’m most likely going to finish up configuring the backup server using the serial console “roamer” port with my handy USB to serial adapter and null modem cable.

Thanks to Google Voice and Google Talk, I’m able to communicate with friends and family back in the states without breaking the bank, and they can contact me. On the downside, I miss my wife, and I’m sure she, along with the dogs and cat, misses me too.

I was talking with someone this morning about ARMs and the sort of financial havoc they have been wreaking upon a population who was assured that they would be able to refinance before the “adjustable” portion of the mortgage kicked in. During that conversation, I realized the reason why banks were so interested in getting people into ARMs, and it didn’t really have anything to do with trying to weasel houses away from people.

Adjustable Rate Mortgages usually have a rate adjustment that kicks in after a few years. Quoting the fed: “With most ARMs, the interest rate and monthly payment change every month, quarter, year, 3 years, or 5 years. The period between rate changes is called the adjustment period. For example, a loan with an adjustment period of 1 year is called a 1-year ARM, and the interest rate and payment can change once every year; a loan with a 3-year adjustment period is called a 3-year ARM.”

These “financial products” have been sold with the idea that buyers would want to refinance with a traditional “fixed rate” mortgage before the adjustable period kicks in. For borrowers who would not otherwise qualify for a traditional mortgage, this gave a way to increase credit score through timely mortgage payments as well as the ability to “own” a house. (Not that any of this stuff is “owned” until the bank isn’t able to take it away for sometimes arbitrary reasons, but whatever…)

I contend that their intent is to keep people from owning (and I do mean owning as in “don’t owe the bank money”) their own house by minimizing the amount of potential equity in their houses. They can accomplish this by the way that mortgages work — at the beginning, virtually none of your monthly payment is applied to the principal (increasing equity), and at the end, almost all of it is applied to the principal. But — what if you never were able to get beyond a few years in a mortgage, as banks push for loans which have to be refinanced quickly to avoid financial penalties? This way, banks get your monthly payments and have to yield very little equity before the loan is renewed or sold to another vendor, at which point the bank receives the remainder of the money beyond the smidgen of equity they have yielded to the borrower. It’s almost like printing money. And we bailed these guys out, why?

In addition, my “financial advisor” pointed out that in order to refinance, if you obtain an new loan for the exact amount to payoff the existing mortgage you still have to suck out more equity because with closing costs, points, new mortgage title insurance, et cetera. You are going to end up borrowing an additional four to seven thousand dollars more just to get out of the old deal, not including any fees for pre-payment penalties. So, often times people are just stuck because they don’t have sufficient equity to refinance, or the cash reserve to refinance out of the deal (especially with the 80/20 deals that were so popular in the early 2000s).

I have been recently been trying to redesign FreeMED (my opensource GPL’d EMR/PM system) in order to work in a “clustered” environment, so that I could support scenarios where multiple application servers were load-balanced to handle larger quantities of traffic. The latest piece of this has been to move filesystem-based storage into the database layer so that I don’t have to mess around with clustered file storage and replication. Some of the highlights of this have been:

• Database-based session handling – At least when dealing with stateless applications like FreeMED, session information has a bad habit of being confined to the local filesystem. We ended up using PEAR’s HTTP_Session2 to support database-backed sessions. I can’t help but think this would be so much easier using JAAS …
• API abstraction – Don’t write this one off too quickly. A good API layer means that whenever you have to make these sweeping changes, you’re only playing with a few files of source code, as opposed to completely rewriting a good chunk of your codebase. Without the few layers of API which I had been using, I would not have been able to implement the database backed information store which I just completed.
• Database backed file store – This was the part I had just finished up. Storing files locally and relying on filesystem-based replication from some of the new clustering filesystems may *seem* like a good idea, but it’s not. Database gives you a single authoritative source, and unless we’re looking at multi-gigabyte files, there should not be an appreciable toll. Besides, you indexed your tables properly, right … ?
• Design for concurrency – That record locking may seem like a pain, but two people working on the same object can be catastrophic. Take the time to add a locking field if you have to.
• Singletons – Take “singleton” processes into account, so you’re only running a single iteration of something which can only be run once.

Those are the major bullet points, although I’m sure that upon review of this, I’ll think of some other design paradigms I had to play with to get this to function properly. Off to enjoy the weekend …

In 2007, I had posted a patch for the ADS DVD Xpress DX2 device to work on Linux, but it had been based on an antiquated kernel version, etc.

Since then, someone was nice enough to post an updated version of the driver, but without DVD Xpress DX2 support. I put together a patch which ensures that the drivers now compile and use the new I2C and V4L2 APIs. I can’t guarantee that it works, only that it compiles the driver properly now. Theoretically it should work, but I can’t find my DVD Xpress DX2 to try out the hardware properly.

• Original driver :
• Patch : wis-go7007-linux-098-5-20100325.diff

I do not like camera phones in the same way that I don’t particularly care for flash photography; you can produce good results (or at least passable results) with either, but the majority of stuff that comes out of it is just pure crap.

I recently moved to one of Sprint’s CDMA Android offerings, the HTC Hero. I just finished the flashing/rooting process, since I don’t particularly care for devices that try to lock me out of their own functionality. (The key to doing this with the “newer” Sprint CDMA Hero phones is apparently using an older version of the recovery image and making sure you have enough available memory to run the image flash, but that’s beside the point.) This particular device came with a 5 megapixel built-in camera, and though I know that resolution != quality, it does seem to produce *passable* images. Not great, but passable. I’m hoping to see an improvement when the CDMA Hero sees “official” Android 2.1 support. This OS version fragmentation is bunk, but at least I can upgrade as soon as the pieces are available for another model. Suck that, closed source technology.

Am I giving up the 40D? Hell emphatically *no*. But I can capture a few things I might miss fumbling for the camera bag. At least, I hope I can.

I have just wrapped up (no pun intended) work on an initial version of a CLI JasperReports wrapper, based heavily off the work of jasperCall. It’s also quite similar to the work being done on RunJasperReports, although it was specifically designed to be integrated into FreeMED’s reporting engine, as it is put together as a fatjar. It currently supports PDF, XML, XLS and HTML output, and should theoretically support parameter passing, though I haven’t tried it out yet. It has a newer version of MySQL Connector/J baked in as well, so it shouldn’t require any external libraries outside a standard JRE install to function properly.

The code can be check out of anonymous Subversion from if anyone is interested in building it. (It obviously should require Java 6 JDK to compile properly.) Hopefully I’ll get around to tagging and releasing versions of it for download shortly, if anyone shows interest in it.

I’ve decided to do a little feature on films that I liked for one reason or another, and to start out, I have chosen a scifi/comedy flick from the 1980s called The Adventures of Buckaroo Banzai Across the Eighth Dimension.

It’s a pretty funny send-up of scifi movies which take themselves too seriously. I think that after watching it, it’s pretty apparent that none of the actors were told that it was supposed to be a comedy. Peter Weller plays the entire movie completely straight, which makes his lines all the funnier. John Lithgow was very funny, in his strange and quirky way.

It was apparently very difficult for the studio that owned it to release “Buckaroo Banzai” because of some legal issues, but it finally made it to DVD in the last few years.

• iMDB Link
• Netflix Link

The simple recipe is to add this to root’s cron:

* * * * * /usr/bin/gmetric -c /etc/gmond.conf -n pf_states -v $(/usr/local/sbin/pftop -b | grep pfTop | cut -d/ -f2 | cut -d, -f1) -t int32 -d 120 2>&1 | logger -t pf_states

and install the pftop package along with a gmetric binary and a working /etc/gmond.conf configuration file. It might be advantageous to check for the maximum number of states as well.

In addition, you might want to know which pf rules are passing how much traffic. A nice easy way of doing this is to create this file as ./pfstates (make it executable, of course):

#!/usr/bin/perl
# pfstates
# jeff@ourexchange.net
my $limit = shift  || 0;
 
my $seg = 0;
my @s = [];

while (chomp( my $line = )) {
        $s[$seg] = $line;               
        if ($seg == 2) {
                $seg = 0;
                if ($s[1] !~ /States: 0/) {
                        my $states = 0;
                        if ($s[1] =~ m/States: (d )/) {
                                $states = $1;
                        }
                        if ($states >= $limit) {
                                print "[$states] $s[0]n";
                        }
                }
        } else {
                $seg  ;
        }
}

…. then you would pipe pfctl’s state output to it:

pfctl -v -s rules | ./pfstates

Optionally you could add a “minimum level” of connections you want to see:

pfctl -v -s rules | ./pfstates 100

for example to see only rules passing 100 or more active connections.