MPHASIS
Mutual Progress on Homelessness through Advancing
and Strengthening Information Systems
Funded by EUROPEAN COMMISSION
Employment, Social Affairs and Equal Opportunities DG
Pilot of the LINK Client Record System in Hungary
Fehér Boróka
June 2009
Research and action of the MPHASIS project are funded by the European Commission - Employment, Social Affairs and Equal Opportunities DG under the employment and social solidarity programme known as PROGRESS (VS/2007/0617 SI2.483181).
Main contractor:
Town and Regional Planning University of Dundee
Nethergate
Dundee, DD1 4HN
Scotland, United Kingdom
Contact Details:
Bill Edgar: [email protected] Barbara Illsley : [email protected] Volker Busch-Geertsema: [email protected] Matt Harrison: [email protected] Peter Watson: [email protected]
Author Contact Details:
Fehér Boróka (BMSZKI Budapest Methodological Centre of Social Policy):
The contents of this report do not necessarily reflect the opinion or position of the European Commission, Directorate-General for Employment, Social Affairs and Equal Opportunities
Table of contents
1 Introduction ... 4
2 Research brief... 4
2.1 Transferability of Good Practice in relation to Client Record systems... 4
2.2 Aims and Objectives... 5
2.3 Methodology... 5
3 Report on experimenting with the Link system in Hungary ... 5
3.1 Phase 1 (May 2008 – November 2008)... 5
3.2 Phase 2 (December 2008 – January 2009) ... 9
3.3 Phase 3 (February – March 2009) ... 10
3.4 Summary of evaluation... 13
1 Introduction
This report covers the trial of the Link online client recording system used in the UK and Ireland to record work carried out by homelessness providers in a time-limited pilot in Budapest, Hungary. Research work (fieldwork, training, evaluation and analysis) was carried out by Fehér Boróka, from BMSZKI, Budapest, Hungary.
This research is part of the MPHASIS project, funded by the European Commission PROGRESS initiative, to take forward a series of recommendations made in the EU Measuring Homelessness Report (Edgar et al, 2007). The main recommendations of this research were as follows:
1. Preparation of a National Homelessness Monitoring Information Strategy in consultation with all the relevant Ministries and stakeholders;
2. Identifying (or establishing) a mechanism or coordination agency for data collection on homelessness;
3. Adopting a shared definition of living situations and homelessness, as a basic framework for data collection;
4. Adopting a series of core standard variables to employ for data collection purposes; 5. Adopting a national definition of the services for homelessness;
6. Establishing and maintaining a directory of services;
7. Ensuring that funds for homeless service providers entail the provision of basic (anonymised) data on clients and the allocation of funds to facilitate the procedure; 8. Establishing a strategy for the collection of data starting from service provider
registration systems;
9. Ensuring the added value of data collection for services and the homeless. This study focuses on recommendations 7, 8 and 9 above, and looks at how an existing client recording system developed in one national context can be transferred to another country and considers how barriers of translation, IT differences, training, support and operational issues might be overcome.
2 Research brief
2.1 Transferability of Good Practice in relation to Client Record Systems
The EU Measuring Homelessness Report (2007) described (and gave guideline costs for) three main options to implement Client Record Systems. These included the option where:
● central government funds the development of specific software which is provided free to agencies that receive public funding, a requirement of which is to provide relevant information on clients in the prescribed format;
● data extract modules and protocols are developed to allow the extraction of the required client information (i.e. the core variables) from existing service management information software systems provided by commercial software companies;
● an existing homeless client recording system software is adapted and used in different member state situations.
The MPHASIS Project provided an opportunity to consider practical issues associated with the third of these options. Research was commissioned into the adaptation of the Link
system used in the UK and Ireland in two distinct national situations, Hungary and Sweden, in order to provide more detailed understanding of the implementation issues in different types of member states.
The Link software is a web-based client record system used in London to record the work carried out with people sleeping rough in London and also used by a number of service providers in London. The Link system is also used in Dublin and Cork in Ireland across the network of service providers in each city.
2.2 Aims
The study aims to:
1. Evaluate the Link system in relation to the particular issues in Hungary and the existing situation of NGO data collection
2. Assess the implementation issues and potential barriers to implementation. 3. Assess the costs associated with implementation and maintenance.
2.3 Methodology
The research sought to test the programme of implementation developed by RIS to prepare and adapt the Link system in a selected region of the country. It involved translating and adapting the Link system to Hungarian circumstances, and its trial by several service providers.
The research was carried out in three phases:
● Phase 1 (May 2008 – November 2008): mapping of existing client record systems in use by outreach teams and emergency lines in Hungary; recruiting agencies willing to try the Link system, introducing Link and its pilot Hungarian version ● Phase 2 (December 2008 – January 2009): implementation of the Link system with
5 participating agencies
● Phase 3 (February - March 2009): evaluation of the experiences of implementation, including recommendations for future action
3 Report on experimenting with the Link system in Hungary
3.1 Phase 1 (May 2008 – November 2008)
Our first task was to find out what type of data collection exists among outreach services in Hungary. Outreach services receiving statutory funding need to comply with relevant legislation (1/2000 Decree of the Ministry of Social and Family Affairs). The 12th appendix of the decree contains the guidelines for what data needs to be registered about each user.
It contains the following information: ● Date of first registration ● Registration number ● Name
● DOB
● Official address ● Actual address
● Contact person (name, address) ● Date of entry into care
● End of care, date and reasons ● Name of case worker
● Name of general practitioner
● State of health at the beginning of the relationship
● Changes in health (a table containing columns for date, recommended therapy and the signature of the doctor
● Actions (a table containing columns for date, actions and the name of the case worker)
During Phase 1, we contacted relevant agencies working with homeless people, and introduced the program to them. It was our goal to find agencies who have some form of cooperation, thus would benefit from using a shared database in their daily work. Our choice included the following projects:
● BMSZKI outreach service ● Menhely special outreach service ● Twist outreach service
● MMSZ outreach service
● Menhely emergency phone line
BMSZKI is managed by the Budapest City Council, the other agencies are all NGOs. The outreach teams work in their designated area, contacting rough sleepers and trying to help them in any problems they might have. They have a steady team, and a relatively steady group of users. The Menhely special outreach service operates not only in Budapest, but also in its suburbs. They do more emergency type of work: they visit rough sleepers who are reported to the emergency phone line, and who either live in areas where there is not outreach service operating, or they need to be checked on when the normal outreach team is not one duty. The special outreach team thus works with a wide range of users, often only meeting one person for a short while. The Menhely emergency phone line is the coordinator of all emergency work in the Budapest area as well as the suburbs – most often they do not have direct contact with users (unless a user calls for help themselves).
We then visited each agency and explained the project briefly. They were enthusiastic in taking part in the experiment, but also expressed that this would mean a double workload in administration for them. They were also interested whether the new system tested would later be made available for their use, to which we had not clear answer.
We asked them to show us the administration they use. All five agencies use a computerized database, although their effectiveness differs greatly. None of these databases are connected with each other in any way, and all of them can only be used on
the computer where the program has been uploaded. The outreach services also use paper-based databases: most services have separate folders for each user where their data is stored. In some case they store the printed version of the computer data, in some cases they manually copy the information from paper to the computer or the other way around. All services register data required by the 12th Appendix of the 1/2000 Decree, but most do not have papers signed by a doctor, nor include details of physical therapy. Generally, services do not assign case workers to each user, rather an area is teamed by 2-4 people, and
homeless people can turn to any of these staff directly.
BMSZKI and Twist outreach services use the same computerized system, called Menedék (Refuge). Menedék was developed by BMSZKI and distributed to all agencies interested in its use. It is now used in many shelters, day centres, and outreach teams in Budapest. The program records the basic data of users (name, mother's maiden name, DOB, place of birth, gender, date of first encounter, date of last lung medical check-up) and generates a ID number based on the initials and DOB. The program also records the address where the person can be found. The Actions window offers a list of actions as well as space for comments (free worded) to be added. There is a separate question regarding the user's state of health. Both services mentioned that it would be good to share some information about the users with other services using the same Menedék database system. They also thought it would be useful to access the database on-line. This would enable them to do their administrative chores from different locations, but more importantly, they could check on the client history when meeting someone in an unexpected way. Twist also uses the exact copy of the 12th Appendix on paper, as they said it is needed at monitoring visits.
MMSZ has developed its own system for registering the data of all its users. In the summer of 2008 the system was under development. This database recorded more specific private data such as tax registration number, health insurance number, retirement registration number – the answer to all these was optional. It recorded some basic data about the length of rough sleeping, the location, whether the person can be reached on the location during the day or at night, the history of rough sleeping, employment status, etc. As the program was being tested at the time, there is no information as to how it functioned yet.
Menhely special outreach also has a paper-based and a computerized database, but they record very different data. People and locations are registered in the daily logbook first, where the actions taken are also described on paper. Then there is an alphabetical list of names and a lost of locations, where the dates of the visit are added. If one wants to see what happened to a given user or at a certain location, they check the date of the (last) visits in one book, and then look up the log of the given day. The computerized version only contains the actions – no locations or names are mentioned here. This is due to the special work of this agency: they do not work closely with any given user, but rather act upon an urgent need. The computerized database in their case was not created to help their work, rather to print reports for funding.
The work of Menhely emergency phone line is completely recorded on computers. They have the possibility to register user data (name, DOB, location) as well as add comments. They also register where the call came from, who reported on the person and why. They then refer the person to an outreach or special outreach service, recording this data as well as what the outreach team has done with the person. This way the emergency phone line does not only record its own work, but everything that happens to a certain user with their coordination.
To sum up what we have learnt about existing databases used by outreach teams and the emergency phone line:
• All of the outreach teams involved in the research use a computerized database for registering data about users and their work, which serves two purposes. Firstly, it enables them to keep track of the work done with individual users. This part of the database tends to be free worded. Secondly, it helps them compile data for their reports towards financial bodies – usually this is the part of the database that uses check-boxes, and it most cases the reports can be automatically generated. In some cases, data can be transferred into an excel spreadsheet and the report can be prepared afterwards, manually.
• All databases include the basic data of users, but most information is optional (i.e. nicknames can be used if the full name is not known, the DOB can be left empty if there is no information, etc.).
• Funding authorities check the time spent doing outreach (services are generally required to spend 30 hours per week on their territory, doing outreach), so most services record time (start of shift, end of shift) in their daily logbook.
• Search is an important feature of the databases: both search by name as well as location.
• All participating agencies would like their system to join other databases, they feel it would help their work if they could check what has been done with a given person by other agencies, who to turn to for more information.
The next step in Phase 1 included discussing the details of their taking part the pilot. Due to funding available through a different project we managed to pay participants a small sum of money for their extra work.
• 2 out of 4 staff of BMSZKI outreach agreed to participate, recording the whole work of their team.
• Shifts in Menhely special outreach are manned by 16 different individuals, who only register data on paper. There is a separate person to copy data onto a computer. This person agreed to test Link in our pilot.
• 1 staff in MMSZ took part, registering the work done during her shifts (5 days a week).
• 2 out of 2 staff in Twist outreach took part.
• All of Menhely emergency phone line staff agreed to take part in the testing. Simultaneously, we were contacted by RIS, responsible for preparing the Hungarian version of Link. We studied the demo version of Link available on-line to see a good example of what can done with the use of such a system. We then collected the common points recorded by most agencies and/or required by the 12th Appendix of the Decree 1/2000. We have agreed on using the following core variables:
● Name: Family name (first) Surname (second) ● Date of birth: yyyy/mm/dd
● Sex
● Address (location, where person can be found): district (##)_street name_house number
● Composition of household (single/couple/in a group, etc) ● Risk status
● Health status
● When did he become a rough sleeper? ● Date of admission (first encounter) ● Type of income
● Contacts with any other service ● Service-history
● Reason for homelessness ● Action type
We decided to omit one core variable mentioned in the Mphasis Synthesis Report, country of birth, as it is not a relevant issue in the Hungarian context.
The following step included defining what Field types to use for each variable among Client details. For those variables where a list of answers could be given, we had to name those options. Among actions, we had to define Types as well as Actions. We decided which answers were obligatory and which could be left answered for a later encounter. When the first version of the pilot was ready, we asked participants to give it a try and see what they have thought, what needed to be changed before the real testing started on December 1st, 2008.
3.2 Phase 2 (December 2008 – January 2009)
We visited each team and presented Link to them on-line. We registered imaginary users to see how it operates. We also prepared a five-page long written guideline on how to use Link, which people could turn to if they were not sure how certain features worked. They could turn to the coordinator if any questions arose, as well as make suggestions on the way.
Unfortunately due to the limitations of funding, the testing had to be finished by mid-January. This was not the most ideal time for such a work, partly as it included two weeks of holidays (when most outreach teams would be working on limited shifts only and when normal working hours are interrupted by longer breaks). The first two weeks of January were extremely cold (with temperatures dropping below -10 C˚ every night), which gave much more work to participating agencies, allowing them less time to experiment with Link at ease.
● BMSZKI outreach agreed to register data on a daily basis.
● The administrator of Menhely special outreach agreed to register data on a bi-weekly basis. However, due to the extreme weather conditions and difficulties adapting to the peculiarities of Link, the actual administration took longer than planned.
● MMSZ outreach agreed to register data a on a daily basis. ● Twist outreach agreed to register data on a daily basis.
Registering data on-line on a daily basis is by no means the standard functioning of all outreach services. As in some cases it is the paper-based registration that is more important for their daily work, while the computer-based on is more for reports and monitoring, some teams only put data in the computer on a bi-weekly or even monthly basis (using warmer, calmer days for doing their administration). This way, participating in the project required more discipline, but also more work hours.
3.3 Phase 3 (February – March 2009) Evaluation and recommendation for future
action
We asked testers to write down their thoughts and experiences with Link, using specific examples where possible. Then we organized a meeting where people could discuss, exchange ideas, and make proposals on how to improve Link in the future.
Strengths of Link
● All services commented positively on the sharing of information. They thought it was useful that when they met a person they could see if any other service had done any work with them. They also thought it would be even better if all agencies used the same system, and they could check what happened to their client in a different service, whether day centre or night shelter.
● For certain staff accessing the system on different computers, on-line, was a bonus. The extra work required by Link did not always fit in their normal work hours, and some people enjoyed reaching the service from other locations.
● Some people mentioned that it was useful to have the detailed search function. Most Hungarian databases can only do search by name or location, DOB or gender, but not, for example, based on action, or a few letters from the name.
● Having a box for nicknames (and being able to search by them) was also thought a good feature.
● Most outreach services thought that Link was useful for getting an overview of what actions were carried out with a given user and when. They were less positive about the input of data.
● All services thought that such a system would be ideal especially if they had a portable computer, both for checking on people as well as doing the administration simultaneously with the action. In the case of the Special Outreach team it would mean liberating the person whose task is administration at the moment to do other things.
Weaknesses of Link
● The biggest weakness, mentioned by almost everyone, is that it is client-based: one can register data only after writing the name and DOB of the user – both are pieces of information that are not always accessible on a first encounter. If this was a rare problem, the suggestion of RIS would be a solution: calling people Anonym
Anonym, and giving their DOB as 01.01.1900. However, in many cases one or both pieces of information were missing. Some felt registering a fake DOB could be a
solution, but only if there was some indication that this was not factual information. The same was thought for people who give their year of birth, but not the month and the date.
● Part of the work of the outreach teams is mapping their terrain. They reported that they could not record these actions in Link, as they could only record actions connected to a concrete person. The same was true for when they visited someone, who was not at „home”, or when they found a human dwelling, with no person there at that moment.
● The emergency phone line reported, that they usually receive phone calls about homeless people anonymously. A typical call would be: „There is a middle aged man lying on the ground, he does not have any blanket”. Registering such a call (where neither the name, nor the DOB is known) is difficult. If they do register the person as Anonym Anonym with a fake DOB, they can correct data once they get more information, but it takes considerably more time than with their current program. (IN some case, the program asks for the location first, and then offers the names of all known users in the given address. In other cases, the unfinished entry can stay visible on the screen, waiting to be edited and closed.)
How Link could be improved in the Hungarian context
● Some people felt that the Client details section includes data thought to be
permanent but in fact changing. One such variable was Address or Location: many rough sleepers are constantly on the move, or have a few dwellings where they can be found. Testers felt that previous or alternative addresses should be recorded and visible.
● They also suggested that the history of Client details should be made available: for example it would be useful to know what the history of the person's income, or health status was – if there are changes during the support, it should be possible to follow those changes.
● People recommended adding a free text window at Health Status where long-term (semi)permanent problems could be added, such as „one leg amputated”, „chronic diabetes”, AIDS, TB, etc. On the other hand they were concerned that this might be classified as sensitive data by Hungarian legislation, so it might be illegal to store such information on-line, where it is visible for other services as well.
● They also felt there should be a free text window for „Veszélyzetető tényezők” (Risks)
● Many people expressed that recording data took a long time. They felt it would be simpler and faster if more than one actions (or sub actions) could be chosen at a given time. One specific example was Material Help, where they suggested all of the items listed could be chosen at once. Another Action was Transportation – often users have to be driven to different services until they reach their final destination. It would make administration simpler if more than one services could be chosen, and the whole story would be added by one screen.
● Other thought it would be good if the program generated an ID number
automatically, but not based on the initials and DOB. Often the DOB is not known at the first registration of the person, registering the true DOB now means a change in the ID number as well.
● Some people recommended adding a feature that would allow for Actions to be transferred to another person or a group. When outreach workers visit a group and provide the same type of support, it would help if they did not have to find each person separately and add every action again. There could be an additional screen which would show all other people registered on the same address, for example. ● People complained that as they usually register data the day after the actual events
(working into the evening), it would be useful if the date offered would be the date used for the previous data entry. This would save a lot of extra mouse clicking. ● It would be useful to add sub-actions (outcomes?) into the detailed search window
– for example to find someone the service have taken to a certain medical centre. ● They had a request about Action History – they felt it would be useful to see all the
details of the actions, not just the main categories.
● Some testers reported that they could not register taking the same person to two different medical centres during the same day.
● People suggested adding location (address) to the basic search surface, as they often do not remember a person's name after the first few meetings.
● Testers recommended that DOB become an optional data field. If it remains obligatory, either there should be a function to mark that the DOB given is a fake one (a blinking window, for example), or even better, the program should create a DOB and remember it is not authentic.
● The same was suggested for all other obligatory fields – there should be an option to mark that the data registered is not the final one, information is missing.
● Certain staff asked if it was possible to add „Date of next visit planned” among the Actions. This would be especially useful it the program then could generate a list of people/location for any day, thus helping to plan the shift.
● One service mentioned that they are required to measure time spent with outreach, and thought it would be good to add time with each Action. (They also thought this would be best if administration could happen sort of simultaneously with the action, so the time would be generated automatically.) Adding the time of the action would also help in seeing what happened when – now when we see Action History, Actions get shown alphabetically. It would be useful to check on
referral? Why did they not speak to the person if they visited him? (because it was 11 PM and they did not want to wake him up).
3.4 Summary of evaluation
To sum up, testers were enthusiastic about an on-line data system where they can share information with other services. The outreach teams and the special outreach found Link useful when registering the data of known users and the actions carried out with them. They had problems when registering non-user specific work (such as mapping, visiting dwellings where no one was at home), or when registering a user whom they did not have adequate information about. The emergency phone line, on the other hand, usually receives calls about people whose personal details are unknown, in their case registering data right in Link was not practical. However, even they benefited from sharing information with the outreach teams this way. Both types of services gave technical recommendations as to how the Hungarian version of Link could be improved and be made more user friendly.
4 Recommendations for future action
From our pilot, it seems obvious that there is a need among services for sharing
information, maybe even using similar programs for storing data about users. Even though each agency already uses some type of computer-based program, staff welcome the idea of a web-based surface where information can be exchanged, and users can be helped more efficiently. In our pilot, testers did not have access to reports or other administrative functions (such as reports on staff activity), but we think those features of Link would be an additional incentive to spread its use.
The testing has shed light on certain weaknesses of Link in the Hungarian context that would have to be improved to make its use easier and more efficient. It would be useful if developers sat down with staff directly to listen to their views and concerns, and find solutions that satisfy both sides.
We believe that Link could not only be used by outreach teams but medical centers for the homeless, shelters and day centers as well. Even though in its current form it is not the most adequate tool for the emergency phone line, they would also like to have access to the information gathered and stored in the database.
One potential disincentive we see is that most agencies have developed their own program or have already bought one that they use in the recent years, in some cases in 2008. In certain cases these programs are not only used by homeless services but with other target groups as well. While agencies probably see the benefit of sharing information with each other, they could think it was a waste of resources to abandon using a program already paid for. They would be more enthusiastic if the data already in their database could be
transmitted to Link.
