Kevin wrote:
>Jim,
>
>This sounds like you are 90% of the way there.
That may well be true in the sense that we have constructed a foundation and a
framework
to build on such that most of the remaining work can be made in small steps
that should be
relatively easy for programmers familiar with nothing more than MUMPS and VistA.
>The only think I would
>want to add would the ability to put some instructions to the user on
>the screen, and maybe a header that says something like "new patient
>registration".
That sort of thing can be easily added in various ways as needed and it is at
least
partially there already. Here is some text pasted in from Firefox from the
first few
fields at the top of the page of screen 1. (slightly altered for readability)
Patient Demographic Data [page 1]
NAME [DOUGLAS,MIKE RONALD]
SOCIAL SECURITY NUMBER [222992222]
under construction - this is the GET handler for screen 1
NAME Enter name in 'LAST,FIRST MIDDLE SUFFIX' format,
must be 3-30 characters in length.
SEX Enter 'M' for MALE, or 'F' for FEMALE.
DATE OF BIRTH Enter the patients DATE OF BIRTH which must be later than
12/31/1870.
SOCIAL SECURITY NUMBER Enter 9-digit SSN or 'P' for pseudo-SSN.
...
- The first few lines are from the page header common to all
of the patient registration screen. The first line is the
page title while the next two lines identify the current
patient record.
- The next line ("under construction") is a temporary reminder
of the early status of the code. This is the first part of
the body of the page that is produced by MUMPS code that is
unique to each page and to the HTTP method (GET or POST)
sent by the browser. (POST is used for saving data.)
- The text following that is the Field label and help text from
the first four fields of the input form. Both are drawn from
the data dictionary. The help text that you see is actually
not visible on the page except during mouseover on the question
icon associated with each field. Input values are not included
because they don't get picked up in selecting text on the page.
>There might also be an issue regarding when adding a new patient with
>the identical name as someone already in the database. In the
>roll-n-scroll code, this is handled by putting the new name in quotes.
Good point. This question hasn't been addressed yet. However, there are several
ways to
handle it.
I have set up screen 0 for looking up and selecting existing patient records.
After
conducting a search and not selecting a record, the current record identifier
would be
blank so simply switching to screen one and posting it (successfully) would
create a new
record.
Additionally, the Name and SSN fields in the common page header could be setup
as inputs
for a simple lookup from screen 1 or perhaps from any screen. We could also
provide a
button to blank the form and another to submit it specificly for a lookup
instead of
committing it to the database. When starting from a blank form, the label for
the button
to save the data could be changed to something like "Create New Record".
I would like to get input and involvement from programmers familiar with the
current
registration and with the Fileman DBS API's.
>Also, would your code check for values in required fields (i.e. ss
>num, veteran status)? I assume that when your code went to file a
>record that didn't have such fields, that it would be rejected by
>fileman. Would the user be shown such errors?
Certainly. Additionally, it would not be too difficult to handle that sort of
condition
client-side and submitting the data could then be disabled until it is
satisfied.
>I haven't had a reason to get M2Web going at my site, but if this was
>developed more, it might well be a reason to start now. It might be a
>reason to get it included standard with a release of OpenVistA
I think that once you do take the time to become familiar with it, you will
find that you
can make significant progress with far less effort than you have imagined.
>Thanks
>Kevin
>
>
>On 10/4/05, Jim Self <[EMAIL PROTECTED]> wrote:
>> Kevin,
>> I have an experimental routine for M2Web (see
>> http://openforum.worldvista.org/~forum/m.cgi/rtn/htDIQ#form) that will
>> generate an HTML
>> input form for a data record given the file, iens, and fields (essentially
>> the parameters
>> for GETS^DIQ. When the form is submitted, the server receives an array of
>> named values,
>> such as:
>>
>> htInput("DtOfBrth")="08/20/1960"
>> htInput("Name")="DOUGLAS,MIKE RONALD"
>> htInput("Sex")="M"
>> etc.
>>
>> The version on openforum automatically represents set-of-codes type fields
>> with a dropdown
>> set of choices and it uses textareas to represent word processing fields and
>> long text
>> fields. The newest version (not yet extracted from VMACS) presents a popup
>> calendar for
>> date fields and a popup window for lookups on pointer fields.
>>
>>
>>
>> Kevin wrote:
>> >Yes, I know that RPC calls and Screen man calls are different. But
>> >what I would do would be to make a GUI that would make an RPC call
>> >asking for a field stream. The server code would then read the
>> >screenman file. It would send back messages something like this:
>> > -- label at 10,10, value="NAME"
>> > -- field NAME/.01 at 10,15, value="DOE,JOHN"
>> > -- label at 20,20, value="DOB"
>> > -- field DOB/.02 at 20,15, value="01-01-1920"
>> > ...
>> > etc.
>> >
>> >Then the GUI would put these on a form. The user would edit the data.
>> > Then the RPC would pass the results back to the server for filing.
>> >
>> >Yes it would be significant work.
>> >
>> >Kevin
---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
