This project has moved and is read-only. For the latest updates, please go here.

Generate XML with unique names for <Loop> element

Mar 13, 2012 at 8:55 PM

Greetings. First of all, a big thanks to your entire team for producing such a fantastic piece of software that is so simple to use and best of all - is extensible. 

The XML that is currently generated from an 837 claim contains various <Loop> elements. For instance:

<Loop LoopId="2010BA" Name="SUBSCRIBER NAME">

Is it possible to change either the source code / xsl / configuration files in the OOP X12 project (source) that would help generate something as follows:

<Loop201BA LoopId="2010BA" Name="SUBSCRIBER NAME">

The intention is to generate unique Loop elements that are perhaps identified by the loopId.

I would greatly appreciate any help in this matter.

Thank you very much, in advance, for your help.

Kind Regards.

Mar 13, 2012 at 10:00 PM
Edited Mar 15, 2012 at 10:24 PM

You can do this by having a post processing xslt to convert to whatever format you want.

I've thought about doing this for some of the standard xml formats you can download off the x12 site, but it's a lot of work and I didn't want to do it without a need.
I didn't do this because the Professional and Institutional have mismatches in their loopIDs where a particular LoopId in one meant something different in the other. The Entity Type identifiers are more trustworthy if you need code that would work with both these formats.


Mar 13, 2012 at 11:18 PM

Dear Sir, thank you so much for your prompt response.

The post processing XSLT will works for me. Thank you.

Is it also possible to accomplish this in the code itself? Or one of the existing XSLTs used by your product? The reason I ask is to minimize the post processing if possible. Also based on your feedback, instead of using the loopId, I think I will now use a different unique qualifier, for instance "SubsciberName" (no space) because our data contains both 837 I & P files.

Thanks again for all your help.

Mar 13, 2012 at 11:43 PM
Edited Mar 15, 2012 at 10:24 PM

I started work to do this and produce the xml seen here: http://x12parser.codeplex.com/SourceControl/changeset/view/15073#156668

The xslt for this can be found here:
This is not complete, but you can use it as a starting place.
It deserializes into C# objects in that same assembly.

Mar 13, 2012 at 11:56 PM

Dear dstrubhar, I don't have words to thank you for your prompt response and willingness to help. This means a lot! The OOP X12 project is a motivation & blessing to us struggling developers working with health care claims. KUDOS to you and your team.

The first link you sent doesn't work. Perhaps a different change set number compared to 156668?

I am wondering if I need the C# code as well as the XSLT you posted on 154136? Am I required to simply replace the existing corresponding files in the CSProject I have downloaded from your site? And simply rebuild the solution to produce a new X12Parser.exe using VS2010?

Awaiting your kind response.

Thanks again.

Regards.

Mar 13, 2012 at 11:59 PM

Sorry, the link works now.

Also, I almost forgot to mention that I am working with HIPAA X12 4010 837 data for now. The changes you have made should be compatible with both 4010 and 5010 formats, right?

Thanks again. 

Mar 14, 2012 at 12:27 AM
Edited Mar 15, 2012 at 10:24 PM

If you are going to transform into your own schema I would not suggest that you do it in-place with the OopFactory code so that if I release updates you can always upgrade without overriding your custom xslt.

There is a sample discussion with simple instructions on how to create a project with an XSLT here: http://x12parser.codeplex.com/wikipage?title=Creating%20a%20flat%20file%20from%20the%20X12%20xml%20using%20XSLT%20and%20XslCompiledTransform
This example creates a flat file, but you would just create xml instead of a flat file with whatever xslt you build.
The parser will be able to tell whether to use the 4010 or 5010 specification, and the xslt I pointed you to should work for both.
Have fun. I actually enjoy working with EDI now that I don't have to be depending on huge infrastructure to parse a text file.

Mar 14, 2012 at 6:13 PM

Dear Sir,

Once again, many thanks for your help last night with the Custom XSLT. It works like a charm. However, there are a few issues that I am running into. Although, someone with a good knowledge of XSLT might be able to resolve these, I would still really appreciate your feedback.

a. In the original XML document produced by X12OOP parser, the patient information (Loop2000C) is either missing for most claims, or, appears to be as a child of the "Subscriber Hierarchical Loop 200B". As such, the custom XML that is now produced by the XSLT you helped with last night doesn't always contain the patient information. I really need the Patient Name, DOB, ID, etc and not sure how do I go about getting these in.

b. The Diagnosis Codes are particularly important. Your XSLT is correctly importing them in as <Diagnosis> elements. However, is it possible to change the element name to be unique? The XSD (schema document) that I generate from the Custom Claim XML only contains a single <Diagnosis> reference, which prevents me from accessing all but the first diagnosis code.

c. You made a note in the XSLT:

 <!-- XXX This is incomplete, but good enough for CMS-1500 -->     
<!-- Other subscriber information loop -->     
<xsl:if test="./Loop[@LoopId='2320']"> 

This other payer information is also important for us and I am unable to retrieve using the custom XSLT. Do you have any suggestions on how I can get this in?

I apologize for so many questions and also understand that someone with a good knowledge of XSLT can modify the file to parse this information. But, any help would be greatly appreciated.

Thank you again for all your timely help.

Kind Regards.

Mar 14, 2012 at 8:44 PM
Edited Mar 15, 2012 at 10:23 PM

The way the 837 hiearchical loops work is that the patient loop only needs to be designated if the patient is different than the subscriber. When the patient is the same that loop is not included and you should be able to get the demographic information from the subscriber loop.

You will either need to modify this xslt or do a second transformation so that each Diagnosis is it's own unique name. If you want to be able to used updated versions of this xslt that will probably have more elements included, than I suggest doing a 2nd transformation.
This is not a trivial task and you might need to be committed to learning xslt to continue with this method.
Alternatively you can load it into the claim object and transform to your final destination using these objects.
I may be able to add the other payer information next week so that the objects will be complete for the UB-04.


Mar 14, 2012 at 9:28 PM
Edited Mar 15, 2012 at 10:23 PM

Here is what a possible 2nd transformation might look like for your Diagnosis remapping.

You would need to remove the xmlns="http://www.oopfactory.com/2011/XSL/Hipaa" from the first transformation because it will complicate things, then you could pass the output of the first transformation to this xslt:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"
>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="Diagnosis[@Qualifier='BK']">
<DiagnosisPrimary>
<xsl:value-of select="@Code"/>
</DiagnosisPrimary>
</xsl:template>
<xsl:template match="Diagnosis[@Qualifier='BF']">
<xsl:variable name="sequence" select="count(preceding-sibling::*[local-name()='Diagnosis' and @Qualifier='BF'])"/>
<xsl:choose>
<xsl:when test="$sequence = 0">
<DiagnosisOtherA>
<xsl:value-of select="@Code"/>
</DiagnosisOtherA>
</xsl:when>
<xsl:when test="$sequence = 1">
<DiagnosisOtherB>
<xsl:value-of select="@Code"/>
</DiagnosisOtherB>
</xsl:when>
<xsl:when test="$sequence = 2">
<DiagnosisOtherC>
<xsl:value-of select="@Code"/>
</DiagnosisOtherC>
</xsl:when>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>

Mar 23, 2012 at 5:42 PM

Dear Sir,

My sincere apologies. I just saw your post. Thank you so much for helping me out with the diagnosis codes. I spent the last few days customizing the XSLT further to parse more information and create unique nodes. Glad to report, I was successful in generating unique xml elements for a number of items in addition to the diagnosis codes. Once again, the X12 parser is simply amazing! I am now generating the XML by invoking your API from our C# application, and using the custom XSLT you provided (with further customizations) to generate the Custom Claim XML document, which gets written to the file system. I am not writing the initial XML to the file system because it is a lot more bigger in size.

fyi - you mentioned in one of the earlier posts that patient information appears if it is different from the subscriber. But that is not the case in a lot of the data we are working with, unfortunately. This remains an open issue for us :-(

Also, I have a huge concern with some big 837 files. Some of our 837 data is ~30Mb and contains ~15,000 claims / 100,000 claim details.

I tried the X12parser + Custom XSLT and after ~3 hours with 100%CPU and ~190MB memory, the XML was still not generated. When I stopped my application, a 50MB file got written to disk, which as incomplete. 

I am not sure if I need to use UnbundleX12? It will generate ~15000 files in a single directory and Windows can have trouble sometimes handling so many files. Do you have any alternate suggestions? Have you had to work with data this size? I would really appreciate your help/suggestions.

Thank you again.

Kind Regards.

Mar 23, 2012 at 6:02 PM

You will need to use some form of unbundling.  You don't need to unbundle at the claim level if that creates too many files.  You may try unbundling at a higher level such as the billing provider hierarchical loops.

I will probably need to add some functionality to unbundle at the ISA, GS or ST level, but I have not gotten to that yet.