Re: [Gnumed-devel] re: rschedule

[Syan Tan]

I was hoping that demographics entry when using a oscar / gnumed system is via the

gnumed demographics entry form. The oscar page visible to the front desk is a copy and modified

appointmentprovideradminday.jsp , with some of the tabs cut out, and mainly just the appointments

and possibly resources stuff.

I was thinking it was easier to just intercept the page flows , where you actually intercept

is at web/demographics/zdemographicssearchresult.jsp.

Here , a query is built out the request parameters, e.g. search by name, dob  health id number, telephone number, address,

and a result set is returned, and wierdly, a  "while (rs.next() ) { " block is started but not  closed !

this file is included into the demographics/demographicssearch2apptresults.jsp  script, and the

formatting for the result rows is returned, as well as continuation buttons next and last so that large result sets

can be viewed in blocks.

 

line 205  demographicssearch2apptresults.jsp 

<script language="_javascript_">

var fullname="";
function addName(demographic_no, lastname, firstname, chartno, messageID) { 
  fullname=lastname+","+firstname;
  document.addform.action="" //+"\"" ;
  document.addform.submit(); //
  //return;
}

<%if(caisi) {%>
function addNameCaisi(demographic_no,lastname,firstname,chartno,messageID) {
    fullname=lastname+","+firstname;
    opener.document.<%=request.getParameter("formName")%>.elements['<%=request.getParameter("elementName")%>'].value=fullname;
    opener.document.<%=request.getParameter("formName")%>.elements['<%=request.getParameter("elementId")%>'].value=demographic_no;
    self.close();
}
<%}%>
</SCRIPT>

line 247 , demographicssearch2apptresults.jsp  , this occurs after the  "  while(rs.next() ) { "  in the include file zdemographicsearchresults.jsp

      <td><input type="submit" class="mbttn" name="demographic_no" value="<%=rs.getString("demographic_no")%>"  if(caisi) { out.print("addNameCaisi");} else { out.print("addName");} %>('<%=rs.getString("demographic_no")%>','<%=URLEncoder.encode(rs.getString("last_name"))%>','<%=URLEncoder.encode(rs.getString("first_name"))%>','<%=URLEncoder.encode(rs.getString("chart_no"))%>','<%=request.getParameter("messageId")%>')"></td>

 

what  seems the easiest thing here , is to substitute the ResultSet object  rs , to return a  aliases select from

gnumed's demographics database.

 

the next intercept point is the  | E     hyperlink that follows an appointment where there is an associated  demographic.

this is seems to be from line 828 in appointmentprovideradminday.jsp ,

which issues a incomingEncounter.do action, and from the struts-config.xml

 <action input="/StartCookie.jsp" path="/oscarEncounter/IncomingEncounter" scope="request" type="oscar.oscarEncounter.pageUtil.EctIncomingEncounterAction">
      <forward name="failure" path="/oscarEncounter/error.jsp" />
      <forward name="success" path="/oscarEncounter/Index.jsp" />

calls  oscar.oscarEncounter.pageUtil.EctIncomingEncounterAction which sets up the

encounter page ;  change the action here to a gnumed xmlrpc calliing action , (have to see if this

is possible in java easily),  then the success path can be back to appointmentprovideradminday.jsp page,

or some intermediate restoring state page.

the idea is that you are mainly using the appointments module of oscar, plus

a demographic search facility that is adapted to a gnumed demographics backend to retrieve basic

demographics details.

you can also intercept the add demographics, by calling a xmlrpc which pops up the add new demographics,

in gnumed.  For a receptionist , they are also running gnumed but with the demographics mainly enabled,

and not much of the clinical input part.

 

Your alternative , is to write a export module for oscar demographics, that automatically export and new

and updated demographics to gnumed after some demographics updates and inserts have been done,

but I think this requires more work.

 

On Sat Jul 1 1:38 , James Busser sent:

> On Jul 1, 2006, at 12:20 AM, Karsten Hilbert wrote:
>
> >> Someone needs to decide if it is desirable to try to link the  
> >> appointments in
> >> oscar to gnumed,
> > I would think so.
> >
> >> and
> >>
> >> then what is the desired mechanism to notify the gnumed applicaiton,
> > I'd suggest using the XML-RPC interface but it's up to you guys.
>
> Part of this discussion depends on identifying whether we are talking  
> about patients being created plus having their appointments made in  
> Oscar, passing to GNUmed any patient activations --- which is what I  
> think we are talking about.
>
> So in this approach, the office (surgery) reception and managers  
> would almost always be working inside Oscar for reception and patient  
> identification. Maybe some would input clinical information and  
> results into GNUmed.
>
> Doctors in the practice would use a hybrid of Oscar with GNUmed might  
> normally navigate inside Oscar while working through the appointment  
> list but could have dual options of searching for patients through  
> Oscar (which would move a GNUmed instance to the linked patient) or  
> could flip into the GNUmed instance to work on a different patient,  
> who could remain the open patient in GNUmed until the user moves  
> within Oscar.
>
> I am not savvy enough to get inside Oscar's appointment objects  
> (whether each appointment is an object, or collection thereof) which  
> are presented in the Oscar browser. Even so, each appointment offers,  
> beyond its toggled "status", the following that can be clicked
>
> - edit appointment information
> - an E for Encounter
> - an M for master demographic record
> - a B for Billing and an
> - Rx for prescribing
>
> each of which should be able to reference the patient's master  
> demographic id number (Oscar's internal unique identifier).  
> Therefore, apart from editing the appointment information then,  
> whichever of E M B and Rx that is chosen, it should be possible to
>
> - extract the master Oscar id
> - pass it, via XML-RPC, to notify GNUmed that a patient has been  
> selected, and cause GNUmed to test whether the patient exists and  
> accordingly move to them, or to create them from the Oscar  
> demographic info
>
> The above could, with the agreement of the Oscar people, be  
> incorporated into the Search-Edit/Create demographic code plus the  
> Appointment code without having to make any changes to the Oscar data  
> structures. The main oscar preference file, which resides on the  
> server (it is the oscar.preferences file) could be altered to contain  
> one extra parameter xmlrpc= yes to control whether or not this extra  
> code gets actioned.
>
> Whether or not the E(ncounter), M(aster demog), B(illing) and Rx  
> buttons keeps users in Oscar, or jumps them into GNUmed (or anything  
> else), could also be specified with the oscar.properties info,  
> something like xmlrpc = (any of) "EMBRx" with a default of ""
>
> I think the above would be much tidier than to aim to store in  
> Oscar's appointment table (or any other Oscar table) any external  
> references. I believe GNUmed already has a place in its backend that  
> could be borrowed to store the Oscar patient id.