The DSM programmers didn’t skimp on anything in designing the new programs for 5010. No, really, I mean they didn’t skimp on ANYTHING in 5010. ALL FIELD SIZES ARE TO 5010 MAXIMUM LENGTHS. This “design to the max” philosophy might have been considered a waste in the past, BUT due to new technologies which increase disk sizes, compress transmissions, and compress the backups, our programmers have taken the high road to system design.

Attrition of programs by regulation has always been the bane of healthcare programmers. The problem with regulation requirements is the simple fact that new fields, field lengths, types and how the data is captured cannot always be anticipated by program designers. Typically the regulations come from entities interested only in a particular end result. The assumption is that any obstacles created by their legislation will be overcome without any problem. And if problems do arise, it’s not THEIR problem. Luckily, the regulators are mostly right. The programmers do overcome the problems but the inability to foresee changes has resulted in solutions that would have benefited from “design” rather than “accommodation”. The lack of the ability to foresee requirements has been one of the most limiting factors in healthcare program design. In recent years standards have helped to mitigate this hindrance, but it has not eliminated it. The fact that 5010 is an upgrade within the X12 standard helps a lot, but without committing to a re-design can cause obstacles which cannot be appreciated by the end user.

Our new programs have benefited greatly in the area of supporting file design. After years of experience with submitter ids, taxpayer ids we have designed the supporting files to be able to accommodate changes in these areas that normally only programmers and support personnel have to deal with. This makes our staff better able to react to changes at the intermediary level.

Our Claredi Classic relationship for testing our claim transmissions way in advance of 5010 is another tool in the hands of our programmers. No longer do the programmers have to wait for testing from the intermediary. Instead, changes are tested immediately by mock transmissions to our partner for confirmation or identification of any problem in the format.

An example of the type of solution we are avoiding by re-design would be what I saw often in the year 2000 programming (Y2K) done by some of our competitors’ programmers. When working with their files we often would find a date minus the century, only to find the century for that date in another field in another record. These “accommodation” programming methods even had names, “re-partitioning” and “windowing”. Those were cool sounding names for what were really bad solutions born out of desperation. Believe it or not many of our competitors still have these poor database designs within their products. (Rest easy, all dates in the HDMS product were made to include the century, “re-sizing” is the cool name and it is the ultimate solution). One might say that the year 2000 should have been anticipated, it’s not like legacy programmers didn’t know it was coming. Yes, but most programmers thought they would never face it!

Experience is a dear teacher and we have applied our experience to predict where regulations are going and the programmers have made educated “guesses” with respect to what areas are going to be addressed next by regulation. The “Y2K” accommodations mentioned above might be necessary to transition ICD9 to ICD10 without re-design. The problems most software companies face is that there is no space for the additional characters, just like in the Y2K situation. The new 5010 addresses ICD10 which positions our new programs for ICD10 as well.

Our design decisions will mean the ability to accommodate field changes for years to come, without the need to do re-“partioning” or “windowing”, the euphemisms for legacy work-arounds. But our new design decisions will not cause the new product to run off and leave our legacy applications. Rather, the new browser based graphics make it easier to get to and use the legacy apps.
For example, note the tabs on the top of the insurance screens. Click the “image” tab for images captured in our eBOSS scanning module.
Click the “Eligibility” for eligibility information received from Passport. “Notes” for the account notes that show maintenance changes, FC changes etc.

The most important design difference is the legacy insurance system in use by our customers was designed around clerks building claims as accurately as possible before transmission and the new insurance system is designed around the computer programs building claims accurately for automatic transmission without clerical intervention. Only rejected claims will require attention by the insurance clerks to work the exceptions. That’s where our clearinghouse and claim scrubbing partners come in, to exploit the opportunity to get clean, paying claims through without intervention.

Keep us bookmarked, more information is coming.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s