Question

I’m looking for some suggestions on better approaches to handling a scenario with reading a file in C#; the specific scenario is something that most people wouldn’t be familiar with unless you are involved in health care, so I’m going to give a quick explanation first.

I work for a health plan, and we receive claims from doctors in several ways (EDI, paper, etc.). The paper form for standard medical claims is the “HCFA” or “CMS 1500” form. Some of our contracted doctors use software that allows their claims to be generated and saved in a HCFA “layout”, but in a text file (so, you could think of it like being the paper form, but without the background/boxes/etc). I’ve attached an image of a dummy claim file that shows what this would look like.

The claim information is currently extracted from the text files and converted to XML. The whole process works ok, but I’d like to make it better and easier to maintain. There is one major challenge that applies to the scenario: each doctor’s office may submit these text files to us in slightly different layouts. Meaning, Doctor A might have the patient’s name on line 10, starting at character 3, while Doctor B might send a file where the name starts on line 11 at character 4, and so on. Yes, what we should be doing is enforcing a standard layout that must be adhered to by any doctors that wish to submit in this manner. However, management said that we (the developers) had to handle the different possibilities ourselves and that we may not ask them to do anything special, as they want to maintain good relationships.

Currently, there is a “mapping table” set up with one row for each different doctor’s office. The table has columns for each field (e.g. patient name, Member ID number, date of birth etc). Each of these gets a value based on the first file that we received from the doctor (we manually set up the map). So, the column PATIENT_NAME might be defined in the mapping table as “10,3,25” meaning that the name starts on line 10, at character 3, and can be up to 25 characters long. This has been a painful process, both in terms of (a) creating the map for each doctor – it is tedious, and (b) maintainability, as they sometimes suddenly change their layout and then we have to remap the whole thing for that doctor.

The file is read in, line by line, and each line added to a

 List<string>

Once this is done, we do the following, where we get the map data and read through the list of file lines and get the field values (recall that each mapped field is a value like “10,3,25” (without the quotes)):

ClaimMap M = ClaimMap.GetMapForDoctor(17);

List<HCFA_Claim> ClaimSet = new List<HCFA_Claim>();

foreach (List<string> cl in Claims) //Claims is List<List<string>>, where we have a List<string> for each claim in the text file (it can have more than one, and the file is split up into separate claims earlier in the process)   
{
     HCFA_Claim c = new HCFA_Claim();
    c.Patient = new Patient();
    c.Patient.FullName = cl[Int32.Parse(M.Name.Split(',')[0]) - 1].Substring(Int32.Parse(M.Name.Split(',')[1]) - 1, Int32.Parse(M.Name.Split(',')[2])).Trim();
        //...and so on...       
     ClaimSet.Add(c);
}                

Sorry this is so long…but I felt that some background/explanation was necessary. Are there any better/more creative ways of doing something like this?

Answer 1

You need to work on the DRY (Don’t Repeat Yourself) principle by separating concerns.
For example, the code you posted appears to have an explicit knowledge of:

1. how to parse the claim map, and
2. how to use the claim map to parse a list of claims.

So there are at least two responsibilities directly relegated to this one method. I’d recommend changing your ClaimMap class to be more representative of what it’s actually supposed to represent:

public class ClaimMap
{
    public ClaimMapField Name{get;set;}
    ...
}
public class ClaimMapField
{
    public int StartingLine{get;set;}
    // I would have the parser subtract one when creating this, to make it 0-based.
    public int StartingCharacter{get;set;}
    public int MaxLength{get;set;}
}

Note that the ClaimMapField represents in code what you spent considerable time explaining in English. This reduces the need for lengthy documentation. Now all the M.Name.Split calls can actually be consolidated into a single method that knows how to create ClaimMapFields out of the original text file. If you ever need to change the way your ClaimMaps are represented in the text file, you only have to change one point in code.

Now your code could look more like this:

c.Patient.FullName = cl[map.Name.StartingLine].Substring(map.Name.StartingCharacter, map.Name.MaxLength).Trim();
c.Patient.Address = cl[map.Address.StartingLine].Substring(map.Address.StartingCharacter, map.Address.MaxLength).Trim();
...

But wait, there’s more! Any time you see repetition in your code, that’s a code smell. Why not extract out a method here:

public string ParseMapField(ClaimMapField field, List<string> claim)
{
    return claim[field.StartingLine].Substring(field.StartingCharacter, field.MaxLength).Trim();
}

Now your code can look more like this:

HCFA_Claim c = new HCFA_Claim
    {
        Patient = new Patient
            {
                FullName = ParseMapField(map.Name, cl),
                Address = ParseMapField(map.Address, cl),
            }
    };

By breaking the code up into smaller logical pieces, you can see how each piece becomes very easy to understand and validate visually. You greatly reduce the risk of copy/paste errors, and when there is a bug or a new requirement, you typically only have to change one place in code instead of every line.