With GT.M you can easily use C (or any language with a C compatible
calling interface - some restrictions apply, so read the documentation)
to call M and vice versa. If you are already programming in M for
VistA, it may make sense to stick with M, but ultimately it's really
your choice.
KB_SQL
Bhaskar,
We were thinking of a higher level language like .NET
or Java rather than C and then have offline data
update of the Fileman database. That should make it
easier to get ready trained programmers.
Thanks
__
Do You Yahoo!?
Tired of spam?
The VA is developing a Java based replacement for CPRS, so perhaps you would
like to consider and Open Source version of Java, and making your work Open
Source, of course! ;-)
On Thursday 03 February 2005 12:13 pm, Nick James wrote:
Bhaskar,
We were thinking of a higher level language like
Hi,
In the context of a new development in a 300-bed
hospital, what language and approach would you suggest
for those modules that are to complement VistA in a
local customisation. These relate to patient
registration, billing, pharmacy and other localized
user requirements that are not directly
I suppose that's an option, but it seems unreasonably pessimistic to
me. A popular solution to this problem is to use HL7, but obviously you
need HL7 support in the non-VistA components, too. VistA provides other
options, like the RPC Broker (used by CPRS), SMTP via server options in
Mailman, or
Nick,
You will get the tightest integration if you use M.
GT.M is designed to work with C, and I believe other
languages that can load is obj files. There is also a
perl interface I believe.
I am facing a similar issue. Our practice was a
practice management package with Oracle as its
