Original 837P Template before errata
We have clients sending us files with version 005010X222 without A1 suffix. Do you have a template for 005010X222 transactions or should I just create one like below? I tried this one and it parsed lots of files without any errors. Just wanted to make sure it's the right way to handle it.
/// <summary>
/// Health Care Claim : Professional, original version without errata
/// </summary>
[Serializable()]
[DataContract()]
[Message("X12", "005010X222", "837")]
public class TS837P0 : TS837P
{
}
Comments
5 comments
Hi Denys,
Yes, we do have those. A new version of all health-care HIPAA templates will be released by the end of this week with full support for Microsoft Entity Framework, so you can also use migrations to automatically create a database the same way as we did for the X12 and EDIFACT templates.
Regarding the other question - yes, this is a correct way to parse multiple transaction type using the same template (another way would be to use a type factory). The difference however, is in the validation attributes and if you validate X222 against the X222A1 template it is highly likely that the validation will fail. I'll let you know when the old templates are made available again.
Thank you for sharing the original versions of the templates so quickly! I noticed though that the message attribute is the same as in the latest versions:
[Message("X12", "005010X222A1", "837")]
Shouldn't it be like this?
[Message("X12", "005010X222", "837")]
Or I must be missing the nature of the difference between the original and the current templates.
I also noticed the difference in the actual types and fields in the classes. Does it mean we essentially need to have two different implementations depending on the version? What would be the best approach for minimizing the code duplication in case we need to read both versions?
As we integrate with many different clients we need to support and generalize the versions below. I'm thinking about creating a dedicated model for each of the document types (835, 837P, 837I) as a base assembly and then creating an assembly for each specific version with the templates. Then the parsing method would return a sequence of the generic models, but internally would use the AssemblyLoadFactory approach to load a specific parsing assembly with the templates based on the specific version of a transaction. Does it sound about right?
835:
004010X091
004010X091A1
005010X221
005010X221A1
837P:
004010X098
004010X098A1
005010X222
005010X222A1
837I:
004010X096
004010X096A1
005010X223
005010X223A1
005010X223A2
I think I'm still missing the following versions. Can you share?
004010X091A1
004010X098A1
004010X096A1
005010X223A1
Hi Denys, the message attributes have been updated with the correct versions, please re-download.
All templates represent the standard transactions as defined by X12.org, for more information regarding the implementation guidelines contact X12.org
All published versions (matrix here) are available as part of the Enterprise plan, so download them using the link you received after the purchase.
Feature comparison between Professional and Enterprise plan.
Cross-version base models are possible, but you'll need to go over all the segments and complex data elements and match them against the implementation guidelines. All segments and complex data elements implement interfaces and have a base class, so your logic can work off that to reduce code duplication.
Please sign in to leave a comment.