MacroHealth Internal

Enrollment FlowsPlatform Flow

To process enrollments in our system, a flow must be constructed to configure the data exchange between the Payer, MacroHealth, and the Network, and it must reflect the agreements detailed in the customer's implementation documents.

A standard enrollment flow will support:

  • Processing X12 834 files sent from a Payer to MacroHealth

  • MacroHealth storing enrollment records

  • MacroHealth performing data transformations

  • MacroHealth sending enrollment files to the network

The payer could expect an acknowledgement using an X12 TA1/999 format, ignoring few exceptions outside standard HIPAA guidelines.

Based on the business processes MacroHealth will be able to:

  • Accept new enrollments

  • Make changes to enrollments

  • Reinstate enrollments

  • Terminate or void enrollments

Building an Enrollment Flow

While the platform offers a lot of flexibility, the following section illustrates a typical enrollment flow. For each integration, some variations may apply.

Diagram Flow Comparison

Although a generic enrollment diagram flow cannot be directly divided into platform flows, certain specific steps of the diagram flow can be recognized into the platform flow.

Figure 11. Enrollment Platform Flow
Enrollment Platform Flow
  1. Sending the 999 to the payer and saving each member record in the incoming file

  2. Performing data transformation and saving the transformed member records

  3. Generating the outgoing file to the network



Figure 12. Enrollment Diagram Flow
Enrollment Diagram Flow


Enrollment Subflows

Note

The following widget configurations are for illustrative purposes only. Each integration as its own specifications, therefore configuration may vary from one integration to the other.

A typical enrollment flow will be divided into three subflows, as illustrated in the previous section:

Tip

In the numbered lists, click on the widget names to find details on how to configure them.

Subflow 1

Subflow 1 is for configuring receiving the Payer's 835 file from the SFTP, saving each member record into the incoming file, and sending a 999 Ack back to the Payer.

Subflow1.png
  1. SFTP Connection:SFTP Sink Receive an incoming 834 file from a SFTP source.

    SF1_1.png
  2. Validate and Split File: Validate the incoming 834 file and split out transaction sets within the file for further processing.

    SF1_2.png
  3. Split Document: Split the individual enrollment member records from origin.

    SF1_3.png
  4. Remap Document: Performs necessary data transformations.

    SF1_4.png
  5. Stage For Store Case: Creates an enrollment case to store the record.

    SF1_5.png
  6. Stage For Store Case Document: Stores the document.

    SF1_6.png
  7. Commit Transaction: Commits the current operations. Signals the termination operation.

    SF1_7.png
  8. Remap Document: Performs necessary data transformations.

    SF1_8.png
  9. Stage For Bucket: Stores the document into "bucket", which can be used later.

    SF1_9.png
  10. Translate X12: Generates an acknowledgement 999 file for the incoming 834 file.

    SF1_10.png
  11. SFTP Connection:SFTP Sink Sends the 999 file to destination.

    SF1_11.png
Subflow 2

Subflow 2 is for configuring retrieving the documents from storage, performing data transformations, and saving the transformed member records.

Subflow2.png
  1. Source From Bucket: Retrieves documents from "bucket" to be used (Subflow 1, widget 9).

    SF2_1.png
  2. Stage For Bucket: Stores the document into "bucket", which can be used later.

    SF2_2.png
  3. Lookup Cases: Look up records based on certain enrollment.

    SF2_3.png
  4. Remap Document: Performs necessary data transformations on records. This step saves specific look up fields with records to prepare for future use (Subflow 3, widget 3).

    SF2_4.png
  5. Remap Document: Performs necessary data transformations on records. The exact transformation scenario is as follows First 3 characters of REF02 in loop 2000 where REF01 = 0F should be truncated.

    SF2_5.png
  6. Remap Document: Performs necessary data transformations on records. Specifies the details to be stored in the next step.

    SF2_6.png
  7. Stage For Store Case Document: Stores the updated records in the Platform.

    SF2_7.png
  8. Commit Transaction: Commits current operations. Signals a terminal operation.

    SF2_8.png
  9. Commit Transaction: Commits current operations. Signals a terminal operation.

    SF2_9.png
Subflow 3

Subflow 3 is for configuring retrieving the documents from storage, performing any other data transformations and merging member records, generating an outgoing 834 file, and sending it to the Network's SFTP destination.

Subflow3.png
  1. Source From Bucket: Retrieves documents from "bucket" to be used (Subflow 2, widget 2).

    SF3_1.png
  2. Remap Document: Performs necessary data transformations.

    SF3_2.png
  3. Search Enrollment:  Search for enrollment records to be populated in the outgoing file.

    SF3_3.png
  4. Merge And Translate to X12: Merges individual member records into one document and generates the outgoing 834 file.

    SF3_4.png
  5. SFTP Connection:SFTP Sink Sends the outgoing 834 file to the SFTP destination.

    SF3_5.png
  6. Commit Transaction: Commits the current operations. Signals a terminal operation.

    SF3_6.png