C#中复杂HL7消息对象的设计方案选型咨询

Great question—HL7 parsing is all about balancing quick implementation with long-term maintainability, so let’s break down both options to help you decide.

Option 1: String List-Based Object #

This approach stores the HL7 message as nested lists of strings (e.g., a list of segments, each segment is a list of fields, each field is a list of subfields, etc.). Here’s how it stacks up:

Pros #

• Fast to build: You can split the raw text by HL7 delimiters (segment separator \r, field separator |, subfield separator ^, etc.) and populate the lists in just a few lines of code.
• Minimal memory overhead: No extra object instantiation beyond basic collections, which might matter for high-throughput scenarios (though HL7 messages are rarely large enough for this to be a critical factor).

Cons #

• No type safety or context: Everything is a string, so you lose meaning about what each field represents (e.g., a patient ID vs. a birth date). You’ll have to manually parse data types every time you access a value.
• Error-prone access: Index-based works, but there’s no validation—if you ask for subfield 3 when a field only has 2, you’ll get an out-of-bounds error or null with no helpful context.
• Hard to extend: If you later need to add logic like validating segment structure, handling repeatable segments, or modifying field values, you’ll have to hack it into list operations, which gets messy fast.
• Delimiter escapes are a headache: HL7 allows escaping delimiters (e.g., \^ for a literal ^), and with a list approach, you’ll have to handle escaping/unescaping every time you read or write values, leading to redundant, error-prone code.

Option 2: Custom Segment/Field/Subfield Object Structure #

This approach models the HL7 hierarchy explicitly with dedicated classes: HL7Message contains Segment objects, each Segment contains Field objects, each Field contains Subfield objects, and so on. Here’s why this is usually the better choice:

Pros #

• Semantic clarity: Each class has a clear purpose, making code self-documenting. A PIDSegment (or generic Segment with a Name property) immediately tells other developers what it represents.
• Type safety and built-in parsing: You can add properties/methods to handle HL7-specific data types directly. For example, a Field could have an AsDateTime() method that parses the string into a DateTime object, or a Subfield could validate against HL7 code sets.
• Easier maintenance & extension: Adding new functionality (like support for repeatable segments, validation rules, or editing message content) is straightforward. You can add methods to Segment to check validity, or to HL7Message to find all repeatable OBX segments.
• Robust access logic: Your GetInfo method can traverse the object hierarchy instead of splitting strings on the fly. For h.GetInfo("PID", 5, 3, 2), it would find the PID segment, then its 5th field, 3rd subfield, 2nd sub-subfield—with built-in checks to handle missing values gracefully (e.g., returning an empty string or a meaningful exception).
• Team-friendly: A well-defined object model is easier for teams to collaborate on. New developers can grasp the structure without digging through messy string-splitting logic.

Cons #

• Upfront development time: You’ll need to define multiple classes and write parsing logic to map raw HL7 text into these objects. This takes more initial work than the list approach.
• Slightly higher memory usage: Instantiating multiple objects uses more memory than simple lists, but for typical HL7 messages, this is negligible compared to the benefits.

Final Recommendation #

If you’re building a quick, one-off tool that only reads a few specific fields, the string list approach might suffice. But for any production-grade application, or if you anticipate extending functionality later (which is almost always the case with HL7), the custom object structure is far superior.

It aligns with HL7’s hierarchical nature, makes code more maintainable, and reduces bugs from manual string manipulation. Plus, your GetInfo method will be much more robust and easier to debug with this approach.

内容的提问来源于stack exchange，提问作者Nimbocrux