Back to all discussions

  •   over 10 years ago

Goal Clarification

There seems to be two goals here: 

One, to produce a system that enables veterans (but not VA employees?) to make, break, change appointments.

Two, to find ways to migrate the current scheduling system to something more modern. 

Re goal 1, I suppose the UI would surface in MHV? And is the idea for the CRUD the vet does to go directly into Vista, or would it first be monitored by a VA employee with final say? In other words, when the vet makes the appt is that end of story, appt made, or is it just a request and the appt is not made until a VA employee okays  it?

Re  goal 2, this a bit nebulous. The end game with this goal is evidently a completely new scheduling system, that's pretty clear. And of course VA cannot expect contestants to produce same by June. I assume, then, the idea is to have some software that demonstrates to some extent the migration strategy but it is that strategy that VA is looking for?

  • 7 comments

  •   •   over 10 years ago

    To go along with Joe G's questions, I have a few of my own to add. I looked up what modules VistA had, but I couldn't find any. Is there no original schedule module, or is it all home grown?

    What's the current problems WITH scheduling? Is it a problem with rescheduling? With access lists, between VA employees and the veterans themselves?

  •   •   over 10 years ago

    I might be able to speak to your second question Johnny. The core, humungous problem with current scheduling is that it is completely inside Vista - including the UI, which is all roll'n'scroll. There may be other problems that arise from this one, lack of ability to add functionality, say, but basically, VA needs to get this out of VistA. Well, at least the UI and business logic. It's conceivable the data could remain in Vista, though it will need refactoring as well. Appointments, for example, do not have their own global but are multiples of both the Patient file and Hospital Location. That said, while an argument could be made that POC data should be in Vista because of its speed, that same argument would not pertain to moving scheduling data into an SQL (and thus easier to manage) source. IMHO, of course.

  •   •   over 10 years ago

    So, the contest doesn't require us to remove that functionality from VistA, then? Meaning, we can completely ignore how the current scheduling works and just use the one we develop? No worries about integrating them?

  •   •   over 10 years ago

    First, I need to make it clear I do NOT speak for the VA. I'm not an employee or involved in this contest - just some guy with opinions, which I hope VA will confirm or correct.

    Now, scheduling is not just scheduling. Other things are tied to it, like workload. Beans are not counted until an appointment is closed. Is that how things should be? I dunno. Maybe you win this contest by changing that, by demonstrating a better trigger to count beans. Maybe if you do that you lose. And workload, I believe, is not the only other domain affected by scheduling. One thing seems clear, however. This is not a simple scheduling app. You will have to handle the other areas one way or another.

    As always, IMHO.

  •   •   over 10 years ago

    Oh, I know that you don't speak for the VA, Joe G. But this contest has been very, vague, in what it specifically wants. Right now, it seems like the best bet is to just read through source code while actually running an instant of VistA to see how it works.

    And I agree with you, it looks like this module will have to play well with the other parts of VistA, though again, it seems to be unknown how extensive this will reflect to other modules, and if they themselves need to be changed to use a newer form.

  •   •   over 10 years ago

    I believe the vagueness is intentional, perhaps unavoidable. I believe what's being requested is a way forward, a plan. And I believe VA leadership is being open regarding that way forward. So if you believe bean counting, say, should not be contingent on scheduling, and can convince VA you're right, maybe you win. Or vice versa.

  •   •   over 10 years ago

    Well, I'm not sure I completely agree with you as they seem to want a working example, like a drop-in for current environment and people to be on their way. In another thread discussion, the moderator stated that the VA doesn't care what environment the development is done in, just that it works:

    "VA leaves the choice of any particular programming language or technology completely to the judgment of contestants. The only requirements that need to be satisfied are those already published in the contest announcement."

    The part where "Scheduling of inpatient, surgical, and extended nursing care is excluded." may be more of what you consider unavoidable, as that should be considered as well, if ALL scheduling types should be considered to completely overhaul the scheduling system.

Comments are closed.