VA Medical Appointment Scheduling Contest – $9M in prizes | Hacker News Reader

VA Medical Appointment Scheduling Contest – $9M in prizes

vascheduling.challenge.gov

71 pointsdanso40 comments

$3 million is enough to make me think crazy so after looking through the spec for a while I downloaded VistA to get an idea of how hard it would be to build something in M and integrate it.

To get a flavor of it, here is a random selection from one of the 913 files making up their current scheduling system (said file helpfully named SCAPMC8P.m, pretty much like all the others):

SCDATES2,SCN2,SCPTP,SCX,SCXA,SCXE,SCNA,SCNE,SCPRCLST,SCPRCPTR N SCP1P11,SCP12,SCP13,SCP14P16,SCR N SCLIST1,SCLIST2,SCN3,SCN4,SCPS,SCPSX,SCPSXA,SCPSXE,SCVALHIS ; S @SCLIST@("PR","CH")=$$VALHIST^SCAPMCU5(404.53,SCTP,"SCVALHIS") G:'$$ACTHIST^SCAPMCU5("SCVALHIS","SCDATES") PRECQ G:'$D(SCVALHIS) PRECQ

Who doesn't love MUMPS?

Ah, yes. M: the language of indirection, post-conditional goto's, period indented block levels, and strict left-to-right order of operations (2+8*10=100). It doesn't require writing code as unreadable as this, but it sure doesn't discourage it.

Would writing a DSL that compiled down to MUMPS be out of the question?

Maybe.

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.

A few years ago, I did some health IT stuff (implemented 5 RHIOs which included 80 hospitals plus various partners comprising roughly 300 data feeds).

I played with VistA. Thought maybe I could steal some of their fire. At the time, the VA was getting a lot of props for turning their act around and VistA was considered no small part.

MUMPS.

I will never willingly work on MUMPS.

I had to do a bunch of Intersystems' Cache, Ensemble, ObjectScript work. Inspired by MUMPS (the communities overlap). Complete garbage. Remember how a coding error can bork (brick) a SmallTalk runtime? Welcome to Intersystems. But without the benefits of a debugger, undo, version control, real database, an actual grammar and compiler, or rational people creating and supporting the product.

I mention Intersystems because as bad as it is, MUMPS makes it look slick.

Please understand that I am completely, utterly committed to universal healthcare with a single payer in the USA. Medicare/VA for all.

But if it means the infrastructure running VistA + MUMPS, I'll probably vote against it. (And I don't know if I'm joking.) I just can't imagine an IT migration to VistA finishing before the heat death of the universe.

From the website under Judging - section b:

<quote> Judges will determine the number and amount of monetary prizes. Judges may determine that no prize will be awarded. </quote>

I've created a web-based calendaring and scheduling system that integrates with a number of cloud services including google calendar. It also works offline and provides a solid foundation for a lot of what they are asking for.

I'm passionate about calendaring and scheduling, and I've been heavily involved in this space for a long time. However, I just can't bring myself to task switch to this and risk 4 months of evenings and weekends when a judge could determine that no prize is to be awarded - or award some small pittance.

In my spare time I'm building a new product to spawn a new division in the fortune company I'm working for. My chances for providing a good stable life for my wife and children are far better at my current employer.

It saddens me to pass on this.

It's not just a scheduling, there are a bunch of legacy systems you have to integrate with. And of course it's health data, so there are more requirements.

Anyone want to burn three months on an unpaid spec? :)

Man, contests like this seem like a bad idea for everyone involved. Solicit bids, take 2 million dollars and get a prototype/demonstration of capability from your top 4-8 options. Review the submitted work and communication each contractor provided, select the one that you feel the most comfortable with and just pay them to make the damn thing.

My understanding is that they've done that already, and that the delivered solutions fail to meet their needs.

A couple of points from the OP:

* The replacement product will, as a part of the overall VistA EHR, deliver privacy, security, data integrity, patient accessibility, interoperability and other services required by federal law, regulations and VA policy. Many of these services are delivered by other components of VistA.

* VA intends to replace the current MSP with a scheduling product[1] which is a standards-based, modular, extensible and scalable, certified as compliant and fully interoperable with the production version of VistA now held by the Open Source Electronic Health Record Agent (OSEHRA), http://www.osehra.org/.

So the app won't have to replace everything...and it may get away with interfacing with some of the more easily interoperable aspects of the system. The main goal behind the contest is "To encourage development of systems that help Veterans schedule appointments to receive care from the Veterans Health Administration and to reduce risks in the future procurement and deployment of those systems"...which is vague enough to include a range of ancillary software services. And I doubt the federal contractors who likely receive much bigger amounts to maintain legacy systems would want the VA to install a system that makes them obsolete.

And on a more subjective note, large sums of money have been awarded to other government ChallengePost winner that were essentially proofs of concept and are barely functional today, if ever heavily used.

This is badly needed. Appointments can take longer than two weeks. For example, if a veteran has PTSD and cannot get immediate care when they're experiencing an anxiety attack that lasts for more than a day, it can result in extreme consequences such as suicide.

I want this so bad. I once tried making an appointment for severe pain and was told three months and there was nothing sooner. They told me if I was in severe pain, I could visit my local ER, pay, and submit paperwork for reimbursement. I informed them that I could not afford that option and asked if they were going to treat me for alcoholism because I was going to drink myself to sleep every night for the next three months... I was then told, "Oh, how about next Tuesday. We have a number of reserved appointments that we can assign for high-need cases."

WHAT!?

This is a ridiculously open-ended spec, and there's a mountain of federal legislation to comply with. I might go as far as to say that it's a reckless way to try to procure software, as it's very much a product which needs to work and be supported over the long term, not some sort of black-box AI quick win.

To which legislation in particular are you referring? I often see this claim on HN, but I do not think that most people here have any real understanding of the situation.

As an anecdote, I work on a medical information system for emergency rooms. The VA uses our system in some locations. Federal regulations are not at all onerous. Things like HIPAA are dealt with using a few really basic rules.

I agree with your sentiment, but the contest rules state

"The replacement product will, as a part of the overall VistA EHR, deliver privacy, security, data integrity, patient accessibility, interoperability and other services required by federal law, regulations and VA policy."

without citing anything specific either.

A summary of those laws, regulations, and policies (and specific pointers to them) would help potential entrants get a real understanding of the situation.

Frankly, standard best practices for software development are far beyond what is common for healthcare software. The sentence that you quoted sounds more like ass covering than anything else.

Besides HIPAA, it is possible this software would need to comply with the VA's "6500", their internal information security handbook, as well as meeting relevant FISMA / NIST requirements (see http://csrc.nist.gov/groups/SMA/fisma/index.html ).

Again, the system on which I work is used by the VA. I cannot imagine that any of these regulations are any more onerous than standard best practices in the industry.

Reading the functional spec, I'm having a really hard time figuring out how this could be built for $3mm, even with mostly offshore resources. Unpacking just a few of those line items is a huge amount of work, and there are >100 of these:

"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...

Money aside, the schedule of the contest is way too aggressive given the long list of requirements; some of which are quite vague.

This actually is pretty cool. It's a rather low cost way to get functioning systems for the government. They are emulating the VC's approach to get products off the ground, minus the upfront funding.

The lack of upfront funding might discourage a lot of potential entries. It might be better to run this as an iterative process. A minimum qualifying round to narrow the field of candidates. Then lightly fund the resulting teams in the next round. Evaluation at another checkpoint weeds out the non-performing teams. And fully fund the last couple entries. Then select the winning entry at the end, and award the long term contract to the winning entry.

This way would be fairer to all parties involved.

If working at a major DoD contractor taught me any anecdotal lessons about software development for the government, its that you are basically disqualified, by logistical means, from making software for the government if the dollar amount in question is anything more than a drop in the bucket for your budget. That may just be a DoD reality, but I wonder how true it probably is for Federal entities.

I'm with markus2012 here. I have a profitable product already in place that would give me a significant head start on those requirements, but I'm still not at all prepared to head down that thorny trail.

It's not too bad in my experience. Though in my case, the Federal agency granted the money to a local agency and they were pretty much hand-off since then. I work with the local agency to build the product and they have been great. We set requirements, feature, and schedule together, and they left it to me to manage the entire development process. I convinced them to do a XP-like iterative process to get involved and give feedback. It had work well.

If they actually get involved actively with the teams for this competition, I think they will get good result.

If you read people's comments here two things are obvious:

(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.

(1) Guilty as charged. How would one go about learning the environment of the VA?

(3) I found some web services they set up for scheduling, but with minimal functionality. And from the specs it looks like new data structures would be required, and I'd think those would have to go in VistA rather than being held in some external database. Is that incorrect?

Here's the result of their previous attempt at replacing this system (with financial breakdowns):

https://www.va.gov/oig/52/reports/2009/VAOIG-09-01926-207.pd...

@_@

"If an individual, an entrant must be a citizen of or permanent resident of the United States". You have already lost 96% of contestants who could have contributed.

Not necessarily. How hard would it be to find an American person to collaborate with who can represent the group?

Not hard. Email me. (Do I get a bonus for veteran status? :D )

Same here. As a user of the VA system this is very much needed and only the tip of the iceberg.

User as in, you're a veteran, or you work for the VA? What problems do you see with the current system?

Assuming I understand the conditions, you can apply either as an individual (in which case you have to be either a citizen or PR) or an incorporated entity.

Shame, I have a lot of spare time and I'd be up for an interesting project (not sure if this qualifies, I've only skimmed it).

Leaving plenty of qualified people in the 4%, and avoiding a "government gives our jobs to India" PR disaster.

But if won by an Afghani or Iraqi it could be a PR win.

This is required by federal law. Contractors are required to reside in the US or be a US citizen. There is no outsourcing in the federal government for obvious security, quality, and political reasons. It is one of the reasons that while many large tech companies are/were laying off gobs of people in their US divisions the survivors were notably for the most part working on government contracts.

$3million? They should go with http://www.makeplans.net instead: starting at $10/month :)

I think the point of the contest is to spur innovation and fresh ideas in a system that's clearly lacking in that department, not just to build a simple "scheduling app"

Its all pointless, unless they scrap the legacy crap build a new system piecemeal. It is the legacy crap that has the current system snafu. I'm a vet and I can tell you this is a waste of yours and my time without a total solution that asses the system as it exists now, throws away what sucks and is broken, and build anew.

Reply on news.ycombinator.com