Move-N Integration Set-up

Move-N has developed a stored procedure that allows customers to export data to a CSV file that can be placed on an SFTP server maintained by the community. FullCount can then access this CSV file on the SFTP server for processing at 6:30 AM each day. This allows customers who utilize Yardi to enter residents in their interface and have them be automatically entered into FullCount. Below are the steps to set up FullCount to receive information from the queue.

FullCount Columns Automatically Updated from Move-N without any set-up

• First Name
• Last Name
• Birthdate (if custom field exists)
• Effective Start Date
• Effective End Date (when applicable)
• Allergies (if custom field exists)
• Nutrition Orders - Diet Type (if custom fields exist)

Move-N Integration Set-up

1. Work with Move-N to identify set-up of SFTP server.

Before Interface Go-Live Back Office Set-Up

1. In the back office, on the Communities page, set up the information under the HL7 section. For HL7 facility number(s), enter a placeholder as this triggers visibility to ADT fields. 1 is an acceptable value.
2. In the back office, on the Customer Types page, confirm that there is a default value set for the resident customer type. If applicable, enter the SQL where clause that will determine if the resident should have this customer type under ADT Query. See examples below.
3. In the back office, on the Plans page, fill in the HL7 integration section. For HL7 query, enter the SQL where clause that will determine if the resident should have this meal plan. See example queries below.
4. In the back office, under the charge accounts table, set the default value column to ‘Y’ for the charge account you want to be created for the new residents. If applicable, enter the SQL where clause that will determine if the resident should have this charge account under ADT Query. See examples below.
5. In the back office, under the report groups resident table for HL7 query, enter the SQL where clause that will determine if the resident should have this report group.
6. In the back office, under the ADT field mappings table, add rows as applicable to map the fields from Move-N to FullCount. Fields with an asterisk are required. Multiple Move-N fields can be concatenated together with multiple delimiters. Any field can be shortened to a specified length. This may be used to get a customer's initial or to shorten unit and room information for apartments. Prefix or suffix values can also be added to the front or end of values received from the integration. When implemented, it is typically used for resident portal ids and passwords.
1. *Patient Id
1. ADT Field 1: patientId
2. *Charge Account Billing Id
1. ADT Field 1: patientId
3. Apartment
1. Use a combination of apartment, unit, and bed. apartment is the typical implementation unless it is not unique among care levels.
4. Resident Portal Id
1. Use combination as specified in integration document. Typical options would include lastName, firstName, birthdate.
5. Resident Portal Password
1. Use combination as specified in integration document. Typical options would include lastName, firstName, birthdate.

Apartment Mapping

1. Pull customer lists for each facility within the community. Follow the steps in https://kb.fullcount.net/howto/internal-api-pointclickcare-access to access each list and open in Excel. Combine all facilities into one list.
2. Determine apartment number to be utilized in FullCount based on what is available in Move-N.
• Confirm there are no unintended duplicates between care levels for apartment. For example, apartment 123 is in IL and 123 is in HC. If there are duplicates, look to add additional fields to make the apartment unique such as unit and bed. Note: couple will share the same apartment and those do not need to be de-duplicated.

Resident Mapping (if existing community)

1. Match row in file with resident in FullCount. This is typically accomplished by matching on last name, first name and resident id via VLOOKUP.
2. Write update statements for patient id and apartment number based on resident id. Execute on database.
• UPDATE RESIDENTS SET PATIENT_ID = '<Patient Id>', GENDER = '<Gender>', APARTMENT = '<Apartment>', PATIENT_ID_2 = '<Secondary Patient Id>', MODIFIED_BY = '<Your Username, Ex. junges>', MODIFIED_DATE = SYSDATE WHERE RESIDENT_ID = <Resident Id>;
1. Example Excel formula - =CONCATENATE("UPDATE RESIDENTS SET PATIENT_ID ='",I33,"', GENDER = '",D33,"', APARTMENT = '",G33,"', MODIFIED_BY = <YourUsername>, MODIFIED_DATE = SYSDATE WHERE RESIDENT_ID =",M33,";")
3. Determine if new effective start dates will occur for the residents due to their move-in date being before their effective start date in FullCount. If applicable, update effective start dates. Also, update effective dates on the matching resident charge account rows.
4. If switching from different billing system
• Create new resident charge account rows effective as of go-live date.
1. Set ADT_ACTIVE = 'N' on old charge account rows.
• update resident_charge_accounts set ADT_ACTIVE = 'N', MODIFIED_BY = <YourUsername>, MODIFIED_DATE = SYSDATE WHERE COMMUNITY_ID =  <CommunityId>;
2. Will need to manually update billing ids for couples in spreadsheet, since it will include individual values for all residents.
3. Use Customer Charge Account template to accomplish.
• After last billing in current billing system, update resident account rows to have new billing id and switch billing file.

1. Run query to see if any residents are active in FullCount but have not been updated. This indicates that they are not actually active. Send to customer to confirm. Based on customer response, end date resident in FullCount.
• SELECT LAST_NAME, FIRST_NAME FROM RESIDENTS WHERE PATIENT_ID IS NULL AND DELETED = 'N' AND EFFECTIVE_END_DATE IS NULL AND COMMUNITY_ID = <Community Id> AND PERSON_TYPE = 116;

Day of Interface Go-Live

1. In the back office, under the ADT Integration tab, add a row with the following information.

• System- Move-In
• Server– Contact development for this information.
• Username - Contact development for this information.
• Password - Contact development for this information. 
• Folder Name - Folder within SFTP server to access  
• Delete File - (Y/N) Should the file be deleted on the server after processing?

2. Monitor resident information being populated/updated in back office application.

After Last Month End Close with Old Billing System, if applicable

1. Update resident accounts to have new billing ids.
2. Update to new billing file format.

Example HL7 Queries

• Group residents by last name. Ex. - All residents with last names A - H have a specific plan.
• community_id = <CommunityId> and last_name < 'H'
• Group residents by level of care/billing id
• community_id = <CommunityId> and resident_id  in (select resident_id from t_resident_charge_accounts where billing_id like '<Criteria>%' and adt_active  = 'Y')
• Group residents who already have plan together (resident choice)
• community_id = <CommunityId> and resident_id in (select resident_id from t_resident_accounts ra inner join t_accounts ac on ra.account_id  = ac.account_id where ac.effective_end_date is null and ac.community_plan_id = <CommunityPlanId>)
• Group residents by apartment number
• community_id= <CommunityId> and (apartment like '<Criteria1>%' or apartment like '<Criteria2>%')
• Charge account grouping by billing id
• (resident_id in (select resident_id from t_resident_charge_accounts rca where billing_id like '<Criteria>%' and adt_active = 'Y'
  and resident_charge_account_id in (select max(resident_charge_account_id) from t_resident_charge_accounts rca2 where rca2.resident_id = rca.resident_id)))