VA VistA Demo 20060926 Toaster
K.S. Bhaskar
Startup and Shutdown
Assuming you have QEMU installed, use "qemu -localtime -redir tcp:2222::22 -redir tcp:9297::9297 VAVistADemo20060926.qcow" to boot the appliance. QEMU boots virtual machines behind a virtual NAT firewall, and the command line forwards port 2222 on the host to port 22 in the virtual machine to provide an ssh connection to the appliance and port 9297 on the host to port 9297 on the virtual machine to allow a direct connect CPRS GUI to connect with VistA.The appliance boots inside a window in your host environment.
To shut down, click on the background in the virtual machine (2 clicks may be needed: the first to give the virtual machine focus in your host environment, and the second click going to the virtual machine. Choose "Power Down" and then "Shutdown".
Connecting to VistA
The normal user in the virtual machine is dsl. The password
for both dsl and for root in the appliance is VistA.
You should not need root access, but if you do, user dsl is
permitted to execute commands with sudo.You can start a shell inside the virtual machine, or you can connect to the appliance via ssh to port 2222 on the host - all Linux distributions come with an ssh client, and I believe Mac OS X does too. putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) is a popular & robust terminal emulator and ssh client for Windows.
CPRS can connect to the appliance from the host with "CPRSChart s=localhost p=9297 CCOW=DISABLE". If you start Taskman, retrieving data in the background will work for the CPRS client. The Access and Verify codes are VistAis#1 and #1isVistA respectively. [Caveat: dummy patients exist created for the purposes of demonstrating the CPRS GUI, and may be as meaningful to a clinician as chess pieces randomly placed on a board to a grandmaster.]
Configuration
The appliance is set up to mimic VistA in a non-ASP production environment (i.e., only one production environment on the machine - an ASP environment would share code across environments, with each having separate data). Code and data are under /var/VAVistADemo20060926/.When the system boots, the database is recovered from the journal file, as would be the case in a production environment. So a rundown should never be needed. However, journal files take up space on disk, and you will periodically need to delete old database files with the command "rm /var/VistADemo20060926/gtm_V5.2-000/g/mumps.mjl_*". Be careful not to delete /var/VistADemo20060926/gtm_V5.2-000/g/mumps.mjl, the active journal file.
Other
The MD5 checksum of VAVistADemo20060926.zip is 74efb1738e92580dd1ca2a0126abc5c2. Please verify your download to protect against damages to the file in transit.VA VistA Demo 20060926 is intended to be a VistA/CPRS demo. It is not suitable for use in installing VistA at a site. You accept all responsibility for its use.
Comments on what works well, and suggestions to improve what doesn't, are always welcome.
Thank you, as always, to Nancy Anthracite, for her guidance with VistA, and for providing the demo in a form I could work with.
Regards
-- Bhaskar
K.S. Bhaskar
> VA VistA Demo 20060926 Toaster is being uploaded and will available
> shortly at the WorldVistA project page at Source Forge
> (http://sourceforge.net/projects/worldvista). A VistA Toaster is an
[KSB] It's uploaded and available, I've had my fun with this toy. Now
it's your turn!
-- Bhaskar
K.S. Bhaskar
inetd like a common Internet service. In the Toaster file, I forgot
to configure inetd to start automatically. To start it manually, from
a shell prompt, just execute: sudo /etc/init.d/inetd/start
Alternatively, if you want to enable inetd to start automatically,
execute each of the following commands once. When you reboot your
Toaster, inetd will start automatically:
sudo ln -s /etc/init.d/inetd /etc/rc2.d/S20inetd
sudo ln -s /etc/init.d/inetd /etc/rc3.d/S20inetd
sudo ln -s /etc/init.d/inetd /etc/rc4.d/S20inetd
sudo ln -s /etc/init.d/inetd /etc/rc5.d/S20inetd
sudo ln -s /etc/init.d/inetd /etc/rc1.d/K20inetd
sudo ln -s /etc/init.d/inetd /etc/rc2.d/K20inetd
sudo ln -s /etc/init.d/inetd /etc/rc3.d/K20inetd
sudo ln -s /etc/init.d/inetd /etc/rc4.d/K20inetd
sudo ln -s /etc/init.d/inetd /etc/rc5.d/K20inetd
My next ambition is to figure out how to get Taskman to start
automatically on boot-up and to shut-down when the machine is halted.
-- Bhaskar
K.S. Bhaskar
beaver /etc/init.d/VAVistADemo20060926" which gives you a WYSIWYG GUI
editor), and make it look like this:
----------------------------------------------
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin
source /usr/local/gtm_V5.2-000/gtmprofile
cd /var/VAVistADemo20060926/gtm_V5.2-000
case "$1" in
start)
sudo -u dsl /usr/local/gtm_V5.2-000/mupip journal -recover -
backward g/mumps.mjl
sudo -u dsl ./run RESTART^ZTMB <<EOF
Y
EOF
;;
stop)
sudo -u dsl ./run STOP^ZTMKU <<EOF
Y
Y
EOF
sleep 5
sudo -u dsl killall mumps
sudo -u dsl /usr/local/gtm_V5.2-000/mupip journal -recover -
backward g/mumps.mjl
;;
*)
echo "Usage: /etc/init.d/VAVistADemo20060926 {start|stop}"
exit 1
esac
exit 0
----------------------------------------------
Taskman will automatically start when you boot the Toaster, and shut
down when you stop it.
--Bhaskar
Gregory Woodhouse
K.S. Bhaskar
In this case, "/etc/init.d/VAVistADemo20060926 stop" would be executed
when the computer is getting shut down, so even if a Taskman process has
not completed its work, it still needs to be terminated (as politely as
possible) expeditiously. Hence the "sleep 5". I guess in this case, it
is an appropriate thing to do because all this appliance would be used
for is to demonstrate CPRS.
How does the VA shut down Taskman as part of shutting down VistA cleanly
when bringing down a server?
Regards
-- Bhaskar
PeterBodtke
I made the modifications to inetd as specified, added the supplied
script to start|stop Taskman when the appliance boots|shuts down, and
rebooted Damn Small Linux. When launched the appliance I get no errors
in the DSL boot sequence, things look good.
>From the host (XP Pro) I ran the command 'telnet localhost 9297' and a
blank telnet window opens (we assume that is a good thing.)
Next I launch CPRS with a bat file stored in the same directory as the
executible, 'CPRSChart s=127.0.0.1 p=9297 CCOW=DISABLE', then CPRS
launches and the VistA sign-on screen displays. Oh yeah! Looks like I
need a Access Code and a Verify Code to complete the connection
between CPRS and the VistA demo. Can you help me out?
I have been trying on and off for a year and a half and am now posed
to connect CPRS to VistA. This is a personally historic moment.
Champagne will be server in the great hall in celebration.
Peter
> > completely non-standard.- Hide quoted text -
>
> - Show quoted text -
Nancy Anthracite
Peter
--
Nancy Anthracite
PeterBodtke
Thanks Bhaskar and Nancy!
Peter
> Nancy Anthracite- Hide quoted text -
Nancy Anthracite
Thanks Bhaskar and Nancy!
Peter
--
Nancy Anthracite
JohnLeo Zimmer, MD
Bhaskar,
I'm pleased to report that VistA Toaster is running on my wife's
Macintosh :-)
OS X 10.3.9
800 MHz PowerPC G4
256M Ram (only)
It installs smoothly in just a few minutes. The Mac port of qemu, "Q" is
a nice GUI, of course; and it's easier to set up than qemu under XP.
SSH works nicely in the Macintosh terminal application:
~$ ssh -p 2222 -l dsl localhost
toy works
highest regards,
gradpaZ
JohnLeo Zimmer, MD
Problem: running a demo VistA system that should always start at a given
date certain so that the clinical and other data is not stale for the
demo. Suggested solution: reset the system clock for the demo...
unpleasant alternative for a computer being used for anything else.
Solution: virtual computer runs the demo and sets <its> clock to the
correct start time whenever it is rebooted.
Question: Where in the boot process for DSL should such a bogus
date/time be set?
having fun,
jlz
K.S. Bhaskar
that does nothing but set the date and "start" it on bootup. See the
way that I have set up a service to recover the database and start
Taskman in /etc/init.d and /etc/rc5.d for example.
The other is to put a "sudo date ..." command in the .xinitrc startup
file for user dsl.
Slicker approach for some day in the future - create some Fileman code
to go through the database and move all dates forward.
Regards
-- Bhaskar
JohnLeo Zimmer, MD
> I can think of a couple of approaches. One is to create a "service"
> that does nothing but set the date and "start" it on bootup. See the
> way that I have set up a service to recover the database and start
> Taskman in /etc/init.d and /etc/rc5.d for example.
>
[jlz] I understand. will give it a try.
> The other is to put a "sudo date ..." command in the .xinitrc startup
> file for user dsl.
>
[jlz] I can do that. :-)
> Slicker approach for some day in the future - create some Fileman code
> to go through the database and move all dates forward.
[jlz] That has been my thought in the past. But Finding EVERY date and
incrementing it by a set delta has to be seriously non-trivial. Would
have to account for $H where it is used and for FileMan's format.
Free text entries, wherever they may occur, would ultimately make a
perfect conversion impossible.
I think there IS a role for a packaged patient record CCR, or the newly
approved CCD to be used to import a new patient. Those formats should
permit us to construct a virtual patient with all dates readily
available for updates to make the patient, for example, exactly 45 year
and 100 days old when imported into VistA. (VistA must gain a CCD
export/import capability if it is to play in the marketplace.)
Thanks again, Bhaskar
jlz
JohnLeo Zimmer, MD
> I can think of a couple of approaches. One is to create a "service"
> that does nothing but set the date and "start" it on bootup. See the
> way that I have set up a service to recover the database and start
> Taskman in /etc/init.d and /etc/rc5.d for example.
>
> The other is to put a "sudo date ..." command in the .xinitrc startup
> file for user dsl.
Ok, this approach works nicely.
By adding this to .xinitrc...
sudo date -s 091108002006
Now my Toaster starts up <every> time on its "born on date".
Predictable problem on booting DSL:
Now GT.M journaling complains that its start time exceeds its stop time.
Dare I mess with that? or should I turn journaling off? I'd rather not.
My next goal is to explore how much, and where this approach messes up
FileMan.
thanks,
GrapaZ
K.S. Bhaskar
Yes, I was independently thinking of this problem just this morninng.
GT.M journaling, like most database engines, does not like time running
backwards. Don't mess with it.
What I suggest you do is when shutting down to save the date in a file
somewhere, and when booting up, to restore that date (plus a minute,
just in case you captured the date a millibleem before the system shuts
down). Now, your VistA patient data will age, but much more slowly.
Maybe you can even put setting and restoring the time in the demo
startup script.
Regards
-- Bhaskar
Mike Schrom
Windows system. I downloaded and installed a software package with a 30
day "free trial". I didn't actually get around to trying it until after
the 30 days were over, so I set the system date back by a month. I tried
the software (uninstalled it when it didn't suit my needs) and reset the
date. But I had done a few other things while the date was set back and
I started getting error messages about restoring backup documents. I
assume this was because the older automatic backups had dates that were
newer than the dates on files I worked on later but with the system date
set back. The messages still pop up occasionally, and I spent a fair
amount of time figuring out which version I actually needed.
However, now I'm not as annoyed by my practice management system, which
doesn't use the system date but requires the manual entry of a date
every time someone logs on, and can't be set backwards.
Mike
JohnLeo Zimmer, MD
K.S. Bhaskar wrote:
>
> Yes, I was independently thinking of this problem just this morninng.
> GT.M journaling, like most database engines, does not like time running
> backwards. Don't mess with it.
> ...
> Maybe you can even put setting and restoring the time in the demo
> startup script.
Thanks for the suggestions, Bhaskar.
Here's my latest.
I've been able to placate mumps journaling by
adding this line to /etc/init.d/VAVistADemo20060926:
sudo date $(date +%m%d%H%M%Y -r mumps.mjl)
So now on boot-up the DSL date/time is set to mumps.mjl's date last
modified. (which, by the way doesn't change; I have not figured out a
simple way to add one minute to my date.) And GT.M doesn't complain.
My version of the complete script is below, I could not get your version
to work unmodified.
Thanks for your help,
JohnLeoZ
My Version of /etc/init.d/VAVistADemo20060926
(caution with line wrapping.
Sets system date. Starts/stops journaling and TaskMan
-------------------------------------------------------
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin
source /usr/local/gtm_V5.2-000/gtmprofile
cd /var/VAVistADemo20060926/gtm_V5.2-000/g
case "$1" in
start)
echo Reset date/time:
sudo date $(date +%m%d%H%M%Y -r mumps.mjl)
/usr/local/gtm_V5.2-000/mupip journal -recover -backward mumps.mjl
../run RESTART^ZTMB <<EOF
Y
EOF
;;
stop)
../run STOP^ZTMKU <<EOF
Y
Y
EOF
sleep 5
killall mumps
/usr/local/gtm_V5.2-000/mupip journal -recover -backward mumps.mjl
;;
*)
echo "Usage: /etc/init.d/VAVistADemo20060926 {start|stop}"
exit 1
esac
exit 0
-------------------------------------------------------------
(take care with word wrap)
K.S. Bhaskar
JohnLeo Zimmer, MD wrote, On 02/18/2007 12:49 AM:
[KSB] <...snip...>
> I've been able to placate mumps journaling by
> adding this line to /etc/init.d/VAVistADemo20060926:
>
> sudo date $(date +%m%d%H%M%Y -r mumps.mjl)
>
> So now on boot-up the DSL date/time is set to mumps.mjl's date last
> modified. (which, by the way doesn't change; I have not figured out a
> simple way to add one minute to my date.) And GT.M doesn't complain.
[KSB] Ingenious solution. Thank you.
-- Bhaskar
Aylesworth, Marc A Ctr AFRL/IFSE
sudo touch mumps.mjl
This will set the access and modify dates of the mumps.mjl to the current
date/time.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On Behalf
Of JohnLeo Zimmer, MD
Sent: Sunday, February 18, 2007 12:49 AM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
K.S. Bhaskar wrote:
>
> Yes, I was independently thinking of this problem just this morninng.
> GT.M journaling, like most database engines, does not like time running
> backwards. Don't mess with it.
> ...
> Maybe you can even put setting and restoring the time in the demo
> startup script.
Thanks for the suggestions, Bhaskar.
Here's my latest.
I've been able to placate mumps journaling by
adding this line to /etc/init.d/VAVistADemo20060926:
sudo date $(date +%m%d%H%M%Y -r mumps.mjl)
So now on boot-up the DSL date/time is set to mumps.mjl's date last
modified. (which, by the way doesn't change; I have not figured out a
simple way to add one minute to my date.) And GT.M doesn't complain.
My version of the complete script is below, I could not get your version
to work unmodified.
Thanks for your help,
JohnLeoZ
My Version of /etc/init.d/VAVistADemo20060926
(caution with line wrapping.
Sets system date. Starts/stops journaling and TaskMan
-------------------------------------------------------
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin
source /usr/local/gtm_V5.2-000/gtmprofile
cd /var/VAVistADemo20060926/gtm_V5.2-000/g
case "$1" in
start)
echo Reset date/time:
sudo date $(date +%m%d%H%M%Y -r mumps.mjl)
K.S. Bhaskar
journal file, and touching the journal file will have no effect on those
records.
Incidentally, if you set up NTP to keep accurate time on a computer
(which is common for UNIX/Linux systems) on which there is a 24x7 GT.M
application running, make sure you tell NTP to slew the clock to correct
it, rather than stepping the clock.
-- Bhaskar
gregory....@sbcglobal.net
Gregory Woodhouse <gregory....@sbcglobal.net>
"Mathematics is the science of patterns."
--Lynn Arthur Steen, 1988
From: K.S. Bhaskar <ks.bh...@fnf.com>
To: Hard...@googlegroups.com
Sent: Tuesday, February 20, 2007 7:17:42 AM
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
JohnLeo Zimmer, MD
gregory....@sbcglobal.net wrote:
> Resetting times is, at best, a very temporary (no pun intended) hack.
[jlz] I agree. Although toying with the clock of a virtual machine such
as QEMU offers real advantages over playing with real hardware.
> What is really needed here is code to generate test patients
> with medical histories following prescribed patterns. ...
[jlz] Again, I agree entirely. I think there may be room for a virtual
patient engine which can take a request for a particular sort of
patient, e.g. "We need a middle-aged diabetic with renal and cardiac
complications. He/she needs to be in the ICU. Workup should include EKG
with LVH and acute MI, cardiac ultrasound with poor ejection fraction,
X-ray with CHF." An interactive process could automatically assemble the
patient for fine tuning of details such as laboratory results, relevant
images, etc. Then the virtual patient would need to be injected into VistA
There are other efforts in this direction, especially for problem based
learning in medical, and nursing schools. There are also sophisticated
computerized case problems being used for medical board exams.
> ... Yes, I know that
> this is a non-trivial undertaking, but a important one. More
> importantly, it is one where documenting the underlying data structures
> /and/ the constraints that must be satisified by the patient record is a
> necessary first step. To my knowledge, no one here has really undertaken
> either of these tasks.
[jlz] Also true. It may prove impossible to manipulate VistA in the way
I think necessary. Where does one start?
regards,
JohnLeo
Woodhouse, Gregory J.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Behalf Of JohnLeo Zimmer, MD
Sent: Tuesday, February 20, 2007 4:17 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
Comments below
gregory....@sbcglobal.net wrote:
> Resetting times is, at best, a very temporary (no pun intended) hack.
[jlz] I agree. Although toying with the clock of a virtual machine such
as QEMU offers real advantages over playing with real hardware.
[gjw] True...but it's still a hack. :-)
> What is really needed here is code to generate test patients with
> medical histories following prescribed patterns. ...
[jlz] Again, I agree entirely. I think there may be room for a virtual
patient engine which can take a request for a particular sort of
patient, e.g. "We need a middle-aged diabetic with renal and cardiac
complications. He/she needs to be in the ICU. Workup should include EKG
with LVH and acute MI, cardiac ultrasound with poor ejection fraction,
X-ray with CHF."
[gjw] Yes, that's exactly what I have in mind.
An interactive process could automatically assemble the patient for fine
tuning of details such as laboratory results, relevant images, etc. Then
the virtual patient would need to be injected into VistA
[gjw] Why? The database you're generating is for training purposes only,
so why not generate a database from scratch that meets your
specifications, and not bother with trying to inject data into an
existing one (where time will be all wrong, anyway)?
There are other efforts in this direction, especially for problem based
learning in medical, and nursing schools. There are also sophisticated
computerized case problems being used for medical board exams.
[gjw] Is any work along these lines freely available? It's becoming
reasonably common to do this in computer science 9even using open source
licenses in some cases), but I have no idea of the situation in
medicine.
> ... Yes, I know that
> this is a non-trivial undertaking, but a important one. More
> importantly, it is one where documenting the underlying data
> structures /and/ the constraints that must be satisified by the
> patient record is a necessary first step. To my knowledge, no one here
> has really undertaken either of these tasks.
[jlz] Also true. It may prove impossible to manipulate VistA in the way
I think necessary. Where does one start?
[gjw] See above. I think the paradigm is wrong. Instead of thinking
about modifying existing databases, you should be thinking of generating
databases from scratch.
regards,
JohnLeo
JohnLeo Zimmer, MD
continually "touching" itself anyway (shameful as that may seem). My
method looks to the journal's date for a time to restart the system.
Thus there is no dead space created while the real world moves on. And
VistA does not age when the Toaster is asleep. Turning the clock <back>
would be another matter, of course. But the virtual system offers the
possibility of freezing the action and returning later to build on that
point.
What I would love to have is a VistA in which ALL dates and times are
relative to some arbitrary point. I could start a brand new, but fully
populated demonstration system and set the clock to NOW and proceed from
that point with patient Johnny Jones born on 10/11/44 and admitted
yesterday, the 19th. If the demo is run on Friday the same patient would
appear, born on 10/14/44 and admitted yesterday (the 22nd).
(... I know. :-)
K.S. Bhaskar wrote:
> Don't do that, Marc. There are time stamps in records within the
> journal file, and touching the journal file will have no effect on those
> records.
> ...
Woodhouse, Gregory J.
Programmers tend to work with globals directly, manipulate Fileman dates
and $H values directly, extracting the information they want, create
cross-references to exectute their own code, etc. These are not
necessarily bad things, but create serious problems for people wanting
to do any sort of meta-programming.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Behalf Of JohnLeo Zimmer, MD
Sent: Tuesday, February 20, 2007 4:47 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
Woodhouse, Gregory J.
you're doing is opening and closing the file, making it look like it's
been open for modification (because it has).
One thing that might not be immeiately obvious, though, is that renaming
a file does not "touch" it. Files don't actually have names (they have
inode numbers). Instead, filenames are mapped to inodes by a particular
type of file called a directory. (Under VMS, by the way, you'll see
these files as files with the .DIR extension). That's why "read"
permission on a directory, is permission to search the directory, write
permission allows you to create and delete files, and so on. Oh, and you
may have read that "hard" links are indistinguishable. That's true
because two links to the same file (inode) are just two entries in a
directory mapping a name to that inode). This also explains why you
can't have hard links across filesystems. "Soft" or symbolic links are
completely different, they are a particular type of file containing the
name of another file.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Behalf Of JohnLeo Zimmer, MD
Sent: Tuesday, February 20, 2007 4:47 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
JohnLeo Zimmer, MD
>>> [gjw] What is really needed here is code to generate test patients with
>>
>> [jlz] Again, I agree entirely. I think there may be room for a virtual
>> patient engine which can take a request for a particular sort of
>> patient, e.g. "We need a middle-aged diabetic with renal and cardiac
>> complications. He/she needs to be in the ICU. Workup should include EKG
>> with LVH and acute MI, cardiac ultrasound with poor ejection fraction,
>> X-ray with CHF."
>
> [gjw] Yes, that's exactly what I have in mind.
>
>> An interactive process could automatically assemble the patient for fine
>> tuning of details such as laboratory results, relevant images, etc. Then
>> the virtual patient would need to be injected into VistA
>
> [gjw] Why? The database you're generating is for training purposes only,
> so why not generate a database from scratch that meets your
> specifications, and not bother with trying to inject data into an
> existing one (where time will be all wrong, anyway)?
[jlz]
1. I'd like to build a more robust Demo of VistA.
2. Would prefer VistA itself to a simulation of VistA.
3. If students are going to use an electronic record in their work,
training on an EHR would be most advantageous.
4. Complete redesign of VistA... that's another thread. :-)
>> There are other efforts in this direction, especially for problem based
>> learning in medical, and nursing schools. There are also sophisticated
>> computerized case problems being used for medical board exams.
>>
>> [gjw] Is any work along these lines freely available? It's becoming
>> reasonably common to do this in computer science 9even using open source
>> licenses in some cases), but I have no idea of the situation in
>> medicine.
[jlz] Some is open, a good deal is proprietary. My daughter teaches at
Emory. They create their own PBL cases, and buy some from, e.g. Harvard.
>>> ... Yes, I know that
>>> this is a non-trivial undertaking, but a important one. More
>>> importantly, it is one where documenting the underlying data
>>> structures /and/ the constraints that must be satisified by the
>>> patient record is a necessary first step. To my knowledge, no one here
> >> has really undertaken either of these tasks.
>>
>> [jlz] Also true. It may prove impossible to manipulate VistA in the way
>> I think necessary. Where does one start?
>
> [gjw] See above. I think the paradigm is wrong. Instead of thinking
> about modifying existing databases, you should be thinking of generating
> databases from scratch.
[jlz] I am thinking that my tool should assemble such a patient for
export, probably in XML format (CCR or CDR) that could be imported into
any EHR that is compatible with the standards... Including into VistA,
the gods willing... someday... when VistA conforms to that standard.
Woodhouse, Gregory J.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Behalf Of JohnLeo Zimmer, MD
Sent: Tuesday, February 20, 2007 5:26 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
> [gjw] See above. I think the paradigm is wrong. Instead of thinking
> about modifying existing databases, you should be thinking of
> generating databases from scratch.
[jlz] I am thinking that my tool should assemble such a patient for
export, probably in XML format (CCR or CDR) that could be imported into
any EHR that is compatible with the standards... Including into VistA,
the gods willing... someday... when VistA conforms to that standard.
[gjw] There's no incompatibility here. If you have your data in some
external format, then that data can be used to seed a fresh database.
There is no reason to try and inject daqta into an existing database
when you can create a new one in which all integrity constraints will be
satisfied by design.
Woodhouse, Gregory J.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Behalf Of JohnLeo Zimmer, MD
Sent: Tuesday, February 20, 2007 5:26 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: VA VistA Demo 20060926 Toaster
>>> [gjw] What is really needed here is code to generate test patients
>>> with medical histories following prescribed patterns. ...
>>
>> [jlz] Again, I agree entirely. I think there may be room for a
>> virtual patient engine which can take a request for a particular sort
>> of patient, e.g. "We need a middle-aged diabetic with renal and
>> cardiac complications. He/she needs to be in the ICU. Workup should
>> include EKG with LVH and acute MI, cardiac ultrasound with poor
>> ejection fraction, X-ray with CHF."
>
> [gjw] Yes, that's exactly what I have in mind.
>
>> An interactive process could automatically assemble the patient for
>> fine tuning of details such as laboratory results, relevant images,
>> etc. Then the virtual patient would need to be injected into VistA
>
> [gjw] Why? The database you're generating is for training purposes
> only, so why not generate a database from scratch that meets your
> specifications, and not bother with trying to inject data into an
> existing one (where time will be all wrong, anyway)?
[jlz]
1. I'd like to build a more robust Demo of VistA.
[gjw] I think we all would. But a necessary first step is spelling out
what robust means in this context. Do you mean one that is more
reliable? one with better test data? one that is more realistic?
something else?
2. Would prefer VistA itself to a simulation of VistA.
[gjw] I'm not sure what this means. Are you referring to running
natively rsther than via virtual machines? It may well be that this
distinction will become less and less meaningful over time.
3. If students are going to use an electronic record in their work,
training on an EHR would be most advantageous.
[gjw] Of course. Then again...if that is so obvious, why is it not
happening now? (Obviously, this is a rhetorical question.)
4. Complete redesign of VistA... that's another thread. :-)
[gjw] Well, yes, but it's an important one. In my opinion the issue
isn't so much redesign, but coming to terms with unmanaged complexity. A
redesign, in and of itself, can really be no more than a temporary fix.
What is really needed is an approach that allows us to address the
problems making redesign necessary.
>> There are other efforts in this direction, especially for problem
>> based learning in medical, and nursing schools. There are also
>> sophisticated computerized case problems being used for medical board
exams.
>>
>> [gjw] Is any work along these lines freely available? It's becoming
>> reasonably common to do this in computer science 9even using open
>> source licenses in some cases), but I have no idea of the situation
>> in medicine.
[jlz] Some is open, a good deal is proprietary. My daughter teaches at
Emory. They create their own PBL cases, and buy some from, e.g. Harvard.
[gjw] We should talk about how this might be done. In my opinion, VistA
is not (yet) enough of a controlled environment. Building an application
with more carefully defined semantics with the capability to export to
VistA may be the way to go.
>>> ... Yes, I know that
>>> this is a non-trivial undertaking, but a important one. More
>>> importantly, it is one where documenting the underlying data
>>> structures /and/ the constraints that must be satisified by the
>>> patient record is a necessary first step. To my knowledge, no one
>>> here
> >> has really undertaken either of these tasks.
>>
>> [jlz] Also true. It may prove impossible to manipulate VistA in the
>> way I think necessary. Where does one start?
>
> [gjw] See above. I think the paradigm is wrong. Instead of thinking
> about modifying existing databases, you should be thinking of
> generating databases from scratch.
[jlz] I am thinking that my tool should assemble such a patient for
export, probably in XML format (CCR or CDR) that could be imported into
any EHR that is compatible with the standards... Including into VistA,
the gods willing... someday... when VistA conforms to that standard.
[gjw] Again, I think the basic issue here is that we need a better
(i.e., more precise) description of VistA. Lacking such a framework,
VistA is always susceptible to uncontrolled variability, and that is the
biggest factor making such goals difficult (or perhaps impossible) to
achieve.
JohnLeo Zimmer, MD
>> 1. I'd like to build a more robust Demo of VistA.
> [gjw] I think we all would. But a necessary first step is spelling out
[jlz] A demo needs realism. The viewer needs to recognize their own
workplace in the story developed by the demo. It's hard to relate to
random numbers assigned to patients named Minnie Mouse or
PATIENT122,TEST. And the task goes on from there.
>> 2. Would prefer VistA itself to a simulation of VistA.
> [gjw] I'm not sure what this means.
I was trying to distinguish a real OS/M/VistA stack actually running
from a screen capture or movie, however assembled. I would want to log
on and enter data as opposed to watching something canned scroll by.
>> Problem Based Learning case availability.
>> [jlz] Some is open, a good deal is proprietary. My daughter teaches at
>> Emory. They create their own PBL cases, and buy some from, e.g. Harvard.
>
> [gjw] We should talk about how this might be done. In my opinion, VistA
> is not (yet) enough of a controlled environment. Building an application
> with more carefully defined semantics with the capability to export to
> VistA may be the way to go.
[jlz] YES.
PeterBodtke
best overall technique to insert records?
I assume there are two approaches:
1) Programmatically inserting records directly into the database from
a data source, flats files or an alternate database.
2) Entering records through the interface with automated regression
tools from a data source, flats files or an alternate database.
What are the advantages and limitation associated with these
approaches? Here is a starter list of thoughts:
Programmatic insert (via SQL or MUMPS equivalent)
- High efficiency inserting records (once scripts are developed)
- Uncertainly that all fields are properly filled (primary, and
internal values that may be generated)
- High level knowledge of VistA internal data structure required
- Knowledge of insert scripting required.
Automated interface entry (via regression tools)
- Lower relative efficiency entering records
- Lower level of VistA internal data structure required
- Certainly that all fields are properly filled
- Regression tool skill needed
- Regression tool required
General:
Which approach is the easiest to sustain as the interface or internal
data structure changes?
Does either approach lends its self better to creating data set
variations, progress over time, widest coverage of diseases?
Peter Bodtke
> >> date/time.- Hide quoted text -
Gregory Woodhouse
If building a database from scratch is the way to go, then what is the
best overall technique to insert records?
I assume there are two approaches:
1) Programmatically inserting records directly into the database from
a data source, flats files or an alternate database.
2) Entering records through the interface with automated regression
tools from a data source, flats files or an alternate database.
...
General:
Which approach is the easiest to sustain as the interface or internal
data structure changes?
Does either approach lends its self better to creating data set
variations, progress over time, widest coverage of diseases?
Peter Bodtke
PeterBodtke
>The scripting approach is actually likely to be more fragile because
>it is vulnerable to small changes to the user interface that a human
>user would scarcely notice. On the other hand, it uses a different
>skill set and may prove useful in some cases. (Is my bias showing
>here?)
A small point, the ease of maintaining regression scripts depends on
the choice of regression tool. There are tools that identify the entry
points in a GUI as objects, not simply using coordinate points to
insert/select values. An object can move, say with in a screen, and
the script with continue uninterrupted becaue the tool is looking for
the object.
I will look at the regression tool mentioned, Expect. Do you know of
any FOSS regress tools?
Please forgive my novice question, is the registration process
supported by a GUI client like CPRS or is it a roll-n-scroll terminal
interface?
Peter Bodtke
On Feb 22, 8:53 am, Gregory Woodhouse
> gregory.woodho...@sbcglobal.net
Gregory Woodhouse
Please forgive my novice question, is the registration process
supported by a GUI client like CPRS or is it a roll-n-scroll terminal
interface?
Gregory Woodhouse
I will look at the regression tool mentioned, Expect. Do you know of
any FOSS regress tools?
Nancy Anthracite
services. We should probably try to get that going with the toaster.
Peter Bodtke
--
Nancy Anthracite
K.S. Bhaskar
records in an XML format. If that is correct, it can perhaps be
leveraged to upload "time corrected" patient data when a Toaster boots up?
-- Bhaskar
Woodhouse, Gregory J.
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Behalf Of Nancy Anthracite
Sent: Thursday, February 22, 2007 7:06 AM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: Building databases (was: Re: VA VistA Demo
20060926 Toaster)
VOE will have a GUI registration option supported by EsiObjects with web
services. We should probably try to get that going with the toaster.
[Greg]
Nancy,
I wonder if you could tell us a bit more about the arcvhitecture here.
My understanding is that EsiObjects provides an OO layer (language and
database bindings) on top of MUMPS, but I confess that I don't fully
understand it. Now, web services are something else. I generally
associate this term with SOAP/WSDL services running under something like
Tomcat. I suppose XML-RPC interfaces could be called web services, too,
but the basic idea is running an RPC style interface over HTTP. It does
not, in and of itself, provide a GUI. That being said, I've seen tools
that allow GUI widgets to be linked to web services (in much the same
way the the Fileman Delpi Components) allow you to link Delphi controls
to Fileman via the RPC Broker. Am I correct here about the basic
architecture? What is the tool you use to link the GUI to web services?
Does EsiObjects support SOAP based web services? Some other standard?
Does it require specialized client-side software?
Greg Woodhouse
I dodn't think I've seen Kevin's code, but I know he put a lot of work
into developing a process for registration. Maybe Kevin can tell us
morre about it.
In general, XML is a perfectly good import format, but VistA's XML
parser only supports ASCII. As long as you don't use Unicode and don't
need a validating parser, you should be fine.
PeterBodtke
it's a great provincial tool that someone workewd very hard to
devleop, and very useful until you start importing data, such as
patient names with special characters... Been there, done that...it's
not a pretty picture.
Peter
On Feb 22, 2:38 pm, "Greg Woodhouse" <gregory.woodho...@gmail.com>
wrote:
K.S. Bhaskar
>
> That the VistA XML parser only supports ASCII is unfortunate. I'm sure
> it's a great provincial tool that someone workewd very hard to
> devleop, and very useful until you start importing data, such as
> patient names with special characters... Been there, done that...it's
> not a pretty picture.
>
> Peter
[KSB] I don't understand why ASCII is such a limitation for VistA. The
application does not use or support Unicode, so this does not seem like
an undue burden right now.
Regards
-- Bhaskar
Woodhouse, Gregory J.
--------------------------
Sent using BlackBerry
Jim Self
> That the VistA XML parser only supports ASCII is unfortunate. I'm sure
> it's a great provincial tool that someone workewd very hard to
> devleop, and very useful until you start importing data, such as
> patient names with special characters... Been there, done that...it's
> not a pretty picture.
from western European languages can be quite easy with GT.M and M2Web.
It turns out that the standard pattern match codes (A, U, L, N, P)
applied in GT.M/Linux to 8-bit characters matches the ISO-8859-1
character representation used in web browsers. This means that existing
pattern match based validation tests on data input values do not have to
be changed. The only change required in VMACS to support special
characters in patient names and other data was extending the case
conversion utility function to handle uppercase and lowercase conversion
of high-bit alphabetic characters.
The primary impediment to doing the same in VistA is the presence of
adhoc case conversions scattered throughout the code - these must be
replaced with calls to a common case conversion function in order to
handle any kind of international spelling of names.
--
---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Information Technology Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---------------------------------------
M2Web Demonstration with VistA
(http://vista.vmth.ucdavis.edu/)
---------------------------------------
Nancy Anthracite
These questions require an understanding of how EsiObjects is
implemented and the services it provides. That information can be
acquired by downloading the system and going through the tutorial.
Given that knowledge, these layers represent the basic architecture to
the point where I understand it.
1. All EsiObjects code, whether core code or library code exists as
MUMPS routines and globals.
2. All EsiObjects code and globals reside in the VES namespace within
the VistA environment. All this code has access to any VistA
routine or global.
3. A library exists in EsiObjects called VistAWebServices. Within
that library there is a class called VistAServices. This Class has
several interfaces that are used to partition the services.
Services can be Properties, Methods, Events or Relationships. The
Security interface contains methods used for login. The
Registration interface contains all the add, delete, get and
update services the external Web services need to read and write
patient registration data. The ReferenceData interface contains
all methods to get static data like city,zipcode, institutions,
insurance companies, etc. that is used as selection data on a web
page. Other interfaces are used for internal support.
4. Because the VistAServices does not support a completely stateless
interface, it implements a nested class call User Class that is
responsible for maintaining context for a session call.
5. All services in these interfaces make calls to existing File
Manager routines to access the required data. In other words, the
business rules of VistA are preserved.
6. There exists a set of core routines that implement the TCP/IP
protocol in EsiObjects called the TCPGateway. EsiObjects contains
a Java package that implements the Java Gateway. It communicates
with the TCPGateway to access VistA data via an instance of the
VistAServices class. The Java Gateway does this through a Java
proxy of the VistAServices class.
7. A Java package called the VistaWebServices wraps the Java Proxy
providing a Web Services interface for external applications.
8. The rest of the application is written in Java and can be
explained Emory Fry's programmers who actually built it.
The EsiObjects layer is actually quit thin. However, it acts as the glue
between the Java world and the VistA world.
Nancy,
--
Nancy Anthracite
PeterBodtke
(the other kiss). The extra step of converting, cleansing or
accommodating character into ACSII is what I find objectionable. If
there is an extra step to take, then be sure that someone, somewhere
will forget and importing/inserting records will fail.
It is provincial and short sighted to develop tools that service the
language of an international minority. Sadly, I sure it was within the
mandate and scope of the project planners to only support ASCII.
Technically, converting names to ASCII introduces a host of problems
matching records down the road. We excise a measure of poetry from an
individual's identity when converting their name from non-ASCII to
ASCII and perhaps that alone is the most important reason to develop
robust importing tools.
Peter Bodtke
JohnLeo Zimmer, MD
And once upon a time to text in general. There is a <perhaps small> but
<definitely unpleasant> sacrifice of information in that limitation.
PeterBodtke wrote:
> It is provincial and short sighted to develop tools that service the
> language of an international minority. Sadly, I sure it was within the
> mandate and scope of the project planners to only support ASCII.
I have little doubt that this "standard" dates all the way back to a
time in the dim past when MUMPS was the whole operating system and ran
on Octo Barnett's most powerful little PDP's where upper case would have
been an impossibly wasteful extravagance.
jlz
JohnLeo Zimmer, MD
oops, I MEANT LOWER CASE...
Gregory Woodhouse
I have little doubt that this "standard" dates all the way back to a
time in the dim past when MUMPS was the whole operating system and ran
on Octo Barnett's most powerful little PDP's where upper case would have
been an impossibly wasteful extravagance.
jlz
Jim Self
> It's a small point, along the line of keep it simple and streamlined
> (the other kiss). The extra step of converting, cleansing or
> accommodating character into ACSII is what I find objectionable.
That is exactly what I was attempting to address in my comments -
accommodating character sets beyond the ASCII set of 128 character codes
(including control characters). What character representations and
languages and problems are you specifically concerned with?
ASCII generally refers to a 7-bit character encoding (128 character
codes, 95 printable) that is the basis for most modern character
encodings. MUMPS implementations generally support 8-bit character
representations or larger.
>
> If there is an extra step to take, then be sure that someone, somewhere
> will forget and importing/inserting records will fail.
>
I was not referring to an extra step in importing data, but to a system
modification that would accept and represent names more naturally - a
first step towards internationalization.
> It is provincial and short sighted to develop tools that service the
> language of an international minority. Sadly, I sure it was within the
> mandate and scope of the project planners to only support ASCII.
>
ASCII was a starting point - standardized 40 years ago. Development of
VistA was started more than 25 years ago based on the MUMPS standard
from 30 years ago. Fully general internationalized applications on the
scope of VistA seem to require a range of expertise and technology that
has been historically difficult to achieve. It is only with the actively
international development of technology like Mozilla/Firefox and Linux
in the last decade that this now begins to seem like a practical
possibility.
With a suitably internationalized front end, like Firefox, M-based
applications can be easily enhanced to support patient names and other
text that can be represented with an 8-bit character encoding such as
ISO-8859-1.
The recent 5.2 version of GT.M can support Unicode. Upgrading VistA to
support Unicode may not be terribly difficult.
Jim Self
> I have always chafed at DHCP/VistA's all UPPER CASE approach to names.
> And once upon a time to text in general. There is a <perhaps small> but
> <definitely unpleasant> sacrifice of information in that limitation.
>
justification for it should have vanished more than 20 years ago with
the last functioning keyboard and printer that couldn't handle lowercase.
> PeterBodtke wrote:
>
>> It is provincial and short sighted to develop tools that service the
>> language of an international minority. Sadly, I sure it was within the
>> mandate and scope of the project planners to only support ASCII.
>>
>
> I have little doubt that this "standard" dates all the way back to a
> time in the dim past when MUMPS was the whole operating system and ran
> on Octo Barnett's most powerful little PDP's where upper case would have
> been an impossibly wasteful extravagance.
>
devices. The common I/O devices of the early 1970's (teletypes, card
punches, and printers) did not support lowercase so there wasn't much
point in programming for it. When I started working with MUMPS in 1981,
the video terminals and printers that I encountered all handled most
8-bit characters but the representation of characters beyond the 95
printable ASCII characters was not standard.
Steven McPhelan
To allow mixed case or all lower case (and it is allowable) in a .01
free text field would require modification of the Fileman file lookup
routines. Your only alternative at this point is to do work arounds.
--
Steve
"Integrity without knowledge is weak and useless, and knowledge
without integrity is dangerous and dreadful." - Samuel Johnson
Jim Self
> I do not know the origin of the basis for using Uppercase in Fileman,
> To allow mixed case or all lower case (and it is allowable) in a .01
> free text field would require modification of the Fileman file lookup
> routines. Your only alternative at this point is to do work arounds.
>
modification of the lookup routines. They already perform case
insensitive lookups if only the cross reference values are uppercased.
PeterBodtke
>> It's a small point, along the line of keep it simple and streamlined
>> (the other kiss). The extra step of converting, cleansing or
>> accommodating character into ACSII is what I find objectionable.
>That is exactly what I was attempting to address in my comments -
>accommodating character sets beyond the ASCII set of 128 character codes
>(including control characters). What character representations and
>languages and problems are you specifically concerned with?
Jim,
Thank you for your detailed and thoughtful reply. Your command of the
topic is obviously deeper than my experience.
Here is my story: a year ago I was contracting on an implementation
project (non-medical software) in a data environment that included
various Western languages, Spanish, German, Dutch, etc.. I can't
recall the specific limitations on character encoding. What I remember
is that the new system could not handle importing "special
characters", so we would filter, scrub, convert and generally exorcize
demons to make the ongoing data feeds functional. It was a painful
experience and would not have been necessary if the new system was
better designed. After importing "cleansed" data we felt a second wave
of frustration because we could not match the original to the imported
records!
It is encouraging to hear you say that upgrading VistA to support
Unicode "may not be terribly difficult." Finding the supporting
funding for such a project may prove otherwise.
My interest in this topic is focused on supporting Spanish in
implementations of VistA, from patient names to lab orders, and
everything in between. This is a topic better suited for its own
message thread.
Peter Bodtke
> ---------------------------------------- Hide quoted text -
K.S. Bhaskar
PeterBodtke wrote, On 02/25/2007 09:44 AM:
[KSB] <...snip...>
> It is encouraging to hear you say that upgrading VistA to support
> Unicode "may not be terribly difficult." Finding the supporting
> funding for such a project may prove otherwise.
>
> My interest in this topic is focused on supporting Spanish in
> implementations of VistA, from patient names to lab orders, and
> everything in between. This is a topic better suited for its own
> message thread.
[KSB] As long as VistA restricts itself to $C(0) through $C(127), and
doesn't use fixed length records, the hardest part of moving to Unicode
will be IO output formatting (which is where there are likely to be
assumptions about the length of a string in bytes being the same as the
length of a string in characters being the same as the display width).
Spanish - and most Western European languages - need neither Unicode nor
$C(128) & up.
-- Bhaskar
Chris Richardson
Unicode is a sub-plane within its expansive range. The wonderful thing
about MUMPS is that it does not identify how big a character is, 7, 8, 16,
24, or 32 bits. In MUMPS there is just characters. The Japanese have a
version of MUMPS which uses 16 bits for Kanji. ASCII is layered into this
range for the Japanese Kanji so they can use MUMPS for the commands.
ISO-10646 was drafted in a response to the efforts of the West to bring the
partial solution of Unicode in front of the world community. The impact of
Unicode was very limited with only 16 bits, was a consolidation of the Asian
languages. The impact was like if someone had come to the US and said, "You
know, that number '1' and the lower-case letter 'l' are really close. Which
one do you want to keep? ...and by the way, let's talk about the capital
letter 'O' and that Zero, '0'...."
The advantages of ISO-10646 are that it uses 32 bits (4 octets) per
character. Now it is true that GTM currently uses primarily a single octet,
8 bits, and further restricted to 7-bit ASCII. Unicode has been extended
to include some extended range with some special shift characters (a
technique used by Baudot, a famous 5-bit code to extend its range). In
ISO-10646, there is no need for shift characters. All characters are the
same size, 32 bits. Now this seems very wasteful, but how the actual data
is stored is dependent upon character set which is being stored. It is only
the least significant octets that usually change. So a long string with the
same group of letters, the difference can be encoded to reduce the common
most siginificant octets from the string. But, I digress.
What does ISO-10646 gain us? Well, in addition to having all of the
cultural character sets in the world at our disposal, it opens up the
possibility of having speacialized character sets like, chemistry, math,
music, performing arts, and a whole bunch of other possibilities, even
Klingon.
Can GTM and other languages adapt to ISO-10646? Yes, just as Bhaskar has
stated, is only a simple matter of money.
Jim Self
> The advantages of ISO-10646 are that it uses 32 bits (4 octets) per
> character. Now it is true that GTM currently uses primarily a single octet,
> 8 bits, and further restricted to 7-bit ASCII.
>
encodings.
Unicode and ISO-8859-1 are interesting to me because they are easily
accessible practical realities implemented in web browsers such as Firefox.
I was wondering why I hadn't found any indication that the same is true
of ISO-10646 so I googled for it and found a wikipedia article that says
essentially that it is subsumed by Unicode and that both are produced by
the Unicode Consortium.
http://en.wikipedia.org/wiki/Universal_Character_Set
Gregory Woodhouse
[KSB] As long as VistA restricts itself to $C(0) through $C(127), and
doesn't use fixed length records, the hardest part of moving to Unicode
will be IO output formatting (which is where there are likely to be
assumptions about the length of a string in bytes being the same as the
length of a string in characters being the same as the display width).
Spanish - and most Western European languages - need neither Unicode nor
$C(128) & up.
-- Bhaskar
K.S. Bhaskar
Comments below.
Regards
-- Bhaskar
Chris Richardson wrote, On 02/28/2007 12:40 AM:
>
> There is little confusion as to the length of a character in ISO-10646.
> Unicode is a sub-plane within its expansive range. The wonderful thing
> about MUMPS is that it does not identify how big a character is, 7, 8, 16,
> 24, or 32 bits. In MUMPS there is just characters. The Japanese have a
> version of MUMPS which uses 16 bits for Kanji. ASCII is layered into this
> range for the Japanese Kanji so they can use MUMPS for the commands.
> ISO-10646 was drafted in a response to the efforts of the West to bring the
> partial solution of Unicode in front of the world community. The impact of
> Unicode was very limited with only 16 bits, was a consolidation of the Asian
> languages. The impact was like if someone had come to the US and said, "You
> know, that number '1' and the lower-case letter 'l' are really close. Which
> one do you want to keep? ...and by the way, let's talk about the capital
> letter 'O' and that Zero, '0'...."
[KSB] While this may have been true many years ago, these days versions
of the Unicode and ISO/IEC 10646 standards track each other
(http://unicode.org/faq/unicode_iso.html).
> The advantages of ISO-10646 are that it uses 32 bits (4 octets) per
> character. Now it is true that GTM currently uses primarily a single octet,
> 8 bits, and further restricted to 7-bit ASCII. Unicode has been extended
[KSB] Could you please explain the comment that GT.M is restricted to
7-bit ASCII? In the database engine, indexes have always been either
canonical numbers or arbitrary sequences of bytes. Unicode support
doesn't change that.
> to include some extended range with some special shift characters (a
> technique used by Baudot, a famous 5-bit code to extend its range). In
[KSB] Do you perhaps have Unicode confused with Shift JIS?
> ISO-10646, there is no need for shift characters. All characters are the
> same size, 32 bits. Now this seems very wasteful, but how the actual data
> is stored is dependent upon character set which is being stored. It is only
> the least significant octets that usually change. So a long string with the
> same group of letters, the difference can be encoded to reduce the common
> most siginificant octets from the string. But, I digress.
[KSB] Unicode (or ISO/IEC-10646) has multiple encodings, one of which is
UTF-8, which is a variable length encoding (see
http://www.unicode.org/faq/utf_bom.html for more information).
> What does ISO-10646 gain us? Well, in addition to having all of the
> cultural character sets in the world at our disposal, it opens up the
> possibility of having speacialized character sets like, chemistry, math,
> music, performing arts, and a whole bunch of other possibilities, even
> Klingon.
>
>
>
> Can GTM and other languages adapt to ISO-10646? Yes, just as Bhaskar has
> stated, is only a simple matter of money.
[KSB] GT.M V5.2-000 supports Unicode 5.0 (the latest version of Unicode
& the ISO/IEC-10646 that it tracks (see
http://www.fidelityinfoservices.com/FNFIS/Markets/Healthcare/InfoBulletins/20070122.htm)
.
K.S. Bhaskar
Regards
-- Bhaskar
On Feb 27, 2007, at 7:55 PM, K.S. Bhaskar wrote:
[KSB] As long as VistA restricts itself to $C(0) through $C(127), and
doesn't use fixed length records, the hardest part of moving to Unicode
will be IO output formatting (which is where there are likely to be
assumptions about the length of a string in bytes being the same as the
length of a string in characters being the same as the display width).
The tricky thing is the semantics of $EXTRACT. Is $E(X,m,n) the Unicode characters m through n, or is bytes m through n.
Spanish - and most Western European languages - need neither Unicode nor
$C(128) & up.
No, but you need to decide which flavor of ISO-8859 you're using. For most Western European languages, you can get away with ISO-8859-1. But as Jim Self pointed out, there are ad hoc case conversions to worry about. A very common idiom is using $TRANSLATE (with just the 26 letters of the English alphabet with no diacritical marks) to convert lower to upper case.
Chris Richardson
should characterize it as Unicode subsuming ISO-10646. Unicode is still a
smaller characterset than ISO-10646 described. Now the smaller characterset
is claiming discovery of the larger characterset. Thanks to Bhaskar for
the updated references. But is is still the Indo-European influence trying
to reduce the representation of the characterset of the Orientals and the
rest of the smaller groups and their cultural heritage. It was the Chinese
who originally suggested ISO-10646 to counter the reductionism of the
original Unicode efforts. How interesting that Unicode now maps the whole
of ISO-10646 when Unicode was a subset within ISO-10646. We live in
interesting times.
----- Original Message -----
From: "Jim Self" <jas...@dcn.davis.ca.us>
To: <Hard...@googlegroups.com>
Sent: Tuesday, February 27, 2007 10:57 PM
Subject: [Hardhats] Re: special characters in patient names
>
Woodhouse, Gregory J.
"includes (at least) the same code points". But, at any rate, Unicode
can change over time, and it obviously has. If you prefer to refer to
ISO-10646, I have no problem with that, but what puzzles me is why the
name Unicode is offensive. I've been talking to the SACC about using
EBNF (Extended Backus-Naur Formalism) in specifications. Now, if I
chose, I could refer to ISO/IEC 14977 - or even ISO/IEC 14977-1996(E),
but the only reason I can give you the full reference number is that I
have a copy of it here on my desk. But if I were to do that, what would
be the point? The term EBNF is well-known to those familiar with
syntactic specifications of programing languages, but the ISO reference
number is not.
(BTW, I thought the current version was Unicode 4.0, but I'm obviously
behind the times).
-----Original Message-----
From: Hard...@googlegroups.com [mailto:Hard...@googlegroups.com] On
Jim Self
> Interesting that you
> should characterize it as Unicode subsuming ISO-10646. Unicode is still a
> smaller characterset than ISO-10646 described.
>
As I read the wikipedia article, Unicode and ISO-10646 have converged
over the last 15 years so that now ISO-10646 *is* the Unicode character
map and nothing more:
"ISO 10646 is a simple character map, an extension of previous standards
like ISO 8859 <http://en.wikipedia.org/wiki/ISO_8859>. In contrast,
Unicode adds rules for collation, normalisation of forms, and the
bidirectional algorithm for scripts like Hebrew
<http://en.wikipedia.org/wiki/Hebrew_language#Writing_system> and Arabic
<http://en.wikipedia.org/wiki/Arabic_alphabet>. For interoperability
between platforms, especially if bidirectional scripts are used, it is
not enough to support ISO 10646; Unicode must be implemented."
Chris Richardson
Chinese proposal was because of the audacity and insensitivity of the
earlier Unicode developers in trying to redefine another cultures means of
doing business and putting them into a corner. Unicode was building more
walls than bridges. When ISO-10646 came along with a framework that
threatened to minimalize Unicode where it belonged, all of a sudden they
discovered that they were now sympatico with ISO-10646. Then, instead of
just accepting the Unicode defined planes under the ISO-10646 standard (as
well as planes for all of the other published character sets), they jumped
in front of the movement and declared that they were leading the parade.
Don't you see the irony of that?
Yes, I read your inclused reference, but it still sounds like revisionist
history. It would be interesting to see who actually makes up the current
Unicode Standards Committee. Mostly venders, I would guess.
----- Original Message -----
From: "Jim Self" <jas...@dcn.davis.ca.us>
To: <Hard...@googlegroups.com>
Sent: Wednesday, February 28, 2007 5:14 PM
Subject: [Hardhats] Re: special characters in patient names
>
> Chris Richardson wrote:
>> Interesting that you
>> should characterize it as Unicode subsuming ISO-10646. Unicode is still
>> a
>> smaller characterset than ISO-10646 described.
>>
>
> As I read the wikipedia article, Unicode and ISO-10646 have converged
> over the last 15 years so that now ISO-10646 *is* the Unicode character
> map and nothing more:
>
> "ISO 10646 is a simple character map, an extension of previous standards
> like ISO 8859 <http://en.wikipedia.org/wiki/ISO_8859>. In contrast,
> Unicode adds rules for collation, normalisation of forms, and the
> bidirectional algorithm for scripts like Hebrew
> <http://en.wikipedia.org/wiki/Hebrew_language#Writing_system> and Arabic
> <http://en.wikipedia.org/wiki/Arabic_alphabet>. For interoperability
> between platforms, especially if bidirectional scripts are used, it is
> not enough to support ISO 10646; Unicode must be implemented."
>
>>> http://en.wikipedia.org/wiki/Universal_Character_Set
> ---------------------------------------
> Jim Self
> Systems Architect, Lead Developer
> VMTH Information Technology Services, UC Davis
> (http://www.vmth.ucdavis.edu/us/jaself)
> ---------------------------------------
> M2Web Demonstration with VistA
> (http://vista.vmth.ucdavis.edu/)
> ---------------------------------------
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats-u...@googlegroups.com
> -~----------~----~----~----~------~----~------~--~---