On Thu, May 29, 2014 at 12:42 PM, Ken Dibble <[email protected]> wrote:
> 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 > > > > > > -------------------- > Not sure that M$ would have ever coded something like this. Gotten a Partner to do it? Yeah that sounds right but they wouldn't get into this situation or that is what my local friends who all work for M$ would say. Have worked on "State" projects before under Arthur Anderson as well as Robert Half. They are never simple, EVER! -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ 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/CAJidMYLb785UTBg-+mNgrvBY=2f6h0huu8gxy0weqjur-fy...@mail.gmail.com ** 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.
