Demographic Fields Support Detail

• Many (although not all) Registration fields can be updated using VSC. These can be updated in athenaPractice or in athenaFlow. If you have a different PM, an HL7 ADT message file can be sent to that system.
• VSC supports the ability to update the following basic demographic fields: Title, First Name, Middle Name, Last Name, Suffix, Social Security Number, Sex, Address fields 1 and 2, City, State, Zip Code, Home Phone, Cell Phone, Work Phone, Email, Preferred Contact Method, Primary Language, Ethnicity, up to 2 Races, and Marital Status.
• For some of these fields (such as Marital Status), only certain values will be accepted. These items are best handled by a drop-down list (or check boxes or radio buttons), which can default to the previous value if there is one.
• These items can only accept the following values without Milbrook Integration Kit modification. Race, Ethnicity, and Contact by have additional support through tables in the VSC database as long as they are properly mapped to an external ID. Note that VSC is still unable to support Ethnicity and Race "Subcategory" values, as athenahealth does not allow those values to be updated in the database via HL7 messaging:
  1. Sex: Male, Female, Undetermined
  2. Ethnicity: Hispanic or Latino, Not Hispanic or Latino, Undetermined
  3. Race: White, Black or African American, Asian, American Indian or Alaska Native, Native Hawaiian or Pacific Islander, Other
  4. Marital Status: Single, Married, Divorced, Separated, Widowed, Other
  5. Preferred Contact Method (note LinkLogic IXP file pid40contactby also needed to make this work): Pager, Cell Phone, Durable Power of Attorney, Email, Fax, Home Phone, Letter, Nursing Home, Work Phone, Paper, Other
  6. Primary Language: there are many values that are accepted here. We recommend a drop-down list containing the languages you expect to see at your site with additional languages added as necessary.

Additional demographic fields that are supported.

 Please carefully read the documentation regarding these additional fields. While the capability to have patients update many of these fields exists, it is not recommended in most cases as it may have unintended consequences. Updating of the additional fields is limited by the capabilities of LinkLogic. Logical Innovations recommends that current patient information be displayed and patients either see a staff member if their current information is not correct or have the patient enter new information on the document but have staff manually enter new information into Registration. Staff will be able to see these changes in Reconciliation. All demographic updates made by patients must be confirmed by a staff member in Reconciliation before they are sent to Registration via an HL7 file. NOTE: When manually updating items in Registration while viewing VSC Reconciliation, you must Save & Exit Registration in the EMR before finishing Reconciliation, otherwise you run the risk of losing the changes VSC might make.

Please reach out to Logical Innovations Support with any questions.




1. Insurance

   Ability to display and update the following fields for Primary and Secondary Insurance: Insurance Name, Insurance Group, Insurance ID, Insurance Group Name, Insurance Address (including City, State, and Zip).
1. If a patient enters Primary or Secondary Insurance information and that information is brought into Registration via LinkLogic, LinkLogic will attempt to match the information entered by the patient to an Insurance company already in the system. Matching is based on the name of the insurance company, the first line of the address, the zip code, the Policy Group, and the Policy Number (Insured ID). If these items match, the patient will be assigned the Insurance Company already in the database. If they don't match, a new insurance company will be created. Moreover, the patient's old insurance company won't be removed, only demoted (e.g. moved from primary to secondary). Although athenahealth documentation does not indicate that the Policy Group and Policy Number are required, Logical Innovations has found that Insurance Information sent via HL7 message will not update properly if the Group is not included. If the Policy Number is not included or is different than previously, a new Insurance Company will be created if there is already an Insurance Company with the same name but a different Policy Number in the system.
2. If there is a match for an insurance company already in the system based on the name, first line of the address, and zip code, and other information entered by the patient (second line of address, city, state) does not match, those fields will be overwritten in the database with the information entered by the patient.
3. Insurance Companies already in the database have "External IDs". However, as these IDs are not known to the patient or VSC, when an HL7 file containing insurance information entered by the patient is brought in through LinkLogic, a warning that no external ID was entered for the insurance company will be seen. However, the file will import. [Note: These external IDs would be found in the MIKIdMap table. It is likely that most Insurance companies are not mapped. This could be confirmed using the MIK mapping tool.]
4. The Insurance Group Name can be displayed, but can't be updated via an HL7 message. This is a limitation of the system, as documented by athenahealth in their Managing Interfaces document.
5. Changing the Insurance Group (Policy Group) via an HL7 message will create a new Insurance Company. This does not appear to be true if the Insurance group is changed through the UI.
6. Changing an Insurance ID (Insured ID) via an HL7 message will create a new Insurance Company. This does not appear to be true if the Insurance group is changed through the UI.



2. Policy Holder (aka Insured Person)

   Ability to display and update (in some cases) the following fields for Primary and Secondary Insurance Policies: Is Policy Holder Patient, Is Policy Holder the Guarantor, Policy Holder First Name, Policy Holder Last Name, Policy Holder Address (including City, State, and Zip), Policy Holder Home Phone, Policy Holder Work Phone, Policy Holder Date of Birth, Policy Holder SSN.
   1. Possible Choices for INSURANCE_POLICYHOLDER_IS_PATIENT are "Yes" and "No". If "Yes" is indicated, the "Insured Person Information" will be populated with the patient information.
   2. If Insured Person is patient, changes to the Insured Person's demographic information don't result in updates in Registration. Demographic information from the patient will be displayed and any changes should be made to the patient's demographic information, not to the Insured Person.
   3. If the policyholder is being updated from someone other than the Guarantor and the INSURANCE_POLICYHOLDER_IS_PATIENT is set to "No" and the INSURANCE_POLICYHOLDER_IS_GUARANTOR is set to "Yes", only the name of the Guarantor will be displayed for the policyholder and all other demographic information will be left empty. Also, the Insured Person will be set to "Other" rather than "Guarantor." This is because LinkLogic will only recognize "Patient" as a value for the Insured Person and all information related to the Insured Person (address, phone, etc.) is ignored by LinkLogic if the Insured Person is not the patient. By default, if the insured person is not the patient it will be set to "Other". This is documented by athenahealth in Managing Interfaces document.
   4. If the Insurance Policyholder is the guarantor, no changes to demographic information will result in updates to the Insurance Policyholder. Changes to the Insurance Policyholder information should be made on the Guarantor tab when the policyholder is the guarantor.
   5. If the Insurance Policyholder is the Guarantor, the Insured Policyholder can not be changed to "Other" via a HL7 file. This is a limitation of LinkLogic. The Insured Person can be changed from "Guarantor" to "Patient" or from "Patient" to "Other", but not from "Guarantor" to "Other".
   6. If the Insurance Policyholder is set to "Other" only the Name will be displayed for the Insurance Policyholder. All other information related to the Insured Person that is contained in the HL7 file (address, phone, etc.) is ignored by LinkLogic if the insured person is not the patient. This is documented by athenahealth in Managing Interfaces document.
   7. If INSURANCE_POLICYHOLDER_IS_PATIENT is set to "Yes" and the INSURANCE_POLICYHOLDER_IS_GUARANTOR is set to "Yes" but the Guarantor is not the patient, the Insurance Policyholder will be set to the Patient. The value for INSURANCE_POLICYHOLDER_IS_PATIENT will supersede INSURANCE_POLICYHOLDER_IS_GUARANTOR if there is a conflict.



3. Guarantor

   Ability to display and update the following fields: Guarantor First Name, Guarantor Middle Name, Guarantor Last Name, Is Guarantor the Patient, Guarantor Relationship, Guarantor Address (including City, State, and Zip), Guarantor Home Phone, Guarantor Work Phone, Guarantor SSN, Guarantor Sex, Guarantor Date of Birth.
   1. Guarantor Sex supports the following values: Male and Female
   2. Only a Home and Work phone are allowed for the Guarantor. This is a limitation of the system, as documented by athenahealth in Managing Interfacesdocument. Cell Phone numbers for guarantors can't be passed in HL7 messages.
   3. The only available values for GUARANTOR_IS_PATIENT are "Yes" and "No".
   4. The only available values for GUARANTOR_RELATIONSHIP are "Self" and "Other".
   5. If the choice for GUARANTOR_IS_PATIENT is "Yes" but choice for GUARANTOR_RELATIONSHIP is "Other", the Guarantor in CPS will be the patient.
   6. If the choice for GUARANTOR_IS_PATIENT is "No" but choice for GUARANTOR_RELATIONSHIP is "Self", the Guarantor in Registration will be the patient.
   7. If the Guarantor is patient, but some info entered for the Guarantor does not match the patient info (for example the address or phone # entered is different from the patient), the Guarantor info will not be changed to the alternate information; patient information will still be displayed. All changes to guarantor demographic info should be made to the patient information when the patient is the guarantor.
   8. When a patient (Patient 1) enters a new guarantor and the resulting HL7 file is imported via LinkLogic, LinkLogic will attempt to match the info entered for the guarantor to a patient/person already in the database. If there is a unique match, that patient (Patient 2) will become the guarantor for Patient 1. Only a unique first and last name are required for a match. The result may be a patient in the system (Patient 2) being listed as the guarantor for Patient 1 even if that is not the intention. Also, the system will match the guarantor to another patient/person in the database even if the data entered other than the patient name does not match that of the patient/person in the database. The result is that the guarantor (Patient 2) for Patient 1 may be linked to another patient/person in the database, but the info on Patient 1's guarantor page (such as address or phone number) will be different from that of the Patient 2.
   9. If the guarantor for a patient (Patient 1) is another patient (Patient 2) in the CPS system and guarantor info, such as an address, is updated, the info will only be updated on the guarantor tab for Patient 1 and not for the actual patient (Patient 2) who is the guarantor. The guarantor tab for Patient 1 will, however, remain linked to the patient who is the guarantor (Patient 2) and the info displayed in the two locations (guarantor tab for Patient 1 and patient tab for Patient 2) will be different.
   10. Note: There is a GUARANTOR_EMAIL, but this is not applicable to athenaPractice, as it does not capture Guarantor email information. It is only for use with athenaFlow Registration module.
   11. Note: LinkLogic will show an error if there is no Guarantor name in the GT1 segment of the HL7 message. If demographic information is being gathered on a document, but it is possible for the patient to not have a guarantor, an output specification without the GT1 segment should be considered.
   
   

4. Contacts

   Ability to display and update the following fields for up to 7 Contacts: Contact First Name, Contact Middle Name, Contact Last Name, Contract Address (including City, State, and Zip), Contact phone #, Contact relationship.
   1. When creating the template in VFE, an index # must be given to each contact.
   2. The following contact relationships are supported: Brother (B), Daughter (D), Father (F), Husband (H), Mother (M), Son (S), Wife (W), Sister (X), Other (O).
   3. Updating the address or phone number(s) for an existing contact will result in that contact's information being updated. However, if the name or relationship for a contact is updated, a new contact will be created (rather than the existing contact being updated).
   4. For Contact Phone numbers, VSC can display home, work, and cell, but only the home and work can be updated. This is a limitation of the system, as documented by athenahealth in Managing Interfaces document. Contact cell phone numbers can't be sent via HL7 messages.
   5. When phone numbers for a contact are updated, the home phone number will always be entered in the "Phone 1" slot, and the work phone number in the "Phone 2" slot. If there is any phone number in the "Phone 3" slot, it will be left unchanged. Note again that this is a limitation of the system and the fact that only home and work phone numbers for a contact can be passed in an HL7 message. This limitation means that if a patient has a cell phone in the second slot and the home phone is changed, the cell phone will be overwritten. If there is a work phone in the third slot, it would result in duplication of the work phone. Staff should be thoroughly familiar with these limitations and how updating of Contact phone numbers is handled by LinkLogic before putting the updating of Contact phone numbers into practice.
      
   6. There is a CONTACT_EMAIL item, but this is not applicable to athenaPractice. It is only for use with athenaFlow. athenaPractice does not have a field for Contact email information.
   
   

5. Pharmacy

   Ability to display and update the Name, Address (including City, State, and Zip) and Phone # for a primary and secondary pharmacy.
   1. CAUTION If a patient enters pharmacy information and that information does not exactly match the information for a pharmacy already in your system (with the exception of the phone number), a new pharmacy will be created in the system. Furthermore, if there is a match, phone and fax information for a Pharmacy already in your system may be overwritten. This may cause confusion for staff and lead to issues with e-Prescribing. For these reasons, Logical Innovations recommends only displaying current Pharmacy information for your patients to verify but having staff enter new/changes to Pharmacy information into the system. However, because some customers have requested the ability, VSC does allow patients to create/update pharmacy information if a site chooses to use that feature.
   2. Any change to the Name, Line 1 of the Address, the City, State, or Zip of the Pharmacy by the user will create a new Pharmacy. Updating the phone number or Line 2 of the Address will update the current Pharmacy rather than create a new one.
   3. When updated via VSC, the phone number for the pharmacy will always come into Registration as a "Home" phone # in the "Phone 1" slot of the Pharmacy. We can only display and update that "Home" number. This is a limitation of the athenahealth interface. As documented in Managing Interfaces document, only one phone number for a pharmacy can be passed in the HL7 message, and that must be a home or work phone number. A Fax number can not be passed to the system via the HL7 message. If a patient updates the phone number for a pharmacy, it will go into the "Phone 1" slot. Any number in the "Phone 2" slot will be left unchanged. However, the type of phone in slot 2 will automatically be set to "Work" even if it was something else, such as "Fax" prior to the update. Finally, any phone number/phone type in the "Phone 3" slot will be left unchanged. Due to the idiosyncrasy of the phone interface for pharmacies, staff should thoroughly understand the way in which updating a pharmacy phone number works before deciding to include this feature in a template.
      
   
   

6. Employer

   Ability to display and update the following fields: Employer Name, Employer Address (including City, State, and Zip), Employer Phone #.
   1. CAUTION - If a patient enters employer information and that information does not exactly match the information for an employer already in the database (with the exception of the phone number), a new employer will be created. Furthermore, if there is a match, phone information for an employer already in the database may be overwritten if that entered by the patient is different. Your site may want to consider displaying employer information for patient verification but having staff actually make changes and add new employers to your system.
   2. Any change to the Name, Line 1 of the Address, the City, State, or Zip of the Employer by the user will create a new Employer. Updating the employer phone number or Line 2 of the Address will update the current Employer rather than create a new one.
   3. When updated via VSC, the phone number for an Employer will be entered into Registration as a "Home" phone # in the "Phone 1" slot of the Employer. VSC can only display and update that "Home" number. This is a limitation of the system and the athenahealth interface. As documented in the Managing Interfaces document, only one phone number for an Employer can be passed in the HL7 message. When displaying the Employer's phone number, VSC will always display the phone number in the "Phone 1" slot, regardless of type. If a patient updates the phone number for an Employer, it will go into the "Phone 1" slot. Any number in the "Phone 2" slot will be left unchanged. However, the type of phone in slot 2 will automatically be set to "Work" even if it was something else, such as "Cell" prior to the update. Due to the idiosyncrasy of the phone interface for employers, staff should thoroughly understand the way in which updating an employer phone number works before deciding to include this feature in a template.
      
   4. VSC can't update the patient's employment status. The system does not support changing that field through HL7 messaging. It must be updated via the user interface.



7. Financial Info

   Display only (athenaPractice only) - Account Balance, Account Deposit, Account Insurance Contribution, Account Patient Contribution, Last Visit Insurance Adjustment, Last Visit Insurance Allocation, Last Visit Insurance Balance, Last Visit Patient Allocation, Last Visit Patient Payment.



8. Patient Age

   Patient age can be displayed on a template.