The medical industry has been struggling for years to determine how to exchange patient information in a uniform manner. Every entity has their own method for piecing together the mishmash of data they collect and filing it away for later use. Now, with governement agencies like Medicare/Medicaid (US) pushing hard on providers to fling themselves into the 21st Century and requires all providers to have EHRs by 2009 there has never been a more pressing need for consistent EHRs.

Enter Laika (http://laikaproject.org); a test suite for Electronic Heath Records (EHR). Laika’s purpose is to support the accessibility of data for providers and patients. Publishers of EHRs using the C32 specification must have their data exports certified by the CCHIT (http://en.wikipedia.org/wiki/CCHIT), which uses Laika for that exact purpose. Laika’s architecture consists of a Rails app up front with Java engines behind for the XML parsing. At this time they only support C32, but with other players entering the market they want to support the CCR standard as well and transforming between the two specifications.

The C32 specification is a combination of of both the CDA (Clinical Document Architecture) spec and CCD (Clinical Care Data). These standards are governed by HL7/ATSM (http://en.wikipedia.org/wiki/HL7), the industry gorilla when it comes to EHRs. A more recent cousin of the C32, the CCR (or Continuity of Care Record, http://en.wikipedia.org/wiki/Continuity_of_Care_Record), has struck the fancy of software behemoths Google in their Google Health (https://www.google.com/health/html/about/index.html) system, and Microsoft’s Health Vault (http://en.wikipedia.org/wiki/HealthVault). The main differences between the two are the document size and detail. As one would expect, the software companies prefer the lighter CCR standard while the industry backs the dense but more verbose C32.

This means that for my projects that as we continue to look at the clinical space we will have to eventually either consume or publish resident information in one of these two standards.

Additional Notes:
would be interesting to see what avenues are open to the consumer market. Google’s plan

NIST provides transform tools
HL7 has a style sheet

August 2nd, 2008 | General, Programming | No comments

After the last article, I discovered that the Drupal framework, while it works perfectly within a SSL context provides little in the way of helping developers direct their users into the secure site. In our application we provide some content to the public at large, but we also require the majority of the site in a private context. This proved challenging because we didn’t want the expense of redirecting the common Joe Browser into the SSL when their casual experience wouldn’t require the overhead. Fortunately, after my last lesson in mod_rewrite I figured a clever approach to pushing authenticated users into the secure context.

RewriteCond %{REQUEST_URI} ^/user
RewriteCond %{SERVER_PORT} ^80$
RewriteCond ^(.*)$ https://example.com/$1 [L,R]

Since Drupal uses the same login section of the site, I was able to push the user under SSL when they went to log in. This doesn’t necessarily prevent them from dropping out of SSL when theyenter the site, but it does mean that they will end up in the right place at the outset.

May 3rd, 2008 | Programming | 2 comments