Re: module localization - perceived VistA problem
On Monday 06 January 2003 13:49, Christian Heller wrote: The daemon would notionally be in two sections - the front end whcih is dependent upon the data structure passed to it, In today's informatics, it is common to distinguish between Frontend (User Interface) and Backend (Persistence Mechanism). THIS IS WRONG. yeah yeah. In a train, each carriage has a front end and a back end, and this has some meaning related to the way in which the whole assemblage works. Nothing more technical and complex intended than that in the description I gave. I'm going to be quiet for a bit, we have all had a holiday, thought, and now threaten to become a medium volume list. -- From one of the Linux desktops of Dr Adrian Midgley http://www.defoam.net/
Re: module localization - perceived VistA problem
On Monday 06 January 2003 13:49, Christian Heller wrote:
The daemon would notionally be in two sections - the front end whcih is
dependent upon the data structure passed to it,
I had in mind, notionally, a daemon consisting of a single executable which
would be made by joining together two sections of code.
One is written once and is the same wherever the daemon is to run, and
whatever medical record and prescription _generator_ is being used.
The other is written once for the UK (well, 1.2 times since Northern Ireland
has a different layout for prescriptions from England Wales and Scotland),
once for France, once for each State of the Union and so on.
But is unaffected by changes in the clincial reocrd system and prescription
generator.
Periodically there would for good reason be a change to the first part, that
part which receives the data input to this section of program code, and this
would be passed out to everyone, but would not occasion any change in
anyone's main medical programs, although presumably the users of one systme
said let us have another field for passing through information on {I dunno}
to the eventual printed prescription or passed message.
Spasmodically and for administrative reasons there would be a change in the
layout demanded for a pritned prescription in some country, and this would be
written once for all systems that cared to use this daemon, but only be used
in that country. If it was really new it might produce a change - an
addition - to the data passed through the first part of the daemon, in which
case the rest of the world would get that as well, but only those systems
that needed to be used in the country in question would actually use and be
modified to satisfy.
I'd envisage, being a simple soul and having done this, the thing working by
watching a particular named directory, and whenever a file appeared in that
directory, reading the file, the part of the first part extracting the data
which would likely be XML, and the part of the second part laying it out in
the order demanded by the local powers temporal.
Then spiking the file, and periodically cleaning out the whole mess.
Why do it like this?
-
Easy.
Widely applicable.
Extensible.
Licence hassles are minimised - the daemon can be GPL and the main clinical
system can be Hewlett(TM) Packard(R) Medicine for all we care.
Not only is it OS agnostic, it can run on a commodity box that isn't on the
same OS or indeed the same continent as the clincial system albeit I doubt it
would go further away than the local pharmacy round the corner. (using scp
or sftp for instance)
Is this a sensible open source component to envisage?
... and to suggest building and making available?
You tell me.
--
From one of the Linux desktops of Dr Adrian Midgley
http://www.defoam.net/
Re: module localization - perceived VistA problem
I had in mind, notionally, a daemon consisting of a single executable which would be made by joining together two sections of code. One is written once and is the same wherever the daemon is to run, and whatever medical record and prescription _generator_ is being used. The other is written once for the UK (well, 1.2 times since Northern Ireland has a different layout for prescriptions from England Wales and Scotland), once for France, once for each State of the Union and so on. But is unaffected by changes in the clincial reocrd system and prescription generator. [...] Is this a sensible open source component to envisage? .. and to suggest building and making available? Absolutely. It is a pity you probably don't have time to join GnuMed with what excellent taste in programming you display (this is NOT meant satirically). At some point GnuMed will have to acquire form printing capabilities. For all I care it could just as well interface with the abovementioned demon. Architecturally, the way GnuMed will handle patient memory cards (which we have here in Germany) is exactly like this: A demon polling/being IRQed to read the data from the cards into files and GnuMed checking upon certain locations regularly to pick up newly inserted/read cards. We've got one developer working on this (www.libchipcard.de). Regards, Karsten Hilbert -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: Sherlock Holmes
It is modular. -- IV On Sun, 05 Jan 2003 22:41:29 -0700 David Forslund [EMAIL PROTECTED] wrote: But it doesn't necessarily meet the needs of other organizations, as I understand. It would be nice if the system were modular so that different components could be plugged in so that best of breed components could be used. -- Ignacio Valdes,MD,MS Editor: Linux Medical News http://www.linuxmednews.com 'Revolutionizing Medical Education and Practice'
RE: On Possible Canards, or Don't forget to duck
I'm not a doctor ... work at cdc hence monitoring this list at the moment sitting in Rochester MN airport to go home, mother at Mayo in ICU, her GBS/vasculitis(still undecided) rough case w/ axonal nerve damage, kidney impairment, asceptic meningitis/stroke[s]/other enchephalitic (sp?) damage possible and ... etc. etc. Relevance to this thread is the Mayo doctors reviewed all similar cases (one? two?) with combo GBS/axonal/IVIG damage and believe possible that those cases may have been misdiagnosis of vasculitis. I believe it is crucial that the background med notes not be lost in a 'structured/coded' information representation. Nothing wrong with a top level coded representation, but the ability to dig below that simplified world view is important. Heitzso
Re: module localization - perceived VistA problem
Is this a sensible open source component to envisage? ... and to suggest building and making available? You tell me. This sounds very reasonable to me, loosely-coupled components that can easily be switched/exchanged. Christian
Re: Beyond VistA, was Re: Sherlock Holmes
On Sun, 5 Jan 2003, Adrian Midgley wrote: Have you ever tried to export data stored in VistA? http://www.hardhats.org/tools/extract/data_extractors.html looks to me as though someone has given it serious thought. Adrian, After reviewing the data_extractors howto above, would you agree that there may be motivation to think beyond VistA? How about creating a new screen for data entry or adding data elements to the schema? There just have to be better ways to support these functions! One of the areas that might be expected to develop is a front end which makes it easier to generate M code to do such things. Two questions that come to mind: 1) how hard would it be to develop a more user-friendly front-end to do these things? 2) is M code the best interface between the front-end and the backend? Against that, those who have learnt M seem to be productive directly in it. Maybe there is priesthood phenomenom here? M continues to present a significant barrier-to-entry. Esiobjects (esiobjects.org) may change this. Does anyone know whether Esiobjects can be used to modify legacy M code, like those in VistA? But building connections is more sensible and less likely to fail hugely than starting from scratch - this is a message repeated many times in the evaluation of large IT projects, usually as part of a storm of recrimination over a failed new implementation. I don't think anyone would categorically oppose connecting their software system to VistA. The questions are how and how hard. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org (Hosting OIO Library #1 and OSHCA Mirror #1)
Alternatives to VistA? Re: Beyond VistA, was Re: Sherlock Holmes
On Sun, 5 Jan 2003, John Gage wrote: But what are the alternatives? John, There are indeed many alternatives. Some are proprietary and others involve other compromises. VistA, like all medical applications, has flaws. Other alternatives also have flaws - perhaps different flaws. ... Andrew, please point out to me the open source medical application that is as successful as VistA. It really depends on how you care to define success. The OIO system gave us capabilities that VistA cannot deliver. In fact, the OIO project was largely motivated by my experience with VistA. Please point out to me the comprehensive medical application where an equal amount of additional effort can produce such extraordinary results. This question betrays your bias. Comprehensive may in fact NOT be such a desirable feature :-). In fact, the OIO project is exactly an experiment in the usefulness and implications of a non-comprehensive medical application. I am happy to clarify if you are interested. Is M-phobia the reason why VistA is not being pursued? No, VistA is difficult to embrace for many reasons. M-aversion is just one of them. Hopefully things will change with help from Medsphere. For one thing, VistA people need to be more active on this list :-). Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org (Hosting OIO Library #1 and OSHCA Mirror #1)
