Technical Information

VESTA- Technical Answers

  • What kind of application is VESTA?  VESTA is an ASP.NET (C# and VB.NET) web application with a Microsoft SQL Server back-end. It is used as a Homeless Management Information System (HMIS) and as a client-tracking and reporting database by social service projects. Users access VESTA across the Internet using a web browser (Internet Explorer version 7.0 or higher).
  • Is the VESTA server secure?  The Cincinnati database and the application itself are run on servers located at CyrusOne in downtown Cincinnati. The Center is monitored by camera 24 hours per day, and provides a secure, temperature-controlled environment with redundant power, redundant HVAC, and disaster recovery.  For Massachusetts VESTA uses a cloud based solution through Microsoft's Azure
  • Is VESTA reliable?  VESTA’s availability has been 99.6% over the years. Scheduled outages for system upgrades are limited to times most convenient for users.
  • Who has access to data in VESTA?  Only authorized users of VESTA have access to any part of the application. VESTA has several layers of security that impact who can log in to VESTA, what data they can see, and which tasks they can do while logged in. 
  • What is required to gain access to VESTA?  In order to access VESTA a user must have:
    • A User Set-Up form signed by the Agency Director.
    • A signed VESTA User Agreement on file and documented in VESTA. This form must be signed by the User annually.
    • An on-site technical assessment of a user’s computer and work station location must be conducted and approved by PCL.
    • A one-on-one training appropriate to job function, covering an introduction to HMIS and VESTA, confidentiality and security, consent, data sharing levels, data collection and entry, and reports.
    • A username and a password which is updated every 90 days.
    • A user selected PIN and answers to security questions (to verify identity in the event of a forgotten username/password or log on from an unrecognized location.
    • At least one project affiliation.
  • What kinds of user levels are available in VESTA?  Whether or not users are permitted to access any given page in VESTA is determined by their security role/type under their current project affiliation in combination with the page’s security definition. The user’s security level must be explicitly granted prior to access to any secure page.
  • How do data-sharing partnerships work?  Partnerships between projects are set up to share selected data about clients when projects participating in the partnership have determined that sharing data will help them to better serve their clients’ needs. Interagency sharing includes intake history and data about household members. Highly sensitive information about a client’s special needs (e.g. HIV status), or services that might reveal special needs (e.g. mental health services), is NEVER shared outside of the originating agency.
  • How does client consent affect data sharing in VESTA?
    • Clients have the right to consent to data sharing and are provided with a consent option at every intake.  With consent, basic client information is shared system-wide to assist with finding a client as they enter a new project.  Without consent the client is not found, and no data is ever shared in VESTA.
    • Data collection on clients is not optional for reporting, all clients are entered into the system even when non-consenting.  However, non-consenting client data is never shared.
    • In order to serve the client within an agency, access to data may be permitted between the projects of one agency on a "need-to-know" basis.
    • Like kinds of projects (e.g. family shelters) may share client records across agencies and their projects.  Clients are notified of that sharing at the time they elect to sign consent.
    • Even with consent, highly sensitive data (e.g. special needs data) is never shared outside of an agency.
    • Clients may revoke consent at any time.
  • What client data is shared without a sharing agreement? In order to prevent the creation of duplicate records, a user must not create a new client record without first doing a system-wide search for the client. To search the system, the user must know either the client’s social security number OR both their last name and date of birth. When searching for clients new to a project, VESTA will not ‘find’ a record for a client who does not have a valid consent on file. Clicking on a search result does not provide access to a client’s entire record.
  • How is confidentiality monitored?
    • In designing VESTA, the confidentiality and security of the data was a primary consideration. Originally, the software development team for VESTA was employed by a housing provider for people with HIV/AIDS. Our social services co-workers made it clear from the beginning that they considered data security crucial and would not consider using VESTA unless we could make it virtually ‘bullet-proof.’
    • VESTA uses Secure Sockets Layer (SSL) protocol with 128-bit encryption; this provides a highly secure, encrypted connection between our server and the user’s computer. SSL is an industry standard and is used by many websites – including banks, credit card companies, and others with highly sensitive data – in the protection of their online transactions with their customers.
    • VESTA’s security framework was reviewed by an independent computer security firm, who found that VESTA is “secure and well-structured to protect against known and unknown attacks.”
    • VESTA users are thoroughly screened and trained. In order to receive a username, and a password, a user must go through the following steps:
      • Agency Directors must sign an agreement to participate in VESTA.
      • User Set-Up forms must be signed by the Agency Director.
      • A User must sign a VESTA User Agreement form prior to access. This form must be signed annually.
      • Training is provided for the user appropriate to job function, covering an introduction to HMIS and VESTA, confidentiality and security, consent, data sharing levels, data collection and entry, and reports.