Agreeing with Dr. Johnson that the core document must be one of use cases focused on what is needed to provide optimal health care. Next level down being abstract design, with discussion re a reference implementation being farther last in line.
Just ack'ing that discussions re technology/implementation is a distraction if the core needs use cases and design not fleshed out. ================================== PLEASE, A SIDE QUESTION: I'm trying desperately to sort out if there is interest in the open source world in the type of project our branch is working on, and, if so, where I would find that interest. I would greatly appreciate a few comments from this list re the appropriateness of my trying to push my project's needs into this space as well as any hints re other projects/lists that might be appropriate. Thanks. .... Our branch needs to query and report against distributed data sources, i.e. epidemiology research in which sickness/death correlated with race/age/sex/pop/geo along with pollution indices and other data sources (water tables, wind speed, ??). My fantasy is that the same is applicable down to the health provider in that health provider records [appropriately scrubbed or confidentiality filtered] are where you will see an outbreak first. So health provider records become a primary data source that may be combined upstream into geo/regional data stores, that are then queriable as a federated system. I _assume_ such a system would be applicable to a health provider in that information needed to aid a patient might be obtained from such a data source. As an odd example, my mother (real life) contracted Guillain Barre Syndrome from a flu shot recently and just got out of the hospital (she's able to walk, but barely). Yesterday I heard of another GB case from this year's flu shots. But when my mother first went to an emergency room she was turned away. It wasn't until she lost the ability to walk that she was correctly diagnosed and treatment started. I wonder whether access to large federated data stores of recent symtoms and diagnosis would have caught her GB on the first ER visit? Heitzso Information Technology Branch Centers for Disease Control and Prevention [EMAIL PROTECTED] or [EMAIL PROTECTED] On Sat, 2002-11-23 at 10:34, Daniel L. Johnson, MD wrote: > Christian Heller wrote: > > > > > I wonder if a collaboratively produced set of documents - a Wiki - may be > > > better than a mailing list for presenting this sort of thing? > > > > Yes, a list is definitely needed to do the actual "analysis", i.e. to talk > > about things. But the precious results of discussion are much better > > stored in a (set of) "Requirements Document", may it be Wiki Web Pages > > (I had to find out about what it is at http://c2.com/cgi/wiki) or normal > > files. Using SGML or XML, it is possible to maintain only one document > > and generate many other types (txt, rtf, html, tex, dvi, ps, pdf) from it: > > http://www.linuxdoc.org > > Dear All, > > I would be willing to re-organize and modify the QuickQuack documents as a > collaborative effort. > > I propose the following scheme: > > 1: I break will down this document into sections. After this task is completed > -> (2) > > 2: CVS is already installed on my Red Hat server; the technician who supports > this server offers to configure CVS for use by trusted users; we will plan to > include wrap-arounds so that the document can be viewed either as sections or as > a whole. > > 3: Trusted users will be permitted to make commits that change the document > (that's the whole purpose of doing this). Backups will of course be kept of > both prior and current versions. > > 4: I am assuming that Molly Chean and Christian Heller would be the first > "trusted users." > > Alternative content management systems are probably too complex or fail to > maintain an intact document. > > For example, Red Hat purchased ArsDigita, which produced content management > system CCM; but this requires one server running Oracle 8xx (because of special > SQL extensions required by CCM) plus a front-end machine. This is fine for > Siemens, with 50,000 people, but not for us. > > For example, Zope began life as a content management system, and Zope bits could > be used to build one for our use - squishdot does this - but I think we want to > maintain an intact document, not a change list. > > PHILOSOPHY > > I think that the QuickQuack documents are a useful specification for two > reasons: > > First, this "specification" is small enough for the beginning worker to wrap his > or her brain around. > > Second, this "specification" defines function and ergonomics rather than data > structures. > > Please correct me if I am wrong. > > Thus I see specifics such as data structures and fields off to the right of this > effort, adjacent to it but not within it; and I see organizing efforts such as > openEHR/GEHR as being off to the left, also adjacent but not within it. > > In other words, I envision the neo-QuickQuack as keeping focused on how the user > needs to work, with specific design features included more as examples than as > mandatory implementation. > > If you are interested in this, please reply to me personally, at > mailto:[EMAIL PROTECTED], with a copy to this list as appropriate. > > Dan Johnson -- Heitzso <[EMAIL PROTECTED]> MetaMedia, Inc.
