Re: [Hardhats-members] Billing Module for VistA
Nancy, I'd be interested in seeing the specs on VistA's billing output. I'm not enough of a progammer to do much more than create a post processor to convert text based output to the ANSI 837 format (probably in BASIC, unless I can figure out M) but that would probably be enough for my low budget office to avoid the costs of clearinghouses and middlemen. I'm back to billing everything on CMS-1500 paper and I'm trying to get VistA to generate it. I'm bogged down trying to place CPT and ICD codes on the CPRS encounter form which seems to be where the billing module captures the data. My encounter form comes up blank, despite having imported all of the CPT and ICD codes. Any Idea how to add codes to the form? Mike Schrom Nancy Anthracite wrote: I believe VistA can still generate a 1500 type bill, although I have never tried any of that. The output in the document I have is for sending to Austin to then forward to WebMD, but it has all of the content that all of the insurance companies might want beyond the usual stuff in a HIPAA compliant transmission. On Sunday 05 February 2006 15:53, James Gray wrote: I assume it is still included in the IHS RPMS FOIA release. The bill generator in RPMS is much more than a single routine. There is also the newer software from Infomatix. Jim Gray - Original Message - From: JohnLeoZimmer [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 05, 2006 1:10 PM Subject: Re: [Hardhats-members] Billing Module for VistA If that routine is available it would give us a big headstart. jlz James Gray wrote: I just want to comment about the concept of putting lines of code into the various revenue-generating packages in VistA. I think that should be avoided as much as possible. In RPMS the approach has been to put a special cross reference onto the Visit file (file 910) that flags the visit as having not been checked by billing. Every night during off hours a background program runs to check all of the new and changed visits and checks all of the data elements in the various package that keep data that might be billable items. Bills are generated in that way without requiring mods to the clinical packages. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
The real solution for this is going to have a formal billing package. There was a conference call with Fred Trotter who wanted to integrate his free billing system with VistA. But there was no one that started the actual programming. Kevin On 2/6/06, Mike Schrom [EMAIL PROTECTED] wrote: Nancy, I'd be interested in seeing the specs on VistA's billing output. I'm not enough of a progammer to do much more than create a post processor to convert text based output to the ANSI 837 format (probably in BASIC, unless I can figure out M) but that would probably be enough for my low budget office to avoid the costs of clearinghouses and middlemen. I'm back to billing everything on CMS-1500 paper and I'm trying to get VistA to generate it. I'm bogged down trying to place CPT and ICD codes on the CPRS encounter form which seems to be where the billing module captures the data. My encounter form comes up blank, despite having imported all of the CPT and ICD codes. Any Idea how to add codes to the form? Mike Schrom Nancy Anthracite wrote: I believe VistA can still generate a 1500 type bill, although I have never tried any of that. The output in the document I have is for sending to Austin to then forward to WebMD, but it has all of the content that all of the insurance companies might want beyond the usual stuff in a HIPAA compliant transmission. On Sunday 05 February 2006 15:53, James Gray wrote: I assume it is still included in the IHS RPMS FOIA release. The bill generator in RPMS is much more than a single routine. There is also the newer software from Infomatix. Jim Gray - Original Message - From: JohnLeoZimmer [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 05, 2006 1:10 PM Subject: Re: [Hardhats-members] Billing Module for VistA If that routine is available it would give us a big headstart. jlz James Gray wrote: I just want to comment about the concept of putting lines of code into the various revenue-generating packages in VistA. I think that should be avoided as much as possible. In RPMS the approach has been to put a special cross reference onto the Visit file (file 910) that flags the visit as having not been checked by billing. Every night during off hours a background program runs to check all of the new and changed visits and checks all of the data elements in the various package that keep data that might be billable items. Bills are generated in that way without requiring mods to the clinical packages. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. Kevin Toppenberg wrote: The real solution for this is going to have a formal billing package. There was a conference call with Fred Trotter who wanted to integrate his free billing system with VistA. But there was no one that started the actual programming. Kevin On 2/6/06, Mike Schrom [EMAIL PROTECTED] wrote: Nancy, I'd be interested in seeing the specs on VistA's billing output. I'm not enough of a progammer to do much more than create a post processor to convert text based output to the ANSI 837 format (probably in BASIC, unless I can figure out M) but that would probably be enough for my low budget office to avoid the costs of clearinghouses and middlemen. I'm back to billing everything on CMS-1500 paper and I'm trying to get VistA to generate it. I'm bogged down trying to place CPT and ICD codes on the CPRS encounter form which seems to be where the billing module captures the data. My encounter form comes up blank, despite having imported all of the CPT and ICD codes. Any Idea how to add codes to the form? Mike Schrom Nancy Anthracite wrote: I believe VistA can still generate a 1500 type bill, although I have never tried any of that. The output in the document I have is for sending to Austin to then forward to WebMD, but it has all of the content that all of the insurance companies might want beyond the usual stuff in a HIPAA compliant transmission. On Sunday 05 February 2006 15:53, James Gray wrote: I assume it is still included in the IHS RPMS FOIA release. The bill generator in RPMS is much more than a single routine. There is also the newer software from Infomatix. Jim Gray - Original Message - From: JohnLeoZimmer [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 05, 2006 1:10 PM Subject: Re: [Hardhats-members] Billing Module for VistA If that routine is available it would give us a big headstart. jlz James Gray wrote: I just want to comment about the concept of putting lines of code into the various revenue-generating packages in VistA. I think that should be avoided as much as possible. In RPMS the approach has been to put a special cross reference onto the Visit file (file 910) that flags the visit as having not been checked by billing. Every night during off hours a background program runs to check all of the new and changed visits and checks all of the data elements in the various package that keep data that might be billable items. Bills are generated in that way without requiring mods to the clinical packages. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as
CS HL7 Interface ~ was: RE: [Hardhats-members] GIS HL7 Software
Is anyone using the Controlled Subs ADT interface? Ric Carroll Health Systems Design Development ( phone: 972-604-8992 + email: [EMAIL PROTECTED] "If it were easy to read, it wouldn't be called code." From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James GraySent: Friday, February 03, 2006 5:27 PMTo: hardhats-members@lists.sourceforge.netSubject: [Hardhats-members] GIS HL7 Software Is anyone familiar with the GIS HL7 software? Jim Gray
Re: [Hardhats-members] Billing Module for VistA
--- Mike Schrom [EMAIL PROTECTED] wrote: I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. How comfortable do you feel with Basic? If you have an idea that you want to try implementing, I'd say to go for it. Personally, I think VistA would benefit from supporting multiple languages, but right now the infrastructure is a bit limited. I like to think M is to VistA as C is to Unix. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
Mike, If you can program in old Basic (I think that is what you are saying), you can learn to program in Mumps. The hard part of Mumps is not really the language, but learning to read some of the older styles of programming in Mumps. But if you do not learn Mumps you surely will not be able to read the VistA Mumps code. Jim Gray - Original Message - From: Mike Schrom [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Monday, February 06, 2006 7:53 AM Subject: Re: [Hardhats-members] Billing Module for VistA I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. Kevin Toppenberg wrote: The real solution for this is going to have a formal billing package. There was a conference call with Fred Trotter who wanted to integrate his free billing system with VistA. But there was no one that started the actual programming. Kevin On 2/6/06, Mike Schrom [EMAIL PROTECTED] wrote: Nancy, I'd be interested in seeing the specs on VistA's billing output. I'm not enough of a progammer to do much more than create a post processor to convert text based output to the ANSI 837 format (probably in BASIC, unless I can figure out M) but that would probably be enough for my low budget office to avoid the costs of clearinghouses and middlemen. I'm back to billing everything on CMS-1500 paper and I'm trying to get VistA to generate it. I'm bogged down trying to place CPT and ICD codes on the CPRS encounter form which seems to be where the billing module captures the data. My encounter form comes up blank, despite having imported all of the CPT and ICD codes. Any Idea how to add codes to the form? Mike Schrom Nancy Anthracite wrote: I believe VistA can still generate a 1500 type bill, although I have never tried any of that. The output in the document I have is for sending to Austin to then forward to WebMD, but it has all of the content that all of the insurance companies might want beyond the usual stuff in a HIPAA compliant transmission. On Sunday 05 February 2006 15:53, James Gray wrote: I assume it is still included in the IHS RPMS FOIA release. The bill generator in RPMS is much more than a single routine. There is also the newer software from Infomatix. Jim Gray - Original Message - From: JohnLeoZimmer [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 05, 2006 1:10 PM Subject: Re: [Hardhats-members] Billing Module for VistA If that routine is available it would give us a big headstart. jlz James Gray wrote: I just want to comment about the concept of putting lines of code into the various revenue-generating packages in VistA. I think that should be avoided as much as possible. In RPMS the approach has been to put a special cross reference onto the Visit file (file 910) that flags the visit as having not been checked by billing. Every night during off hours a background program runs to check all of the new and changed visits and checks all of the data elements in the various package that keep data that might be billable items. Bills are generated in that way without requiring mods to the clinical packages. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search
Re: [Hardhats-members] Billing Module for VistA
I'm sure I could do it in BASIC, but if I'm going to stick with VistA, I'd probably try to learn M eventually anyway. I have the ANSI 837 documentation, though it may be an older version. I'd like to see how VistA formats the output. Greg Woodhouse wrote: --- Mike Schrom [EMAIL PROTECTED] wrote: I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. How comfortable do you feel with Basic? If you have an idea that you want to try implementing, I'd say to go for it. Personally, I think VistA would benefit from supporting multiple languages, but right now the infrastructure is a bit limited. I like to think M is to VistA as C is to Unix. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] How to add Program to tools menu
I do Stephen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen K. Miyasato Sent: Friday, February 03, 2006 11:58 AM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] How to add Program to tools menu Does anyone know how to add a program to be started from CPRS in the tools menu? Thanks Stephen K. Miyasato --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
The output is delivered in an email message as I understand it, so you probably have to figure out how to parse that, not Mumps code. On Monday 06 February 2006 12:06, James Gray wrote: Mike, If you can program in old Basic (I think that is what you are saying), you can learn to program in Mumps. The hard part of Mumps is not really the language, but learning to read some of the older styles of programming in Mumps. But if you do not learn Mumps you surely will not be able to read the VistA Mumps code. Jim Gray - Original Message - From: Mike Schrom [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Monday, February 06, 2006 7:53 AM Subject: Re: [Hardhats-members] Billing Module for VistA I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. Kevin Toppenberg wrote: The real solution for this is going to have a formal billing package. There was a conference call with Fred Trotter who wanted to integrate his free billing system with VistA. But there was no one that started the actual programming. Kevin On 2/6/06, Mike Schrom [EMAIL PROTECTED] wrote: Nancy, I'd be interested in seeing the specs on VistA's billing output. I'm not enough of a progammer to do much more than create a post processor to convert text based output to the ANSI 837 format (probably in BASIC, unless I can figure out M) but that would probably be enough for my low budget office to avoid the costs of clearinghouses and middlemen. I'm back to billing everything on CMS-1500 paper and I'm trying to get VistA to generate it. I'm bogged down trying to place CPT and ICD codes on the CPRS encounter form which seems to be where the billing module captures the data. My encounter form comes up blank, despite having imported all of the CPT and ICD codes. Any Idea how to add codes to the form? Mike Schrom Nancy Anthracite wrote: I believe VistA can still generate a 1500 type bill, although I have never tried any of that. The output in the document I have is for sending to Austin to then forward to WebMD, but it has all of the content that all of the insurance companies might want beyond the usual stuff in a HIPAA compliant transmission. On Sunday 05 February 2006 15:53, James Gray wrote: I assume it is still included in the IHS RPMS FOIA release. The bill generator in RPMS is much more than a single routine. There is also the newer software from Infomatix. Jim Gray - Original Message - From: JohnLeoZimmer [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 05, 2006 1:10 PM Subject: Re: [Hardhats-members] Billing Module for VistA If that routine is available it would give us a big headstart. jlz James Gray wrote: I just want to comment about the concept of putting lines of code into the various revenue-generating packages in VistA. I think that should be avoided as much as possible. In RPMS the approach has been to put a special cross reference onto the Visit file (file 910) that flags the visit as having not been checked by billing. Every night during off hours a background program runs to check all of the new and changed visits and checks all of the data elements in the various package that keep data that might be billable items. Bills are generated in that way without requiring mods to the clinical packages. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
--- Nancy Anthracite [EMAIL PROTECTED] wrote: The output is delivered in an email message as I understand it, so you probably have to figure out how to parse that, not Mumps code. It's true that mail is often used for message transport, but there's really no reason why a VistA based solution couldn't opt for another alternative. For example, VistA HL7 still supports e-mail as a possible transport, but the most common option over TCP/IP is MLLP. There are all kinds of options: HL7, HTTP, FTP, web services (probably over HTTP), and so forth. Rather than being limited by what is being done now, why not ask what best suits your needs? === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[Hardhats-members] Step back and think about your needs
This is just an observation, but my experience is that if you start out focusing on implementation details before you understsnd at a high level what it is that you want to accomplish, it's easy to ind yourself in a quagmire, making no real progress. Questions like Should I use e-mail, HL7 or wb services for message transport? are simply NOT THAT IMPORTANT, and they can wait until you've figured out what the content of your messages needs to be. I know it's tempting to look at an existing module that seems close to what you want and then start focusing on implementation details, but that's seldom a good idea. In order to be successful, you really need to focus on understanding what it is you're trying to do, and put matters of execution on the back burner until you reach the point that those kinds of low level decisions really do need to be made (which is probably later in the process than you think). If you don't, you'll find yourself overwhelmed with mostly irrelevant information, and it will be very difficult, even to guess what needs to be done next. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
Because if you use what is shipped out in email, you do not need to know M and you don't need to modify VistA, and I thought it was a something thing that a VB Programmer could deal with. On Monday 06 February 2006 13:34, Greg Woodhouse wrote: --- Nancy Anthracite [EMAIL PROTECTED] wrote: The output is delivered in an email message as I understand it, so you probably have to figure out how to parse that, not Mumps code. It's true that mail is often used for message transport, but there's really no reason why a VistA based solution couldn't opt for another alternative. For example, VistA HL7 still supports e-mail as a possible transport, but the most common option over TCP/IP is MLLP. There are all kinds of options: HL7, HTTP, FTP, web services (probably over HTTP), and so forth. Rather than being limited by what is being done now, why not ask what best suits your needs? === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Nancy Anthracite --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[Hardhats-members] Purchasing CPT code license
Just to confirm, is the AMA CPT code setwhich is formatted for VistA Office also compatible with FOIA VistA? In other words, the following: https://catalog.ama-assn.org/Catalog/product/product_detail.jsp?productId=prod64?checkXwho=done Other than the CPT codes, are all other code sets included with the FOIA distribution? Thanks, Marc
Re: [Hardhats-members] Billing Module for VistA
--- Nancy Anthracite [EMAIL PROTECTED] wrote: Because if you use what is shipped out in email, you do not need to know M and you don't need to modify VistA, and I thought it was a something thing that a VB Programmer could deal with. Extending VistA (adding new components) and modifying VistA (altering existing components) aren't the same thing. There's no reason not to *extend* VistA, but modifying what is already there is another thing entirely. I agree with you that a VB (or Java, or C) programmer ought to be able to deal with mail messages without any trouble, but isn't that true of HTTP, HL7, and other protocols, too? The tricky thing is not the message format itself, but the interface with the rest of VistA. But then again, I suspect we're saying the same thing in different ways. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Purchasing CPT code license
Yes and yes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Krawitz Sent: Monday, February 06, 2006 12:41 PM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] Purchasing CPT code license Just to confirm, is the AMA CPT code setwhich is formatted for VistA Office also compatible with FOIA VistA? In other words, the following: https://catalog.ama-assn.org/Catalog/product/product_detail.jsp?productId=prod64?checkXwho=done Other than the CPT codes, are all other code sets included with the FOIA distribution? Thanks, Marc
[Hardhats-members] Making Fileman language independent?
First of all, I need to clarify that I am not talking about the way Fileman is implemented. I'm not talking about rewriting it in some language other than MUMPS. Rather, I have in mind modifying Fileman so that people *using* it (both as programmers and as users) do not have to work directly with the underlying global subsystem or embedded code such as input transforms, screens, cross-refereences, etc. It seems to me that in many, if not most cases, Fileman does an admirable job of insulating both usewrs and programmers from the details of the underlying implementation (e.g., by building input transforms and computed expressions from high level descriptions, by choosing reasonable defaults for global storage locations, and so forth). But it stops short of achieving full language independence. This is unfortunate, because it forces would-be VistA developers to deal directly with what should be system internals, and is a major obstacle to providing support for multi-language development in the VistA environment. It's not an issue of whether MUMPS is or is not a good language. C is a perfectly good language, too, but how many programmers would want to use Unix as their primary development platform if it were the only language choice available? There are certainly obstacles to making Fileman language independent, and I don't mean to suggest that it would be easy, but I do think VistA would benefit. If nothing else, it would benefit from the increased pool of potential developers and greater ease of integration with other systems. The biggest obstacle would, of course, be backward compatibility. People are used to $ORDERing through the B cross-reference, or writing their own screens and identifiers, and code using these techniques isn't going to just go away. But right now, it's not even possible to write code that avoids delving into the internals, at least at some level (or in some cases, it is possible, but the performance cost is unacceptable). === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Billing Module for VistA
I have a HCFA1500 billing application (using it years) in FileMan that I am willing to share. I can export it via KIDS for interested parties. The downside is it is in FileMan - not VistA and it has a few files not represented in VistA. It does the HCFA just fine. I now make a daring statement that I will make every effort to get it to a level that will integrate with VistA by the end of this month. It is quite rudimentary, built on multiples and ScreenMan. It would be interesting to have feed back on whether it has any potential for other users. I may be able to set it up with VPN (or outside our firewall) to give someone a chance to look at it as is. thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Mike Schrom Sent: Monday, February 06, 2006 11:18 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Billing Module for VistA I'm sure I could do it in BASIC, but if I'm going to stick with VistA, I'd probably try to learn M eventually anyway. I have the ANSI 837 documentation, though it may be an older version. I'd like to see how VistA formats the output. Greg Woodhouse wrote: --- Mike Schrom [EMAIL PROTECTED] wrote: I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. How comfortable do you feel with Basic? If you have an idea that you want to try implementing, I'd say to go for it. Personally, I think VistA would benefit from supporting multiple languages, but right now the infrastructure is a bit limited. I like to think M is to VistA as C is to Unix. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Billing Module for VistA
Having traded Basic for FileMan nearly 20 years ago - I would not advise Basic for billing - though I do use a VB interface to create some jazzy forms with Omniform. http://www.nuance.com/omniform/ thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Monday, February 06, 2006 1:43 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Billing Module for VistA --- Nancy Anthracite [EMAIL PROTECTED] wrote: Because if you use what is shipped out in email, you do not need to know M and you don't need to modify VistA, and I thought it was a something thing that a VB Programmer could deal with. Extending VistA (adding new components) and modifying VistA (altering existing components) aren't the same thing. There's no reason not to *extend* VistA, but modifying what is already there is another thing entirely. I agree with you that a VB (or Java, or C) programmer ought to be able to deal with mail messages without any trouble, but isn't that true of HTTP, HL7, and other protocols, too? The tricky thing is not the message format itself, but the interface with the rest of VistA. But then again, I suspect we're saying the same thing in different ways. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Billing Module for VistA
--- Thurman Pedigo [EMAIL PROTECTED] wrote: The downside is it is in FileMan - not VistA and it has a few files not represented in VistA. What do you mean? There is nothing wrong with creating new files (so long as you stsay within your namespace and numberspace, to avoid possible conflicts with other VistA modules). In fact, it is be expected that new applications (modules) will introduce new files. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Making Fileman language independent?
How is this done in relational databases? There has some be some sort of language to evaluate the database. SQL is a language, I guess. It seems that a M database is a more organic creature -- containing code to protect itself etc. Probably relational databases can do this too, but at our site at least, it is not done. For example, when our front staff put in goofy social security numbers, the database is perfectly happy to accept these erroneous values. So I am guessing that to be insulated from M would require an introduction of some different language as a replacement. I can't see that happening. Kevin On 2/6/06, Greg Woodhouse [EMAIL PROTECTED] wrote: First of all, I need to clarify that I am not talking about the way Fileman is implemented. I'm not talking about rewriting it in some language other than MUMPS. Rather, I have in mind modifying Fileman so that people *using* it (both as programmers and as users) do not have to work directly with the underlying global subsystem or embedded code such as input transforms, screens, cross-refereences, etc. It seems to me that in many, if not most cases, Fileman does an admirable job of insulating both usewrs and programmers from the details of the underlying implementation (e.g., by building input transforms and computed expressions from high level descriptions, by choosing reasonable defaults for global storage locations, and so forth). But it stops short of achieving full language independence. This is unfortunate, because it forces would-be VistA developers to deal directly with what should be system internals, and is a major obstacle to providing support for multi-language development in the VistA environment. It's not an issue of whether MUMPS is or is not a good language. C is a perfectly good language, too, but how many programmers would want to use Unix as their primary development platform if it were the only language choice available? There are certainly obstacles to making Fileman language independent, and I don't mean to suggest that it would be easy, but I do think VistA would benefit. If nothing else, it would benefit from the increased pool of potential developers and greater ease of integration with other systems. The biggest obstacle would, of course, be backward compatibility. People are used to $ORDERing through the B cross-reference, or writing their own screens and identifiers, and code using these techniques isn't going to just go away. But right now, it's not even possible to write code that avoids delving into the internals, at least at some level (or in some cases, it is possible, but the performance cost is unacceptable). === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
I'm interested in seeing it, but I would really like to have an EDI billing routine. You planted a seed, though. I didn't consider using Fileman, but that isn't such a bad idea. Fileman is pretty Vista 'friendly', and doesn't require 'programming' per se. Thurman Pedigo wrote: I have a HCFA1500 billing application (using it years) in FileMan that I am willing to share. I can export it via KIDS for interested parties. The downside is it is in FileMan - not VistA and it has a few files not represented in VistA. It does the HCFA just fine. I now make a daring statement that I will make every effort to get it to a level that will integrate with VistA by the end of this month. It is quite rudimentary, built on multiples and ScreenMan. It would be interesting to have feed back on whether it has any potential for other users. I may be able to set it up with VPN (or outside our firewall) to give someone a chance to look at it as is. thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Mike Schrom Sent: Monday, February 06, 2006 11:18 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Billing Module for VistA I'm sure I could do it in BASIC, but if I'm going to stick with VistA, I'd probably try to learn M eventually anyway. I have the ANSI 837 documentation, though it may be an older version. I'd like to see how VistA formats the output. Greg Woodhouse wrote: --- Mike Schrom [EMAIL PROTECTED] wrote: I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. How comfortable do you feel with Basic? If you have an idea that you want to try implementing, I'd say to go for it. Personally, I think VistA would benefit from supporting multiple languages, but right now the infrastructure is a bit limited. I like to think M is to VistA as C is to Unix. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Making Fileman language independent?
--- Kevin Toppenberg [EMAIL PROTECTED] wrote: How is this done in relational databases? There has some be some sort of language to evaluate the database. SQL is a language, I guess. Yes, SQL is a language, but unlike M, but it's a very different sort of language. If you write FOR I=1:1:10 S A(I)=2*I+1 then you're giving a set of instructions for carrying out a task. On the other hand, the SQL query SELECT PATIENT_ID, ADMISSION_DATE FROM PATIENT WHERE (PATIENT_SEX=M AND PATIENT_DOB 1/1/1960) is a totally different type of animal, it's a *description* of a set of data, not a prescription for obtaining that data. It is up to the underlying DBMS to try and figure out how to respond to your query. If relational databases are sometimes slower than MUMPS systems, it's because they are designed to respond to non-procedural queries. In theory, a good query optimizer could go a long way toward making the translation from SQL to procedural code, but that does not change the underlying point: SQL (or, more abstractly, relational algebra) is not a procedural language. It seems that a M database is a more organic creature -- containing code to protect itself etc. Or, at least, that code is more visible to the application programmer. Probably relational databases can do this too, but at our site at least, it is not done. For example, when our front staff put in goofy social security numbers, the database is perfectly happy to accept these erroneous values. In fact, most relational databases will allow you to specify constraints involving specific patterns (MATCHES). In addition, other types of integrity constraints are often specified (e.g., a foreign key may be qualified with something like REFERENCES PATIENT.ID, making it impossible to enter a key not found in the other table), but it's not uncommon to disable enforcement of these constraint (or, rather, relegate it to front-end applications). In fact, I don't even think MySQL 4.0 implemewnts these kinds of contraints. You can include them in your table definitions, and they will be politely accepted (and ignored). I don't about later versions. So I am guessing that to be insulated from M would require an introduction of some different language as a replacement. I don't follow you. The implementation language need not have anything to do with the language application programmers use to interact with the database. The DBS calls go a long way toward achieving language independence of the type I'm describing, but there are still things that require you to reference the underlying globals. Sure, you work with the DBS APIs in MUMPS, but the fact that your code is written in MUMPS is really incidental. Once you start $ORDERing through a cross-reference, then your choice of language is no longer incidental, and your application becomes more tightly bound to the underlying representation. I can't see that happening. Maybe not, but one thing is sure: It never will happen if everyone just shrugs their shoulders and says that they can't see it happening. Defeatism is not the way to make VistA succeed. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Billing Module for VistA
I just looked at the Users manual and that has the WebMD, Austin stuff in it - all proprietary. However, it looks suspiciously like VistA might be capable of transmitting an 837 now. On Monday 06 February 2006 16:36, Nancy Anthracite wrote: Have you looked at www.va.gov/vdl under Financial Infrastructure, Integrated Billing where there is an EDI users manual, etc.? On Monday 06 February 2006 16:09, Mike Schrom wrote: I'm interested in seeing it, but I would really like to have an EDI billing routine. You planted a seed, though. I didn't consider using Fileman, but that isn't such a bad idea. Fileman is pretty Vista 'friendly', and doesn't require 'programming' per se. Thurman Pedigo wrote: I have a HCFA1500 billing application (using it years) in FileMan that I am willing to share. I can export it via KIDS for interested parties. The downside is it is in FileMan - not VistA and it has a few files not represented in VistA. It does the HCFA just fine. I now make a daring statement that I will make every effort to get it to a level that will integrate with VistA by the end of this month. It is quite rudimentary, built on multiples and ScreenMan. It would be interesting to have feed back on whether it has any potential for other users. I may be able to set it up with VPN (or outside our firewall) to give someone a chance to look at it as is. thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Mike Schrom Sent: Monday, February 06, 2006 11:18 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Billing Module for VistA I'm sure I could do it in BASIC, but if I'm going to stick with VistA, I'd probably try to learn M eventually anyway. I have the ANSI 837 documentation, though it may be an older version. I'd like to see how VistA formats the output. Greg Woodhouse wrote: --- Mike Schrom [EMAIL PROTECTED] wrote: I agree, and I'd like to help, but my programming experience is limited to 35 year old recollection of BASIC. How comfortable do you feel with Basic? If you have an idea that you want to try implementing, I'd say to go for it. Personally, I think VistA would benefit from supporting multiple languages, but right now the infrastructure is a bit limited. I like to think M is to VistA as C is to Unix. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Nancy Anthracite --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
[Hardhats-members] Screen Scraping
It would seem that a big impediment to a graphical interface for scheduling is the lack of separation of domain logic and user interface in Vista. Is that right? I'm sure that there are several powerful means to access the fileman data, but it is probably unsafe given that it would subvert important procedures contained with the roll and scroll user interface routines of Vista. Years ago I saw a demonstration of some modeling tools that allowed graphical interfaces to drive unmodified character oriented applications. I don't know enough about this particular company to endorse their tools, but it is an interesting approach. There is a flash demo here: http://www.yrrid.com/Products/LOF/LOFModeler-Video/ It only demonstrates the interactive modeler. Once the model is created, applications can be created that use the model to drive the terminal based application. When the GUI needs to display some fields, the application looks in the model for the field locations and then drives the terminal to all of the screens necessary to locate the fields. It updates data using a similar approach. I wonder if this is feasible for Vista. Could an application reliably snoop on a conversation between a terminal and Vista and pick out data fields? The modeling tools would not have to match those of the commercial application show in the demo above because they could be specific to just one application, Vista. Has anyone seen anything like this? -Ken McKee --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Making Fileman language independent?
--- Kevin Toppenberg [EMAIL PROTECTED] wrote: Well, the more I have used M, the more I find that it is much easier to do the low level coding than it is to use the higher level interface. That's actually not terribly surprising if what you are trying to do is retrieve a single value or perform a similar operation. But if someone were to come along and change the way data is formatted (e.g., using name components instead of the .01 field, or perhaps encoding non-ASCII characters), then your old code would then be broken. The point (well, one of them) of using proper abstractions is to protect the intgegrity (and maintainability) of your system. I think that says something significant I do, too, but perhaps for a different reason. MUMPS arrays are already sophisticated data structures, so including them in the language itself make it easy to write code to do what could be quite a bit harder in other languages. The real point is that you're not really working at such a low level of abstraction after all! Consider what would be involved in doing a similar lookup in an ordinary file using C. First, you'd need to do a lookup in an index to find the record offset, then you'd need to seek to that location in the file, read a fixed number of bytes, and then extract the record, copying it into another array you had allocated. Oh, and by the way, that index would most likely be a B-tree!) Most of these details are hidden from you because MUMPS isn't really such a low level language, after all. I know that sounds like a contradiction to what I was saying earlier, but it's not because the fundamental abstraction provided by MUMPS is different from the basic abstraction supported by Fileman (the file). The difference is close in spirit to the distinction between structs in C and objects in C++. Yes, C is easier than C++, but you may well find that if you're working in C, you have to spend a lot of time implementing the kinds of abstractions supported by C++, Java, Delphi, VB, or another language. If you don't need them, then the added complexity of the language seems like just so much dead weight. On the other hand, if you do need them, having language level support can be very valuable. ... But set name=$piece($get(^DPT(1234,0)),^,1) is just easier than do GETS^DIQ(200,1234_,,.01,,TMGOUT,TMGERR) How about W $$GET1^DIQ(200,.5,,.01) POSTMASTER It's easier, but it's still an API you need to learn. I can understand why I a programmer might prefer something like W $P(^VA(200,.5,0),^) POSTMASTER because it uses constructs of the underlying language only, without any extrinsics. Even so, there's some hidden subtlety here: How did you know that name of user N would be stored in the first ^ piece of ^VA(200,N,0)? You wouldn't need to know this to use the $$GET1^DIQ call. So, I suppose it's kind of an even swap. (The patient file, stored in ^DPT is file 2, but that's a trivial detail, and has nothing to do with your main point.) (more code here to parse TMGOUT) (Just to do this example, I had to pull out the manueal to get the parameters correct.) But how about a compromise? Set up a special category of platform-independant-code. Programmers can $order through an index if they want, but then they will fail to qualify as XYZ type code. Then, there would need to be some reason that users would want to have their code be XYZ status. Kevin Sort of like 100% Pure VistA? :-) But my point isn't to make value judgments here. Rather, the type of developments I describe here are things that I believe are needed for the long-term success of VistA. Others may disagree, but I hope I've made reasonably cogent arguments. === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Making Fileman language independent?
I do not understand the value or point of this. Both examples seem more complicated than either of the two one line statements that Kevin has below. I do not understand how this is connected to Greg concept of making Fileman language independent. Jim Gray - Original Message - From: Michael Zacharias [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Monday, February 06, 2006 3:52 PM Subject: Re: [Hardhats-members] Making Fileman language independent? This is something I've thought about for a long time too. I've always thought that Fileman could benefit from it's own scripting language (FSL?) Profile's DataQwik has done this, and it is quite elegant. Using Kevin's example below, obtaining a patient's name can be reduced to something like: N Pat,Name S Pat=CreateObject(Patient,1234) S Name=Pat.Name Or even sql: N sql,NAM k rs,err S sql=NAME FROM PATIENT WHERE ID=1234 F D SqlSelect(sql,.rs,.err) Q:$D(err) D . S NAM=$P(rs,$C(9),1) . Q (note I am sure I've screwed up the syntax as it has been a few months since I've had to do this!!). Michael --- Kevin Toppenberg [EMAIL PROTECTED] wrote: Well, the more I have used M, the more I find that it is much easier to do the low level coding than it is to use the higher level interface. I think that says something significant--since it is usually harder to do lower-level coding E.g. c++ is easier than c, which is easier than assembly, which is easier than machine byte code. But set name=$piece($get(^DPT(1234,0)),^,1) is just easier than do GETS^DIQ(200,1234_,,.01,,TMGOUT,TMGERR) (more code here to parse TMGOUT) (Just to do this example, I had to pull out the manueal to get the parameters correct.) But how about a compromise? Set up a special category of platform-independant-code. Programmers can $order through an index if they want, but then they will fail to qualify as XYZ type code. Then, there would need to be some reason that users would want to have their code be XYZ status. Kevin I can't see that happening. Maybe not, but one thing is sure: It never will happen if everyone just shrugs their shoulders and says that they can't see it happening. Defeatism is not the way to make VistA succeed. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Find your next car at http://autos.yahoo.ca --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Silent Fileman calls not silent
Opening a NULL device is an option if you are certain all your IO is in the form of Reads. On 2/5/06, Gregory Woodhouse [EMAIL PROTECTED] wrote: Kevin, Try setting ZTQUEUED (to anything) right before making the DB call.Yeah, a kludge - but it might stop some of the messages. Don't do that. Lying to the system (telling it that a process isrunning in the background in this case) is almost always a bad idea,because there could be unknown side effects. If you must do something here, it is preferable to open and USE the NULL device (so that allterminal output will be redirected there).
Re: [Hardhats-members] Silent Fileman calls not silent
--- Steven McPhelan [EMAIL PROTECTED] wrote: Opening a NULL device is an option if you are certain all your IO is in the form of Reads. I guess I don't understand. If you USE the null device, your WRITEs will go to the null device, too. Are you thinking about multiplexing devices here? === Gregory Woodhouse [EMAIL PROTECTED] All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. --Arthur Schopenhauer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Silent Fileman calls not silent
You never want to READ from the NULL device, especially with something like Press return to continue as the application may get stuck in a infinite READ loop especially if the READ answer is required. On 2/6/06, Greg Woodhouse [EMAIL PROTECTED] wrote: --- Steven McPhelan [EMAIL PROTECTED] wrote: Opening a NULL device is an option if you are certain all your IO is in the form of Reads.I guess I don't understand. If you USE the null device, your WRITEswill go to the null device, too. Are you thinking about multiplexing devices here?===Gregory Woodhouse[EMAIL PROTECTED]All truth passes through three stages: First, it is ridiculed.Second, it is violently opposed. Third, it is accepted as being self-evident.--Arthur Schopenhauer---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Hardhats-members mailing listHardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members-- Steven McPhelanAction springs not from thought, but from a readiness for responsibility. - Dietrich Bohhoeffer
Re: [Hardhats-members] Silent Fileman calls not silent
On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote: You never want to READ from the NULL device, especially with something like Press return to continue as the application may get stuck in a infinite READ loop especially if the READ answer is required. I see what you mean. Even with a * or # read (both forbidden by the SAC), a read from NULL should fail immediately. Even so, a lot of programmers interpret a null result to mean the user just pressed enter. At any rate, having code that does anything of this sort in a data dictionary is VERY strange (which isn't to say it's never happened). Out of curiosity, I tested this in Cache (no Kernel involved) csession cache USERO /dev/null USERU /dev/null R X#1 USERW $L(X) 0 It seems to me much more sensible to raise an error when EOF is encountered than just return an empty string, but a lot of code seems to assume that trying to read past EOF will just silently. === Gregory Woodhouse [EMAIL PROTECTED] Good acts are like good poems. One may easily get their drift, but they are not rationally understood. --Albert Einstein --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Silent Fileman calls not silent
On Feb 6, 2006, at 6:45 PM, Gregory Woodhouse wrote:
On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote:
You never want to READ from the NULL device, especially with
something like Press return to continue as the application may
get stuck in a infinite READ loop especially if the READ answer is
required.
I see what you mean. Even with a * or # read (both forbidden by the
SAC), a read from NULL should fail immediately. Even so, a lot of
programmers interpret a null result to mean the user just pressed
enter. At any rate, having code that does anything of this sort in
a data dictionary is VERY strange (which isn't to say it's never
happened).
Out of curiosity, I tested this in Cache (no Kernel involved)
csession cache
USERO /dev/null
USERU /dev/null R X#1
USERW $L(X)
0
It seems to me much more sensible to raise an error when EOF is
encountered than just return an empty string, but a lot of code
seems to assume that trying to read past EOF will just silently.
Just for fun, this is C
~:$ cat test.c
#include stdio.h
int main()
{
FILE *fp;
int c;
fp = fopen(/dev/null, r);
if ((c = fgetc(fp)) == EOF)
printf(end of file!\n);
}
~:$ cc test.c
~:$ a.out
end of file!
~:$
===
Gregory Woodhouse
[EMAIL PROTECTED]
The most profound technologies are those that disappear.
--Mark Weiser
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Silent Fileman calls not silent
Actually I believe that all reads from a null device immediately receive
a terminating character (CR). All writes also complete successfully
without problems. That's the purpose of the null device.
The thing that often causes looping code is a call to a fileman utility
with bad data (i.e. doesn't match input transform) and the error message
is displayed to and then read from the null device and gets a CR.
You'll often see evidence of it in the fileman variables.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Gregory Woodhouse
Sent: Monday, February 06, 2006 8:08 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Silent Fileman calls not silent
On Feb 6, 2006, at 6:45 PM, Gregory Woodhouse wrote:
On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote:
You never want to READ from the NULL device, especially with
something like Press return to continue as the application may get
stuck in a infinite READ loop especially if the READ answer is
required.
I see what you mean. Even with a * or # read (both forbidden by the
SAC), a read from NULL should fail immediately. Even so, a lot of
programmers interpret a null result to mean the user just pressed
enter. At any rate, having code that does anything of this sort in a
data dictionary is VERY strange (which isn't to say it's never
happened).
Out of curiosity, I tested this in Cache (no Kernel involved)
csession cache
USERO /dev/null
USERU /dev/null R X#1
USERW $L(X)
0
It seems to me much more sensible to raise an error when EOF is
encountered than just return an empty string, but a lot of code seems
to assume that trying to read past EOF will just silently.
Just for fun, this is C
~:$ cat test.c
#include stdio.h
int main()
{
FILE *fp;
int c;
fp = fopen(/dev/null, r);
if ((c = fgetc(fp)) == EOF)
printf(end of file!\n);
}
~:$ cc test.c
~:$ a.out
end of file!
~:$
===
Gregory Woodhouse
[EMAIL PROTECTED]
The most profound technologies are those that disappear.
--Mark Weiser
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Silent Fileman calls not silent
On Feb 6, 2006, at 7:45 PM, Palmer, Mike wrote:
Actually I believe that all reads from a null device immediately
receive
a terminating character (CR). All writes also complete successfully
without problems. That's the purpose of the null device.
The thing that often causes looping code is a call to a fileman
utility
with bad data (i.e. doesn't match input transform) and the error
message
is displayed to and then read from the null device and gets a CR.
You'll often see evidence of it in the fileman variables.
Under Unix, at least, the null device is supposed to look like it's
perpetually at EOF when you try to read from it. Now, at the MUMPS
level, the behavior is evidently different.
Here's another simple test
~:$ cat test.c
#include stdio.h
#include fcntl.h
int main()
{
int fd;
char buf[256];
int chars;
fd = open(/dev/null, O_RDONLY);
chars = read(fd, *buf, 255);
printf(There were %d characters read.\n, chars);
}
~:$ cc test.c
~:$ a.out
There were 0 characters read.
~:$
===
Gregory Woodhouse
[EMAIL PROTECTED]
It is foolish to answer a question that
you do not understand.
--G. Polya (How to Solve It)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Silent Fileman calls not silent
On Feb 6, 2006, at 8:24 PM, Gregory Woodhouse wrote: Under Unix, at least, the null device is supposed to look like it's perpetually at EOF when you try to read from it. Now, at the MUMPS level, the behavior is evidently different. Hmm...Any attempt to read from /dev/null does seem to fail, but feof () returns 0 (false). I need to look into this further. Anyway, this is definitely interesting. === Gregory Woodhouse [EMAIL PROTECTED] Prediction is difficult, especially of the future. --Niels Bohr --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[Hardhats-members] ACM - Exotic tools go mainstream
Of course, I'm a LISP fan, but I wonder if MUMPS and VistA qualify. 'Exotic' Programming Tools Go MainstreameWeek (02/06/06) Coffee, PeterNew releases of such programming tools as LISP, PROLOG, and others have brought what were previously considered exotic applications out of obscurity and closer to mainstream Web-facing technologies. A recent test of Franz's Allegro Common LISP 8.0 far exceeded the performance speeds of previous versions, with its source editor, debugger, and other coding devices rivaling the most advanced Java applications. With its rigidly consistent syntax and incremental compilation, Allegro CL offers regular-_expression_ parsing that is Perl-compatible, database interface drivers, and XML parsing. AllegroCache is the gem of version 8.0, however, offering freestanding and client/server transactional database applications. Developers are also harnessing the practical capabilities of neural nets, PROLOG, and genetic algorithms, the previous versions of which had been the untenable province of artificial intelligence hype. Aimed at creating extensible and adaptive frameworks, these applications are rapidly compiling imperfect solutions that are nevertheless of practical use in today's environment. Researchers are currently using PROLOG for speech-recognition applications, such as the implementation of its SICStus Prolog in the Clarissa speech-recognition program that helps facilitate communication among crew members of the International Space Station. The Regulus spoken-dialog processor, which includes SICStus Prolog, brings the swift application of statistics to speech recognition, says Manny Rayner of NASA's Ames Research Center. "You can develop a command grammar fairly quickly, without having to collect a huge amount of data," he said. Science Applications International's Larry Deschaine has used the technology to glean meaning from data sets, rather than the spoken word, running code on a Web page in milliseconds that would have taken weeks on a remote server.Click Here to View Full Article (BTW, AllegroCache sounds an awful lot like MUMPS -- except, of course that it's LISP.) ===Gregory Woodhouse[EMAIL PROTECTED]"Before one gets the right answer, one must ask the right question." -- S. Barry Cooper
