x12 278 and United Healthcare – anyone doing this?

All,

Here is a summary of where we are at this point.

1. UHC has a Companion Guide. It is still in a draft stage and does need some clarification. We have outstanding issues, not the least of which is – how will we communicate with UHC?

2. We are building our X12 278 from an ADT^A01 (not my decision – that is what we have to work with).

3. The provided Cloverleaf(R) scripts such as hcijoinX12 (I think that is the name) will not work in our case because they rely on the USERDATA Metadata field being populated with the appropriate keys which normally come from the hcisplitX12 proc and an inbound X12 message. The Cloverleaf(R) provided procs assume X12 to X12 (an oversight in my opinion). So I have written a proc to populate the USERDATA field. This proc is argument driven so should be usable by anyone finding themselves in the same situation. I have more work to do in this area and some additional outstanding questions regarding things like how to set the seperator characters for the Xlate when the seperator characters are either in the ISA (which the Xlate is not allowed to see) or in the USERDATA (which is not set if the inbound message is not an X12).  – Anyway lots more research here.

4. You need to understand this is a Query/Response set. The response is a 278 and in order to associate the response with the query, you need to provide an identifier in the TRN segment of one of the loops – I do not recall which one at this point.

5. When you send the 278 you will receive a TA1 acknowledgment (standard X12 stuff) essentially telling you the query (278) was received. It also appears UHC will be validating the 278 from a technical standpoint before returning the TA1. This could slow things down if we go real time. In a real time environment we can loosely consider the TA1 equivalent to the HL/7 ACK.

6. You will also receive a 997 acknowledgment (that is asynchronous to the 278 query). That will tell you if the UHC application will process the query or reject it for some flaw (such as subscriber not located or whatever). Again there will be the identification number you provided with the 278 in the 997 so you can associate the 997 with the original query.

7. UHC has had at least a couple of ‘kick off’ meetings and established pilot goups. If you have attended one of those you have more information than I do.

8. You should get the Implementation Guide for the HIPAA 278 from Washington Publishing. The Companion Guide from UHC only speaks to the UHC requirements. There are additional requirements for all 278s regardless of vendor. The Implementation Guide should fill in those blanks.

9. Our preference is to utilize a real time integration with UHC using a direct connect (hopefully none of that web services crap – should not be needed for this but it is hard to find programmers who understand or are willing to learn anything else these days)

In my opinion it should NOT be the responsibility of the Integration Engine to associate the query 278 with the 997 and the Response 278. There should be some application to which the Integration Engine connects and receives the identificaiton number and reports back the 997 and 278 response information.

We are still trying to complete our internal specification of this Integration and I am trying to assure we can provide the scripting needed so that we can build the objects necewssary to complete this integration.

It is in its very early stages and quite frankly I do not think UHC was prepared themselves when they dictated to all that they needed to do this. There are still some major unknowns regarding what UHC wants. Hopefully that will all get settled out with the ‘pilot groups’ but in my opinion that should have already been accomplished.

I have every confidence we can make this happen technically.

That is all I have for now.

Thanks,

Jim Kosloskey

Rickey,

At this point it is still a work in progress but I have proved the concept (for the proc that is not yet the entire 278 process).

I expect to have something you could have within the next couple of weeks (as we all are I am working on multiple integrations at once).

Thanks,

Jim Kosloskey

Rob,

Thanks.

That is what I intended to try – I was just not sure if the Xlate would honor those changes at the point it creates the translated message.

Armed with that intelligence, I will proceed with confidence.

Thanks again!

All,

I have finished the proc which builds the ISA, GS, and Sep Chars entries in the metadata for those instances where the source is a non X12 message.

That is our case (we are using an ADT^A01).

This proc would be stacked before the provided x12buildinterchange proc.

If you want the proc and doc, email me.

Jim Kosloskey

All,

I have successfully created an X12 278 message to UHCs specification from an ADT^A01.

I have validated the message generated.

There are some refinements (still some minor specification details to be worked out) but the Xlate is essentialy functional.

It took some work but it was not really terrible.

There are some caveats with the way the 278 transaction set is defined in Cloverleaf(R) and the requirements to set the HL segment properly among other things.

I tell you this to encourage you that you can do this.

Thanks,

Jim Kosloskey

All,

My colleague Russ Ross attended the UHC 278 pilot conference in Phoenix this past Friday.

At this point I am still somewhat unclear as to how exactly the connectivity will work.

Russ brought back the information he garnered and as I understand it this is how things stand:

UHC will NOT be sending a TA1 transaction to signify receipt of the 278 request. I am not used to this – the other X12 work I have done always used a TA1 and I believe that is strongly suggested although not required by X12.

UHC will send either a 997 transaction indicating essentially validation failure OR a 278 Response which can be either a rejection with explanation or confirmation.

The Responses are asynchronous (expected) but in a real time scenario it is unclear if there will be a way to assure receipt of the 278 request.

It also appears that there is some confusion as to whether the request/response can be fully realtime. The request can be sent via HTTPS Post but there is conflicting information at this time as to whether the responses (997 or 278) will be realtime or rather (this was the way it was explained at Phoenix) in a file which has to be picked up via FTPS or FTP with PGP on a periodic basis.

The documentation provided by UHC for their Connectivity software indicates a real time response paradigm. So the confusion.

We intend to push them for a complete HTTPS based real time request/response paradigm and dispense with any of the file based nonsense for those who desire realtime. I will let you know what occurs.

Here is a summary of the connection methods described in the Connectivity Director documentation from UHC:

HTTPS:

           Real time

           File

FTPS (inidications at the conference they might be moving to FTPS – I don’t know why).

FTP with PGP.

Here is the documentation you will need:

HIPAA 278 Implementation Guide (get this from Washington Publishing – can order on the Web).

UHC 278 Companion Guide (I heard there is a final – I have version 10 a draft).

UHC Connectivity Director documentation – again I have a draft – I do not think there is a final.

You can get a free X12 browser from Blue Iris software. It works well and I would suggest getting it. I am pretty sure the X12 configurator in Cloverleaf(R) chokes on the full message (meaning with ISA and GS) as those segments cannot be defined in the variant. You definitely do not want to read X12 message without a parser.

You can also get free validation on the web. I can get you the URL.

I strongly suggest you create a marrying specification that marries the inbound message structure and element (if HL/7 segment/field for example) detail as well as the X12 278 structure and loop/segment/field detail. Where the X12 information specifies how the 278 will be built from the inbound and static fields (there is a lot of that in X12).

The marrying spec will simplify the process of building your Xlate and help you keep things straight.

That is what we did and it helped.

What we have accomplished thus far took just about a month and a half not working full time and waiting for answers from UHC that hopefully will now be in the availabe documentation. That also includes some holiday time.

Lastly do not panic regarding X12. If you have the above documentation and ask pointed questions of UHC (they seem very cooperative) you will move through this process.

X12 is like HL/7 on steroids – however – it is a fairly enforced standard and so although the architecture seems stiff and pedestrian, it is predictable.

There is a very good reason why it has the architecture it does and if you want to discuss that rationale – buy me dinner  😆

Besides the connectivity issue (which I have every confidence we can accomplish if we can get the details and have a sensible protocol) I have to also provide integration to whatever Business Process our application folks will devise to manage the whole handling of the data flow.

This is something your organization will need to do. That is – the transfer of messages is only a part of the challenge. You also need to have an application that tracks the 278 request, the responses and proveds a mechanism for correction and resubmission.

Thanks,

Jim Kosloskey

All,

I will be modifying the proc I wrote that adds the ISA, GS, and SEPCHARS information to the metadata.

The modification will allow specification of a counter file to use for the ISA Control ID (Intechange Control Number) and the GS Control ID (Group Control Number).

The use of the counter file will be optional and if used will override what is specified in the ISA and GS argument sets.

You can just always use the same values by setting them in the ISA and GS sets but probably not a good idea. Anyway here we will be using independent counters for both and independent for each payer thus the need to be able to specify the Counter File.

For the realtime HTTPS, UHC is saying at this time they will not be returning a TA1 to acknowledge receipt of the message by the application.

At this point it appears the only acknowledgment we will get to indicate we should send the next message is an HTTP Header with the status code set. In my mind this is not a reliable method to determine the receiving system has actually received the message. A TA1 would be much more reliable.

In any case, it MAY be true that we will have no reliable way of knowing that a paricular 278 request was received by UHC. We will know we sent it and given that there is a Business Process in place to manage the messages, we could always set some time threshold to trigger an action if a 997 or 278 Response has not been received for a 278 Request sent.

Thanks,

Jim Kosloskey

All,

We will need to set counters in the ST segment within oor Xlate(s).

Since the Xlate has no intrinsic function to manage Counter Files, I have written a generic, resuable Counter Management proc for reference from an Xlate.

We will use that proc whenever we need a counter that is persistant across instances and uses of Xlates, etc.

You may already have something that does this for you.

If you would like that proc, let me know.

Thanks,

Jim Kosloskey

All,

I have finished and preliminarily tested the addition of counter capability to the proc which can be used to build the envelope in the instance where the source message is not X12.

I have attached the proc and the User Documentation.

Questions, etc. contact me.

Thanks,

Jim Kosloskey

Bob,

That is correct.

What I did was to have a MATH ADD Action in each segment to add 1 to a temp variable. That temp variable is then used in the SE specification.

Not foolprooof but it does provide a visual reminder.

Because an X12 Xlate can get fairly cluttered I also use something like this to keep things organized:

IF =ST eq =ST

Then I put all of the ST releated stuff inside the IF.

I use the same idea IF =2000 eq = 2000 for the Loop/Levels and everything for that Loop/Level goes inside.

This is a technique I picked up from James McPheron – thatks Jim – and I use it a lot. Makes handling Xlates easier.

Jim Kosloskey

All,

Charlie LaBaw did some testing and indicated a couple of minor issues. I have corrected those and I have attached the corrections. Thanks Charlie.

The proc can use a Table for its arguments or the NetConfig. I neglected to include the proc which we use for Table lookup which is referenced. I have included it here.

Thanks for those who have been doing some testing. If you have a situation which needs to be addressed specifically for your location, feel free to take ownership of the proc or any parts thereof for your specific use.

I do welcome any comments you might have.

Jim Kosloskey

Apparently there is some limitation being imposed (I thought it was 2MB and I do not think I exceeded that).

Anyway here is the doc for oth_lookup:

Jim Kosloskey

Rick,

Some Payers are requiring 3rd. party validation. UHC is not.

UHC has validation built into their process so each message is validated as it is received and the hope is once the obvious structural issues are disposed of during testing, the occurrence of structural failures reported in 997 Transactions will be minimal if not non-existent.

Time will tell if that is true but I think that is a good potential.

We will still need to provide for handling of the 997 transaction even if it never happens – just like we provide handling for HL/7 NAKs although we rarely expect to actually see them

I have not been able to get any documentation on InsureNet (I am not sure any exists). I do not think it will be necessary simply for validation with this project. It appears the only way to find out anything about InsureNet is to get your HealthVision Account Manager and an implementer involved. Personally, I want to see some documentation before I want to talk to sales folks or implementers. That’s just me.

There is a free web based validation service (one message at a time) that I used once. My message passed so I am not sure that was an effective test since I was trying to build a good message.

The Xlate Testing tool seems to be pretty picky and points out structural issues. It is not very informative and requires a bit of effort to interpret what the objection is – but it is usable.

I am currently fighting what I hope is the last of my structural issues in my Xlate related to the last Level (Service Level) which has multiple repetitions. I have the repetition for Facility – I am attempting to construct the repetition for Admitting Doctor.

Jim Kosloskey

All,

In past posts I indicated your 278 mesages (or any HIPAA X12 message for that matter) could be validated for free.

I realize I neglected to indicate where that validator lived.

No one asked for this but I thought I would post it anyway.

http://www.hipaavalidator.com/

Jim Kosloskey

Jim,

I set up a variant for UHC.

It is my opinion we may get more payers wanting to do this and so we will give each their own variant just like we do with HL/7. Ideally there should be no need for a variant since this standard is more stringent. But it is a small price to pay for the future flexibility it affords.

We are on Cloverleaf(R) 5.2 and the definitions are HIPAA-00401 -v1 and HIPAA-00401 -v2.

If you take a look you will see v1 is the request (278 that is) and v2 is the response – and they are different.

Right now my variants look just like the provided layouts they just have different names.

If you are intending to atttend the Indianapolis Regional User Conference (Cloverleaf(R)), I will be there in attendance and we can chat if you like.

Jim Kosloskey

All,

In a previous post I indicated there are two variants for the 278 set (HIPAA-004010-v2 – for the Request, HIPAA-004010-v1 for the Response).

My first creation of a 278 from an ADT^A01 used a UHC copy of the v2 variant and had a dependent as the Patient (meaning all loops/levels were utilized). That created a message no problem that I could run into the tester, validate via the Web based free validator – joy was found.

I then attempted to use the same Xlate (thus the same variant) to generate a 278 from an ADT^A01 where the Patient is the Subscriber and there is no Dependent. The loop/level for the Dependent information in this variant (v2) is defined as optional/repeating.

So this should be no problem (I thought). Just adjust the values in the HL segments for the loop/levels following the Dependent to account for its absence and put the COPYs under an IF so that the Dependent loop/level does not get generated.

That does not work!

I have tried all sorts of combinations for HL settings and everything is fine and dandy if I have at a minimum the HL segment for the Dependent loop/level but no joy if it is not there.

It appears that when monkeying with the HL segment values even though the address path references are to the correct loop/level, the Xlate changes the address path to accomodate something – what I have not yet figured out.

So — I have sample messages from UHC which have validated on their validator and I think I am a clever guy — I will run their messages into the X12 Tester and see where I might have srewed up.

Their messages fail in the Tester!!

I did some searching here on clovertech and got an inspiration from another post. Use the non HIPAA specific variant at least to test their messages.

Easy to do and I am not going anywhere with my present direction. So that is what I did. I used the tester for the 00410 X12 variant.

Their messages test perfectly!!!

Not only that but I could not get the tester to handle mesages with the envelope using the v2 variant (neither the one distributed nor the copy I made). BUT with the 00401 variant all is good.

So now this is what I am faced with:

It appears the HIPAA-00410-v2 (and I supect v1) variants are broken – at least on Cloverleaf(R) 5.2.

If they are not broken, then they should parse a valid message including envelope – and they do not.

Can anyone confirm if the HIPAA -00410 variants of any or all flavors are broken or not broken?

If the HIPAA-00410-v2 and v1 variants are not broken (someone is successfully utilizing them) please contact me so I can figure out what I am doing wrong.

If I do not resolve the above soon – I will need to use the 004010 variant and it is sufficiently different that would be a complete rebuild of my Xlate which is fairly complex as it is.

I would like to use the appropriate variant – but if it won’t function then I will need to move on.

Thanks,

Jim Kosloskey

Charlie,

Thanks for the info.

I never tried the tester noise at 0. I never use 0 as it seems worthless to me.

However, I tried that and you are correct – error free.

Charlie – have you tried to use the X12 testing tool on the message you generated specifying the HIPAA variant? For me it fails on trying to format inside the envelope if I have the noise level above 0.

At 0 it does not complain.

How about it Healthvision – got your ears on? Is there a bug in the Xlate testing tool and X12 testing tool for X12 messages using the HIPAA variants? It appears this is an issue on 5.2 and 5.5 Cloverleaf(R).

Jim Kosloskey

Nathan,

Thanks for the insight.

I went to using the non HIPAA variants for building the 278 messages because I do not want to guess if my message is correct by having to know when to ignore errors produced by the tester.

I prefer not to test using the engine just to tell if I have all the basics in place.

To my way of thinking, if a HIPAA type variant is provided it should work within the product completely.

Anyway after a couple of hours work, I am moving forward once again with renewed confidence.

Jim Kosloskey

Nathan,

I located a free X12 viewer (Windows based) which I provide to the application folks so that they can easily read the X12 messages.

I use it myself.

Not only does the HPIAA variant not set the HL segment values automatically (after all based on the address path it would seem it could do that), but in my testing, it attempts to change the pathing to fit what you put in the HL segment values. Based on my experience it does not do that successfully.

I fully expected to have to populate the HL segments myself so I was not too upset about the values not being set automatically. I was suprised the address paths I set in my COPYs were being changed.

But I was seriously disappointed to discover the provided variants were not as usefull as I would have liked.

Thanks again,

Jim Kosloskey

All,

http://www.geocities.com/laughingblueiris/

Is where I found the viewer.

Jim Kosloskey

Rickey,

I believe we had to sign an agreement in order to start the process which got us the Companion Guide among other things.

You should have a contact at UHC who will get things lined up for you. Let me know if you need that information. I think I have a listing of the US contacts by territory.

You will also need the Implementation Guide which you get from Washignton Publishing.

Jim Kosloskey

Rick,

Make sure the package index has been created for the x12lib package.

It should be at $HCIROOT/tcl/lib/X12lib.

Jim Kosloskey

Rick,

I have a proc that creates the package index that I use and there is one here https://usspvlclovertch2.infor.com/viewtopic.php?t=2172&highlight=package+index

Jim Kosloskey

Rick,

I think you are OK.

I am not familiar with that specific proc but the result looks OK.

Have you tried to execute the X12 proc I provided again?

Thanks,

Jim Kosloskey

Rick,

Which proc is that?

Rick,

I am not sure where you placed the proc, but I used it in the tps-outbound stack in my integration. I have it stacked just before the invocation of the Healthvision provided proc to reassemble the envelope (ISA, etc.).

Rick,

The proc was developed to be used in the TPS context. As such it does the package require in the startup section of the code.

I am not sure what would keep you from finding the X12lib in any Tps UPoC. I do not think another proc should cause an issue.

I am not sure of your architecture (feeder threads).

I have entertained the possibility of changing the proc to adapt to the context so that it might be usable at different UPoCs than just Tps.

When you say you cannot access the X12lib from the command line do you mean the package or the directory and by command line do you mean via hcitcl (or tcl)?

Rick,

It is my understanding we will get an updated companion guide (although not necessarily a final) the end of July.

The pilots that were done with direct communication seem to have all been batch based rather that real time so I would expect none of the rough edges I have seen with their real time specification have been smoothed out.

There is also a rumor they have moved to HIPAA 005010 rather than HIPAA 004010 used in the original Companion Guide.

I am on vacation but will see what the latest Companion Guide brings when I return.

All,

I have noticed the newest Companion Guide has no reference to FTPS as in the original Guide. Instead SFTP is now specified.

For those of you planninng on connecting using FTP this means you won’t be able to use Cloverleaf(R) FTPS protocol.

You will need to do some Tcl coding and other activity to deploy SFTP.

I am still early in the review of the 5010 specification for UHC versus the 4010 version.

Here is what I have noted:

1. It appears there are only minor layout differences which actually affect the needs of UHC. Some of what could be troublesome expansions such as repeating Data Elements do not seem to be required.

2. They have switched the roles of the 2000A and 2000B Loops. 2000A was the Payer and 200B was the Requester. Now they are reversed. A minor annoyance.

3. The value from GS08 needs to also be in ST03. Depending on your point of view this can be trivial or cause some consternation. Many will simply hard code both entries (the GS in arguments to a Tcl proc or in the Tcl proc itself – the ST03 in the Xlate). Personally I find that a maintenance issue waiting to happen. I am leaning towards modifying my envelope building proc to allow usage in other than the Outbound Tps context (I was kind of thinking I would need to do that anyway); deploying the proc pre-xlate; and then using an Xlate proc to extract the value set for the GS08 and COPY it to the ST03.

Since I have designed this integration to be as Table driven as possible, some of the issues I have found don’t pose any great hardship.

Thus far it looks like the 5040 variant (which is what we need to use in Cloverleaf(R) 5.6 to get a 5010 variant) is not significantly different than the 4010 such that I am using a copy of the Xlate pointed at a replication of the 5040 variant. I have not had to make any serious changes yet.

I am only at the 2000B Loop with the real meat yet to go.

At this time we are not planning on doing FTP to/from UHC and that is the only connection mechanism (other than Clearing House) offered by UHC at this time. I will continue to work on the message structure and other non-connection related pieces until there is a real-time connection environment ready from UHC.

Many of you who decide to use FTP will get ahead of me easily and hopefully I will learn from your experience.

I expect the real time connectivity  to be problematic.

Stephen,

Thanks for that update.

Did they give any indication as to the scope of changes to the Companion Guide?

All,

I have just received notice that our testing and go live has been changed from January, 2009 and March, 2009 to March, 2009 (Testing) and May 2009 (Production).

I expect that any of you who alsowant to do real time will be correspondingly affected.

Check with your UHC rep if you have not heard yet.

All,

I have finished an xltp proc to change the SEPCHARS metadata field.

This is necessary in our case because UHC requires a different COMPONENT separator than the default and we need to populate one component field in an HI segment.

If you think this proc may be of use to you please let me know via email and I will share the proc and the doc.

Anyone connected realtime via https to UHC yet?

I have some questions for you if you are.

Supposedly some folks have been doing the real-time connectivity with an April live time frame. Surely soemone in the Cloverleaf(R) community is in that group.

We are scheduled to have our kick-off meeting 3/2/2009. We are intending to connect real-time and the Connectivity doc from UHC leaves me feeling less than fulfilled.

All,

the Cloverleaf(R) provided hcix12splitinterchange proc which is intended to split messages out from the envelope in X12 messages (the complement to hcix12buildinterchange) does not function properly in my opinion.

I wanted to share my experience with those of you who might be going to use this proc.

The proc hcix12splitinterchange functions but when the GS and GE segments need to be removed from the message and the GS fields placed in the metadata USERDATA field (as in the case of the 278 and 997 messages in the 51010 variant), there is no way to tell the X12lib package event split X12 to treat the GS and GE segments as envelope segments (the ST argument as specified in the Cloverleaf(R) User documentation).

This causes segment errors to appear in the log. The messages still process through an Xlate because the segments are stripped. BUT it means the GS fields are not available to the Xlate AND there are errors in the log. We do not tolerate unnecesary errors in the Process log so that is an issue to us as well.

So I copied the distributed proc and created a new proc to allow for a user provided argument specifying ST or GS which is passed to the X12lib::splitX12 event – and all is well.

Suffice to say I could not see how to get the provided proc to behave as advertised or desired without modification.

I hope this is  of some help.

Just an update:

We have pressed UHC to provide us with the name of any provider currently doing real-time connection for this 278.

As of yet, there are none that I can see. So if you are connecting to UHC real-time, let me know – please.

We intend to go that route and quite frankly do not think the protocol they have laid out for real-time is reasonable at this point.

We are hoping we may be among the first to do this real-time and thus get to shape their requirements somewhat. If you have ideas about their real-time connectivity requirements, I would love to discuss them with you.

We have a 5/1/2009 go-live date but if they cannot get a reasonable rel-time working, we will certainly push to have that extended.

If you are currently exchanging 278 transaction sets with UHC I need to know something.

It does not matter wheter you are using FTPS or whatever.

When you submit a 278 and it contains multiple errors (but no structural errors so that you do not get a 997) does the 278 Response from UHC contain AAA segments for ALL detected errors or does it stop with the first error it finds?

Thanks,

Jim Kosloskey

Rickey,

You will need the SSL (now called Secure Messnger I think) from Healthvision for either HHTPS or FTPS.

The Implementation Guide we have from Washington Publishing is titled ASC X12N005010X216. I am not sure how that is listed on the Washington Publishing Web site.

All,

The proc that I wrote that places the desired X12 envelope(interchange) data in the USERDATA metadata so the envelope can be built has an error I just detected.

It assumes GS06 field should be zero filled. That is incorrect.

If you have that proc you can either correct it yourself (the lines of code are fairly obvious) or let me know via email that you would like a refreshed copy.

Of course, if you do not have that proc but want it let me know that via email.

All,

We are still trying to find out what the particulars are for connecting HTTPS real time with UHC.

However, we have sent 278 Requests via their Connectivity Director Web Page.

I need to warn those of you that have not yet started down this path.

As of today, UHC’s test system has issues. I will enumerate the ones we know about at this time.

1. If you are sending TRN (Trace) segments (we use them to pass the mrn and visit numbers), they are not returned in the 278 Request as required by the X12 00510 278 standard. For us this means we cannot associate the response with the patient in our Patient Management system where the corrections will take place.

2. The Responses (apparently both the 997 and the 278) are version 004010 not 005010. Our position is what is good for the goose is good for the gander and we should get messages in the same standard version we sent. This is not trivial as there are some differences in the use of the 278 at least between 004010 and 005010.

3. The BHT03 field value which is the unique Control ID for the Request is required to be returned in the Response. It is not.

4. I intentionally sent bad data in one of the UHC sensitive fields so that I could make sure we are handling the error conditions properly. No error was returned.

UHC says all of the above is due to the fact that their Test Environment is not set up to provide that level of compliance nor to provide data content evaluation.

UHC states those issues can be ironed out in Production where (trust us) everything is proper.

Thus far our position is we do not ‘iron out issues’ in Production, that is what testing is for.

We were told all the other hospitals, etc. were dealing with the same issue.

I could just spit!!

That is like a child complaining to their parent that they should be able to do whatever they like because the other kids parents are letting them.

I don’t know if any of you are in the boat of those who are dealing with the issues in Production.

If so please let me know.

If you feel like I do that test is the place to ‘iron out the issues’, please contact me as well.

Those of us who do not accept the ‘Microsoft philosophy – throw the release in front of the users, they will debug it for you’ need to coordinate our opposition to UHC’s position.

Chris,

What issues are you dealing with?

They may be ones we are yet to face and forwarned is forarmed/

Rickey,

I don’t see any error indicated – did you provide all of the log entry?

Or perhaps do you have the EO Config turned up – this looks like the information displayed when a proc is being invoked in the engine and the EO Config is turned up.

Rickey,

I notice you have DEBUG on (Y) email me the entire log including the debug output from the tps_x12_put_envelope_userdata proc.

I say email because that output might be rather long for the forum.

Rick,

I did not check but isn’t the ISA in the Message Metadata?

If so then ISA13 will be there and you can just use that I would think.

Since we are not intending to do FTP, I have not faced that issue.

Rick,

Here is our plan in a nutshell:

The essential data from the 278 request is stored via the ODBC drivers in a DB2 mainframe DB.

The essential data from the 278 reply is stored in another DB2 Table from the Request.

A mainfrmae application that our billing folks have access produces a work list based on replies that have errors.

The user makes the corrections and a LU3 (we are SNA from the mainframe) document with the essential data is sent to Cloverleaf(R) and we convert the FRL to a new 278 Request.

How we tie the information together is with one of the BHT fields (I think it is BHT03) that is a control ID and the MRN and Visit numbers for the patients which we stuff in a TRN (Ithink that is the segment) segment in the Request. These fields are supposed to be sent back in the corresponding reply.

Since we still have been unable to connect via https with UHC, and since full testing cannot happen in Test, I have constructed a simulated reply generator so that we can test the above process without a connection to UHC.

Then once we get connected and move to production, we won’t have to deal with the basic functionality – hopefully just the details.

It is sounding like the details are an issue as the Companion Doc apparently does not match the actual UHC application.

Rick,

I am not sure how this is supposed to work for Batch (FTP) however for real-time (if we ever get connected) I expect that the GS06 field in the 997 will match the GS06 field in the 278 Request I am sending. Moreover in the real-time world this interface is synchronous meaning if I receive a 997 it must be for the 278 Request just sent.

Since we cannot test any of this in Test and since we are not yet connected, I have yet to see proof that the standard or the Companion Guide/ Implementatin Guide are being followed in this regard.

If you receive a 997 for real – let me know if the GS06 of the 997 is the same as the GS06 in the 278 batch you sent.

Rick,

That is my understanding for real-time. I have not really studied the FTP action but I think I recall that as a 997 would be sent of there were a structural problem some where in the batch (if you are doing one mesage per batch then that would be per message).

Although in their ‘Test’ environment, the 997 produced is constructed incorrectly I have been ‘assured’ that a proper 997 is constructed in their ‘Production’ environment.

I am not sure I believe that.

Rick,

Thanks!

Rick,

It should be.

Rick,

Assuming UHC has their part properly done, I expect that plan to work.

I have just been told there is a bug in the Connectivity Director for REAL TIME processing.

This is something I suspected for almost a year and it has taken this long to finally get someone to really investigate. All this time UHC has been indicating the REAL TIME functionality works fine – it does not – the flaw detected is a major flaw and I cannot imagine anyone getting this to work without a lot of work.

Obviously no one else has or one would have hoped UHC would have known about it and changed their Connectivity Director Documentation.

Hopefully you will not experience anything similar with FTP.

All,

We finally have connectivity real time with UHC (HTTPS).

Here was the issue:

On Page 24 of the Connectivity Director Guide (April 2009) the parameter indicated for file is ‘File’ (note the upper case F). The examples show file can also have a lower case f. ALL of the other parameters on Page 24 begin with an upper case letter.

Apparently file is an exception it must be completely lower case.

The only error received when using the wrong case is an ‘Invalid Session’ response.

Multiple requests for what ‘Invalid Session’ meant were met with silence.

Finally after the developers of Communication Director got involved, they suggested the upper case F in the File parameter could be a problem and asked me to try a lower case f.

That did the trick.

Now that we are getting connected I am running into other issues with the message exchange.

If there is anyone else attempting real-time connectivity for the UHC 278, please post here otherwise I will keep the rest of my findings to myself unless they also will apply to FTP.

Donna,

Yes you need the license for SSL.

I will tell you the way we are doing it here. The best way is what works the best for you.

We have ADT^A01 (HL/7) converted to X12 278. That is sent to UHC via HTTPS Real time (not file transfer). The essential data from the 278 Request is also sent to a DB2 database for the backend system which allows the user to make corrections on rejected 278s.

The essential data from the 278 Reply is sent to a DB2 data base and is used in conjucntion with the essential data of the 278 Request (above) for the backend system.

users make necessary corrections and those come back into Cloverleaf(R) via a separate connecion than the ADT^A01 and are converted to 278 Requests which are then delivered to UHC via the same thread as above.

A Fileset/FTP (FTPS) thread checks UHC routinely for those instances where UHC has replied via HTTPS that it was busy and the  request would be processed off-line. The FTP is to pick up those delayed Responses.

We are just now getting ready to move this whole solution into Production where we can actually Test.

You need to be aware that the UHC test environment is practically wortthless.

UHC seems to subscribe to the Microsoft theory – Test in Production.

So the above architecture seems to function as desired in Test but could not be thoroughly tested in Test. We will find out how much we need to change once we can actually test.

Some Tcl is needed.

Apparently UHC issued an email that among other things indicated that for weekends and holidays the notification would be changed from 24 hour to next business day.

My management is interpreting this to mean that the requirement for 278 electronic notification has been rescinded.

They are trying to get clarification.

Anyone else seen this email and more importantly does anyone have any clarification?

Our clarification indicates that the X12 278 electronic transfer is no longer required. You may want to get your own clarification.

We will continue using the process we moved to our Production environment one week ago to at least get a feel for it.

Management here may decide to continue using our solution.

I will give details of what we have accomplished to follow.

We have finally moved our solution to our Production environment so the real testing can begin.

Recall UHC does not have a functional testing environment.

We are deploying an HTTPS solution using the SSL licensed package from Healthvision and the ODBC Drivers from Healthvision.

We are Cloverleaf 5.6 Rev2, ODBC 5.2, and AIX.

We have Siemens Invision as our Patient Management module.

An ADT^A01 HL/7 message arrives from Invision into Cloverleaf(R) and if the insurance code is a UHC code, the ADT^A01  is translated (using Xlate and some Tcl and Tables) into a 005010 X12 278 Request Transaction Set.

The X12 278 Request Transaction Set is delivered to UHC via an HTTPS thread. At the same time the essential data from the X12 278 Request is sent to a DB2 Stored Procedure (via the ODBC drivers) that inserts a row into a ‘Request Table’. This table will be used by the Business Office as part of a work list in Invision. More on that later…

The UHC X12 278 Response Transaction Set is received and essential data is sent to a DB2 Stored Procedure (via the ODBC drivers) that inserts a row into a ‘Response Table’. This table in conjunction with the ‘Request Table) is used by the Business Office to form the work list inside Invision.

If the Response from UHC indicates a delayed response (meaning the real time system is busy) then there is an FTPS thread that scans periodically for the delayed response files and just like the real-time responses retrieves the essential data and  invokes the Stored Procedure which inserts into the ‘Response Table’.

The Business Office views the Work List which now tells them what requests have been sent and what the responses are. If there are any rejected responses, the codes from the 278 have been converted to their textual equivalents (this is done inside Cloverleaf(R)) and the user can then determine what needs to be corrected.

The corrections that are made return to Cloverleaf via an LU3 (SNA) connection from Invision as a flat record (FRL). This is then converted to a 005010 X12 278 Request Transaction set and arrives via the same path as the ADT^A01 converted X12 278 Request Transaction Set to UHC and the ‘Request Table’ as described above.

The backend system also periodically checks to assure that Requests have been responded to. UHC has no method to absolutely guarantee to us a message is received.

We are still ‘testing’ and there are some pieces of the solution that have not yet been tested. That is because since we are in Production, we cannot ‘force’ situations.

For example, we have been told how to detect that the Connectivity Director is down. However when we think we detected that situation in our Test environment, the behavior we detected was not the same as what we were told to expect. When questioned, UHC replied that it worked properly in Production.

Tomorrow night we should be able to check that since there is a planned outage (not sure if this is Connectivity Director or not but we will see).

Another thing we could not check was our handling of the 997. In test, the 997 does not get returned (however one can look at the Web Page to see the interpretation of the 997). In Production, the 997 is returned but one cannot look at the Web Page. Since we did not get 997s in Test, we could not test our handling of them.

Hopefully as things settle down, I will get time to flesh out the 997 handling detail and actually test that by creating a failing 278 Request.

There are a LOT more details as to how the particulars of the above overview actually occurs.

If you are planning on doing this HTTPS real-time interchange with UHC and would like more of the details, let me know via email.

All,

We pulled the plug yesterday on our electronic submission of Admission Notification to UHC.

I was not privy to the reasons for the decision.

However, I think the fact that it is no longer required by UHC played a big role.

Dave,

Will you have a 278 from your patient Management system or will you need to convert a ADT^A01 to a 278?

If your Patient Admin system will send out a 278, you may not need to do any Xlate (not likely though).

You will need to build an X12 5040 Transaction set  (I think they are using 5040) as I don’t believe any release of Cloverleaf provides the 5040 Transaction Sets. This is not difficult to do if you have all of the documentation you need.

An April 1st time frame however is unlikely I would think.