Membership Info Files Overview

CirrusMD is able to ingest membership information separate from eligibility through a Membership Info File Ingestion System (MIFIS). This capability allows a client to provide supplemental information where a full eligibility file would neither be possible, nor make business sense (such as SSO setups, or API eligibility). The MIFIS supports ingesting CSV and other file formats which include patient data, marketing information, and additional reporting values that may not be possible to provide through normal eligibility file means.

User records are imported into the CirrusMD Data warehouse via the ingestion of Membership Info files. Much like eligibility records, each user record in a membership info file must have a unique “External Id” field as we use that as our primary key.

Differences between Membership Info Files & Eligibility Files

While Eligibility imports through the Patient Eligibility Ingestion System (PEIS) and Membership Info File Ingestion System (MIFIS) use a lot of the same bones, there are some differences between them which adds additional functionality and nuance to MIFIS.

• The only required fields for a membership info file are the External ID, Effective Date, and Expiry date. All other fields are optional.

• The data is primarily stored within our data warehouse for reporting purposes and use cases. The data is only sent to the core app/CirrusMD platform if a matching External Id on the file is already present within the core app/CirrusMD platform. The match must be exact for the data to get passed to the core app/CirrusMD platform.

With these differences in mind, it is important to think of the MIFIS as a way to enrich the CirrusMD reporting capabilities with additional metadata, or population counts data. Some examples of primary use cases would be:

• Passing a file of user records to enable utilization reporting. This file would provide us with the denominator (population count) for the utilization formula.

• Passing marketing information to enable engagement protocols without having to build a complete eligibility file.

• Adding additional record metadata from different sources, without having to build a complete eligibility file, for reporting.

Data storage and Use, Impact on Core App Data

The data captured within a membership info file is primarily stored within the CirrusMD data warehouse because the primary use cases are reporting-focused. This data can make its way over to the main platform, but the source of truth is the data warehouse instead of platform data.

The process for membership info file data to get into the core app is as follows:

1. A membership info file is uploaded to the shared SFTP location

2. CirrusMD Retrieves this file and begins its data ingestion process

3. During the ingestion process, we check if any external ids, for the associated plan, are already within the core app and CirrusMD platform.

4. If an exact match is found, we will enrich the data in the platform with the information from the membership info file and upload that data to the core app.

Please keep in mind the following notes:

• We check for matching External Ids during membership info file processing. If a membership info file is uploaded weekly, we only check for matching External Ids weekly. This could mean that data posted to the core app could lag behind receiving it in a membership info file depending on processing frequency.

  • If the primary use case is for this data to be present in the core app, we would recommend daily uploads to trigger this matching process often.

• The External ID must be already present within the core app to conduct the matching process. Commonly this is done through API or SSO.

• Data must be present within the core app to create a valid eligibility file that can then be enriched with a membership info file. We are passing data to the core app by creating an eligibility file with data already found within the core app, adding the membership info file data to it, and then sending that to the core app. Please see this document on data that must be within the system. This data should be present, it is captured during registration when needed.

CSV File Format (RECOMMENDED)

Delivering a file in CSV format ensures quicker onboarding and prevents custom development work.

• MS-DOS-style lines that end with (CR/LF) characters (optional for the last line).

• UTF-8 character encoding.

• A header record with the name of the field is documented below. If a field is not needed, and not required, you do not need to include it in the file.

• Each record must contain the same number of comma-separated fields.

• Any field may be quoted (with double quotes). We recommend Quoting all fields to reduce errors.

• Fields containing a line break, double-quote, or commas should be quoted. (If they are not, the file will likely be impossible to process correctly).

• A (double) quote character in a field must be represented by two (double) quote characters.

• The order of the fields does not matter, but we ask that it is the same & consistent order with each file provided.

Custom File Formats

CirrusMD can import almost any flat-file format such as fixed width and pipe delimited as long as the data is consistent. Parsing non-CSV file formats will incur development and ongoing maintenance fees. Please see the Custom File Formats section if this is required.

Available Fields

name	type	description	format or validation
External Id 1	String	Unique Identifier2	123345 MUST BE UNIQUE
Effective Date	ISO8601	Access Active Since2	2019-01-01
Expiry Date	ISO8601	Access Expires On2	2020-01-01
Any Field to be considered Metadata	Various	Any data can be passed to CirrusMD and if it is not part of the above fields, will be considered reporting metadata. This data is viewable by our providers during time of visit.	Anything!
Customer Type	String	High level identifier for customer type associated for the record3	Health System
LOB	String	"Line of Business" business unit or classification for the record3	Distribution Center
Group Id	String	A sub group within a plan id or customer. This is typically associated with plan benefit coverage. Applies more to Coverage benefits (health plans)3	ABC123
Group Name	String	The normalized name associated with the group id. Please see Group Id. Applies more to Coverage benefits (health plans)3	John Smith's Apple Picking Company
Payer Plan	String	Identifies the payer associated to coverage or claims. This is necessary to support RTE processing.3	Insurance Provider
Medical Plan Description	String	Identifies the detailed plan description of the coverage3	High Deductible Health Plan
Medical Plan Type	String	Identifies the broad category of coverage3	HDHP
Medical Provider	String	An association to a non-cirrusmd medical provider (typically PCP). NPI is preferable though can be set by the client. If NPI, CirrusMD can maintain a lookup to common NPI databases.3	1234567999
Behavioral Provider	String	An association to a non-cirrusmd behavioral provider (Typically therapist or psychologist). NPI is preferable though can be set by the client. If NPI, CirrusMD can maintain a lookup to common NPI databases.3	1234567888
Subscriber Relationship	String	Identification if user record is a Primary or Dependent3	Primary
Relationship Code	String	Identification of the record in relation to the Primary. Supported values are:3 'SPONSORED MOTHER' 'SPONSORED FATHER' 'CHILD' 'DAUGHTER' 'CHILDREN (2)' 'SPONSORED' 'CHILDREN (3)' 'CHILDREN (4)' 'CHILDREN (+6)' 'SPONSORED MALE CHILD' 'SPONSORED FEMALE CHILD' 'SON' 'SPONSORED FEMALE' 'SPONSORED MALE' 'HUSBAND' 'WIFE' 'SPOUSE' 'COMMON LAW SPOUSE' 'DOMESTIC PARTNER' 'DIVORCED SPOUSE'	CHILD
Ethnicity Code	String	Standard Ethnicity Classifications:3 Hispanic White alone, non-Hispanic Black or African American alone, non-Hispanic American Indian and Alaska Native alone, non-Hispanic Asian alone, non-Hispanic Native Hawaiian and Other Pacific Islander alone, non-Hispanic Some Other Race alone, non-Hispanic Multiracial, non-Hispanic https://www.census.gov/newsroom/blogs/random-samplings/2021/08/measuring-racial-ethnic-diversity-2020-census.html	Hispanic
County	String	Reporting identification for patient county. This is only used for external reporting, we leverage zip code for internal reporting.3	Hudson
Gender	String	User Sex assigned at birth (Biological)3	m, f, o, u
Gender Identity	String	Gender that a person identifies themselves as. This gender could be different than the gender set at birth3	m, f, o, u
Medical Enrollment	Boolean	User is actually enrolled in client/company provided medical coverage.3	True/False
Medical Eligibility	Boolean	User is eligible to enroll in client/company provided medical coverage, but may not be actually enrolled.3	True/False
Behavioral Enrollment	Boolean	User is actually enrolled in client/company provided behavioral coverage.3	True/False
Behavioral Eligibility	Boolean	User is eligible to enroll in client/company provided behavioral coverage, but may not be actually enrolled.3	True/False
Patient Utilization Category	String	An identifier, of the clients choosing, to break utilization into.3	Emergency Department High Utilizer

1 See External Id Rules below.

2 Required in all cases

3 Optional reporting segmentation data

External ID Rules

The External Id field is the most critical. The CirrusMD system uses the External Id to find members in our system. When importing a membership info file, if we do not find a match, we create a new user in our system. If we find a match, we update the user’s record.

Validation rules:

• External Id must be unique per file. If not, we take the first one and filter out the rest.

• External Id must be consistent between files. If we import a large number of records with different or incorrect External Ids, CirrusMD will charge custom development fees to fix the problem.

Required Fields

---

Below are the fields that must be provided in order to process the record.

• External Id MUST BE UNIQUE

• Member Id MUST BE UNIQUE

• Effective Date

• Expiry Date

Optional Fields for Marketing

• Email MUST BE UNIQUE

• Phone

Standard Segmentation Fields

CirrusMD allows the following fields as standard segmentation fields. This means that they are natively available to the data team, and subsequently, client reporting. Please work with your Account Manager if you need help fitting your desired segmentation fields into this standard. All of these fields are optional in a membership info file.

• Customer Type

• LOB

• Group Id

• Group Name

• Payer Plan

• Medical Plan Description

• Medical Plan Type

• Medical Provider

• Behavioral Provider

• Subscriber Relationship

• Relationship Code

• Ethnicity Code

• County

• Gender

• Gender Identity

• Medical Enrollment

• Medical Eligibility

• Behavioral Enrollment

• Behavioral Eligibility

• Patient Utilization Category

Metadata

CirrusMD has a unique capability in that the membership info file provider may pass any field to CirrusMD and we will ingest that field as reporting metadata if that field does not map to a column outlined in the Available Fields dictionary. If there is a match on an external id already found within our system, this reporting metadata will also be visible to providers during an encounter.

This data is stamped onto the patient record through an upsert process where we will add metadata, or update it, based on what is present in the eligibility file. This also means that the data does not need to be passed every time, as once it is upserted it is not removed.

Change Files

By default, all files are considered change files. Even when providing a full population, we check the provided data against what has been provided in the past and only apply changes to our systems. We also support termination by absence. This means that if you wish to terminate an individual you may leave them off the file and we will update their expiry date to yesterday, effectively terminating their access to our systems. If you wish to leverage termination by absence, please let your implementation or account manager know as the default behavior is not to leverage termination by absence and to assume you will pass us an expiry date.

How to update a member’s info, and set expiry

You terminate a user’s membership by importing a membership info file with the Expiry Date for the user set to the date on which you want their membership to terminate. Setting it to any date in the past will terminate their membership immediately. You may also set their expiry date to any date in the future, at which time their access will be terminated. It’s acceptable (and recommended) to include these records in your usual file upload.

If you are leveraging termination by absence, we assume that anyone not on the eligibility file should be terminated. We will set the termination date to the prior day.

Please note, that you may turn on termination by absence at any time, post-implementation. If this is enabled post-implementation, termination by absence will run slightly differently the first time. Instead of setting the expiry date to yesterday, the termination date will be set to the earlier of either yesterday or the first of the month following the last time we received data on the individual. For example, if the last time we received data on an individual was 3/22/2020 - their termination date would be set to 4/1/2020 as that is earlier than the current date.

File Delivery

Eligibility Files are expected to be uploaded to an SFTP server (FTP over SSH).

File Name Requirements

Every file must follow a consistent location and naming pattern such as /my_folder/My_Program_YYYYMMDD.csv. The file must be placed in the same folder on a scheduled basis (The root/directory is acceptable.) We recommend a static prefix like My_Program_ in the example. The suffix changes based on the current date. The file extension must remain static.

SFTP Server Setup

CirrusMD will create an SFTP server for your exclusive use. The server meets healthcare compliance standards including restricted access and data encrypted at rest. You must provide CirrusMD with an ssh public key. Password authentication is not possible. An IT admin can easily generate ssh keys following these instructions. When generated, protect the private key like a password and do not share with CirrusMD. The public key may be sent to CirrusMD over insecure means such as email. CirrusMD will provide you with a username.

Frequency

Please send a new file weekly or monthly. If you wish to send files on a different cadence, please speak with your account manager. CirrusMD polls SFTP servers at least once at the end of every business day. If we find a new file, we will process it. New files take 1-2 business days to import into our system. If you require a rush import that is quicker than 1-2 business days, please contact your account manager. You may be charged professional service fees for each rush request.

Membership Info File Launch Timeline

Generally, we want configuration and testing begun 4 weeks prior to the launch date (This ASSUMES the membership info file conforms to standard format)

• To start off, you must provide us with your ssh public key.

  • Key length must have a minimum strength of 112 bits which requires parameters of 2048.

  • Acceptable symmetric algorithms include AES-128, AES-192, AES-256, and Three-key TDEA.

• Once SFTP access is established you can upload an initial file

  • We expect the initial file to contain the actual members you want to import on the launch date. In other words, please do not send us a test file. It’s vital the External Ids are accurate in this file.

  • We also assume the file conforms to the CSV specs laid out in this document.

  • Any problems with the initial file may delay your launch.