Data Integration With Vim - File-Based Integration

File-based integration allows organizations to securely share structured data with Vim via an sFTP server. Through this secure connection, structured data files are shared for each Vim application, with separate files for each app. These files follow a specified format and delivery cadence. Upon receiving a file, Vim validates and filters for invalid rows, then securely ingests the data under a dedicated namespace. As Gaps are addressed via Vim applications, Vim provides reporting passbacks to inform the data connection, facilitating accurate gaps file updates. This process ensures that the data is available, on demand, for use in Vim applications, enhancing application security and usability. This section will outline in detail the requirements and deliverables for the file-based integration between Vim and a data source.

Setting Up the sFTP Connection

The first step will be setting the sFTP connection to allow sharing files from the data source → Vim and from Vim → data source. Vim will be hosting the sFTP connection supporting public key-based authentication allowing a secure method for logging in via RSA SSH. This authentication method requires:

• RSA SSH keys: This authentication method requires a public key and private key. The public key will be shared with Vim, while the private key will use the data source to connect to the sFTP server
• IP whitelisting: Vim is allowing only identified IPs to access the sFTP server. The data source will share the IP addresses, or range of addresses, that will be allowed access to the sFTP server. Vim supports up to 20 IP addresses
• Access details: Vim will define and share with the data source the username and hosting URL for the connection To authenticate with the Vim sFTP server, the data source will use the username provided by Vim and the private key they have created. Vim will verify it with the public key The sFTP server will hold two folders:
• from Vim: All the files sent from Vim to the data source will be placed in this folder
• from <data_source_name>: All the files sent from the data source will be placed in this folder For public key-based authentication hosted by the data source, please contact a Vim representative.

Preparing Your File

A prerequisite to the integration with Vim is a generation of a file following the specifications in this section. The file should contain the data your organization wants to share with providers, structured in the outlined format to support accurate processing.

File Level Specification and Configurations

Vim supports several configurations of the file, including different formats and cadence of sharing the file, as well as configurations that would impact the ingestion logic and the data presented in the application. In the following section, you can find the details of each specification and supported configuration.

File Format and Structure

Below you can find the specifications expected and the configurations supported for the file shared with Vim including the data to be presented in the application:

• A file per gap type: Vim is expecting a separated file for diagnosis gaps and care gaps (file schema can be found below)
  • Vim also supports receiving a member eligibility file
• File naming convention: <customer_name>_<gap_type_name>_<yyyy-mm-dd>.<format>. The naming convention format will be enforced during the ingestion process, file names that are not recognized will not be ingested
• Accepted gap type names: diagnosis_gaps, care_gaps
• Accepted characters: only lowercase letters, no spaces
• File format: csv, txt, xls
  • The file can be zipped
  • Encrypted files are not supported out-of-the-box, please contact a Vim representative to support encrypted files
• File delimiter: Comma or pipe
• Encoding: UTF-8
• Cadence: Daily, weekly, or monthly to your preference

File content Ingestion Configurations

Below you can find the configurations supported by the file ingestion logic allowing you to share data in the Vim application:

Configuration	Relevant Data Set	Description	Mandatory?	Optional Configurations
Gap system	Diagnosis gaps	Allowing to define which gap type (ICD/ HCC) should be the primary gap presented in the application	Yes	HCC/ ICD/ Hybrid*
Gap model version	Diagnosis gaps	Allowing to define the default model version of the gaps shared	Yes	CMS HCC V24/ CMS HCC V28/ HHS-HCC/ RX-HCC V08/ Hybrid*
Gap status filtering	Diagnosis gaps Care gaps	Supporting filtering gaps form the display based on the gap's status	No	Indicate the statuses Vim should present in the application: Open/ In Progress/ Not Closed/ Closed
Custom fields	Diagnosis gaps Care gaps	Sharing additional specific information on the gap or patient, to be presented in the application Supporting up to 3 fields	No	Details to be provided per custom field: the title of the field to be present in the app, the entity the custom filed relates to (patient or gap), the type of the field (date, string, integer, decimal, URL)
Additional CPT code or descriptions	Care gaps	Vim's default mapping can be enhanced to add additional CPT codes or descriptions	No	Yes - provide your mapping enhancements No - use Vim's default mapping

• Hybrid: when more than one option is expected to be sent in the file. In that case the gap configuration should be specified in the file per gap in the appropriate field as indicated in the "data fields" sections

Required Data Fields Row Level Specifications

The received file is expected in the following structure and fields. Each data type (diagnosis gaps, care gaps) will require a separated file following the specifications below.

Diagnosis Gaps File Schema

This table outlines the expected file schema, accepted data types, and field names that will be provided to Vim for ingestion Diagnosis Gaps data and display in the application:

Field Name	Description	Required?	Type	Valid Values/Format	UI display	Example
patient_first_name	The patient's first name	Required	String	Letters only, up to 50 characters	TRUE	John
patient_last_name	The patient's last name	Required	String	Letters only, up to 50 characters	TRUE	Doe
unique_patient_id	An internal identifier shared by the customer that uniquely identifies a patient in the file	Required	String	Letters + digits, up to 50 characters	FALSE	1234qwer
patient_dob	The patient's date of birth	Required	Date	YYYY-MM-DD	TRUE	1990-07-19
patient_insurance_id	The id of the patient in the health plan (member/ subscriber_id)	Required - at least one of these fields is required	String	Up to 50 characters	FALSE	123445455
ehr_patient_id	The patient's EHR unique identifier	Optional - once one field is shared	String	Up to 50 characters	FALSE	a1b2c3d4
patient_zip_code	The patient's Zip code	String	xxxxx/xxxxx-xxxx/xxxxxxxxx	FALSE	90210
patient_insurer	The patient's insurance company	Optional	String	Up to 50 characters	FALSE	United Health Care
patient_state	The patient's US state	Optional	String	US states codes only	FALSE	FL
gap_id	An ID that identifies a unique gap per gap code and patient	Required	String	Up to 50 characters	FALSE	1234567890
gap_system	Defining the primary gap code presented in app	Required for Hybrid files	Enum	HCC/ICD	FALSE	HCC
hcc_code	The HCC gap code to present	Required	String	CMS codes only	TRUE	18
hcc_description	Description of the HCC code	Optional	String	Up to 250 characters	TRUE	Diabetes with chronic complications
icd_code	The ICD code to present	Required for ICD system, Optional for HCC	String	CMS codes only	TRUE	E11.21
icd_description	Description of ICD code	Required for ICD system, Optional for HCC	String	Up to 250 characters	TRUE	DM with nephropathy
hcc_model_version	Specific HCC model version if CMS	Required for Hybrid, Optional otherwise	Enum	CMS-HCC V24/V28/HHS-HCC/RX-HCC V08	TRUE	CMS-HCC V24
gap_background	Previously coded vs suspected diagnosis	Optional	Enum	KNOWN/SUSPECTED	TRUE	KNOWN
gap_status	Gap's status for filtering	Optional	Enum	OPEN/IN PROGRESS/NOT CLOSED/CLOSED	FALSE	OPEN
gap_raf_score	Risk adjustment factor	Optional	Numeric	Not accepting "-"	TRUE	2.659
gap_source	Source of the gap	Optional	String	Up to 250 characters	TRUE	2024 claims
last_recorded_dos	Most recent recorded date	Optional	Date	YYYY-MM-DD	TRUE	1990-07-19
last_recorded_npi	NPI of most recent provider	Optional	Numeric	10 digits	TRUE	1234567890
last_recorded_npi_name	Name of most recent provider	Optional	String	Up to 100, letters only	TRUE	John Smith
notes	Additional gap information	Optional	String	Up to 250 characters	TRUE	Please address all suggested gaps
custom_field_1_value	Additional custom information	Optional	As configured	As configured	TRUE	2.51
custom_field_2_value	Additional custom information	Optional	As configured	As configured	TRUE	-
custom_field_3_value	Additional custom information	Optional	As configured	As configured	TRUE	-

Care Gaps Data Schema

This table outlines the expected file schema, accepted data types, and field names that will be provided to Vim for ingestion Care Gaps data and display in the application:

Field Name	Description	Required?	Type	Valid Values/Format	UI display	Example
patient_first_name	The patient's first name	Required	String	Letters only, up to 50 characters	TRUE	John
patient_last_name	The patient's last name	Required	String	Letters only, up to 50 characters	TRUE	Doe
unique_patient_id	Internal patient identifier	Required	String	Letters + digits, up to 50 characters	FALSE	1234qwer
patient_dob	Patient's date of birth	Required	Date	YYYY-MM-DD	TRUE	1990-07-19
patient_insurance_id	Health plan member ID	Required - at least one	String	Up to 50 characters	FALSE	123445455
ehr_patient_id	EHR patient identifier	Optional after one required	String	Up to 50 characters	FALSE	a1b2c3d4
patient_zip_code	Patient's zip code	String	xxxxx/xxxxx-xxxx/xxxxxxxxx	FALSE	90210
patient_insurer	Insurance company	Optional	String	Up to 50 characters	FALSE	United Health Care
patient_state	US state	Optional	String	US states codes only	FALSE	FL
gap_type	Care gap category	Optional	Enum	Customer provided list *Will be available in early Q2 2025	TRUE	HEDIS
gap_id	Unique gap identifier	Required	String	Up to 50 characters	FALSE	1234567890
gap_code	Gap code	At least one required	String	-	TRUE	18
gap_display_name	Gap description	String	Up to 250
cpt_II_code	Recommended CPT II code associated with the gap	Optional	String	Up to 100, letters only	TRUE	John Doe
cpt_II_description	Recommended CPT II description associated with the gap	Optional	String	Up to 100, letters only	TRUE	Most recent systolic BP less than 130 mm Hg
gap_status	The gap's status, allowing to filter the gaps displayed in the UI according to the desired status	Optional	Enum	open, not closed, closed, in progress	FALSE	open
gap_source	The gap's source	Optional	String	Up to 250	TRUE	2021 claims
collection_date	Date in which the prior values were documented	Optional	Numeric	YYYY-MM-DD	TRUE	1234567890
required_action	The action that should be taken by the healthcare provider	Optional	Numeric	Not accepting "-"	TRUE	2.659
last_recorded_dos	Most recent recorded date of the diagnosis being coded by a provider	Optional	Date	YYYY-MM-DD	TRUE	1990-07-19
last_recorded_npi	NPI of the most recent coding provider	Optional	Numeric	10 digits	TRUE	1234567890
last_recorded_npi_name	Name of the most recent coding provider	Optional	String	Up to 100, letters only	TRUE	John Doe
notes	Additional information related to the gap	Optional	String	Up to 250	TRUE	Please address all suggested gaps
custom_field_1_value	Additional customized information	Optional	As configured	As configured	TRUE	2.51
custom_field_2_value	Additional customized information	Optional	As configured	As configured	TRUE	-
custom_field_3_value	Additional customized information	Optional	As configured	As configured	TRUE	-

How Data Will Be Presented in the Application

Some of the fields sent in the files will be presented in the UI, below you can find the data that will presented in the Care Insights application:

Diagnosis Gaps Data

Care Gaps Data

File Ingestion Process

Vim's ingestion process will ingest the latest file received via sFTP with the configured file name. This is a full refresh process where the new data entirely replaces the old data, without introducing downtime. The process will not allow partial ingestion when the process has not been completed successfully.

Data Validations

As part of the ingestion process Vim is validating the file received. Upon a file rejection, the data will not be ingested and Vim will contact the data connection to notify the issue and resolution path. A file will not be ingested upon:

1. Ingestion process will not start when the file was not received in the expected format, naming convention or delimiter
2. The file is empty
3. The file does not include headers
4. Changes in the file schema: new columns, deleted columns, changes to column name, changes to column type or changes in column order
5. The data type deviates from the definitions in the BRD
6. The file size is 60% lower/higher than the previous file

During the ingestion process, Vim is validating that all the data entries meet the requirements. Data entries that will not meet the requirements will be excluded and will not be visible to the end user. These rows will be added to a gating file, which will be sent back to the customer via the SFTP connection. Rows will be excluded upon:

1. Any required fields are empty
2. At least one of these three fields are missing: member_id, ehr_patient_identifier, zip_code
3. The unique patient ID or gap ID are not unique (all duplicated rows will be excluded)

Failed Gaps Gating File

A gating file, indicating rows with violations that were not ingested, will be shared following every ingestion (daily). The file will include the rows that were rejected along with the reason for the row rejection.

Feedback Loop

Vim tracks user actions and sends structured feedback passback to the customer for reporting and data updates, allowing the data source to monitor and update the gaps that were addressed. Feedback files are shared through the same sFTP connection.

File Format and Structure

1. File name: <CUSTOMERNAME>YYYY_MM_DD__HH_MM_SS<diagnosis/quality>_gaps_report
2. File type: CSV
3. File delimiter: Comma or pipe, where pipe is the default
4. Cadence: Daily, weekly or monthly to your preference
   • Recommended - in alignment with the cadence of the gaps files send - daily if a refresh file is sent from the customer on a daily basis
5. Coverage timeframe: Day, week, or month to your preference
   • Recommended - according to the cadence of the gaps files send - if the files refreshes daily, sharing the passback daily to share data on the past day
6. Sending time: A time at the end of the working day of the customers, to capture all the actions of the past day to your preference
   • The configuration of the sending time should take into account the sFTP sync processes

Shared Data Fields

The feedback passback format below applies to both gaps data sets and will be sent separately for each diagnosis and/or care gaps data:

Field Name	Description	Required?	Type	Example Diagnosis Gaps	Example Care Gaps
organization_name	The user's in session organization's name as defined in the Vim system	Required	varchar	Scott's Clinic	Scott's Clinic
vim_organization_key	The unique organization ID as available in the Vim system	Required	varchar	8i7owzgbgo6zJHYNxkNLRc	8i7owzgbgo6zJHYNxkNLRc
user_first_name	The user's in session first name as defined in the Vim system	Optional	varchar	Scott	Scott
user_last_name	The user's in session last name as defined in the Vim system	Optional	varchar	Cohen	Cohen
ehr_username	The user's in session EHR username	Optional	varchar	scott.cohen	scott.cohen
user_npi	The user's in session National Provider Identifier (NPI)	Optional	varchar(10)	8495738475	8495738475
encounter_id	The ID of the patient's EHR encounter which is in context during the session	Optional	varchar	859574	859574
encounter_date	The date of the patient's EHR encounter which is in context during the session (according to the organization's timezone)	Optional	Date (YYYY-MM-DD)	2023-10-17	2023-10-17
gap_system	The type of gaps presented in the application Shared only for Diagnosis Gaps	Required	varchar	hcc	N/A
gap_id	The unique ID of the gap selected during the session	Required	varchar	32fn48f	347g4rg
gap_code	The code of the gap selected during the session	Required	varchar	82	CBP
gap_description	The description of the gap selected during the session	Optional	varchar	Assess Drug Dependence	Controlling Blood Pressure
selected_medical_codes	The medical code(s) selected during the session	Optional	varchar
action_date	The date of the reported action (EST)	Required	date (YYYY-MM-DD)	2023-10-19	2023-10-19
action_type	The type of the reported action	Required	text	accept	dismiss
action_reason	The reason of the reported action	Optional	varchar	ADD	EVALUATE_NEXT_VISIT
action_additional_comments	The free text added by the user for the reported action. Available only for the "dismiss" action_type	Optional	varchar	not seen today
patient_customer_id	The unique customer internal patient identifier received by the customer	Required	varchar	738463	738463

Testing the Integration

Vim supports the data source with the ability to perform end to end testing of the integration on Vim's mock EHR. If you wish to perform end to end testing in lower environments, please contact a vim representative.

Recommended: to be able to perform a production verification of the integration prior to the rollout, Vim supports adding dummy patients to the production file. A dummy patient should include the word "test" in the patient's first or last name.

Monitoring and Support

Vim is committed to knowledge and identify the root cause upon file ingestion failure within 24 hours from ingestion process start (excluding weekends).

For questions or technical assistance, contact Vim's Support Team at [email protected].