Wednesday, September 05, 2007

New MDS/OASIS VPN Connection Available

Thank goodness, we can finally begin ditching those obnoxious dial-up modems and use the broadband that we all know and love by downloading the client from https://www.qtso.com/mdcn.html. CMS has given nursing homes the ability to submit MDS's via the Internet using a virtual private network provided by AT&T Global Networking. The client is easy to set up, and seems to work well in Windows 2000 and XP. But my joy ended here.

Apparently our friends as CMS forgot that we are all highly dependent on our computer networks and that we occasionally keep important stuff like MDS files on a network drive. So when we connect to MDS/OASIS using the VPN and try to upload our MDS's from a network drive thenetwork drive is unreachable and we cannot select and submit our files.

I did what any good tech does before pulling his hair out - I called tech support. The guy at CMS tech support was friendly and knowledgeable, and acknowledged that this is a problem. Furthermore, the tech assured me that this is by design. Apparently the rest of our network presents a threat to CMS's computers (I'm paraphrasing here), so the machines that connect to CMS are quarantined from their network.

The tech went on to explain that CMS expects users with networked computers to copy MDS's from the network to their computer prior to connecting to the MDS/OASIS site.

Instead of manually copying these files, I created a batch file to copy them automatically and then launch the AT&T Global Network Client once the copy has completed. Here's how you can make your own:

  1. Create a text file on your desktop and rename it to a batch file by changing its filename extension to .bat - I named mine MDS-OASIS.bat
Edit your text file so that it contains similar to the following - you may use a different program with different network drives and foldernames replace m:\marktech\XFEROUT with the path to your MDS's - if you don't know what this means, then call a professional:
xcopy m:\marktech\XFEROUT\*.mds c:\XFEROUT /d /v /y /i
"C:\Program Files\AT&T Global Network Client\netclient.exe"
exit
  1. There a LINE BREAK (in other words, press Return) at then end of each line if you're typing this.
  2. Save this file as a .txt file and rename it as a .bat file. If you don't know how to do this, consult a computing professional.
  3. When you run it, a DOS window will open, it will copy all .MDS files that you don't already have to the folder c:\XFEROUT, then invoke the AT&T Global Dialer.
  4. When you finish your transfer and close the dialer, the DOS window will disappear.
So what exactly goes into this sausage? Well, here's a detailed explanation of what xcopy is doing:

/d only replaces files that are newer than ones on the target drive

/v verifies that each file is copied correctly

/y suppresses prompting to overwrite files on the destination computer

/i causes xcopy to assume that c:\XFEROUT is a directory, not a file.

12 comments:

Reepiceep said...

At least you got through the VPN. I have been trying for a week to connect. MDCN says the problem is the firewall. Cisco people say the firewall isn't the problem.

Justin said...

Perhaps the firewall in question is your computer's local firewall, not Cisco's. Does AT&T try to connect via VPN then just do nothing? Do any warnings or error messages appear?

Reepiceep said...

I have shut off the computer firewall and the Cisco tech I was using said they opened every possible port. Nothing has worked. According to the cisco guys again the only other time they saw this the client had to get an additional outside IP and statically assign it to the individual computer. I didn't think that was a good solution so I have reverted to using the dial up connection.

Justin said...

The MDS tech people do ask which firewall you're using - perhaps they have identified a problem with their software and some firewalls.

Yesterday I tried to establish a VPN connection to my office while behind a Cisco PIX and it wouldn't work.

Looking around the web, I think I found your solution. There are known problems with Cisco's firewalls and the way the handle VPN's - here's info from IVANS, our other Nursing Home EDI partner:

IVANS PDF Document

Jhansen said...

Solution for anyone who use a terminal server, MS Virtual server 2005. Create a XP machine, install the AT&T client. Access the virtual machine through Virtual Machine Remote control client. Since it connects to the console of the VM you dont loose connection once the VPN in activated.

Justin said...

Thanks for the tip, JHansen! I've not yet tinkered with Virtual Server 2005, but this makes it worth it as we will be moving to terminal clients later on this year.

Wolf-Girard said...

If anyone is interested....

We support multiple health care organizations and ran into this problem a while ago. I keep coming back and revisiting it to make sure I'm not missing the boat.

Approximately 7 yrs ago we developed a routed solution using the dialup method. It worked great for upto about 10 concurrent users. We have access to network drives and network printers while the dialer was running and logged in. We could run this in a terminal server environment where the floor nurses used only dumb terminals. It worked GREAT.

I have been calling AT&T & MDCN for the past 5 years begging them to support the VPN solution.

In 2008 we developed a solution that is VPN based using the AT&T Global VPN Client. Just as in the dialup solution I can see network drives and network printers while the AT&T vpn is running and logged in. We support this in a Terminal Server environment with dumb terminals on the nursing floor.

Just because the manual says I can't do "abc" doesn't mean I can't do "xyz".

We are currently working on making this solution available via SSL so it can be demo'd over the internet.

Ultimately we learned that the AT&T Global VPN CLient does not pass through many of the most popular firewalls out there i.e. Cisco, Watchguard, Sonicwall to name a few. The cheap-o home units i.e. NAT routers are no help either.

Justin said...

Wow, this sounds like a great solution, but I'm wondering - does it require proprietary hardware and/or software or is it a solution that can be implemented using available open-source/free/inexpensive 3rd-party applications or hardware?

More details would be very interesting. The healthcare computing industry has a marked lack of free support resources available to them. Them being those very few who are capable of then actually implementing the solution due to the fact that they don't consider themselves a computer expert like ourselves.

If it's a solution that you are selling (and I mean software and hardware or saas, not just service), I encourage you to explain it here more fully so that those who can't work their way around this may at least be able to buy their way around this!

Wolf-Girard said...

Thanks for the questions Justin.

I'll try to answer them in order.

Kinda yes and kinda no. All depends on your definition of those items. Currently we use off the shelf hardware i.e. name brand hardware. We haven't tried white boxing the solution but I'm 99% sure it would work. Just use good hardware. Currently the VPN solution leverages Microsoft but I think I can port it to the Penguin. The original dialup solution also used some 3rd party software that is no longer needed with the VPN solution.

The original dialup solution was ported to vmware. I was/am quite proud of that. I was trying to make this a vm appliance. The VPN solution does not work on VMware, workstaion, ESX, ESXi, server. That damn AT&T software does not like going through the VM nic. But I took some VM Cert classes and am ready to try it again. This is the first app that I have found that will not run in VMware!!

Ultimately I would like to turn the solution into a SAAS. ~$35 per user per month. Open a browser, point to my SSL server, login, and it takes you to your MDCN login page.

The other solution that also works similar is the Passport system. AT&T vpn but it takes you to an entirely different federal site. I currently have this solution in a dialup routed mode running on a vm server.

So I am at a cross-roads. Convert Passort to run in VPN mode but on a physical machine. Or work on getting the MDCN solution to run on a vm platform. Ultimately the problem child is the AT&T software.

Anonymous said...

I work for the MDCN help desk and believe me it's no fun trying to support the software. I am doing some digging though and trying to find out ways to fix the problem. There is a new account that was created to use called ANRMS instead of the HMDS accounts. The ANRMS accounts login to a different set of servers all together that support UDP encapsulation and also allow local subnet traffic. So if a network drive is on the same subnet that the work station is on you'll be able to access it. Also you can use ssl authentication instead of ipsec for connecting through the vpn which has fixed a lot of issues.

Justin said...

Wow, I've seen some traffic from CMS-related systems on my site, so it's exciting to know that the information flow can go both ways!

If I'm in need ANRMS account, may I just call the MDS-Oasis support line and request it?

Thanks!

-J

vishal said...
This comment has been removed by a blog administrator.