5010 – Are you really ready?
Every place I go these days and ask people the question if they are ready for 5010, the answer that I get is ‘Yes, absolutely’ and then invariably 20 minutes into the conversation it transpires that ‘No, not really’. Most everybody seems to have missed out one or two, and in some cases quite a lot more, crucial components of the overall transition. And it does not matter whether people are opting for tactical (downgrade to 4010 and proceed) or strategic (full remediation) approach.
That made me think; wouldn’t it be a good idea to create an illustrative checklist for things that one must take care of to ensure smooth transition? So, given the fact that once I start thinking on a particular line, I invariably become obsessed about it and must get it out of my system (mostly at the expense of readers), here is an attempt at a very high level checklist for the tactical approach. Will cover the mandatory requirements for the strategic approach in the next blog.
Tactical Approach
The approach entails downgrading the inbound 5010 into 4010, pushing the downgraded version through the downstream applications so that they can process them as they have been doing for last 10 years, upgrade the returning document to 5010 and then pushing it out through one’s EDI gateway. Things one must consider include but definitely are not limited to,
• First and foremost a bidirectional converter between 4010 and 5010 that is driven by dynamic rules, i.e., wherein the rules can be modified very easily by the end users without any involvement from IT. It is absolutely crucial to have the ability to be able to modify and configure these rules on the fly because the conversion logic is not going to be same for all payers/providers and they will change all the time.
• A solid store and forward mechanism wherein the downgraded information from 5010 is stored in a standalone repository so that it could be retrieved at any given point by any application throughout the infrastructure. It won’t be much fun to find out that once you downgrade the 5010 to 401, the information is lost for good.
• A clear strategy focused on performance aspects of the converter and store-and-forward mechanism because, trust me, having the best converter won’t hold you in good stead if it is slow because nobody, and I mean nobody, has any spare cycles for claims adjudication.
• A clear strategy to identify all the data attributes that are present in 5010 and not in 4010 and which can be required by the downstream applications in order to achieve basic compliance. In addition one needs to identify the methods and changes needed in the downstream applications to fetch the required data during production run and make use of it. For example, if the last name of a claimant happens to be 45 characters, the downgrade converter will chop of the last 10 characters when it converts inbound 5010 to 4010 as 4010 can support only 35 characters for last name, unlike 5010 which can handle 60 characters. So now, unless you want to address the claimant with partial last name, your downstream application that prints the Id cards better have some mechanism to access the store-and-forward repository being used by the downgrade converter.
• A large set of 5010s to test and a comprehensive test strategy along with associated test cases and test scenarios. There are 968 unique and more than 6500 combinational changes between 4010 and 5010 TR3s, not to mention the changes that are specific to companion guides. If you want to be at peace that you have tested every possible scenario, you better have a comprehensive list of the changes between 4010 and 5010, especially the ones that are specific (and hence configured) to your environment. The vendors may certify your 3rd party applications as 5010 compliant, but one can take them on their word only at one’s own peril. One must have a large number of 5010s to test those compliant applications and what better way to generate those 5010s but to create them from existing 4010s using, yes you guessed it, the same converter that was described in step 1.
• A clear set of rules to describe the re-morphing of the previously downgraded 4010 back into its outgoing version of 5010. These rules should not only leverage the standard transformation clauses (such as deletion of deprecated values) but also mechanism to get additional data from downstream applications and data received along with initial transaction. In addition there should be focus on a very robust unique identifier generation from within the data of the original transaction itself, which could be carried back to the up-converter logic.
So these are a few of my favorite things, when it comes to 4010 to 5010 transition using tactical approach, which by the way, is good only though the date when ICD10 hits the road. Next time, we talk about strategic approach. Stay tuned….
