Thanks everybody for your enlightening comments so far.
Boy..a lot of traumatized people out there!
Remember, this is not a "specification", it's a "feeler". A clear
specification certainly would be issued before anyone is asked to bid.
Perhaps a bit of background would help:
Currently the state's developmental disabilities service agency has a very
big, very complicated web-based document-management/workflow system called
CHOICES. It is based on some MS proprietary web application development
software whose name I can't recall right now. It was developed about four
years ago and its use is mandatory for thousands of people working under
contracts with this state agency. It only works in IE versions 7, 8, and 9.
It doesn't work in the two most recent versions of IE. It doesn't work in
any other browser. MS promised some pointy-headed IT guy that the system
would be "updated" to work with other browsers but it never was. The
underlying MS software itself is not even being updated in a timely
fashion, BY MS, to work with its most recent platforms. And the agency
itself has no budget to keep the application updated.
The system I'm talking about is not anywhere nearly as complicated as this
example, nor will it require anything like the amount of data storage or
user concurrency as this system. The CHOICES system is an example of what
can happen when somebody depends on a big proprietary software house for
stuff that needs to be kept current.
"Commercial solution" providers lie. They make promises they have no
intention of keeping. So yeah, if the developer who builds it can't be
bothered to keep it updated in a timely fashion for a reasonable fee, you
bet your ass we would want to be able to find another developer to do that.
And yes, there might not be money for updating at some point. In which
case, no updates would be expected. What's the problem?
Now, for the system I'm describing.
It's a data warehouse for querying and generating reports. Data uploaded to
it will contain no personal identifying information, just surrogate primary
keys to keep the records separate. Therefore it has NO HIPAA compliance
requirements. I have researched HIPAA extensively; I do it all the time.
There's a big difference between what CYA lawyers, and paranoid IT
Department heads, think HIPAA "requires" and what it actually does require.
Uploads would be via CSV or perhaps XML files. Not hourly, daily, or
weekly. Perhaps quarterly. Perhaps, at most, monthly.
This is not a "medical" application. The data to be stored consists mostly
of demographic stuff that changes over time, and very simple dated service
"events".
It's not a real-time end-user data-entry system. It's designed purely to
accept periodic bulk uploads and enable queries on the data it stores.
Number of sites uploading would never reach 100. Number of people who need
to query the data would never exceed 200. Very little of this access is
likely to be concurrent.
Again, a state agency would purchase this. It is not going to be resold.
The flexibility thing: For example, we want to be able to report on the
disabilities of the people served. Suppose today we have a list of 20
disabilities: arthritis, spinal cord injury, diabetes, brain injury...etc.
Now next week the state agency adds five more disabilities to the list. The
system needs to be able to accommodate that sort of thing as a
"configuration" issue, not as a hard-coded feature of the interface or the
back end. There could be various sets of other specific data points in the
categories of, for example, income ranges, or race/ethnicity categories, or
education or employment levels. I already do this sort of thing all the
time with my main system. It's not very hard, but it does require forethought.
The system needs a flexible query system in order to cross tab any number
of demographic data points with each other or with service data. Also stuff
we've all done, also requiring forethought.
It will also need some minimum number of hard-coded reports, and more would
need to be added over time, for a fee.
That's all. No secret hidden agenda to rip off hard-working developers here.
Do you people make a lot of money by distrusting and bad-mouthing potential
customers when they come to you with ideas??
Jeez people, take a breath. :)
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
