Subj : Translating Case From Ba
To : Murray Lesser
From : Mike Luther
Date : Mon Feb 19 2001 01:35 am
I'll continue .. Murray .. your posts are very helpful in trying to reach a
decision on where to go next ..
All "ML>" symbols mark your priceless advice.
ML> To my knowledge, PL/I does not have automatic garbage collection.
ML> AFAIK, no language that requires a "FREE" (or equivalent) statement to
ML> recover memory otherwise lost in "the heap" has automatic garbage
ML> collection. I've never written a program (except in C) that required a
ML> "free" statement, so I really don't know.
Yes, another mis-said or mis-phrased use of terminology. I suffer that I've
never had formal training in any of this. Properly beaten early-on, my
understanding of all this would be better. However, in this case, Lewis
Carroll's comment, "He only does it to annoy ..", isn't true at all here.
ML> I consider all of these (even BASIC) to be "modern"
ML> languages. But then, I am very old.
So am I, and shopworn, too.
ML> There is no multithreading built in to any programming language that
ML> I know other than PL/I (for "workstations") and Java. (I'm not sure
ML> that one can write a Java interpreter or a PL/I compiler with built-in
ML> multithreading, that will work under an operating system that doesn't
ML> intrinsically support multithreading. For other languages, one makes
ML> calls on the operating-system API if one wishes to implement
ML> multithreading. The PL/I manuals warn _not_ to make such calls; use the
ML> appropriate PL/I functions, instead. IBM "host" [big iron] versions of
ML> PL/I implement multitasking within the same application, rather than
ML> multithreading, because the host hardware and operating systems support
ML> such constructs.
These are things in which I have no experience. I know where I want to go.
Getting closer to there has been fun. I really wish I'd had the formal
training and schooling long ago and far away. But if I'd taken the time and
gone down that road, I'd not have the other perceptions from experience that
seem to be critical to the tasks, either..
It's almost back to Lewis Carroll again, "You are Old Father William, the Young
Man said.." ;(
ML> But I don't see how DOS can support multitheading per se.
ML> OS/2 supports DOS multitasking in separate VDMs, but communication
ML> between the DOS tasks is (intentionally) very difficult (and somewhat
ML> dangerous to the health of your system).
Which is exactly why I isolated the required communication to disk I/O. A long
time ago Paul Sittler taught me, "Let the operating system do the work!"
ML> If I understand what you are talking about, "certification" means
ML> proving the whole system is bug free!!! For one thing, that is both
ML> theoretically and practically impossible!!
You understand perfectly. I understand, well enough, I think, your comment. I
agree. Now, that said, I'll pass along Dr. Shoppe's instructions to me in
roughly 45 minutes he gave me in October of 1996, I think. He has been
remarkable accurate in some ways about where the Feds are going. As far as I
can tell, it is the intent of the FDA that "certification" means proving the
whole system is bug free!!!
Period.
They take the position that when they issue a certification for a `medical
device', that's supposed to be the case. As a result of what happened in
Tyler, Shoppe, as Chairman for the Software Standards committee told me, in
essence, the following:
1.) If software and hardware combined, touch the body to either
take data from it or treat the body, it will be a licensed
medical device.
2.) If medical data of any kind is stored in a medical record
by hardware and software, we want to make sure that record
is seen exactly as it was placed there, by any qualified
medical practitioner who uses that data to make a future
determination on treatment.
That means that all forms of compression are of interest to
to the FDA. The FDA will insist that compression must be
loss-less in every case.
I was told that, at some point in the future, the results
of that position would become quite interesting. He told
me that, although most folks didn't think about it, all
modems use compression algorithms to move data. Thus,
at some point in the future, all modems used in medicine
would wind up being licensed, at least to the extent of
their compression techniques!
I was cautioned to stay completely out of the network game.
In that all networks use compression of some form for data
exchange and packetizing, at some point in the future all
networks used in medicine would become licensed. (!)
3.) In so far as medical record storage was concerned, at some
point in the future, push technology would be forbidden
for medical record modification. The position of the FDA
was and will become that only a qualified medical person
can make a decision as to what data goes into a medical
record at any specific facility. Multiple site storage
of records wasn't a problem, provided that the precise data
that was in that record was absolutely guaranteed to be
delivered in lossless fashion to some other place. However,
any use of a remote facility being able to alter other site
records on a remote-insertion basis, without the approval
of a qualified medical person on site to permit that, would
at some point in the future, be completely forbidden.
That was pretty darn specific, I thought. I also was on hand at the Houston
HAL-PC when the president of Western Digital laid out the next five years of
what we could expect in storage technology, as compared to the march of
hardware evolution. I thought of the above comments by Schoppe and wondered if
it truly would work out that way. That was in mid-1998.
Now, if you have followed what has happened, particularly in the last two years
as to the Federal adoption of the new, now formally required AMC-X12 record
transmission standard, what Schoppe told me is turning out to be dead on
target, I think! Together with what is currently a mandated PKI
identification and security blanket, within the next two years from October 16,
2000, for all large institutions, and three years for everyone, all forms of
electronic exchange of medical data must comply to that standard.
The facility doesn't have to store in that exact format, but every single
medical operation in the whole country has to talk it and be able to handle
everything that is in the transmission format, even if it doesn't store it
directly as such.
As of the Final NPRM that was only given 30 days for public comment which was
issued on June 4, 1999, that standard encompassed, if my count was correct,938
different field definitions. Although the fields were fixed-length records in
the raw workup, the transmission standard is variable length data, trailing
spaces truncated, for transmission effectiveness. As well,it includes nested
loops in those variable length layouts, total iterations not sent, if loop
count isn't filled.
I've managed to code that 'standard' at least the proposed form from 1998,into
BASIC's UDT's and "C" structures. That expands, as far as I can see into CLASS
concept for C++, in my training-starved programming mind-set. I've managed to
cross-walk this to the current HCFA1500 form, as well as the more recent UB-92,
both of which are technically dead now. I've managed to cross-walk it to the
roughly 1,000,000 lines of BASIC source in my real-time facility control
template.
The test bed works. But it isn't WAN, nor in present form, what would be
efficiently mirrorable on distance-separated big-iron sites. The massive
binary logic keying operations also seem easiest to move from Btrieve to
C-tree, if my current research looks correct. That's another whole different
story. Large numbers of keys and where they point are crucial.
The only way to catch a run-away pony in the near future will be to get it as
it leaves the barn, I think. And since we are operating in near-real time with
concurrent reasonable standard GAP accounting double-entry scorecard work,
that's, as far as I can see, far beyond the intent or proposed scope of
AMC-X12. If I don't stumble, we might be in the running for a pre-processor
slot for our own way to obviate any need or third-party claims processing,
removing that cost of business.
AMC-X12 provides for 'pointering' to remote site WAN deliverable embellished
record content for what will be and become all the visual and audio detail
content that will evolve in time. No, I can't provide interface to all that in
DOS, but then, exactly what Dr. Shoppe forecast isn't happening, in what's out
there for medicine today, is it?
The trick, looks like, to me, in being able to make the right decision on the
tools to implement what's been done in a WAN environment. Tools that also must
effectively move us off the current testbed crude way of doing what was done,
the only way it could be done, I think, as it is now.
OS/2 sure looks good for that, given that it is reasonably stable, is
reasonably free from pot-shots, and it *COULD* be certified as part of what FDA
might want as a medical device, if needed. I suspect Dr. Schoppe's full
target display is beyond what FDA can every pay for, but maybe not.
Thus, we are here in the OS/2 programming echo!
ML> For more on the themes you expressed, see my message to David,
ML> topic: "Extending PL/I," that I am uploading to this same echo at the
ML> same time as this one.
So noted.
Thank you very much for taking time with a very less capable person than either
of you two gents.
Mike @ 117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
