Office Ally setup

Day-to-Day Users
#1

ptalerico wrote on Monday, November 16, 2015:

Year-old Open-EMR user here, planning to bring billing in-house. I have an Office Ally account and also have SFTP credentials with them. I have scrubbed the forums and see several mentions (c.2013 posts) of them doing a desktop-sharing session to set up their information in my version of OEMR. I have spoken to Office Ally people in Enrollment, Customer Service, and Tech Support and none of them know anything about this. Is it something they’ve discontinued doing?

#2

fsgl wrote on Monday, November 16, 2015:

It is not necessary to use SFTP to send 837P’s, just use their website.

The only time we use SFTP is to submit Blue Shield claims because our local carrier no longer pays Office Ally for their service. We submit claims to their own clearinghouse. Setup with them, unlike with Office Ally, was like pulling teeth.

#3

fsgl wrote on Monday, November 16, 2015:

More about Office Ally.

#4

fsgl wrote on Monday, November 16, 2015:

As part of the setup, Office Ally usually assigns one of their technical support staff, via LogMeIn (not SFTP), to set up X12 Partners for you. If this has been done & you’ve applied Patch 4 for the ICD-10 changes, you should be ready to send claims.

Our local Blue Shield refused to give us any assistance with the X12 Partner setup. As a result a process that should take mere minutes turned into an ordeal lasting 6 weeks.

#5

ptalerico wrote on Tuesday, November 17, 2015:

I had seen on several forum posts that Office Ally has staff to set up X12 Partners in Open-EMR. I called their tech support again today and got nowhere. The tech asked his next-higher-level guy, who knew nothing about it and couldn’t tell me if anyone there had experience or knowledge of Open-EMR. They just kept repeating that I need to call my softward vendor…

Any idea why they set me up with SFTP credentials? I assumed they were for entering somewhere in Open-EMR to allow direct transfer of the x12 files, rather than uploading them via the Office Ally website.

#6

fsgl wrote on Tuesday, November 17, 2015:

Are all the insurers to whom you submit claims “participating” on the Office Ally Payors List?

If that is the case, there is no reason to send claims via SFTP. Even if some are not, nonpar claims can still be sent via 837P or CMS1500 to the Office Ally website.

What precisely are these SFTP credentials & where are you suppose to use them? Describe the conversation when these credentials were given you. Were you given a specific website as a destination for file transfer via SFTP?

#7

fsgl wrote on Tuesday, November 17, 2015:

See attached.

Did you ask for FTP transfer or did tech support suggest it?

#8

fsgl wrote on Tuesday, November 17, 2015:

If you did not ask for FTP transfers, contact you enrollment specialist again (you should have the name, phone # & email address for this person) for another appointment, wherein tech support can set X12 Partners for you via LogMeIn.

Something must have gone awry the first around, if you did not ask for FTP transfers.

#9

ptalerico wrote on Tuesday, November 17, 2015:

Yes, all my payors are on the OA list of participating payors.

The whole SFTP issue arose from an OA tech support person who stated Open-EMR customers needed additional credentials. Later that day, I received two emails:

  1. First email provided u/n and instructions:
    You must use an SFTP client, or a Billing Software that supports SFTP.
    You cannot use FTP, Internet Explorer, or other web browser to access this site.

Address: ftp.officeally.com

Username : ********
Port: 22
Passive Mode Enabled
SSH/SFTP Enabled

Please make sure to COPY AND PASTE the username and password rather than typing it out.
This will help avoid any errors for mistyping.
Password will be sent in a separate email.
If you do not see the password email immediately following this email, please check your SPAM folder!

During Logon, if asked to Cache SSH. Click Yes

Submissions: Files uploaded to Office Ally MUST be placed in the “inbound” folder for processing. Any file not placed in this folder will not be picked up for processing.

Reports: All reports from Office Ally will be available in the “outbound” folder at the same timing as they are available on the website.

ERA/835: A zip file containing an ANSI formatted 835 as well as a human readable 835, will be made available in the “outbound” folder if/when ERAs are available. Note: ERA/835 normally requires pre-enrollment.

Optional ANSI formatted 999 and/or 277CA reports may be turned on by request. You may reply to this email with a request for those reports to be enabled. Note: 999s acknowledge Office Ally’s receipt of your file submission, not the payer’s receipt. 277CAs contain Office Ally’s initial responses only, not payers’ responses.

  1. Second email provided the p/w:
    Please be sure to COPY AND PASTE the password below rather than type it out. This will help avoid any errors for mistyping.
    This password is for your SFTP account ONLY, and you will input it in your billing software’s FTP section, or give it to your software vendor for them to setup the connection.

This password is NOT your Office Ally web portal password.

Password : ********

My (apparently incorrect) assumption from this was that these credentials were entered in OEMR’s X12 Partners for Office Ally, and thus would allow OEMR to send the file directly to OA without use of their website for a manual upload.

#10

fsgl wrote on Tuesday, November 17, 2015:

The tech support response makes no sense. If you are going to use the web portal & log in with the first set of credentials given by your enrollment specialist, there is no reason to use SFTP.

You would also need a client like WinSCP to transfer files this way. A total waste of time when you can use just the web portal.

Occasionally tech support, no matter the company, is off in left field.

The fact that they are unfamiliar with OpenEMR does not give one a great deal of confidence.

When I had my LogMeIn X12 setup, the tech support person was knowlegeable about OE & complimented it.

I’m under the impression that SFTP is used for their Online Entry Tool or for those users without a Practice Management Software. See attached. This definitely does not apply to you because you have a complete EHR that easily generates 837P’s/CMS1500 claims.

Start by contacting your enrollment specialist to sort this out.

If that fails, we’ll try to help you set up X12 Partners for use with the web portal.

#11

fsgl wrote on Tuesday, November 17, 2015:

Other reasons for not using SFTP:

  1. You are responsible for the security of your files as it travels through the Internet.
  2. Office Ally is responsible for the security of the web portal, not you.
  3. Acknowledgment & Error files (999 & 277) will require additional software for decoding. Deciphering 837P’s is bad enough without the 999’s/277’s.

In short, unless one is a glutton for punishment, no reason to do it the hard way.

N.B., there is no way to send files directly from within OE to OA, without changing the codebase. Files which are saved to Downloads must be sent to the web portal (preferably) by the user or via the more circuitous route, with a SFTP client, to ftp.officeally.com.

Other tasks such as occasional bill paying, knowledge base lookup, access to LogMeIn can only be accomplished in the web portal. Better to centralize all these activities.

#12

harleytuck wrote on Wednesday, November 18, 2015:

Hello Dr Talerico-

I suspect that the Office Ally customer support people set you up with sftp because either they misunderstood you to say you wanted it, or that is simply step 2(a) or whatever, of their troubleshooting script, which they must obey without question.

Clearinghouses usually have a pre-written list of all the connection information a customer needs to submit electronic claims. In fact, the Office Ally site has that very document, at http://www.officeally.com/files/Provider%20Packet_20150820.pdf It supplies on pg 6 the information that is asked for in that handy ‘More about Office Ally.’ link provided by fsgl above.

Hope that helps.

Regards- Harley Tuck / MI2

#13

ptalerico wrote on Tuesday, December 08, 2015:

I figured out the missing piece of the puzzle: I had never scheduled my training session with Office Ally. Once that appointment was set up, OA staff with familiarity with OpenEMR appeared. The training involved a LogMeIn session, like mentioned in other posts, where the trainer set up Office Ally as an X12 partner in my OpenEMR.

When we created a test X12 file with phony patients’ encounters and uploaded it via the OA website, the OA system rejected it with the following error report: “Issues in 2010AB and 2000B”

They told me this was a problem with how OpenEMR formatted the X12 file. I have attached the test X12 file that we created (using all phony HIPPA-less data). Has anybody had this same issue and figured out the solution? My guess is it’s an extra period, comma, or space somewhere that’s causing the rejection.

Also, if I understood him correctly, the trainer also said the SFTP credentials were assigned because, once we are able to generate acceptable X12 files, we’re supposed to be able to upload them directly from OpenEMR without the need to use their website. As soon as I can get past the above X12 file problem, I’ll share with the forum what I learn about any possible SFTP/direct uploading.

#14

fsgl wrote on Tuesday, December 08, 2015:

This webpage gives a synopsis of the loops & segments of the 837P.

Note that because your 15th segment of the Interchange Control Header is P, it has been designated as a production file.

Consequently any fictitious data in 2000B & 2010AB will be erroneous when checked against other databases.

You will need to change the X12 Partner dialog for Office Ally from Production to Testing, if you want to send a test file.

I see that you did read page 6 of Harley’s link for labelling the test file, but followed it too literally, vis-à-vis using P.

#15

ptalerico wrote on Thursday, April 21, 2016:

It’s funny you asked (on my other thread) about automatic SFTP. I had to drop the whole billing project in December in order to put out other fires, and just got back to it last weekend. I am now able to generate X12 files that are accepted by OA and plan to set up another training session with them to see if I can get further along in the process and to follow up on what the original OA trainer said (above) about SFTP. I promise to keep the forum posted on what I find out.

#16

fsgl wrote on Thursday, April 21, 2016:

I don’t think that automatic SFTP transfer is enabled in OE. I don’t recall seeing any mention of it elsewhere in these Fora. It is not something that OA would configure from their end.

Ultimately it safer to use their website, for which OA is responsible in regards to Internet security. God forbid if that there are any HIPAA breaches, you will be less culpable using the OA website than to upload/download files via SFTP.

#17

tmccormi wrote on Thursday, April 21, 2016:

sFTP is in use in Rod’s lab orders system and is fully HIPAA complient. It could easi;y be used for claims processing. Have to disagree with FSGL opinion on this one.

–Tony

#18

fsgl wrote on Thursday, April 21, 2016:

The question is not whether using SFTP is HIPAA compliant or not. I use it for our Blue Shield claims because our local Blue refuses to pay OA for the service.

The question is thus framed: if a physician’s file is hacked, to/fro, we will get the bigger ding; because a SFTP transfer is under our control. We don’t have full control of security at OA, as a result the ding will be smaller, if we deliver the 837P’s to their website.

#19

ptalerico wrote on Friday, April 22, 2016:

Should everyone assume that the S=secure aspect of SFTP will not provide any defense in the event of a hack? In my (rather low-capacity, under-functioning, and burned-out) mind, if we are transfering files, just like we practice medicine, using standard of care methods (assuming SFTP is SOC), that should be adequate.

That being said, this assumption is coming from a mind described as above, which has been running a private practice less than 2 years. Feel free to crush my naivete with some harsh government oversight reality from your experience.

#20

tmccormi wrote on Friday, April 22, 2016:

HIPAA is a little about tech (doing your best to encrypt and secure) and a lot about reporting data breaches. If you report the penalties are zero, if you hide it and get caught they are large.