To expand on Jason’s suggestion of building everything at v2.5 minimum, I recommend going with v2.7 because there are some new data types introduced in the later HL7 versions and you might as well be prepped to handle those data types especially since the majority are compound data types.
I also recommend striving to have a single variant to handle everything sent from Epic (based on v2.7) and a single variant for everything destined for Epic (also based on v2.7). There are exceptions, but for the most part having only two variants to maintain makes things much simpler in the long run. For any other application, I normally try to build a single variant based on the vendor’s published specification because a single variant should accommodate both inbound and outbound. However, there are some distinct differences in some of the message structures depending on the message direction with Epic (in vs. out). And since you can’t have more than one message structure for a given message type + event in a single variant then you’re forced to make two variants. For example, if I recall correctly, there are structural differences between an ORU^R01 sent from Epic compared to the expected structure for an ORU^R01 sent to Epic. Just place the two variants (named epic_in and epic_out perhaps) in your Master site and encourage everyone on your team to utilize those two variants for all Xlates that are Epic related.
Hope that helps.
