VA Medical Appointment Scheduling Contest – $9M in prizes

"1.4.5 The system shall have the capability to allow, in certain circumstances, Veterans to schedule appointments via remote access mechanisms such as phone, internet, email and other mobile devices."

"3.5.2 The system shall apply configurable business rules to the management of a long-term appointment request list."

"3.8.2 The system shall have the ability to merge, purge, or distribute scheduled appointments from one resource to another when emergency scheduling changes occur."

"4.1.6 The system shall have the capability to configure and enforce business rules at the clinical service level, clinic level, provider, and appointment type level (e.g., females in Obstetrics/Gynecology clinic)."

At least they've been kind enough to write a web services API for VistA for you to use...

MUMPS has a hierarchical data model. What the genius' at Intersystems call n-dimensional (arrays of arrays, or nested arrays). The reason MUMPS is still used is because the implementers still have hierarchy on the brain and believe that kind of work is best done in MUMPS.

I think they're wrong.

Either way, I can't think of a way to compile generic Java (or equiv) to generic MUMPS. The data models just don't line up.

The HL7 view of the data, which is just a tree graph, can be well supported in languages like Java. I wrote a code generator that compiled HL7 specs to Java code. It was awesome. Because it catches coding errors at compile time. Versus using a dynamic programming language. Or even worse, something like a declarative schema thingie, like all the ETL tools I've seen. (Think Hibernate style ORM for HL7.)

But having done that, I also think that's wrong.

We spent a lot of time reading HL7 (eg lab results), decomposing it for storage into a RDBMS, creating wicked joins to recreate the original hierarchical data, and then send it along (to a data feed or web page report).

I now think medical data should mostly be stored as documents and indexed using something like Lucene. Completely skipping SQL. Using an HL7 code generator & parser like the one I wrote, it's trivial to pull out the bits you care about. And when you have to mimic the single source of truth (eg what medications is the patient taking today?) you can tackle that with a map/reduce strategy.

That idea is a freebie for you, the world, or nobody. I'm not doing any healthcare work any more, so no longer have a dog in that fight.

(1) Few people have little if any understanding of federal government contracting. This solicitation is the norm, get used to it if you want to earn big money in a market where few dare tread. The government is, for obvious reasons, highly risk averse - so fly by night untested products from day 1 startups usually aren't an option. As are products from companies and individuals who don't thoroughly understand the regulatory environment of dealing with health data and the ramifications of having to report directly to Congress because of an app that leaks sensitive data, no matter how inconsequential it may be. To create a winning product, you need to take the time to understand the environment of the VA.

(2) The fact that so many people here choose to complain about the complexity of the challenge means that it is worth doing. They are already ruled out as competitors, and it is a worthwhile cause as many veterans, including myself, would greatly benefit from this type of functionality.

(3) Yes, M is a horrid, horrid language, but there are available interfaces so that you don't have to really touch it (much). There is a fairly robust XML-RPC system in place and some other options for reading and writing data in and out of VistA.