[Top][All Lists]
[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