Model Accessors/Properties

[dixonwhitmire]

X12 transaction models can be cumbersome to navigate due to the nested and hierarchical nature of some of the transaction sets such as eligibility and claim status. Let's make things a bit easier by adding "accessor" methods for the entities in the transaction set. An entity is a record which is comprised of one or more loops.

For example in the Eligibility Inquiry model (270) we could add a subscriber property:

@property
def subscriber(self, return_first=True) -> Union[Dict,List]:
   """
    Returns all segments related to a subscriber record across all subscriber loops.
    The return_first parameter is used to indicate if the records for a single subscriber
     are returned or if all subscriber records are returned.
    """
    pass

The return_first parameter will default to True for each implementation. The majority of x12 transactions convey data for a single member rather than batch. The one notable exception is the 834 (Benefit Enrollment) format.

Finally, adding properties to the transaction set models provides a greater and simpler DX experience.

[ccorley]

I wonder if we don't need a lower-level accessor, like:

@property
def subModel(self, segment_name: string, identifier: string) -> Dict:
     """
     Returns the dict for a specific segment.
     """

We could use this to ask for, for example, the "NM1" "IL" segment dict and easily access the values we need.

[dixonwhitmire]

I wonder if we don't need a lower-level accessor, like:

@property
def subModel(self, segment_name: string, identifier: string) -> Dict:
     """
     Returns the dict for a specific segment.
     """

We could use this to ask for, for example, the "NM1" "IL" segment dict and easily access the values we need.

That's a great point @ccorley! We may need to add the "loop_name" to the signature (we have enumerations for these) as there could be multiple segments of the same name in the transaction set. We may still need to support a return type of List[Dict] due to the "reuse".

[dixonwhitmire]

Met with @ccorley to discuss the initial implementation. We will provide accessors for each high level loop with an additional parameter to indicate if we want the first result. This will default to "true" (in 7 years at PokitDok I never saw a multiple record eligibility transaction).

Additionally we are currently storing the x12 delimiters with each segment. This will lead to a bit of duplicative effort to exclude the delimiters from a pydantic export via dict(), json(), etc. It looks like the pydantic team will support a model based configuration in their next release, 1.9 - pydantic/pydantic#660. We can utilize this new feature to simplify our property implementation, or we can look into removing the delimiters from each model. I will look into the latter to see what that looks like.