Hello all,
        I just wanted you to update you all with the design decisions that I am
trying to make right now. I am strongly leaning towards perl, mostly
because of a single module.

        Parse::RecDescent. This will essentially allow me to implement a
"little billing language" to handle billing. 

        The reason for this is historical. Medical Manager uses a (very poorly
implemented" billing language. The question is why would they do that??
The reason is that to fill out even the simplest form, simple logic is
needed. This logic is trivial if statements and loops. There is
definitely not heavy lifting going on here.

        But consider the alternative... How do I give non-technical people the
ability to generate a form. When filling out a form is a data-driven
logical process?

        Consider the simple case of the Male/Female Box! On line #20 in column
40 is the Box labeled "female" on the same line in column 44 is the
"male" check box. Based on whether a patient is male or female, the form
engine has to check the correct box.

        But this logic could have other implications, perhaps slightly
different formats are used for male and female patients. In this case
the LOGIC of male vs female could drive totally different behavior...

        This is classic case for a little language. Filling out a form is 90%
simply putting data into the same place, with about %10 LOGIC driven
variation...

        My current design calls for both the 90% and 10% to be encoded into the
same XML file.

        The major benefit of doing it this way is three fold. 1. It makes it
easier for people to donate forms without having them betray their
favorite general language (grin) 2. Non-Hardcore-Programmers will
eventually be able to easily modify forms via a (someday not now) GUI
interface to the billing code 3. It will be trivial to convert Medical
Manager Format definitions into the new system. My Uncle and Aunt have
written hundreds of programs in Medical Manager language. This serves to
scratch my own itch, as well as give us a starting point far farther
then we would if we used another implementation. 4. of my three points
(what ????) is that it makes it a somewhat Perl independent project. If
another language would obviously work better then we can just migrate
the interpreter... The formats will remain the same!! 

        Does anybody on this list have little language experience? Help here
wold be appreciated.

Fred Trotter

        




Reply via email to