gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: another xDT file format and BC Canada


From: Karsten Hilbert
Subject: [Gnumed-devel] Re: another xDT file format and BC Canada
Date: Mon, 13 Jul 2009 18:50:36 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Jul 13, 2009 at 09:11:17AM -0700, Jim Busser wrote:

> On 12-Jul-09, at 11:20 AM, Karsten Hilbert wrote:
>
>> One important aspect: what is the *encoding* of [your source] file ?
>> They do say this:
>>
>>> *-- File is ASCII text - Named "MSVAEX30.TXT"
>>      (which presumably means 7 bit ASCII)
>> but what about, say foreign names, addresses, etc ?
>
> Foreign names etc are not supported. For example, I tested the following
>       Περαντώνη
> and despite that in Windows XP Notepad pasted correctly, when I pasted 
> this same Greek text in the billing application "Medical Manager" the 
> text pastes thus:
>       ?E?A?T???

That'll be a bit of a problem at times because names can
then differ between GNUmed and them. It is probably unlikely
to get them to "fix" that.

> So this begs a number of gnumed.conf questions :-)
>
> 1) What is the function of the variable
>
>       source = (for example) DoktorenFreud

Since the MSVA file isn't an xDT format file there's no use
configuring an xDT import profile for it...

However ...

> Does the above name get substituted into some macro or shell command, or 
> is it simply for screen output (labeling) purposes?

Yes.

> Despite that the 
> billing program that I am looking to use is marketed as "Medical  
> Manager", the actual Windows exe is "MD.EXE".

Is that, by any chance, the same as the AU Medical Manager ?
If so we already support their import format...

> 3) Does DOB format refer to the raw character format within the source 
> XDT file and so – if in my source file, a DOB would be (e.g.) 19600101 – 
> shall the DOB format be configured to be
>
>       DOB format = %Y%m%d

That would be correct.

> 4) should encoding be specified to be
>
>       encoding = SQL_ASCII

Conceptually, yes, in practice it would have to be "ascii"
while in real practice either "latin1" or "cp1252" is likely
to work better and in more cases.

> 5) [XDT profile generic XDT connector]
>
> Can I name "generic XDT connector" anything that I want, for example
>
>       BC CA MSVA30 Medical Manager
>
> and can I alter its name at any time (provided I keep consistency within 
> a config file), or does any connector name get stored in the backend?

No, renaming is fine. However, rather clone and then rename it.

>> If the billing program is dumb one could write a shell script which  
>> would once
>> run check for the export file and on existance call the patient in a 
>> running GNUmed instance.
>
> I believe it may be "dumb" in the sense that (AFAICT) it had never had to 
> make provision for inter-application communication, except that it *does* 
> include a menu command to call Internet Explorer with the parameter of a 
> URL. Even so, a suitable shell script that could be (chained to the 
> billing application's yet-to-be-created current patient "Export" button) 
> would surely pose the lowest barrier to vendor-programmer co-operation.

The (for us comfortably sufficient) sequence to implement
inside the billing program would be:

- some initiation of patient export evokes:

- export patient into a file of their choosing
- calls an OS level script (say, .bat) with a well-known
  name of their choosing
- passes in the full path + name of the export
  file as the first parameter to said OS level script

Inside that script we can then do anything we need to do.

> Would the shell script simply call the helper script, in the form
>
>       gm_ctl_client.py --conf-file <conf file specification>

That would be one possibility, yes. It could also move the
export file to a directory known to GNUmed and rename it
based on, say, the current time where GNUmed can pick it up
via, say, F2 in the search field or a menu item or whatever
we care to implement.

> and is it the *helper* script that needs to contain the lines
>
>       [GNUmed instance]
>       ...
>       startup command = <gnumed startup command> --slave

No, that would be the config file passed (or known) to
gm_ctl_client.

> and does the helper script's (if specified)
>
>       [script]
>       # show the documents plugin
>       target plugin = gmShowMedDocs
>
> over-ride what is set via the GNUmed menus?

No, it would simply signal the controlled GNUmed to
activate that plugin.

> Elsewhere in CVS there exists a gnumed.conf.example file with
>
>       # default is gnumed-client if not set
>       #
>       #slave personality = slave-test
>
> so I am not clear the difference between a conf file "personality" and a 
> conf file  "workplace" which (the latter) would normally need
>
>       name =

The workplace defines which plugins to load (and other
options). The personality, however, is visible from the
outside -- it defines what type of controllable GNUmed
instance this is.

The personality in the gnumed(-client).conf and the
gm_ctl_client.conf must match -- thereby the controller
detects whether the GNUmed instance it connects to is
suitable.

> Attached are two example files plus a reposting :
>
> MSVAEX30 which has the 5 test patients created in the billing program

Could you add a patient "Mr.Firstname Lastname" etc where
fields are filled with their labels ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]