[EMAIL PROTECTED] wrote:
> the problem is trying to understand the breakdown of costs of $2 million. 
> This 
> would fund 10 developers
> $200, 000 biannually each , to do what ? re-invent a wheel ? do they need to 
> go 
> around to each major hospital
> and examine the hospital information system, and do integration for each one 
> of 
> them ? e.g. do the
> message-orientated federation bit on hundreds of applications ?
> - or is  20,000 dollars for each of 100 functional points API , and legislate 
> that hospitals have to pay a big fine
> if they don't meet a 1 year deadline for integration to the API ?
> Or maybe it's 200,000 dollars each to 8 board of directors, and 60,000 
> dollars 
> each to 3 developers.
> Sounds like a more real life division of work.

Assume average $200k per annum per person with on-costs etc (really
smart people don't come cheaper than that unless they live in Mumbai or
Manila). Also, we want 10 or 12 hours days from these people.

FTE=full-time equivalents, ideally comprising individuals working full-time.

Project manager x 1 FTE (articulates the overall direction and vision,
responsible for assembling the functional specifications, and for
detailed daily oversight of project, bug tracking, etc etc - *the* key
person for the success of the project).

Project admin/assistant manager x 1 FTE (handles the paperwork, helps
with bug tracking etc)

Analysts/programmers x 4 FTE (initial light-weight design phase of a
month or so, then using agile/iterative development model, with daily
"scrums" to check progress etc)

Software testing/QA co-ordinator x 1 FTE (programmers write their own
unit tests for everything they do, under supervision of this person, who
is also responsible for higher-level integration tests and functional
tests - all tests automated and repeated continuously as development
proceeds).

Field testing co-ordinator x 1 FTE (iterative development means having a
panel of volunteer testers to provide feedback, such a panel is not
self-organising)

Technical writers x 2 FTE (documentation, user manual, online
interactive training modules)

That's about $2m over 12 months.

Role delineation is only nominal - it is important that everyone at
least knows about all other aspects of the project - that's why a
smallish team is essential.

There also needs to be a 2 or 3 month phase before all that to develop
the broad functional specs. Much work has been done on that in the past,
but it needs to be refreshed and reformatted. Also involves careful
examination of all extant systems to see what features should be
emulated. Plus pulling together all interfacing and other standards
which need to be observed. Probably need a team of 3 or 4 people,
including the project manager and assistant and one or two of the
analysts programmers during this phase.

Once completed, the non-profit foundation that holds the IP and
co-ordinates maintenance and extension of the software might have a
salaried staff of two or three plus a budget for hiring contractors etc.
However Board members would be honorary positions as befits a non-profit.

There's more to it than just writing programme code, Syan, although
ultimately the quality of the code and the quality of the design and
vision that that code implements is what really counts. But
co-ordination and project management is needed, as is someone whose sole
purpose is testing and QA, and the technical writers creating the
documentation and training materials for end users and system admins etc
are absolutely key, and the person organising feedback on the design and
implementation as it evolves is also vital. In other words, the whole
team is needed. Programmers alone not enough.


Tim C

> On Tue Apr 3 10:44 , Tim Churches sent:
> 
>     syan tan <[EMAIL PROTECTED]
>     <javascript:top.opencompose('[EMAIL PROTECTED]','','','')>> wrote:
>     >
>     >  oops, wrong here as well. It's not bad ; it is probably strongly bound
>     >  to the underlying middleware zope and plone, but the organization is
>     >  not clueless. It's a little different from gnumed .
>     >  For instance, it has a consultation and a progress note, and a
>     >  procedural report section ( eg echo, stress test). the consultation
>     >  and progress note section look identical, single text box entry
>     >  but associated with a date field and a doctor field. The procedural
>     >  report section looks like what the consultation section should look
>     >  like, e.g. with free text boxes for every aspect of a medical report
>     >  with the option of importing existing information in each section
>     >  e.g. past history, medications, allergies .
>     >  The script section does look like a database row entry, but is as
>     >  simplified as what is normally usable, e.g. free text drug name,
>     >  free text script instructions, with boxes for quantity and repeats,
>     >  and script validity date. It also adds some script mx functions such
>     >  as retirement of medication and reason for retirement.
>     >  The immunization and allergy sections look not done.
>     >  The results and documents section look like file upload screens
>     >  with metadata entry, but the results section gives the hint that an
>     >  attempt will be made to parse the file uploaded for metadata
>     >  information, such as which patient, and category of result.
>     >  There is a section for entry of vital signs;
>     >  recalls are called health maintenances , with three fields , recall
>     >  date, type of recall, and reason for recall / eh .. health maintenance.
>     >  The appointments section is adequate too - it has 3 views,
>     >  month by hour, giving rapid overview of available appointments,
>     >  multiple doctors view for the secretaries, and single doctor's view
>     >  for doctors, pretty much basically what we get in oz.
>     >  So it is better than openemr, and it looks like several months work,
>     >  given it might have gone over one iteration, unless the guy
>     >  who did it worked it out on paper first, and worked within the
>     >  limitations of his platform, which is what it looks like, so it
>     >  could have been several weeks work.
> 
>     Yes, yes, fine, OK, whatever, but the political point that I am trying to
>     make is that building a capable and very sound open-source primary care 
> EMR
>     for Australia is *not* a few afternoons work, not even for Horst, but 
> *nor*
>     is it a $100 million exercise. It is, instead, about 8 to 10 person-years
>     effort by half a dozen smart people working full-time on the project over
>     the course of 12-18 months of calendar time, at a total cost of $1.5 to $2
>     million. I can think of no more cost-effective investment to improve of 
> our
>     nation's health than that, because it would save hundreds of millions by
>     simplifying the creation of shared EHRs and other initiatives, and it 
> would
>     provide an open platform for a whole range of decision-support, quality
>     assurance and public health program plug-ins. And much more.
> 
>     Tim C
> 
>     >  On Tue, 2007-04-03 at 07:01 +1000, Tim Churches wrote:
>     >  > Well, that's its name. It is a new, open source, Web-based EMR for 
> the
>     >  > US market, based on Zope and Plone, which are intriguing but probably
>     >  > quite sound choices for infrastructure (uses an object database, not 
> a
>     >  > relational database - makes much sense for clinical data). See
>     >  > http://www.uemr.com/index.html
>     <parse.pl?redirect=http%3A%2F%2Fwww.uemr.com%2Findex.html>
>     >  >
>     >  > Probably not usable as-is in the Oz setting, but yet another
>     >  > demonstration that it *is* possible to create viable open source
>     >  > clinical apps with very modest investment. They mention "four years 
> of
>     >  > effort", probably by one to three people - thus around 10 
> person-years
>     >  > of effort. That's around $1.5-2.0 million of investment. Would be
>     >  money
>     >  > well spent by a govt agency or even a private philanthropic concern 
> in
>     >  > the Australian setting (or even sponsorship by a private health
>     >  > insurance company - what better way to promote yourself but to have
>     >  > posters in GPs' waiting rooms say "the computer software used by this
>     >  > practice is proudly sponsored by...". No need to wait 4 years: half a
>     >  > dozen smart people could do it in 12-18 months, with increasingly
>     >  > polished prototypes to show off and get active feedback at monthly
>     >  > intervals along the way. That's what Australian patients and health
>     >  > professionals deserve.
>     >  >
>     >  > Tim C
>     >  > _______________________________________________
>     >  > Gpcg_talk mailing list
>     >  > [email protected]
>     <javascript:top.opencompose('[email protected]','','','')>
>     >  > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>     
> <parse.pl?redirect=http%3A%2F%2Fozdocit.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fgpcg_talk>
>     >  >
>     >
>     >  _______________________________________________
>     >  Gpcg_talk mailing list
>     >  [email protected]
>     <javascript:top.opencompose('[email protected]','','','')>
>     >  http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>     
> <parse.pl?redirect=http%3A%2F%2Fozdocit.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fgpcg_talk>
>     _______________________________________________
>     Gpcg_talk mailing list
>     [email protected]
>     <javascript:top.opencompose('[email protected]','','','')>
>     http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>     
> <parse.pl?redirect=http%3A%2F%2Fozdocit.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fgpcg_talk>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gpcg_talk mailing list
> [email protected]
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to