At 10:41 AM 8/29/2003 +1000, Horst Herb wrote:
On Fri, 29 Aug 2003 08:35, David Forslund wrote:
> division of labor and efficiency in people knowing their field.   You see
> books on how to be a C++ expert in 21 days, but
> not how to be a brain surgeon in 21 days.   I think it is laughable for
> anyone to think they could be a C++ expert
> in 21 days.    I think it is a waste of time for a physician to create
> healthcare-oriented web pages other than providing

I would strongly disagree. I would go that far as proclaiming that the current
misery in health IT is due to the lack of medical domain knowledge in too
many of those dabbling in health IT.


The reason why you can learn to be productive with simple scripting languages
in very short time is - that they are simple. A tool. Like a spread sheet.
Would you say that doctors should not do their calculations in spread sheets
either?

Of course not. Spreadsheets are a general utility. But you shouldn't be expected
to build the spreadsheet application. Things like Plone make
Content Management Systems easy to use. But this is not the same as building
a web page or a system of web pages or a healthcare application.


Your example with C++ is not valid - different league.

So is brain surgery. Or do you think writing good applications in C++ is easy? Especially a distributed C++ application.

Having some physicians become proficient in informatics is a wonderful idea, but
shouldn't be a requirement for all physicians.



The reason why I went through informatics was for the same reason: as a
student in human genetics at that time I was frustrated (same as everybody
else in the department) that the IT guys always blew our budget without ever
delivering what we needed. They blamed us for not delivering the right specs.
We claimed that by the time we go that deep into the nitty gritty with the
specs it will be trivial to implement it ourselves w/o need for the IT guys.

Time proved that our assumption was correct: in less than two years a handful
of geneticists (me among them) learned enough IT to solve all our problems to
our complete satisfaction. I was the only one to continue with IT from that
bunch (and later changed again into medicine), but the others are still
proficient enough to *solve* their day-to-day computing needs with minimal
extra effort.

I applaud the effort.


But this doesn't help in the larger interoperability problem. A patient's record
is acquired from a variety of locations and circumstances. Pulling it together
today is a nightmare. If we did a better job at following good IT principles and
worked as a larger group of IT, we could also have good interoperability.



Lesson learned was that it takes a lot longer to introduce a domainless
software engineer into highly specific domains (such as medicine or genetics)
than to teach the respective domain specialists enough software engineering
to solve their problems themselves.

I don't think this is true in general. To create a distributed medical record system needs more work than simply solving my own problem in my domain. Without a broader coordinated effort, the patient ends up suffering.

I think good software engineering is not as simple as you indicate. The
statement I made refers to this issue.

This doesn't mean that a person can't be both a good physician and a
good software engineer. But people shouldn't trivialize the software
engineering task. And every physician shouldn't feel they have to be
a good software engineer. The publications at the bookstore lead one
to be believe that there isn't much effort involved in being a good software engineer.


What I've observed is that software engineers frequently fail to talk to the domain
experts to see what they need. This seems to be especially true in healthcare.
This needs to be a tight coupling, not simply throwing a few requirements over the wall.



Mind you - that was at a  time where we had to write hundreds of thousands of
lines in Fortran (!) without access to any reasonable software libraries at
all - guess what the evolution of programming tools means for that lesson.

When were you doing this? Better tools than Fortran for doing this have been around a long time.


Dave


Horst



Reply via email to