On Sat, 2003-02-08 at 14:08, [EMAIL PROTECTED] wrote: > Tim: > > <<I think that is an excellent exposition of the effects of scale, and I > agree with everything you say. My only comment is that any project with > more than 10,000 function points is just too large, and the Big IT > bosses need to learn to be content with smaller successes (but more > often).>> > > Just as a point of reference Microsoft Word is approximately 5,000 function > points. Linux is approximately 50,000 funtion points and Windows Xp is over > 100,000 function points in size. > > What if the EHR is really a large software project (ie, over 10,000 function > points) and it requires a different way of thinking about the software > engineering process to succeed? What if large software requires a > qualitatively different way of thinking and managing to be succesful as > opposed to the way small or medium projects are done? Then perhaps the > reason why most of the big IT projects in healthcare fail is because most of > the people involved in managing and thinking about them have only been > involved in small or medium projects and don't realize that a different > approach is necessary to succeed at large projects.
Well, I think that a comprehensive, community-wide EHR is ultimately going to be a very big project, and any attempt to constrain it to something less is bound to fail - there will be irresistible scope creep as more and more stakeholders become more and more interested as the project progresses (you can guarantee they will be disinterested at the early design/scoping phases), and there will be unavoidable scope creep as the true complexities of the security and privacy issues become apparent. Even if the scope creep doesn't occur in the first fielded version, it will in subsequent versions. Thus, any attempt to build a community-wide EHR using traditional top-down design and development methodologies and a traditional rigidly specified, "hard-coded" software architecture is a) highly likely to get into difficulties (cost and time overruns, and technical problems getting the whole massive edifice to work) b) exponentially rising maintenance (which includes extension) costs thereafter. Luckily, there's the OpenEHR project (and GEHR before it), which recognised these truths from the outset. Instead of designing and implementing ever more elaborate, baroque data structures in a vain attempt to accommodate the labyrinthine complexity of health information and of the social relations between healthcare providers and consumers, OpenEHR describes a methodology for creating, and more importantly, evolving and maintaining information models, together with a relatively simple (and thus verifiable and debuggable) software kernel to implement that methodology. The kernel is being developed using fairly traditional methods, but at this stage, I don't think anyone can say exactly what the development model for entire OpenEHR systems will be, but it sure won't look like any traditional IT development models (thank goodness). More like the Linux model, but with health professionals instead of geeks and nerds (and not just nerdy/geeky health professionals as hang out on this list), so there will be differences. All we need is the OpenEHR kernel. It's coming, I know. Tim C
