assignment health information system in sudan

Southern Sudan Medical Journal

• Clinical Guidance
• Search SSMJ

Implementing a Routine Health Management Information System in South Sudan

[a]Director Monitoring and Evaluation Division, Ministry of Health [email protected]   

[b] Liverpool Associates in Tropical Health

[c] Health Information Systems Program

[d] Malaria Consortium/ Inter-Church Medical Assistance (IMA) World Health

South Sudan has recently acquired statehood. Planning and management of the health care system, based on evidence, requires a constant flow of information from health services. The Division of Monitoring and Evaluation (M&E) of the Ministry of Health developed the framework for the health sector of the country in 2008. At that time data were collected through surveys and assessments.

Two health system assessments conducted in 2007 (1) and 2009 (2) highlighted the absence of a working routine Health Management Information System (HMIS). An M&E Scoping Mission conducted in March 2010 (3) noted the lack of tools and procedures for data collection, the inconsistent data flow and the limited capacity for analysis and use of data for action at all levels of the system. A plan to develop the system based on the ‘3-ones’ strategy (one database, one monitoring system, one leadership) was put in place under the leadership of the Ministry of Health (MOH). The MOH has since developed, tested and refined the tools and procedures for the routine HMIS, produced a comprehensive roll out plan and started the integration of health programmes into the system.

The design of the routine HMIS tools was followed by their pre-test in Jonglei and Upper Nile States.  In these two states, the combination of appropriate tools, training and support resulted in health facilities, counties and states officers able to provide consistent and quality routine reports. While this happened in the two states, at central level tools were refined and explained to MOH programmes staff and partners staff; consensus was built on the need for collecting only the relevant data for action and the database for the South Sudan information system was developed in the District Health Information Software (DHIS). This joint approach provided the needed impulse for the health agencies to adhere to the MOH system. From February 2011, a flurry of activities happened to support M&E in states and counties including provision of equipment, printing and distribution of registers and manuals and training in HMIS and DHIS of MOH officers, partners and programmes staff.

This approach has started to pay off and the routine information system is progressing. This paper presents the path followed, challenges met, advances made, and the way forward in establishing an integrated routine HMIS in South Sudan.

South Sudan is a country coming out of more than two decades of civil war and has a history of marginalisation and under-development. Since Sudan’s independence little happened to develop the health care system or services in the South. During the conflict years health care was provided by Non-Governmental Organisations (NGOs) and Faith Based Organisations with access estimated at 20-25%. The health status of inhabitants was one of the worst in Africa. For the major part of the war, the health information system was non-existent and reduced to surveys conducted by humanitarian organizations and development partners usually for their own purposes. 

The signing of the Comprehensive Peace Agreement in 2005, which led to a referendum in 2010 and the creation of a new country in 2011, represented the start of South Sudan developing a health service again and building this from almost nothing. However, the development of a Health Management Information System (HMIS) could not happen overnight. With the MOH in its infancy there was not a coordinated approach to collect and report information from health services. Stakeholders ‘did their own thing’, created their own tools and procedures to collect, transmit and analyze data from health services to their head offices or donors. 

The newly formed MOH set about developing the health care system in line with the health policy of the Government of South Sudan, 2006-2011. Accordingly, the health care system was to be based on evidence and monitored by regular information from health services so as to guide planning and management.  In line with these principles, the MOH started the long process of developing an efficient and relevant HMIS, to provide information to each management level – health facilities, counties, states and central MOH.  The M&E framework was published in 2008 (4), but still most of the data were generated from surveys starting with the Household Survey (5) and also periodic data from health facilities, NGOs, international agencies and donors or through the MOH, using the Federal Ministry of Health (Khartoum government) procedures and indicators.

In March 2010 (6) a rapid assessment took place to assess the status of the routine HMIS – the conclusions were sobering: there was not a system in place – data collection was piecemeal and in various formats; the list of indicators for collection was not defined or not relevant; reports (when available) were often incomplete and, when completed, were not understood by the health staff.  Perhaps more importantly, there was a lack of understanding by health workers of the basic concepts of data collection, analysis and feedback.  To compound matters NGOs and donors collected their indicators more to serve their own individual purposes of reporting to donors than to reinforce the management based on evidence principle. As providers of services, and while the government was strengthening its management capabilities of the health care system, the NGO community established their information systems based on their own information needs.

As a result of the evidence of the rapid assessment the consensus was that to establish a working routine HMIS two principles were essential: simplicity and relevance. The first, simplicity, required development of uncomplicated tools to be understood and used by health staff and managers at all levels. The second principle, relevance, required understanding and responding to the information needs of health care services staff, counties and states officers, programmes, health partners, donors and the MOH.

The first step was to define what information should be collected by the routine and the non routine systems, particularly the routine system, taking into account limitations for data collection in health services and low capacity for analysis and interpretation at higher levels. Based on the M&E framework of the health sector and the capacity of health facilities staff to calculate and use the data elements, a list of indicators was defined and a simple data flow put forward. The data flow (Figure 1) follows the management lines of the health care system:

• Health facilities collect numerical indicators on paper for the County Health Department
• Counties enter data into the DHIS, calculate coverage indicators and send reports to the SMOH
• SMOH aggregate counties results and send State indicators to the central level.

NGOs operating at county level report to Counties; if operating at State level they send reports to the SMOH M&E Department. Feedback follows an inverse path: from MOH to SMOH, County Health Departments and health facilities.

Figure 1. Data flow of the routine HMIS

The implementation milestones were:                    

• The priority list of indicators, a sample one page monthly report and the quantified supervisory checklist with guidelines were developed, discussed, pretested and refined.
• Registers for all health facilities (Antenatal Care, Delivery, Outpatient Department for Adults and Children, and Expanded Programme of Immunization) were fine-tuned, so that registers contained all the information needed for the routine monthly report. Requirements for each category of health services were calculated based on activity recorded by the health mapping of 2009-2011 (7). MOH and health partners then started printing and distributing the registers.
• Training in HMIS and DHIS started at central, state and county levels, with very fast achievement of computer literacy and knowledge by MOH, state and county officers (Figure 2).
• Programmes’ staff and information were progressively integrated into the system: Malaria and Tuberculosis were the first, followed by the Expanded Programme of Immunization, Integrated Disease Surveillance and Response, and HIV.

Figure 2. County Health Officers practice their skills in HMIS and DHID during training conducted in Bor, Jonglei State in 2010, organized by IMA and the State Ministry of Health.

Six months after the start of activities, the MOH organized a review meeting (8). State and counties representatives, NGOs, UN Agencies and donors contributed their experience and helped finalise tools and discuss strategies. The main achievement was an agreed reformed list of indicators with programme data elements and the first integrated routine monthly report for all health facilities.  The report had two sections . Part 1 included all routine service indicators to measure performance of high impact services; Part 2 incorporated information on communicable diseases relevant for the Integrated Disease Surveillance and Response division, on drugs for the pharmaceuticals directorate and of vaccinations and vaccines for the Expanded Programme of Immunization.  

Major organizational challenges were discussed to look for solutions:

• How to improve data flow and ensure that counties and states were not bypassed.
• How to integrate all reports (programmes, NGOs, donors) into the MOH system to reduce duplication and workload to health facilities and counties’ staff and still get all information needed for action.
• How to improve the deficit of equipment and tools in rural areas and capacity of and support for the M &E officers in states and counties.

Adopted Solutions

• Participants agreed that to maintain the flow of information without bypassing the lower management levels of the public health system (Figure 1), state and county officers had to be perceived as leaders and decision makers in HMIS/DHIS. To achieve this proficiency, an intensive training programme was prepared and implemented: MOH, state and county officers were trained by experts in HMIS and DHIS while other health partners trained programmes, health facilities and NGOs staff[e]. HMIS and DHIS manuals were finalized and shared (9). Preliminary training materials have been developed and a basic training curriculum agreed with the SMOH officers. Feedback and performance reports have been defined. The result is best expressed by the comments of one of the SMOH M&E Directors quoted in Box 1.
• The MOH and partners have purchased and distributed equipment to reach all counties. IT equipment has been sent and installed to state capitals and most are operative, although the budget for recurrent expenses in M&E still needs to be addressed, to ensure autonomy of the M&E Department in each state.

Figure 3. John Mading, Director of M&E of Lakes States installs DHIS in his laptop with the support of the M&E Directors of Warrap, Western Bahr El Gazal, Unity and Upper Nile states, September 2011.

The implementing of a routine HMIS from scratch is challenging but possible. The system requires tools and procedures but also an enthusiastic, motivated and proficient team who understands the value of data for planners and managers. South Sudan has professionals in the public health care system who are working to make the routine HMIS a reality and to implement the mandate of the Government of a system based on evidence. While there are still challenges ahead there is also measurable progress. This is a joint effort between stakeholders in which negotiation and pragmatism are key concepts.

What’s next?

• Complete the printing and distribution of registers so that all health facilities have data collection tools.
• Provide a small allocation of funds to M&E departments in states and counties for printing essentials (toner and paper), fuel for the generator and/or visits to the counties to collect reports.
• Continue delivering training to SMOH officers so they can in turn start training their fellow colleagues in states and counties.
• Proceed with integration of programmes into the system and with the integration of staff into the South Sudan M&E Team.
• Support the central HMIS Unit in Juba to undertake a country wide monitoring function.
• Ensure that the information collected is used to improve service provision and the health of the people of South Sudan.
• Rajkotia Yogesh, Stephanie Boulenger, and Willa Pressman. July 2007. Southern Sudan Health System Assessment. Bethesda, MD: Health Systems 20/20 project, Abt Associates Inc
• Ministry of Health, March 2009. Assessment of South Sudan Health System Performance. Program of Technical Assistance to Health Priorities of South Sudan, Liverpool Associates in Tropical Health.
• Carmen M. Camino, William Vargas and Joe Valadez, March 2010. M&E Scoping Mission, Program of Technical Assistance to Health Priorities of South Sudan, Liverpool Associates in Tropical Health.
• Division of Monitoring and Evaluation, Ministry of Health, Republic of South Sudan: The Monitoring and Evaluation Framework for the health care system of South Sudan, 2009.
• Southern Sudan Household Survey report, 2006.
• Ministry of Health, Division of Monitoring and Evaluation: Health Facilities Mapping report, 2009-2011.
• Division of Monitoring and Evaluation of the Ministry of Health, February 2011: Report of the review of tools and procedures of the routine HMIS.

Mohamed Ali and Norah Stoops N: DHIS Foundation and DHIS Advanced Training Manuals for South Sudan Health Care System. 2011.

[e] Liverpool Associates for Tropical Health (LATH)-  Health Information Systems Programme (HISP) and Inter-Church Medical Assistance (IMA) World Health trained MOH and SMOH officers, South Sudan AIDs commission and programmes staff; IMA World Health focused on Upper Nile and Jonglei states staff; WHO supported training of the Epidemiological Surveillance Officers; Basic Services Fund (BSF) of NGO staff and counties where they operate; Norwegian People’s Aid (NPA) is assisting Central and Eastern Equatoria; Warrap State has trained county staff with support from UNICEF and WHO.

More from the February 2012 issue

Privacy | Terms of Use | Site Map | Accessibility | RSS

Copyright 2010-2022 The Author(s), distributed under the terms of CC BY-NC . Disclaimer

CMS website by Maple Design Ltd

• Emergency responses
• Central and East Africa
• West Africa
• Blogs and news

Decrease font size. Reset font size. Increase font size.

Strengthening Health Information Surveillance: Implementing Community-Based Surveillance in Sudan

•  Download

This case study explores the 2018–22 implementation of a national community-based surveillance (CBS) programme in Sudan. The programme was designed to meet critical needs of the existing health surveillance system. It aimed to empower communities to detect and contain public health threats, improve relations between communities and their local health system, and involve villages in rural areas. Federal, state, and locality (district) staff attended CBS workshops before recruiting and training community volunteers. Over 8,000 volunteers across 11 states were recruited. The volunteers alerted staff to priority syndromes for communicable diseases as well as local events with public health implications (e.g., natural disasters, conflict-induced displacement, food insecurity). Lessons learnt can be used to increase understanding of large-scale CBS programmes and to identify opportunities to strengthen new and existing programmes. For more social science guidance on CBS, see our companion: Key Considerations: Community-Based Surveillance in Public Health .

The challenge: strengthening health information surveillance in Sudan

Community-based surveillance (CBS) involves engaging community members to systematically collect and report health information from within their communities. The information is used for public health surveillance purposes to prompt a rapid response.

The World Health Organization (WHO) has supported Sudan’s Ministry of Health to implement a national CBS programme to address the acute health information shortage in rural areas. It also contributes to the recent push across the African region to help countries meet their international reporting requirements to control epidemics and meet other global health priorities.

Sudan’s CBS programme is designed to meet several critical needs of Sudan’s existing health surveillance system. These include the gap in information reporting from two-thirds of public health facilities and a perceived deficit in trust in local health systems. 1 , 2 Both issues are most acute for rural populations due to the long history of government focus on the capital and centre of the country, and armed conflicts in peripheral areas.

Sudan’s CBS programme

In 2016, Sudan’s Ministry of Health’s Surveillance and Information Directorate (SID) started a new country-wide programme of event-based surveillance (EBS) to rapidly capture and interpret information about events that are a potential risk to public health. This involved creating new national and state structures to act on priority information. The information could come from non-health and non-government partners or from existing outreach initiatives, such as a call centre with a free hotline for the public to report emergency health concerns. The EBS programme was intended to complement the passive detection of epidemic information from the one-third of public health facilities participating in a sentinel surveillance programme. 1

In 2018, a CBS programme was introduced in 11 of the country’s 26 states as part of the broader EBS programme. CBS was the largest component of the EBS programme and had specific funding from the WHO and other donors (Sudan Humanitarian Fund, Central Emergency Response Fund, and disaster assistance departments of the USA, Qatar, Japan, and Italy).

The CBS programme started with a concept note written in September 2018 that highlighted the need for CBS to help Sudan fulfil its international commitments to the Integrated Disease Surveillance and Response (IDSR) in Africa, and to the global elimination of key diseases such as Guinea worm. The concept note also outlined the importance of CBS as a means of addressing Sudan’s history of predictable and multiple disease outbreaks and surveillance system gaps. 3 , 4

The CBS programme implementation started with a pilot project in December 2018 in the states of White Nile (Alsalam and Aljabalin localities) and Red Sea (Tokar and Sinkat localities). These sites were selected for the high prevalence of diseases and the perceived high quality of their health information systems. Another factor in their selection was the potential challenge of operationalising the concept of ‘community participation’ in these populations, given several large populations of internally displaced persons and refugees in White Nile, and politically marginalised populations in Red Sea. The aims of the pilot were to assess the performance of community volunteers in identifying events and how the events were reported upwards.

By 2021, the CBS programme had gained sufficient policy traction and resources to become one of the key channels monitored for health information alongside other sources (e.g., point of entry screening by border control officers; early warning, alert and response (EWAR) monitoring from settlements for refugees and internally displaced persons; case-based surveillance and contact-tracing during specific outbreaks) and specific disease control programmes (e.g., antimicrobial resistance).

Vision and aims

The CBS programme’s vision was to strengthen a community- and locality-level surveillance system run by local volunteers. The programme aimed to empower communities to detect and contain public health threats, improve relations between communities and their local health system, and involve villages in rural, inaccessible, and remote areas. Community participation in surveillance was noted to be crucial as it was often missing in existing programmes.

Staff and volunteer training

The CBS programme staff, drawn from surveillance departments in the federal and state Ministries of Health, attended two-day training workshops in November 2018. The 48 staff learned about the programme, its rationale, and channels of reporting. The workshops also covered recruitment criteria for community volunteers, and expectations and materials for future training in the state localities.

CBS focal persons (‘supervisors’) were identified from existing staff in public health departments at the locality level. They attended one-day workshops that covered the programme rationale, community engagement strategies, and reporting expectations. These staff then identified and trained the community volunteers.

Three approaches were used to identify volunteers. The main approach was to use existing networks of community volunteers who had been involved in previous health programmes. Community leaders ( shiyukh ) were also asked to identify individuals considered to be respectable and acceptable in society, and who would be able to interact intensively with the community; these volunteers did not need to be able to read or write. Finally, communities were asked to nominate trained health workers who were un- or under-employed. These included midwives, paramedical professionals, health inspectors, and lab technicians.

Priority diseases to identify in the community

The CBS programme was an extension of the national surveillance system for communicable and non-communicable diseases. Volunteers were asked to help identify 26 diseases and syndromes, including vaccine-preventable diseases, malaria, neglected tropical diseases, malnutrition, and reproductive health issues. Six syndromes were prioritised: acute diarrheal syndrome; acute haemorrhagic fever syndrome; acute jaundice syndrome; acute neurological syndrome; acute respiratory syndrome, and Guinea worm disease. Suspected COVID-19 cases were also prioritised during the pandemic.

Volunteers could also raise concerns about specific local priorities, such as food insecurity, flooding, or the broader needs of people recently displaced from fighting. In these situations, CBS supervisors reported them using flexible definitions for ‘unusual events’.

The response so far

Volunteer recruitment.

Between November 2018 and the end of 2020, 8,310 volunteers were recruited across 7,183 villages in 11 of Sudan’s 26 states. People who attended training workshops in White Nile and Red Sea reported that most CBS volunteers were health workers with existing community-based roles, unemployed health workers, or older men from the general community.

Information sharing

Most volunteers reported events verbally (face-to-face or via a phone call or text message) to their CBS supervisor in the locality. Volunteer monitoring booklets were occasionally used. These included a checklist of syndromes and space to include information on the timing and location of reported risk events.

The CBS supervisors then collated and evaluated the information about reported events through direct visits to the suspected area (when necessary) and submitted written reports to state-level staff. The reports were then shared with the preparedness and response departments at the state and federal levels to take action through their channels.

Impact of staffing constraints

Most event reporting happened promptly. There was, however, high turnover among CBS staff at all levels, often related to the multiple changes of government following the end of the military dictatorship in 2019 and a military coup in 2021. 5 This sometimes affected both work plans and relationship building, potentially impeding surveillance.

At the state level, all surveillance work typically fell to between one and three people. Staff members generally prioritised the CBS programme over other EBS-related duties – such as encouraging event reporting from non-health partners in animal health, agriculture, police, climate, and media – because of the complexity in relationship-building required. CBS was also sometimes prioritised over engaging staff at non-sentinel health facilities because of a perception that health facilities are often not geographically and financially accessible for people in many areas of Sudan.

Assessments of the CBS programme have focused on the system’s ability to achieve early warning and response; this includes the performance of community volunteers and their supervisors.

Overall, communication channels in each state have reportedly been characterised as very good; for example, they have been credited with containing an outbreak of acute watery diarrhoea in White Nile. In states dealing with large humanitarian emergencies, such as South Kordofan, reporting has been less reliable.

At the community level, little information has been collected on how CBS volunteers complete their work to source information and make reporting decisions. A small evaluation of 26 volunteers found that most (18) had reported at least one event of public health importance. These events tended to be biological threats (infectious diseases), while a few were social (forced displacement). In general, volunteers became aware of events during social gatherings or via personal contacts and observations.

Lessons learnt

The implementation of the CBS programme in Sudan can be used to increase understanding of large-scale CBS programmes and identify opportunities to strengthen new and existing programmes.

Use existing resources or assets

When implementing CBS programmes, opportunities to collaborate with existing programmes should be explored. In Sudan, for instance, there was feedback that people, knowledge, and equipment from the country’s established Guinea worm eradication programme could have been shared and integrated for mutual benefit. However, when incorporating CBS into existing state and local structures, it is important to consider the impact of the additional workload on staff and the structures themselves. In Sudan, for example, the supervisory workload associated with CBS largely overtook the time people had to support other EBS functions.

Provide feedback to volunteers

The CBS programme relies on volunteers. Programmes should consider how to engage with volunteers over time to keep them motivated and prepared, and to ensure volunteers are not overworked. Volunteers should be provided with feedback on the information they have provided.

Enhance diversity in volunteer pool and community group relationships

Volunteers were mainly individuals with prior related experience or were un- or under-employed health workers. These volunteers tended to have high literacy and familiarity with biomedical reporting categories, and this helped with the training and supervision as well as in actual reporting.

The CBS concept, however, emphasises the importance of diversity. Having a diverse group of people participating as volunteers to identify health threats can help reach vulnerable populations, avoid stigma, and address equity in employment practices. Volunteer recruitment practices should therefore encourage diversity. Supervisors should also consider encouraging volunteers to cultivate good relationships and spend time with diverse population groups in their communities; this can enhance trust and information sharing.

Engage with communities when designing a CBS programme

The CBS programme aimed to build participation and trust in the local health system. Community engagement dynamics are complex and change over time, and there is a limited evidence base on community engagement in CBS. Future work and research could build on the following experiences in Sudan:

• Building in a flexible reporting category about ‘unusual events’ is potentially a good way to be responsive to community priorities, though the responses required may exceed the experience and mandate of staff in Ministry of Health roles. This underscores the importance of building and maintaining relationships with non-health actors for both ad hoc reporting of public health threats as well as for responding appropriately to them.
• Training programmes should consider incorporating a dialogue with communities to learn about specific local contexts, phrases, and words used in the community to describe priority diseases and other health-related concerns, and the circumstances of different social groups. This can help tailor the training and CBS reporting practices to the local environment.
• CBS programme designers should consider how communities view CBS reporting and address any sociopolitical threats that reporting could pose to certain populations.
• Programmes should plan how to work with volunteers to discuss the potential problem of health service mistrust and to develop creative strategies to overcome this.

Provide additional supervisory support during crises

The large-scale political insecurity in Sudan in 2023 is likely to further increase workload pressures on CBS staff at all levels of government and in communities. This insecurity may also make both information communication and response much harder. Public health needs may also be expected to grow. As described in our related briefing Key Considerations: Community-Based Surveillance in Public Health , where possible, increase opportunities for supervisory support to adapt approaches when needed, and consider targeting resources to communities most affected by armed conflict.

Acknowledgements

This case study was prepared by Mariam Sharif (PhD candidate), École des Hautes Études en Sciences Sociales (EHESS) and SSHAP fellow, Rasha Ahmed, SSHAP fellow, Diane Duclos, London School of Hygiene and Tropical Medicine (LSHTM), and Jennifer Palmer (LSHTM), with contributions from Elrofaay Abdelazeam Mohammed Eltaib and Aisha Yousif Rdwan Mohammed at the Sudan Federal Ministry of Health, Sara Omer Makki Mohamed Ahmed from the WHO Sudan office, and several supervisors and volunteers of the CBS programme in White Nile and Red Sea States. It was reviewed by Ruwan Ratnayake (LSHTM), Maysoon Dahab (LSHTM) and Luisa Enria (LSHTM) and edited by Harriet MacLehose (SSHAP editorial team).

Research and writing were co-funded by SSHAP and a grant to the LSHTM by the Centers for Disease Control and Prevention (CDC) of the United States’ Department of Health and Human Services (HHS) as part of financial assistance award U01GH002319. The contents are those of the author(s) and do not necessarily represent the official views of, nor an endorsement, by CDC/HHS, or the US Government. This brief is the responsibility of SSHAP.

If you have a direct request concerning the brief, tools, additional technical expertise or remote analysis, or should you like to be considered for the network of advisers, please contact the Social Science in Humanitarian Action Platform by emailing Annie Lowden ( [email protected] ) or Juliet Bedford ( [email protected] ).

The Social Science in Humanitarian Action is a partnership between the Institute of Development Studies (IDS) , Anthrologica , CRCF Senegal , Gulu University , Le Groupe d’Etudes Sur Les Conflits Et La Sécurité Humaine (GEC-SH) , the London School of Hygiene and Tropical Medicine (LSHTM) , the University of Ibadan , the University of Juba , and the Sierra Leone Urban Research Centre . This work was supported by the UK Foreign, Commonwealth & Development Office and Wellcome 225449/Z/22/Z. The views expressed are those of the authors and do not necessarily reflect those of the funders, or the views or policies of the project partners.

Keep in touch

Twitter:  @SSHAP_Action

Email:  [email protected]

Website:  www.socialscienceinaction.org

Newsletter:  SSHAP newsletter

Suggested citation : Sharif, M.; Ahmed, R.; Duclos, D. and Palmer, J. (2023) Strengthening Health Information Surveillance: Implementing Community-Based Surveillance in Sudan. Social Science In Humanitarian Action (SSHAP) DOI: www.doi.org/10.19088/SSHAP.2023.011

Published May 2023

© Institute of Development Studies 2023

This is an Open Access paper distributed under the terms of the Creative Commons Attribution 4.0 International licence (CC BY) , which permits unrestricted use, distribution, and reproduction in any medium, provided the original authors and source are credited and any modifications or adaptations are indicated.

• Malik, E. M., Abdullah, A. I., Mohammed, S. A., Bashir, A. A., Ibrahim, R., Abdalla, A. M., Osman, M. M., Mahmoud, T. A., Alkhidir, M. A., Elgorashi, S. G., Alzain, M. A., Mohamed, O. E., Ismaiel, I. M., Fadelmula, H. F., Magboul, B. A. A., Habibi, M., Sadek, M., Aboushady, A., & Lane, C. (2022). Structure, functions, performance and gaps of event-based surveillance (EBS) in Sudan, 2021: A cross-sectional review. Globalization and Health , 18 (1), 98. https://doi.org/10.1186/s12992-022-00886-6
• WHO Eastern Mediterranean. (2018, November 19). WHO steps up efforts to establish community-based surveillance in Sudan . http://www.emro.who.int/sdn/sudan-news/community-based-surveillance.html
• Malik, E. M., & Khalafalla, O. (2004). Malaria in Sudan: Past, present and the future. Gezira Journal of Health Sciences , 1 (1). http://journals.uofg.edu.sd/index.php/gjhs/article/view/158
• Charani, E., Cunnington, A. J., Yousif, A. H. A., Seed Ahmed, M., Ahmed, A. E. M., Babiker, S., Badri, S., Buytaert, W., Crawford, M. A., Elbashir, M. I., Elhag, K., Elsiddig, K. E., Hakim, N., Johnson, M. R., Miras, A. D., Swar, M. O., Templeton, M. R., & Taylor-Robinson, S. D. (2019). In transition: Current health challenges and priorities in Sudan. BMJ Global Health , 4 (4), e001723. https://doi.org/10.1136/bmjgh-2019-001723
• Osman, A. K., Ibrahim, M., Elsheikh, M., Karrar, K., & Salih, H. (2021). Saving the fundaments: Impact of a military coup on the Sudan health system. Sudan Journal of Medical Sciences (SJMS) , 567–574. https://doi.org/10.18502/sjms.v16i4.9959

DHIS2 International Consultant for South Sudan Ministry of Health - Juba, SOUTH SUDAN

• Procurement Opportunities
• Contract Awards
• Tender Alert Service (TAS)
• Supplier Code of Conduct
• UN Standard Products and Services Code (UNSPSC)
• News and recent deployments
• The UN System of Organizations
• UN Tourism (previously UNWTO)
• The World Bank
• Samples of Specifications
• SDG Digital Investment Framework
• Joint Initiatives on Vehicles and Fleet Management
• IPS, Copenhagen, November 2023
• IPS, Copenhagen, March 2023
• IPS, Turin, November 2022
• IPS, Vienna, April 2022
• IPS, European Consortium [2], June 2021
• IPS, European Consortium [1], January 2021
• IPS, Nordic Countries, January 2021
• IPS, Argentina, November 2019
• IPS, Copenhagen, June 2019
• IPS, Rome, May 2019
• IPS, Copenhagen, November 2018
• IPS, Copenhagen, June 2018
• Spain - November 2016
• IPS, Bonn, November 2016
• "How to do Business with CPAG", Geneva 2018
• Nordic Countries, June 2016
• The Netherlands - May 2016
• Poland, November 2016
• Hungary, May 2016
• Lesotho Business Seminar
• The Gambia virtual business seminar
• Burundi virtual business seminar
• Guyana virtual business seminar
• Nordic UN Procurement Seminar 2023
• Rwanda Virtual Business Seminar
• Sierra Leone Virtual Business Seminar
• UN International Procurement Seminar March 2024
• The Republic of Zambia Virtual Business Seminar 2024
• IPS Business Seminar
• Summaries of Theses
• The Turin School of Development (TSD)
• Procurement Practitioner's Handbook
• The UN Market
• Supplier countries
• Developing countries
• Organizations
• Collaboration among UN agencies
• Sustainable procurement
• The Sustainable Procurement Indicators
• The UN Sustainable Procurement Statistics
• The Sustainability Procurement Portfolio Model
• Resources for UN staff members
• UNOPS eSourcing
• UNDP eTendering System
• Target Product Profiles
• School furniture design
• Doing business with UNOPS
• Other UN e-Learning Platforms and Courses
• The UNGM Glossary
• UN Procurement Statistics

Organizational Context

The Ministry of Health (MOH) since 2018 has been using the District Health Information System (DHIS2) as electronic health information management system for South Sudan. The DHIS2 has been scaled up to all counties and some selected health facilities in the country. There is need to strengthen and scale up the use of the DHIS2 in the country and this will entail, readjusting the current modules to be able to accommodate the changes in the data collection tools, adding modules to the existing system to make it more comprehensive in capturing HMIS data, linking the existing DHIS 2 module to other system in country to support reporting through the DHIS2.

 South Sudan has also been affected by the COVID-19 pandemic and the need for accurate data to inform the pandemic response is more acute.  The DHIS2 has been adopted by the MOH for data collection and management for the COVID-19 pandemic. The key tools particularly the case investigation forms, and case management forms have been customized into the to the COVID-19 DHIS2 Tracker. There is need to build a robust system to support the COVID -19 responses from alerts through to case investigation, case confirmation in the laboratory, case management to final outcome. The need for in country systems developer to support the customization of the DHIS2 to capture data along the cascade as well as explore and provide the opportunities to link the DHIS 2 to other systems, enhance interoperability capacity and eventually have an integrated system for the country.

Scope of work

The international consultant will work with MOH and UNDP focal points to carry out the following tasks:

• Develop an inception report with detailed work plan for providing. technical support for strengthening DHIS2 system functionality.
• Work with the technical team at the MOH to review and finalize the HIS roadmap/plan for South Sudan
• Scale up the COVID-19 DHIS2 tracker for COVID-19 surveillance in the country
• Customize all the modules into the COVID-19 DHIS2 Tracker to enable the individual case data to be captured across the cascade
• Link the COVID-19 DHIS 2 tracker to other digital systems platforms that will be identified and approved by the MOH to facilitate interoperability of the systems and enhance reporting through the DHIS2
• Customize standard reports for aggregate reporting at the various levels
• Customize the dashboards for data visualization, interpretation, and use
• Continuously update the customized tools in the system based on new changes 
• Identify and fix all the common errors in the current DHIS2 system.
• Importing and exporting data in different platforms on to the DHIS2 system.
• Upgrading of the DHIS2 system.
• Develop the DHIS 2 module and/or Integrate DHIS2 system with other systems. The systems will include but not limited to: Laboratory  management Information system (LMIS), Logistics Information management system( supply chain Management)-LIMS, e-TB system, electronic medical record (EMR) system, EWAS, IDSR, IHRIS to the District Health Information System (DHIS 2) at the MOH.
• Improve and enhance visual outputs from DHIS 2 system, using the applications like the Power Business Intelligence (Power BI) data visualization tools and ArcGIS.
• Customize the DHIS2 system to suit other demands as will be identified by the MOH. E.g. SMS messaging.
• Train and mentor at least 2 in country South Sudan national staff to support the DHIS 2 system development and scale up
• Provide mentorship and capacity building to the members of the DHIS2 Technical team.
• Perform any other related duties that will be assigned by the supervisor.

Deliverables

The consultant will be expected to submit the following deliverables:

• Inception report developed detailing:
• Design of the review/approach/workplan
• List of documents to be reviewed
• List of stakeholders to be visited
• Sample of health facilities to be visited
• Schedule of visits to partners and health facilities
• Final consultancy report describing clearly each activity performed as per scope of work and feasible recommendations including but not limited to:
• A finalized HIS roadmap/plan for South Sudan
•  A scaled up the COVID-19 DHIS2 tracker for COVID-19 surveillance in the country
• A customized all the modules into the COVID-19 DHIS2 Tracker to enable the individual case data to be captured across the cascade
• A linked the COVID-19 DHIS 2 tracker to other digital systems platforms that will be identified and approved by the MOH to facilitate interoperability of the systems and enhance reporting through the DHIS2 system.
• A customized and standard aggregated reporting tools at the various levels
• A list of identified common errors in the current DHIS2 system and train users on how to be fixed.
• An importable and exportable data forms on and to the DHIS2 system.
• A developed the DHIS 2 module and/or Integrate DHIS2 system with other systems. The systems will include but not limited to: Laboratory  management Information system (LMIS), Logistics Information management system( supply chain Management)-LIMS, e-TB system, electronic medical record (EMR) system, EWAS, IDSR, IHRIS to the District Health Information System (DHIS 2) at the MOH.
• An Improved and enhanced visual outputs from DHIS 2 system, using the applications like the Power Business Intelligence (Power BI) data visualization tools and ArcGIS.
• A customized DHIS2 system to suit other demands as will be identified by the MOH. E.g. SMS messaging.

Evaluation criteria for the International consultancy

Applicants will be evaluated based upon their submitted expressions of interest and financial proposals, which includes a cumulative analysis method based upon a combination of technical and financial evaluation results.

Individual consultants will be evaluated based on the following’s methodology:

Cumulative analysis

When using this weighted scoring method, the award of the contract shall be made to the individual consultant whose offer has been evaluated and determined as:

• Responsive/compliant/acceptable; and
• Having received the highest score out of a pre-determined set of weighted technical and financial criteria specific to the solicitation.
• Relevant Education
• Relevant Experience

* Technical Criteria weight; [70%]

* Financial Criteria weight; [30%]

To be computed as a ratio of the Proposal’s offer to the lowest price among the proposals received by UNDP.

Competencies

Corporate Competencies:

• Strong skills software development especially in digital health solutions including developing modules for the system
• Developing system interoperability functions and linking different systems to DHIS2
• Dashboard development and deployment
• Web applications design and
• Fixing bugs.
• Advanced server management: For example, restoring servers in case of a failure.
• Database management

Functional Competencies:

• Strong analytical, negotiation and communication skills, including ability to produce high quality practical advisory reports and knowledge products.
• Professional and/or academic experience in one or more of the areas of international development, public health, or related field

Project and Resource Management:

• Ability to produce high quality outputs in a timely manner while understanding and anticipating the evolving client needs.
• Strong organizational skills.
• Ability to work independently, produce high quality outputs

Communications and Advocacy:

• Strong ability to write clearly and convincingly, adapting style and content to different audiences and speak clearly and convincingly.
• Strong analytical, research and writing skills with demonstrated ability to think strategically;
• Strong inter-personal, negotiation and liaison skills
• Excellent oral and written English.

Qualifications of the Successful International Consultant

Qualifications:  

·        Advanced degree (Masters level) in a relevant field (computer science, data/information/health management, econometrics, advanced statistical analysis, information technology, and software engineering).

Experience:

·        At least five years expertise in information system management especially on web-based software platforms and database administration and Management.

·        Five years’ experience in DHIS 2 configuration for health information systems.

·        Previous work experience supporting countries in DHIS2 rollout in sub Saharan countries including experience in training DHIS 2 administrators and health information uses.

·        Previous work experience of HMIS in South Sudan will be an added advantage.

·        Excellent skills and experience in training facilitation, mentoring and capacity development

Demonstrate oral and written communication skills, including presentations.

Guidelines for Applications

Interested applicants are advised to carefully review this advertisement and ensure that they meet the requirements and qualifications described.

 Applicants are to submit:

• Signed and Updated Personal History Form (P11) or CV. The template can be downloaded from this link: http://sas.undp.org/documents/p11_personal_history_form.doc).
• Letter to UNDP Confirming Interest and Availability  

*Please note that the financial proposal is all-inclusive and shall consider various expenses incurred by the consultant/contractor during the contract period (e.g. rent of dwelling, fee, health insurance, vaccination, visa costs and any other relevant expenses related to the performance of services...). All envisaged costs (except of the unforeseen travel costs for missions, if any) must be included in the financial proposal. Unforeseen travel costs for missions, if any, will be paid separately according to UNDP rules and regulations. All envisaged travel costs must be included in the financial proposal. Per diems cannot exceed UN DSA rates (http://icsc.un.org/rootindex.asp).

Security : Individual Consultants are responsible for ensuring they have vaccinations/inoculations when travelling to certain countries, as designated by the UN Medical Director. Consultants are also required to comply with the UN security directives set forth under https://trip.dss.un.org

Incomplete applications will not be considered. Please make sure you have provided all requested materials.

Due to large number of applications we receive, we can inform only the successful candidates about the outcome or status of the selection process.

UNDP GTCs.pdf TOR for International Consultant DHIS2 - Covid.pdf Download all documents No files selected

Procurement Unit - [email protected] Email: [email protected] First name: Procurement Surname: Unit

This procurement opportunity integrates considerations for at least one sustainability indicator. However, it does not meet the requirements to be considered sustainable.

The tender contains sustainability considerations promoting health and general well-being of consumers/ recipients of the good or service.

Hazardous chemicals handling, labelling of chemicals.

Assessment of Sudan’s health information system 2020

• Create your own medbox
• Data privacy
• Legal notice

• Health Systems Stabilisation & Delivery
• Procurement, Warehousing & Distribution

Monitoring & Evaluation

• Operational Research
• Fund Management

Home » Monitoring & Evaluation

HPF supports the Ministry of Health (MoH) and implementing partners to implement and manage the national health management information system (HMIS), and works to strengthened reporting through DHIS and to improve the quality and timeliness of the data reporting from the health facilities.

HPF supports the Ministry of Health (MoH) and implementing partners (IPs) to strengthen the national health management information system (HMIS). This includes enforcing the use of the MoH DHIS for routine reporting as well as and ensuring continual improvement in the quality and timeliness of the data reported from the health facilities.

HPF collates, analyses and summaries project data from several databases to provide feedback to all IPs and inform HPF internal programmes on the progress of project implementation as well as reporting to the donors and MoH. These databases include the DHIS, pharmaceutical e-monthly reports, IP technical reports, Human Resources Information System, Supportive Supervision Reports, Quality of Care among others.

HPF collaborates with MoH in data generation through continued updating and rollout of data collection tools and training. Additionally, HPF supports MoH in data compilation, analysis, synthesis, utilisation and dissemination

Under HPF3, the project continues to emphasise high quality reporting as to facilitate compilation of strategic information to better inform the project’s direction and realise increased value for money (VFM) outcomes.

Monitoring, evaluation and reporting in HPF3 hinges on the following principles:

• Use, promote, and strengthen the use of government systems to collect data.
• M&E Ensure linkages with HPF3’s work plan, GESI, community engagement, conflict sensitivity, VFM, risk management strategy, and operations research.
• Results based program management and value for money
• Generating strategic information
• Extending reach through strategic partnerships with government, donors, NGOs, and third parties
• Continuous innovation for simplicity and compliance (completeness, accuracy and consistency).

The M&E team compromises of Montrose International specialists who work with the Ministry of Health to ensure that all data is captured and used to inform decision making in the programme. 

Using data and capacity building to enhance Sudan’s health system

As countries move towards attaining the Sustainable Development Goals (SDGs), ensuring good health and wellbeing remains a top global priority. This story highlights the contributions of two UN Volunteers to the public health system in Sudan, which is severely affected by years of underfunding. The situation is further complicated by humanitarian needs reaching record levels in the country.

Serving as a Public Health Specialist with the United Nations Development Programme (UNDP) in Khartoum, national UN Volunteer Mohamed Maher Saad works closely with the Federal Ministry of Health in data collection. He is supporting the development of a digital library which will make a health database and research available to medical personnel and students, who can also use it to publish studies and research papers.

Additionally, Mohamed is helping with the development of a mobile application called Health Pulse. This will facilitate disease surveillance and treatment, tracking of epidemic outbreaks and management of chronic diseases.

Despite the challenges Mohamed faces in his work, namely scarcity and inaccuracy of health-related data in Sudan, he is proud of being a part of these two projects and witnessing them come to life.

High-quality health data is essential for responding to specific health needs, monitoring progress and evaluating the impact of health programmes. It is vital for good public health decisions and informed policymaking. --Mohamed Maher Saad, national UN Volunteer with UNDP, Sudan

For Mohamed, serving as a UN Volunteer has been an opportunity to meet new people, discover new passions, and gain new insights about himself and the world around him. More broadly, he sees volunteering as a powerful means of engaging people in tackling development challenges. 

Volunteering brings with it a deep appreciation of all that you have in life and helping those in need is a firm reminder of what really matters. Volunteering is an experience that stays with you forever. The fulfilment that comes with helping others, the satisfaction from knowing you’ve made a difference, and the good old fun factor, are just a few reasons why once is never enough. -- Mohamed Maher Saad 

Waleed Ali Ahmed is a national UN Volunteer Planning, Monitoring and Evaluation Officer deployed by WHO with the Federal Ministry of Health in Khartoum. His assignment supports strengthening health systems and delivering training at federal and state level on issues related to the SDGs, universal health coverage, global and local challenges and other technical skills. Through these training sessions, Waleed has been able to reach more than 500 participants in various parts of the country.

I help the communities I serve by building the capacity of health care leaders to deal with crises, strengthen coordination and engage local communities. The impact of my work is tangible, as I have seen increased interaction in the health sector to improve the accessibility and affordability of health services. --Waleed Alia Ahmed, national UN Volunteer Planning, Monitoring and Evaluation Officer with WHO, Sudan

However, in Waleed’s opinion, there is still much room for improvement to address gaps in resources and the lacking technical and financial support.

On a personal level, Waleed says serving in this assignment has given him a chance to better experience Sudan, by taking him to different parts of his home country. Moreover, it has broadened his experience and knowledge, through his exchanges with partners and communities on tackling health issues.

Volunteering creates a positive impact. It allows us to help other people and share our experiences with them, while learning from them. --Waleed Ali Ahmed, national UN Volunteer with WHO, Sudan  

• youtube-play

This website benefits from the continuous support of Online Volunteers. UNV is administered by the United Nations Development Programme (UNDP).

UNV Scam Alert

UNV Privacy Policy

UNV Website Terms of Use

An official website of the United States government

The .gov means it's official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you're on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings
• Browse Titles

NCBI Bookshelf. A service of the National Library of Medicine, National Institutes of Health.

Winter A, Ammenwerth E, Haux R, et al. Health Information Systems: Technological and Management Perspectives [Internet]. 3rd edition. Cham (CH): Springer; 2023. doi: 10.1007/978-3-031-12310-8_2

Health Information Systems: Technological and Management Perspectives [Internet]. 3rd edition.

Chapter 2 basic concepts and terms.

Published online: March 22, 2023.

A common terminology is needed when dealing with information systems. Health information systems, as socio-technical subsystems of a healthcare setting, compriss data, information, and knowledge processes as well as the associated actors. They support information and knowledge logistics.

When dealing with health information systems and their architecture, we distinguish between concepts such as entities and entity types, computer-based and non-computer-based application components supporting functions, and physical data processing systems. Electronic health records ( EHR ) are parts of health information systems that collect patient health data from different health care settings. A patient record is the collection of a patient’s health data from a certain facility.

Management of health information systems includes planning, directing, and monitoring tasks.

The three-layer graph-based metamodel (3LGM 2 ) is a metamodel that supports the management of health information systems. It describes the components of health information system architectures and their relationships among each other at three layers. It consists of the domain layer to describe functions and entity types, the logical tool layer to describe application components, and the physical tool layer to describe physical tools, as well as the inter-layer relationships between the three layers.

2.1. Introduction

Health informatics specialists usually deal with ambiguous terms based in computer science, medicine, health sciences, business informatics, and related disciplines. In practice, ambiguous terms lead to difficulties and errors in communication.

One major objective of this textbook is to provide the reader with a clear terminology , i.e., a system of concepts and related terms, for health information systems and their management. Such a terminology helps health informatics students, practitioners, and scientists in specifying, describing, and communicating their objectives, tasks, and working results (Fig. 2.1 ).

Health information systems constitute an essential part of providing good health care. Agreeing on concepts and terms is the precondition for professionally managing information systems

This chapter introduces the terminology for health information systems and their management as used in this book. For describing information system architectures for health, we introduce the three-layer graph-based metamodel. It links the logical and physical tools that are used in health information systems to health care functions, which describe the tasks to be performed in certain health care settings, for example, patient admission or execution of diagnostic procedures in a hospital.

To support the learning of the terminology provided in this textbook, some of the authors have developed an ontology called SNIK (semantic network of information management in hospitals) that contains the most important concepts and terms of this book together with their relations to each other. 1 In addition, the ontology links our terminology to other terminologies from business informatics and management of information systems. This gives the reader a holistic view of the management of information systems in health and its overlap with other disciplines.

• explain the difference between data, information, and knowledge,
• define (health) information systems and their components,
• define management of information systems, and
• describe and model health information systems with the help of the three-layer graph-based metamodel.

Please note that the terms highlighted in italics are terms from the glossary or represent functions or application system types (Sects. 3.3 and 3.4 ).

2.2. Data, Information, and Knowledge

There are several definitions of data , information , and knowledge . In this chapter, we introduce pragmatic definitions which help to distinguish the three concepts from each other.

Assume a physician at Ploetzberg Hospital finds a note on her desk that says “Russo”, “8.5”, and “++”. These characters and numbers written on the note are data.

Data are characters, discrete numbers, or continuous signals to be processed in information systems.

Metadata is data about data. Metadata provides information about one or more aspects of data such as the purpose of the data, author and time of creation, used standards, or file size.

Data cannot be interpreted by a person without knowledge about the documentation context. To be reinterpretable, there must be an agreement on how data represent information.

After the physician found the note saying “Russo”, “8.5”, and “++”, she meets a nurse who tells her that the note documents the fasting blood sugar level of the patient Jakub Russo. Now the physician can interpret the note. “Jakub Russo has a fasting blood sugar level of 8.5 mmol/L” is health-related information about the patient Jakub Russo.

There is no unique definition of information. Depending on the point of view, the definition may deal with a syntactic aspect (the structure), a semantic aspect (the meaning), or a pragmatic aspect (the intention or goal of information). We want to define information as follows:

Information is a context-specific fact about entities such as events, things, persons, processes, ideas, or concepts. Information is represented by data.

What does the symbol “++” on the note mean? The physician can interpret this data because she has knowledge about blood sugar levels. She knows that fasting blood sugar levels below 5.5 mmol/L are normal, from 5.6 to 6.9 mmol/L are an indicator for prediabetes, and above 7.0 are an indicator of diabetes.

Knowledge is general information about concepts in a certain (scientific or professional) domain (e.g., knowledge about diseases or therapeutic methods) at a certain time.

Knowledge as general information contrasts with specific information about particular individuals of the domain (e.g., information about a patient). This means that, due to the physician’s general knowledge about diabetes symptoms, she can conclude that Jakub Russo suffers from diabetes, which, in turn, is information about Jakub Russo.

Although a paper note saying “Russo”, “8.5”, and “++”, and its subsequent interpretation, is not an example of systematic data, information, and knowledge processing in health care, it may be helpful to understand the difference between data, information, and knowledge.

However, in the context of health information systems and beyond, it is sometimes difficult to distinguish between the processing of data and information. Does an application system for patient administration process data or information during patient admission ? Do physicians process data or information when they make a diagnosis? Throughout this book, we use the terms “data,” “information,” and “knowledge” as precisely as possible and want to emphasize the differences between them. Therefore, the reader should be aware that we have given careful thought to the use of terms containing “data,” “information,” and “knowledge.”

2.3. Health care Settings

In accordance with the World Health Organization (WHO) [ 1 ], we regard settings as places, social contexts, or facilities where people actively use and shape the environment and thus create or solve problems. In these settings, life situations take place. Within these life situations, creating and solving problems requires and causes complex information processing .

If people actively use and shape the environment and thus create or solve problems in settings related to health care, we call these settings health care settings . Cities, villages, private homes, medical offices, hospitals, health care regions, health care facilities , and health care networks are all health care settings. And again, solving problems related to health care is essentially characterized by intensive information processing.

2.4. Systems and Subsystems

Before considering the details of information systems, let us first define the concept of a system.

A system is a set of persons, things, events, and their relationships forming an integrated whole.

We distinguish between natural systems and artificial (human-made) systems. For example, the nervous system is a typical natural system, consisting of neurons and their relationships. An artificial system is, for example, a hospital, consisting of staff, patients, relatives, and their interactions. If a (human-made) system consists of both human and technical components, it can be called a socio-technical system .

A system can be divided into subsystems that comprise a subset of the components and the relationships between them. For example, the sympathetic nervous system is a subsystem of the nervous system. A subsystem of a hospital is, for example, a ward with its staff and patients. Subsystems themselves are again systems.

For professionals, however, the term “system” is often not specific enough and needs to be refined in order to avoid misunderstandings (“If you don’t know what it is, call it a system.”).

2.5. Information Systems

Focusing on processing, storing, and providing data, information, and knowledge in settings leads to the term “information system.”

An information system is defined as that socio-technical subsystem of a setting which comprises all data, information, and knowledge processing as well as the associated human or technical actors in their respective data, information, and knowledge processing roles.

As stated above, if a (human-made) system consists of both human and technical components, it can be called a socio-technical system . But what does “socio-technical” mean when looking at the information system of a given setting? “Socio” refers to the people involved in data and information processing (e.g., health care professionals, patients, medical or health informaticians), whereas “technical” refers to tools such as computers, software, telephones, and paper-based patient records. Thus, when considering the information system of a setting, the people and tools in this setting are considered only in their role as information processors, carrying out specific actions following established rules. A physician carrying out medical admissions of patients in a hospital, for example, follows established rules for interviewing and examining the patients and documenting their answers in medical documentation and management systems ( MDMS ) .

An information system can be divided into subsystems called sub-information systems . For example, the information system of a setting can typically be split into two sub-information systems: the part where computer-based tools are used is called the computer-based sub-information system; the rest is called the non-computer-based sub-information system of the information system. Information systems of health care settings may also be divided by organizational structures (e.g., sub-information system of surgical departments or sub-information system of departments for internal medicine) or by professions (e.g., sub-information system of nursing and sub-information system of medical treatment).

2.6. Health Information Systems

Health information systems support health care professionals working in health care facilities as well as healthy or sick persons in their different life situations. The life situations as introduced in Sect. 1.2 are linked to various health care settings, such as health care facilities, where prevention , patient care , or rehabilitation are carried out. Such situations are also linked to the personal home environment, where people care for their own health or for the health of their relatives and where they solve health-related problems.

Obviously, health care cannot be considered an isolated procedure taking place in one health care facility (e.g., one hospital or one medical office). Instead, health care is a patient-oriented process encompassing prevention , diagnosis, and therapy going beyond the facilities’ boundaries and integrating the home environment. The patient-oriented care process thus takes place in networks of different actors. Such actors are, for example, hospitals, medical offices of general practitioners (GPs), pharmacies, rehabilitation centers, home care organizations, and even health insurance companies and governmental authorities. We call these networks health care networks. Health care networks can also be understood as health care settings.

With the definition of information systems in mind, a health information system can thus be easily defined:

A health information system (HIS)  is the socio-technical subsystem of a health-related setting which comprises all data, information, and knowledge processing as well as the associated human or technical actors in their respective data, information, and knowledge processing roles.

A health information system that uses computer-based data processing and communication tools is called a computer-based health information system . Please note that health information systems typically comprise both computer-based as well as non-computer-based sub-information systems.

If we refer to the information system of a certain health care facility, such as a hospital or a medical office, we can use the more specific terms “hospital information system” or “medical office information system,” respectively. The information system of a health care network can be called a transinstitutional health information system (tHIS) .

As a consequence of this definition of a health information system, a health care setting has a health information system from the beginning of its existence. Therefore, the question is not whether a health care setting should be equipped with a health information system, but rather how its performance can be enhanced, for example, by systematically managing it or by introducing state-of-the-art tools.

We will describe health information systems in more detail later in this book, especially in Chaps. 3 and 6 . In Chap. 3 , we will discuss general characteristics of health information systems. In Chap. 6 , we will discuss special characteristics that arise for information systems in specific (health care) settings.

2.7. Information Logistics in Health Information Systems

The goal of a health information system is to sufficiently enable patient care , administration, and management. For some types of health care facilities, such as university medical centers, health information systems also have to enable research and teaching.

While managing health information systems, legal and other requirements must be taken into account. Legal requirements encompass, for example, data protection or reimbursement aspects. Other requirements may result from management decisions, such as building a common EHR in a transinstitutional information system.

• It must make information, primarily about patients, available. Current information should be provided on time, at the right location, to authorized staff, and in an appropriate and usable form. For this purpose, data must be correctly collected, stored, processed, and systematically documented in order to ensure that correct, pertinent, and up-to-date patient information can be supplied, for instance, to physicians or nurses, so that they can make the right decisions.
• It must make knowledge available, for example, about diseases, side effects, and interactions of medications, to support decision-making in diagnostics and therapy.
• It must make information available about the quality of patient care and the performance and cost situation within the health care setting.

We can summarize this under the term information and knowledge logistics .

Information and knowledge logistics aims at making the right information and knowledge available at the right time, at the right place, to the right people, and in the right form so that these people can make the right decisions.

• medical offices,
• rehabilitation centers,
• nursing homes or ambulatory nursing organizations, and
• personal environments, especially patients’ homes.

Who are the “right people” to be provided with the “right information and knowledge”? Obviously, the most important people in a health care setting are the patients and, in a certain respect, their informal caregivers such as spouses or other close relatives. The most important groups of people working in health care settings are physicians, nurses, midwives, pharmacists, administrative staff, technical staff, medical informaticians, or health information management staff and managers. Large facilities, such as university medical centers, are managed by a board of directors.

Within each of these stakeholder groups, different needs and demands on the health information system may exist, depending on the role, tasks, and responsibilities (Sect. 1.3 ). Ward physicians, for example, require different information than physicians working in service units or in a medical office. Patients sometimes need similar information as physicians but in a different form.

2.8. Functions, Processes, and Entity Types in Health care Settings

In this book, we want to clearly and unambiguously describe the systems needed to ensure information and knowledge logistics. To do this, we need clear concepts to describe the information and knowledge to be provided, the situation in which it is needed, and the people involved. For this reason, we introduce the concepts of entity , entity type , function, process, and role in this section.

Entities are excerpts of the real or conceivable world.

Think back to the “Russo example” from Sect. 1.4 . After his stay in the hospital, Mr. Russo’s GP Dr. Andersson receives discharge letters from both Ploetzberg Hospital and the Kreikebohm Rehabilitation Centre. The “patient Mr. Russo” and the “discharge letter for Mr. Russo from 2020-08-15” are examples of entities.

An entity type is the set of virtual or physical entities that have certain properties in common (e.g., “discharge letter” or “patient”).

Entity types form a “unit of thought” when talking about similar entities. Thus, both the discharge letter for Mr. Russo and a discharge letter for another patient, Mrs. Smith, belong to the same entity type “discharge letter” and share the same properties such as sending date, author, and recipient.

For the sake of simplicity, we sometimes take entity types as representatives of the covered entities and their data. If, during certain information-processing activities (e.g., admitting patients), data on entities (e.g., name of patients’ hometown) is used and interpreted, we simply say that the entity type “patient” is used during administrative admission of a patient. In this sense, the entity type “discharge letter” is updated during medical discharge . We will also simply say “data on entity type X” if we mean the data describing entities of entity type X (e.g., “data on entity type ‘patient’” means data on patients).

An information- processing function is the class of similar activities which update or use entity types. Due to their similarity for all patients in a health care facility, the above-mentioned information-processing activities administrative admission and medical discharge can be considered information-processing functions.

An information-processing function (short: function ) is a directive in a health care setting on how to use data on entity types and how to update data on entity types. An information-processing function has no definitive beginning or end.

Functions are ongoing and continuous. They describe what is to be done, not how it is done. Functions describe which data on entity types are used to perform the function and which data on entity types are updated by the function.

Functions are performed by human or technical actors.

• search for (i.e., “use”) the patient’s administrative data among all instances of the entity type “patient” in the patient administration system,
• check (i.e., “use”) the patient’s administrative data which is already available if the patient has been treated in the hospital before,
• change (i.e., “update”) parts of the patient’s administrative data if, for example, the address or the insurance data has changed, and
• insert (i.e., “update”) new patient administrative data if the patient is admitted to the hospital for the first time.

Thus, we can state that the function patient admission updates and uses the entity type “patient.”

Functions are usually denoted by nouns or gerunds (i.e., words often ending with -ing or -ion), for example, care planning or patient admission .

Functions can be structured into a hierarchy of functions, where a function can be described in more detail by refined subfunctions. For example, nursing admission can be seen as a subfunction of patient admission . There are different opportunities of refining functions that are further described in Sect. 2.14 .

An activity is an instantiation of a function. For example, “the physician admits the patient Mr. Russo” is an activity of the function patient admission . In contrast to functions, activities have a definite beginning and end.

To describe how a function is performed may require not only information about its subfunctions but also information about their chronological and logical sequence. This information is described by business processes .

Business processes describe the sequence of activities together with the conditions under which they are performed.

Business processes are usually denoted by verbs which can be followed by a noun (e.g., “admitting a patient,” “planning care,” or “writing a discharge letter”).

Instances of a business process are composed of the individual activities; hence, they also have a definite beginning and end. While functions concentrate on the “what,” business processes focus on the “how” of activities. Functions can be considered representatives of business processes. For example, there is the function patient admission and the business process patient admission in a hospital. The function patient admission is specified by the entity types used and the entity types updated when a patient is admitted. The corresponding business process describes the activities of patient admission in their chronological and logical sequence.

For both functions and processes, it is necessary to know who is responsible for them or who performs them. The concept of a role summarizes all the stakeholder groups and groups of people working in health care settings.

Roles describe the sum of expectations addressed to persons or groups of persons.

Roles can also be regarded as a surrogate for the set of functions to be performed by a person or group of persons together with the resulting duties and the rights needed to perform the functions.

Typical roles in health care settings are ward physician, head nurse, project manager, or chief information officer ( CIO ).

The term “information-processing function” presented in this section is related to the term enterprise function from business informatics. Enterprise functions mainly emphasize the contribution of activities to business goals , whereas functions, in the meaning presented here, emphasize the information- processing aspects of activities.

2.9. Application Systems, Services, and Physical Data Processing Systems in Health Information Systems

Whereas functions describe what is done, we now want to look at how information, knowledge, and data processing is done. We will thus take a closer look at tools for data, information, and knowledge processing, in particular physical data processing systems and application component s.

Physical data processing systems ensure the storage, manipulation, and communication of data.

Most people would intuitively call such systems the physically touchable hardware of an information system or physical tool. Physical data processing systems are able to receive, store, forward, or purposefully manipulate data. We denote receiving, storing, forwarding, and purposefully manipulating data as data processing.

Physical data processing systems can be human actors (such as the person delivering the mail), non-computer-based physical tools (such as forms for nursing documentation, paper-based patient records, filing cabinets, or telephones), or computer systems (such as terminals, servers, personal computers (PCs), or tablets). Computer systems can be physically connected via data wires, leading to physical networks.

A physical data processing system is a physical entity that is able to receive, store, forward, or purposefully manipulate data.

For the administration of physical data processing systems that are computer systems, it can be useful to abstract from single pieces of hardware and instead focus on the optimum use of available processing power, storage, or network capacity. For this reason, the technique of hardware virtualization has found its way into data processing centers in recent years. Virtualization software can help simulate the behavior of servers, storage, and networks. Virtual servers (or virtual machines), for example, simulate the functionalities of physical servers. To install different software products which require different operating systems, virtual servers that run on one physical server can be used. By contrast, in a server cluster, different servers could alternatively, depending on their capacity, run a certain application system. The server cluster, however, can be managed as one (virtual) server.

Virtualization techniques to simulate computer systems are widely used in professional health care settings. When using the term “physical data processing systems” in this book, we include their possible implementation as simulated computer systems, i.e., as simulated physical data processing systems such as virtual machines or server clusters.

A computer system is useless without software. Software can be considered as explicit rules for processing the data in a computer system.

An application software product is an acquired or self-developed piece of software that can be installed on a computer system.

By installing and customizing an application software product on a computer system and customizing it to the users’ needs, application systems (computer-based application components) are created.

An application system is the installation of a certain application software product on a certain computer system. It supports certain functions of a health care setting or communication between other application systems and can store and communicate data on certain entity types.

Application systems may be described by the functions they support and by the features they provide. Features are functionalities offered by the application software product of the application system which directly contribute to the fulfillment of one or more functions. The finer the granularity of a function, the greater is the probability that the function semantically corresponds to a feature offered by an application system.

We denote features by a short phrase consisting of at least one verb and one noun expressing the ability of the application software product.

For example, the application system patient administration system stands for the installed application software product to support the functions patient admission and administrative discharge and billing in a hospital. It may offer the features “generate a unique patient identification number ” ( PIN ) and “provide catalog of diagnoses” in order to fulfill the functions patient admission and administrative discharge and billing . Other typical application systems are the medical documentation and management system ( MDMS ) , the computerized provider order entry ( CPOE ) system , and the picture archiving and communication system ( PACS ) . These and other application systems are discussed in more detail in Sect. 3.4 . Application systems store data in database systems. Depending on the architecture style of a health information system, each of its application systems either has its own database system or uses the database system of another application system (Sect. 3.5 ).

Even in highly computerized health care settings, not every information-processing function is supported by an application system. Sometimes, the rules for processing data are not implemented as executable application software product but as organizational rules or working plans that describe how people use certain physical data processing systems. For example, the rules regarding how, by whom, and in which context given forms for nursing documentation have to be used in a certain hospital may be described verbally as text in a handbook of this hospital. In this example, the paper-based forms that are used represent physical data processing systems. We call sets of organizational rules for data processing which are implemented by non-computer-based physical tools “non-computer-based application components.” They are often also denoted as paper-based application components .

“ Application component ” is an abstract concept for both application systems and non-computer-based application components.

An application component is a set of implemented rules which control data processing of certain physical data processing systems. It supports certain functions of a health care setting or communication between application components.

For those dealing with the management of an information system, it is important to have an overview of the information system’s application systems. However, users often do not know which application systems they are using. They are merely interested in certain features provided on a website or by an app on their smartphone. The actual application system providing these features may even be hidden from the users and invoked by another application system. We call these features that are provided by one application system for use by another application system and which are thus not immediately used by users “services.” Using a service means invoking it.

A service is an encapsulated feature provided by application systems in order to be invoked by other application systems.

Details on the most relevant tools for data, information, and knowledge processing, i.e., application components, services, and physical data processing systems, in health care settings can be found in Sect. 3.4 and the following sections.

2.10. Electronic Health Records as a Part of Health Information Systems

The most important functions of health care settings are related to prevention , diagnostics, therapy, and rehabilitation. Obviously, data and documents that are relevant to medical decision-making both in diagnostics and in therapy need to be collected and presented in a record for the patient.

Until just a few years ago (and in some cases still in the present), many documents in the records have been paper-based documents, such as laboratory results or discharge summaries. The portion of documents created and stored in computer-based application systems has increased, however, in recent years and will continue to increase further. It therefore seems natural to strive for a record that is used and updated by application systems and stored in database systems: the electronic health record ( EHR ) .

The electronic health record ( EHR ) is the collection of a person’s health data from different health care settings. It is stored by one or more application systems in a transinstitutional health information system (tHIS).

This means that the EHR for a person might be scattered physically across the database systems of multiple (discrete or interconnected) application systems at various health care facilities. Each of the database systems will hold and manage a partial EHR containing partial patient information or, to be more precise, containing data about patient-specific entity types. Each partial EHR is scoped according to the person’s stays at the health care settings which will be discussed in Sect. 3.5 .

EHRs provide relevant information about a person whenever and wherever it is needed during patient care . Furthermore, EHRs provide information that is relevant for administrative functions, such as billing and quality management .

An electronic patient record ( EPR ) is the collection of a person’s health data from one certain health care facility where the person is or has been a patient. They are stored by application systems designated for this purpose by the facility.

Some years ago, EPRs were the predominant form of electronic records in health care. Hence, potentially relevant information about the medical history of a patient that was recorded in one facility was missing or had to be recorded again in another facility. This led to quality and efficiency problems.

Although this situation can still be found in many facilities, efforts are being made today to organize EPRs as patient-centric, i.e., independent of boundaries of facilities, which will transform the multiple EPRs to one EHR for one person.

Different strategies can be found to achieve the vision of a complete and lifetime-spanning EHR that supports health care on the one hand but respects legal and ethical issues on the other. These are described further in Chap. 3 .

In the international literature, the terms EHR and EPR are usually defined as presented here. In some countries, however, the use of these terms may differ. According to the German data privacy law, for example, health insurers are obliged to provide their insured persons with the so-called electronic patient record (EPR) which contains selected patient data from different facilities. This “EPR,” in fact, corresponds more to our definition of an “EHR.”

2.11. Architecture and Infrastructure of Health Information Systems

The architecture of an information system describes its fundamental organization, represented by its components, their relationships to each other and to the environment, and by the principles guiding its design and evolution [ 2 ].

The architecture of an information system can be described by functions, business processes, application components, services and physical data processing systems, and their mutual relationships.

There may be several architectural views of an information system, e.g., a functional view looking primarily at the functions or a process view looking primarily at the business processes. Architectures that are equivalent with regard to certain characteristics can be summarized in a certain architectural style .

The set of components of the information system and services, which are centrally coordinated and provided for use throughout the health care setting, is called the infrastructure of an information system . The infrastructure of an information system consists of physical data processing systems such as servers set up centrally in a data center as well as printers and scanners made available for all users at central locations. The infrastructure may also contain logical tools such as central application systems that have to be used by most of the users throughout the health care setting. Moreover, the service desk providing support for all users in the health care setting is also part of the infrastructure. Components and services that are dedicated only to a specific department are not considered to be part of the infrastructure [ 3 ].

2.12. Management of Information Systems

Information systems need systematic management. In general, management comprises all leadership activities that determine the goals, structures, and behaviors of a setting. Management as a task includes planning , directing , and monitoring a specific object. Within a setting, management can focus on different aspects and objects of the setting. In companies, for example, a distinction is made between management of finances and management of personnel. Accordingly, there is the management of a setting’s information system.

• planning the information system and its architecture,
• directing its construction and the further development of its architecture and its operation on the basis of these plans, and
• monitoring compliance of its development and operation with the plan specifications.

The goal of managing information systems is systematic information processing that supports information and knowledge logistics and therefore contributes to the setting’s strategic goals (such as efficient patient care and high satisfaction of patients and staff in a health care setting). Management of information systems therefore directly contributes to the setting’s success and the ability to compete.

Management of information systems encompasses the management of all components of the information system—the management of functions, processes, and entity types, of application components and services, and of physical data processing systems.

Management of information systems is discussed in detail in Chap. 4 .

2.13. Modeling Information Systems

Modeling health information systems is an important precondition for their management: What we cannot describe, we usually cannot manage adequately. But what is a model?

A model is a description of what the modeler believes to be relevant about a system.

In the sciences, models commonly represent simplified depictions of reality or excerpts of it. Models are adapted to answer certain questions or to solve certain tasks. Models should be appropriate for the respective questions or tasks. This means that a model is only “good” when it is able to answer such a question or solve such a task. For example, a model that only comprises the patients (and not the nurses) of a ward cannot be used for nurse staffing and shift planning. Since we are dealing with management of information systems , this means that models should present a simplified but appropriate view of a health information system in order to support management of information systems .

• Which functions are supported by computer-based logical and physical tools?
• Which tools for data, information, and knowledge processing are used in a nursing home?
• What information is needed if a patient is to be admitted to a rehabilitation hospital? What information can be provided afterwards?
• Which functions of a hospital are affected in the event that a specific server breaks down?
• How can the quality of information processing in a regional health care network be judged?

The better a model assists its users in answering a given question, the better the model is. Thus, the selection of the adequate model depends on the problems or questions to be answered or solved.

There exists a large number of different classes of models. Each class of models is determined by a certain metamodel. A metamodel can be understood as a language for constructing models of a certain class and a guideline for using the language.

• modeling syntax and semantics (the available modeling concepts together with their meaning), i.e., the modeling language;
• the representation of the concepts (how the concepts are represented in a concrete model, for example, in a graphical way); and
• (sometimes) the modeling rules (e.g., the modeling steps), i.e., the guideline for applying the language.

Functional metamodels focus on functions (Sect. 2.8 ) that are supported in a health information system. They provide the means to describe dependencies between functions, for example, hierarchies of functions or information flows between them.

Technical metamodels are used to build models describing the tools for data, information, and knowledge processing (see, for example, application components, physical data processing systems, Sect. 2.9 ) used in a health care setting. They also help to describe data transmission or communication links between the tools. If the model comprises a graphical presentation of tools and their links, it also visualizes the architecture of a health information system. Examples of technical metamodels are technical network diagrams or application landscape diagrams.

Organizational metamodels help to describe the organizational structure of a health care setting. Organizational models typically consist of organizational units or roles and their hierarchies. Examples of organizational metamodels are organizational charts (also called organigrams).

Data and information metamodels are used for building models of the structure of data and information processed and stored inside health information systems. Their concepts are typically entity types and their relationships. Examples of data metamodels are UML class diagrams (UML = Unified Modeling Language) or entity-relationship models (ERMs).

Business process metamodels focus on a dynamic view of information processing in health care settings. They provide concepts that describe the activities to be done, their chronological and logical order, the conditions under which they are performed, and often their links to roles, organizational units, entity types, and logical or physical tools for data and information processing. Examples of business process metamodels comprise UML activity diagrams, event-driven process chains (EPCs), Petri nets, or the business process modeling and notation (BPMN) language.

Information system metamodels (also: enterprise metamodels) combine different metamodels (i.e., functional, technical, organizational, data, or business process models) into an integrated, enterprise-wide view on information processing in a facility. Examples of information system metamodels comprise the three-layer graph-based metamodel (3LGM 2 , Sect. 2.13 ), The Open Group Architecture Framework (TOGAF), the Extended Enterprise Modeling Language (EEML), or the Architecture of Integrated Information Systems (ARIS).

Define the questions or tasks to be solved by the health information system model.

Select an adequate metamodel.

Gather the information needed for modeling.

Create and validate the model.

Analyze and interpret the model (answer your questions).

Evaluate if the right metamodel was chosen, i.e., if the model was adequate to answer the questions. If not, return to step 2.

Especially step 3 of gathering the information needed for modeling is often time- and cost-intensive.

Modeling patterns which can be customized to the specific situation to be modeled can reduce the modeling effort. We call these types of models reference models . According to the metamodel used, a reference model supports the construction of models of a certain class of systems and helps to deal with a certain class of questions or tasks concerning these systems.

• the derivation of more specific models through modifications, limitations, or completions (generic reference models) or
• direct comparison of different models with the reference model concerning certain quality aspects of the modeled systems (e.g., completeness, styles of system’s architecture) (non-generic reference models).

A specific model may be considered a variant of a generic reference model developed through specialization (modifications, limitations, or completions). This variant is an instance of the metamodel that also underlies the corresponding reference model. For example, a model of the processes in a hospital information system of a specific hospital may be derived from a general reference model on health information system processes. Both the specific model and the reference model used are instances of the same business process metamodel.

A reference model should be followed by a description of its usage, for example, how specific models can be derived from the reference model or how it can be used for the purpose of comparison.

Specific models can be compared with a reference model, and consequently models can also be compared with each other, judging their similarity or difference when describing certain aspects.

Reference models can be normative in the sense that they are broadly accepted and have practical relevance. Reference models are more likely to be accepted if they are not only reliable and well-tested but also recommended by a respected institution. For example, the initiative Integrating the Health care Enterprise (IHE) (Sect. 3.7.2.5 ) provides a comprehensive set of models describing how to use communication standards such as Health Level 7 (HL7) and Digital Imaging and Communications in Medicine (DICOM) in typical health care settings. These models can be regarded as reference models. Many experts in the field use these reference models as norms or standards although they are explicitly not. These models apparently became normative because they are widely used especially in commercial invitations of tenders for software supporting radiology departments.

In the following section, we introduce the 3LGM 2 as an information system metamodel that integrates aspects of functional metamodels, technical metamodels, organizational metamodels, and data metamodels. For 3LGM 2 , there are also reference models describing certain aspects of health information systems available (Sect. 3.11.1 ).

2.14. 3LGM 2 : A Metamodel for Information System Architectures

The three-layer graph-based metamodel (3LGM 2 ) is a metamodel for modeling (health) information systems. It aims to support the systematic management of health information systems and especially the structural quality assessment of information processing in health care settings. We will use this metamodel further on in this book (especially in Chaps. 3 and 6 ) and thus present it in detail here.

• Which functions of a health care setting are supported?
• Which information is needed or updated when performing a function?
• Which application components are used and how do they communicate?
• Which physical data processing systems are used?
• Which functions are supported by which application component?
• Which application components are installed on which physical data processing systems?
• What is the overall architecture of the health information system?
• domain layer,
• logical tool layer,
• physical tool layer.

The following sections provide a user-oriented description of the three layers, complemented by examples from health information systems.

2.14.1. Domain Layer

The domain layer of a 3LGM 2 model describes what kinds of activities in a health care setting are enabled by its information system and what kind of data is stored and processed. This layer is independent of the implemented physical and logical tools for data and information processing.

Information -processing activities at a certain time and place in an information system use certain data in order to create, update, or delete other data. For example, the clerk entering Mr. Russo’s administrative data into the patient administration system when he arrives at the Kreikebohm Rehabilitation Centre creates or updates Mr. Russo’s patient data. For the sake of simplicity, we will from here on subsume creating, updating, or deleting patient data under the term “updating.”

In Sect. 2.8 , we already introduced the important concepts for the domain layer, namely entities, entity types, and information-processing functions. Entities are excerpts of the real or conceivable world, such as “patient Mr. Russo,” while an entity type (such as “patient”) is a set of virtual or physical entities that have certain properties in common. An information-processing function (short: function) is a directive in a health care setting on how to use data on entity types and how to update data on entity types (such as care planning or patient admission ). At the domain layer, we now use these concepts for health information system modeling to describe entity types, functions, and the relationships between functions and entity types performed in a health care setting.

Figure 2.2 shows an example. The function administrative admission updates the entity type “patient,” which represents a patient’s administrative data. This indicates that during the administrative admission , patient data such as name, birthdate, insurance data, and identification numbers are documented for the first time or updated. The entity type “patient” is used by the function medical admission which indicates that during a medical admission , the administrative data is available and can be used. Medical admission , in turn, updates the patient’s “medical history.” This indicates that information on the medical history is documented or updated during medical admission . Both the entity types “patient” and “medical history” are needed to create a medical care plan. Therefore, these two entity types are used by the function medical care planning . In 3LGM 2 models, functions are represented by rectangles and entity types are represented by ovals.

3LGM 22 representation of functions (represented by rectangles) and entity types (represented by ovals) at the domain layer of 3LGM 22 . An arrow pointing from a function to an entity type represents an updating access of an entity type. An arrow pointing (more...)

Functions and entity types can be structured hierarchically by “specialization” and “decomposition.” When a function or an entity type is specialized, all its sub-elements are a refinement of the function or the entity type and independent of the respective super-element. For a function, this means that the activities regarding this function are performed differently in different contexts. The function “execution of diagnostic procedures,” for example, has different specializations in different diagnostic departments. Similarly, an entity type can have different forms for slightly different purposes: A radiologic finding is different from a laboratory finding; but both are specializations of findings, which is the generalized term (Fig. 2.3 ).

3LGM 2 representation of a specialization of functions and entity types. “Execution of radiologic procedures” and “execution of laboratory procedures” are specializations of the function “execution of diagnostic (more...)

By contrast, when a function or an entity type is decomposed, all its sub-elements form a proper subset of the function or the entity type. An activity regarding a function is only completed if all activities regarding all its decomposed subfunctions are completed. For example, the activities regarding patient admission are only completed if appointment scheduling , patient identification , administrative admission , medical admission , nursing admission , and visitor and information services have been performed (Fig. 2.4 ). Similarly, a decomposed entity type is only complete when all its subordinate entity types are available. The entity type “patient,” for example, must contain a name, a PIN , the patient’s address, and insurance data.

3LGM 2 representation of a decompositions of the function patient admission and of the entity type “patient”

Both decomposition and specialization are represented by dashed arrows from sub-elements to super-elements in 3LGM 2 . For modelers, it is important to differentiate between specialization and composition at the domain layer. To avoid misunderstandings, it might be useful to predefine the use of only one hierarchical relationship for functions or entity types in one model. If this is not possible, one should at least consider that an entity type or a function cannot be specialized and decomposed at the same time.

Using relationships and updating relationships between functions and entity types are inherited to their sub-elements, no matter whether the functions or entity types were decomposed or specialized. This means, for example, that the PIN , which is a sub-element of the entity type “patient,” may be updated by the functions patient identification , administrative admission , etc. although the “update” relationship is only modeled between the super-ordinated entity type “patient” and the respective functions.

Functions are usually performed in certain parts of health care settings. The execution of radiologic procedures, for example, is performed in the radiology department of a hospital. We call those parts of health care settings “organizational units.”

An organizational unit is a part of a facility which can be defined by responsibilities.

Organizational units such as a radiology department can be decomposed, but not specialized.

Functions, entity types and organizational units are part of a static view of a health care setting. For modeling the dynamic view of health care settings, business process models are more appropriate. Which entity types and which functions of an information system are modeled depends on the health care setting and on the modeling purpose. Reference models may offer recommendations on important entity types and functions for certain kinds of hospitals.

2.14.2. Logical Tool Layer

2.14.2.1. application systems.

At the logical tool layer , application systems or, in a broader sense, application components are the center of interest. As defined in Sect. 2.9 , an application system is the installation of a certain application software product on a certain computer system. Application components as a more general concept are sets of implemented rules that control data processing of certain physical data processing systems. Application systems as well as non-computer-based application components support functions.

An application system cannot be bought in a shop but must be constructed by customizing a buyable application software product onsite. A patient administration system , for example, is implemented by an application software product offering features for appointment scheduling , patient identification , checking for readmitted patients, and administrative admission . Many application software products developed for health care facilities consist of different modules, and buyers can decide which of the modules of the application software product they purchase. Application software products for enterprise resource planning systems ( ERPS ) , for example, may offer modules for human resource management , material management , financial accounting , and customer or patient administration (Fig. 2.5 ).

3LGM 2 representation of the application system enterprise resource planning system which consists of four sub-application systems and a database system and of the paper-based “patient data privacy form system” as non-computer-based application (more...)

Non-computer-based application components are controlled by rules which we can understand as working plans describing how people use non-computer-based data processing systems to support a given function. A working plan may be available in written form in a document (e.g., in an SOP—standardized operating procedure). In most cases, however, working plans are verbal agreements or are merely specified implicitly. A non-computer-based application component for patient data privacy forms, for example, may be controlled by a working plan that describes when and how to hand out paper-based data privacy forms to the patients and where and how to archive the signed document.

Application components of an information system are objects that are recognized and used by staff members in a facility. But nevertheless, they are not tangible in the same way as physical tools are. We therefore refer to application components also as logical tools . Consequently, we call the layer describing the application components the logical tool layer. This is in contrast to the tangible tools, which we refer to as physical.

At the logical tool layer, application components are responsible for supporting functions and for storing and communicating data on certain entity types. Computer-based application components usually store data in database systems which are controlled by database management systems. Non-computer-based application components use document collections for data storage.

Both application systems as well as non-computer-based application components are represented by rounded rectangles at the logical tool layer of a 3LGM 2 model. Visually they can be distinguished by different coloring and the different symbols for database systems (cylinders) and data collections (dashed rectangles, Fig. 2.5 ).

For communication between two application systems, we distinguish between the message-oriented and the service-oriented communication paradigm, which are explained in the following sections.

2.14.2.2. Message-Oriented Communication

For message-oriented communication, application systems use communication interfaces . A communication interface can either send or receive messages over communication links. A patient administration system , for example, may communicate with an MDMS by sending messages over communication interfaces and a communication link (Fig. 2.6 ). In this example, the message may comprise information on the admission of a patient and the related administrative patient data.

3LGM 2 representation of a patient administration system’s communication interface (represented by a circle) sending messages to a medical documentation and management system’s communication interface over a communication link (represented (more...)

A message is a set of data on entities (e.g., administrative data on a given patient) that are arranged as a unit in order to be communicated between application systems. A message type describes a class of uniform messages and determines which data on which entity types is communicated by a message belonging to this message type. For example, the message type “patient administrative data” could describe how the administrative data on a patient (name, address, identification number, insurance data, etc.) must be arranged in a uniform way in order to be understood by both the patient administration system and the MDMS .

A message type can belong to a communication standard, i.e., a standard for syntactic interoperability (Sect. 3.7.1 ). There are several communication standards which describe how messages of a certain data format must be communicated between application systems. In medical informatics, Health Level 7 Version 2 (HL7 V2) and DICOM are well-known examples of such message-oriented communication standards (Sects. 3.7.2.1 and 3.7.2.4 ). Application systems have to communicate by using their interfaces to ensure that functions can use and update entity types as described at the domain layer.

The concept of a message-oriented communication paradigm may also be used to model the communication between application systems and non-computer-based application components.

2.14.2.3. Service-Oriented Communication

The service-oriented communication paradigm assumes that application systems provide encapsulated features (“services”) that can be used by other application systems. A patient administration system , for example, could offer a service “get patient” to other application systems within a health care facility. When invoking this service, an application system such as the MDMS can request and obtain the administrative patient data of a given patient from the patient administration system .

Application systems need “providing interfaces” to provide services to other application systems and “invoking interfaces” to invoke services provided by other application systems. In 3LGM 2 models, invoking interfaces are represented by circles and providing interfaces are represented by triangles (Fig. 2.7 ).

3LGM 22 representation of a situation where the patient administration system provides a service “get patient” invoked by the medical documentation and management system

Services themselves are not graphically represented at the logical tool layer but can be assigned to interfaces. Services of a similar type can be summarized in 3LGM 22 service classes.

A function can be either supported by one service or by a set of combined (“orchestrated”) services. In health information systems, the interoperability standards HL7 FHIR (Fast Health care Interoperability Resources) and open Electronic Health Record (openEHR) support the implementation of service-oriented architectures ( SOA ) .

Communication with non-computer-based application components can take different forms and is therefore considered separately.

Communication of data between two non-computer-based application components is only possible through an active human intervention, for example, by carrying a paper document from one place to another.

In a similar way, human intervention is necessary for the communication between non-computer-based application components and application systems. Scanning a paper form for archiving or typing a discharge letter which is available as an audio recording are examples of communication from a non-computer-based application component to an application system. Printing out a paper form available in the MDMS or storing radiological images on a memory device to be taken to another health facility by a patient are examples of communication from an application system to a non-computer-based application component. Figure 2.8 shows the 3LGM 2 representation of such “media breaks” between application systems and non-computer-based application components. The details of the communication should be modeled by messages (Sect. 2.14.2.2 ).

Communication between an application system and a non-computer-based application component

2.14.3. Physical Tool Layer

The physical tool layer describes physical data processing systems and their data transmission links among each other. As defined in Sect. 2.9 , a physical data processing system is a physical entity that is able to receive, store, forward, or purposefully manipulate data.

For the computer-based part of information systems, servers, PCs, notebooks, tablets, switches, routers, smartphones, etc. are modeled at the physical tool layer. In addition, virtualized physical data processing systems are modeled at the physical tool layer because they behave like physical data processing systems to the outside world (Sect. 2.9 ).

For the non-computer-based part of information systems, human actors (such as persons delivering mail) and non-computer-based physical tools (such as printed forms, telephones, books, paper-based patient records, administrative stickers) are modeled at the physical tool layer.

Figure 2.9 shows a simple model of the physical tool layer. A virtualized server farm is represented by one physical data processing system. This “black box” is connected to a patient terminal, a PC and a tablet PC. The physician uses both a tablet PC and a telephone as physical computer-based or non-computer-based tools, respectively.

3LGM 2 representation of physical data processing systems at the physical tool layer. The patient terminal, the PC and the tablet PC are connected with the virtualized server farm

Depending on the modeling goals, health professionals, patients, or caregiving relatives can be modeled as physical data processing systems (as in Fig. 2.9 ) to highlight their information-processing role in the health information system. In most cases, this will not be necessary.

To specify the relationship between physical data processing systems and virtualized physical data processing systems in a 3LGM 2 model, a “virtualizes” relationship can be modeled. Figure 2.10 illustrates the 3LGM 2 representation of virtualization techniques. In a server cluster, physical data processing systems can run certain application systems alternatively. Virtual machines allow multiple operating systems or different instances of one operating system to run on one physical data processing system (compare Sect. 2.9 ).

3LGM 2 representation of a virtual machine. On the top, the concept of a cluster virtualizing several physical data processing systems is illustrated. At the bottom, there is one physical data processing system which is virtualized into several virtual (more...)

Physical data processing systems such as a specific server or a specific PC can be assigned to a “tool class” (e.g., server, PC) and a location.

Physical data processing systems are physically connected via data transmission links (e.g., communication network, courier service) which can use different transmitting media. A transmitting medium is either signal-based (e.g., copper cable, optical fiber) or non-signal-based (e.g., sheet of paper, CD-ROM, USB flash drive).

Physical data processing systems can be refined by decomposition. A physical data processing system can be part of exactly one physical data processing system. Thus, the lower part in Fig. 2.10 does not show a decomposition but a virtualization.

2.14.4. Inter-layer Relationships

A variety of dependencies, called inter-layer relationships, exist among concepts of the three layers of a 3LGM 2 model. Relationships exist between concepts of the domain layer and the logical tool layer and between concepts of the logical tool layer and the physical tool layer.

• Functions (domain layer) can be supported by application components or, in SOA , by services which are both modeled at the logical tool layer.
• Entity types (domain layer) or, more exactly, their representation by a dataset or document collection, can be stored in an application component (logical tool layer).
• An application system storing an entity type can, in addition, be the primary application system of that entity type. This means that the application system contains the “original” data on that entity type. Data on that entity type that are stored in other application systems have to be considered copies of the “original” data. Consequently, only data in primary application systems can be updated directly by users; data integrity in the other application systems must be maintained by sending new copies of the original data to the other application systems (see Sects. 3.5 and 3.8.1 for an in-depth discussion of data integrity and data integration ).
• In the message-oriented communication paradigm, entity types or, more exactly, their representation by a message can be communicated over communication interfaces and communication links.
• In the service-oriented communication paradigm, entity types are represented by parameters that are handled by services.
• One relationship between application components and physical data processing systems states that an application component needs physical data processing systems to be able to provide its features. For example, an application system needs to be installed on a server to make its features available.
• The second relationship between application components and physical data processing systems states that application components need a physical data processing system to store data on entity types.

2.14.5. First Steps of 3LGM 2 Modeling

2.14.5.1. installation of the 3lgm 2 tool.

To start modeling, the current version of the full version of the 3LGM 2 tool can be downloaded from http://www.3lgm2.de . The Java-based tool runs on different platforms and can freely be used for non-commercial purposes.

2.14.5.2. Modeling the Domain Layer

• Each function should use and update at least one entity type.
• Very similar or even equivalent functions that are performed in different areas, different organizational units, or different health care facilities of a health care network should be modeled only once at the domain layer. The functions can be identified as similar by checking whether they use and update the same set of entity types.
• If an entity type is updated or used by a function that is decomposed or specialized, then all of the subfunctions also use or update the entity type. For clearer models, it can be helpful to assign entity types only to functions that are not further refined by subfunctions.
• Functions should be decomposed or specialized only to that level of detail needed to describe the support of the functions by single application components.
• “Documentation” may not be modeled as a function in 3LGM 2 because it is an inherent part of a function updating an entity type. If an entity type is updated by a function and this entity type’s data are stored in an application component, we call this combination the “documentation of the entity type.” However, sometimes it may improve the readability of a model to include the word “documentation” in a function’s name.

Identifying appropriate functions and entity types for a specific health care setting is a non-trivial task. The most elaborate but also the most direct way to identify functions and entity types of a setting is to conduct interviews with the persons performing the functions. Preparing and conducting these interviews, function patterns, or reference models providing lists of typical functions and of relationships between the functions of a specific type of health care setting may be helpful. In Chap. 3 , we develop patterns for functions that are performed in many health care settings. These patterns as well as a reference model for the domain layer of hospital information systems are available at http://www.3lgm2.de and can be used and refined for modeling a specific health information system.

2.14.5.3. Modeling the Logical Tool Layer

• Application systems are installations of application software products. For every installed instance of an application software product, there should be one application system in a 3LGM 2 model.
• Application software products in health care often consist of different modules for different functional areas (e.g., a module for operation planning and execution, a module for nursing). Thus, an application system may consist of sub-application systems (modeled by part-of relationships) according to the installed modules of an application software product.
• For message-based communication between two application systems, each application system should have at least one communication interface. The message type communicated over a communication link between two communication interfaces should be named according to the message type of the communication standard used. If the technical name of the message type is not known or the message type is proprietary, the name of the message type should describe the message type’s content concisely, for example, by using the name of the entity type connected to the message.
• Depending on the modeling scope, the modeler may decide to model only application systems or to model a mix of application systems and non-computer-based application components.
• There are at least two strategies for modeling non-computer-based application components. (1) All non-computer-based information processing of the logical tool layer of a health care setting can be modeled with the help of one non-computer-based application component having several communication links to application systems of the setting. (2) For each application system where there is an intervention of a person necessary to enter data which are already documented at another medium, a non-computer-based application component describing this media break is modeled. Likewise, for each application system where intervention by a person is necessary to transfer data stored in the application system to another medium, a non-computer-based application component describing this media break is modeled.

To obtain a correct representation of a logical tool layer, it is in most cases not sufficient to interview health care professionals who work within the health information system. They often have too little insight into the technical details of the logical tool layer. Interviewing information management staff or analyzing the current documentation of the information system are the most promising methods for obtaining information about the logical tool layer of a health care setting.

2.14.5.4. Modeling the Physical Tool Layer

Physical data processing systems and their connections are modeled at the physical tool layer. This layer has the fewest modeling rules. Depending on the purpose, the modeler must decide whether to model single physical data processing systems such as servers and PCs or to provide a more abstract view, for example, by modeling the data processing center of one facility as one physical data processing system.

Information about the physical data processing systems and the network can be obtained from the staff of the information management department or the data processing center, respectively.

2.14.5.5. Modeling Inter-layer Relationships

Functions are to be connected with application components supporting them in a health information system. To establish this relationship between the domain layer and the logical tool layer, the organizational unit where the function is supported by the application component should be specified. This is especially important if a function is supported by one or more application components in a health care setting. Therefore, even if one of these application components fails, this function could still be performed, at least in selected organizational units. In this case, we have a functional redundancy which may be an indication for superfluous application components.

There are also desired functional redundancies. To update the application software product of an application system, it might be necessary to shut down an application system for a few hours. If this concerns an application system which is permanently in use, such as an MDMS , it can be helpful to have an evasive application system.

However, we must also be careful that supposed functional redundancy does not result from inaccurate modeling.

In a 3LGM 2 model, we specialize or decompose functions to that level of detail needed to describe the support of the functions by single application components. That means if we think of the hierarchy of functions in a 3LGM 2 model as a tree in graph theory, then each of the tree’s “leaf functions” must completely be supported by one application component of the information system. We only assign application components to the “leaf functions” of the tree. For example, if we find that the function medical and nursing care planning needs joint support of two application components X and Y, we have to specialize or decompose the function in such a way that the resulting subfunctions are supported by X and Y, respectively. If X is used by clinicians and Y is used by nurses, a solution could be to decompose the function into medical care planning and nursing care planning .

Besides the relationship between functions and application systems, it is important not to forget to model the relationships between entity types of the domain layer and their representation forms at the logical tool layer (message types, parameters, dataset types).

Between the application systems at the logical tool layer and the physical data processing systems at the physical tool layer, the relationships have to be modeled—both for expressing the installation of an application component on a physical data processing systems and for the storage of data in such a system.

2.15. Example

For this example, we merge many of the small examples of Sect. 2.14 into one 3LGM 2 model showing a section of the information system of a fictional hospital. Figure 2.11 illustrates which logical and physical tools are used for the function patient admission in the hospital. Four subfunctions of patient admission ( appointment scheduling , patient identification and checking for readmitted patients, administrative admission , and visitor and information services ) are supported by the patient administration system , which is a part of the ERPS . Medical admission and nursing admission are supported by the MDMS . Obtaining consent for processing of patient-related data is supported by the non-computer-based application component for patient data privacy forms. This application component is based on paper forms which are scanned by a clerk (see physical tool layer) and then stored in the MDMS .

3LGM 2 representation of domain layer, logical tool layer, and physical tool layer and their relationships of the function patient admission in a hospital

The patient administration system , which is the master application system (Sect. 3.9.1 ) for the entity type “patient,” sends the administrative patient data as a message to the MDMS . The MDMS can thus store this information about the entity type “patient” in its own database; administrative patient data that is needed to support medical admission and nursing admission as functions therefore do not have to be reentered in the MDMS . The entity type “patient” is both stored in the database systems of the ERPS and the MDMS what is represented by dashed lines between the domain layer and the logical tool layer in Fig. 2.11 .

Both the patient administration system and the MDMS are run on servers at a virtualized server farm (see relationships between logical and physical tool layer). The application systems can be accessed by different end devices (patient terminal, PC, tablet PC).

Note that Fig. 2.11 shows a model of the information system expressing what the modeler believed to be relevant about the information system. It therefore simplifies some aspects which might be relevant in other contexts.

Another visualization of relationships between 3LGM 2 model elements is the matrix view. Figure 2.12 shows connected functions (columns) and application components (lines) expressing that the functions are supported by certain application components. The patient administration system supports three different functions, the MDMS supports two functions, and one function is supported by the paper-based patient data privacy form system. The matrix view also helps to identify incomplete parts of models. In Fig. 2.12 , we can see that there are no functions modeled that are supported by the financial accounting system , the human resources management system , and the material management system , which are parts of the ERPS .

The matrix visualizes the relations between functions and application components

The matrix view presented in Fig. 2.12 is an alternative representation of configuration lines between functions at the domain layer and application components at the logical tool layer (compare Fig. 2.11 ). Matrix views are also available for visualizing relations between other pairs of connected 3LGM 2 classes.

2.16. Exercises

2.16.1. data, information, and knowledge.

Imagine that a physician is given the following information about his patient, Mr. Russo: “Diagnosis: hypertension. Last blood pressure measurement: 160/100 mmHg.” Use this example to discuss the difference between “data,” “information,” and “knowledge”!

2.16.2. Systems and Subsystems

Look up some information on the nervous system of the human body. Then try to identify subsystems of the nervous system. In the same way, can you also describe subsystems of the system “hospital”?

2.16.3. Information Logistics

Imagine a situation in which a physician speaks with Mr. Russo at the patient’s bedside. The physician looks up Mr. Russo’s recent blood pressure measurement and ongoing medication, decides to increase the level of one medication, and explains this to Mr. Russo. Use this example to discuss the meaning of “information and knowledge logistics.” What in this example indicates the right information, the right place, the right people, the right form, and the right decision? What could happen if an information system does not support high-quality information and knowledge logistics?

2.16.4. 3LGM 2 Metamodel

Look at the 3LGM 22 example in Sect. 2.15 . Use this example to explain the meaning of the following elements: functions, entity types, application systems, non-computer-based application components, physical data processing system, and inter-layer relationships.

2.16.5. Interpreting 3LGM 2 Models

Find examples of specialization or decomposition at the domain layer in Fig. 2.11 .

What is the meaning of the arrows pointing from patient identification to “patient” and from “patient” to medical admission in Fig. 2.11 ?

What entity type that is stored in the paper-based patient data privacy form system should be added at the domain layer in Fig. 2.11 ?

Why is the function patient admission not connected with any application system in Fig. 2.11 ? (Hint: Look at the graphical representation of the domain layer in Fig. 2.11 and remember the modeling rules from Sect. 2.14.5 .)

Which physical data processing systems are needed for the function “obtaining patient consent for the processing of data”?

https://www ​.snik.eu .

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License ( http://creativecommons.org/licenses/by/4.0/ ), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

• Cite this Page Winter A, Ammenwerth E, Haux R, et al. Health Information Systems: Technological and Management Perspectives [Internet]. 3rd edition. Cham (CH): Springer; 2023. Chapter 2, Basic Concepts and Terms. 2023 Mar 22. doi: 10.1007/978-3-031-12310-8_2
• Disable Glossary Links

In this Page

• Introduction
• Data, Information, and Knowledge
• Health care Settings
• Systems and Subsystems
• Information Systems
• Health Information Systems
• Information Logistics in Health Information Systems
• Functions, Processes, and Entity Types in Health care Settings
• Application Systems, Services, and Physical Data Processing Systems in Health Information Systems
• Electronic Health Records as a Part of Health Information Systems
• Architecture and Infrastructure of Health Information Systems
• Management of Information Systems
• Modeling Information Systems
• 3LGM 2 : A Metamodel for Information System Architectures

Recent Activity

• Basic Concepts and Terms - Health Information Systems Basic Concepts and Terms - Health Information Systems

Your browsing activity is empty.

Activity recording is turned off.

Turn recording back on

Connect with NLM

National Library of Medicine 8600 Rockville Pike Bethesda, MD 20894

Web Policies FOIA HHS Vulnerability Disclosure

Help Accessibility Careers

Content Search

Sudan - grants coordinator (m/f) - ndjamena.

• Solidarités International

Desired start date: 13/05/2024 Duration of the mission: Location: 9 months

SOLIDARITES INTERNATIONAL (SI) is an international humanitarian aid association which, since more than 40 years, has been providing assistance to populations affected by armed conflicts and natural disasters by meeting their basic needs for food, water and shelter. Particularly committed to the fight against diseases linked to unsafe water, the leading cause of death in the world, SI's interventions provide expertise in the field of access to drinking water, sanitation and hygiene promotion, but also in the essential area of food security and livelihoods. Present in some twenty countries, the SI teams – 2500 people in total, made up of expatriates, national staff, permanent staff at HQ, and a few volunteers - intervene with professionalism and commitment while respecting cultural norms.

ABOUT THE MISSION

Following fighting between SAF (regular army) and RSF (rapid support forces) since April 2023, SI is developing a rapid emergency response in Sudan.

In Geneina, West Darfur, SI opened a base in August 2022, providing assistance to IDPs living in the gathering sites inside the city. The response was WASH in emergency activities with water trucking, construction of boreholes, hygiene kits distribution, latrines construction and rehabilitation…

Today, the situation in Darfur, and specifically in Geneina is worsening due to the conflict at country level. SI is assessing the sites and the needs for an emergency response which began in May 2023, providing WASH in emergency activities to the IDPs and host communities in Geneina, and possibly in other states in Darfur (El Fasher, Nyala). SI began water trucking activities in May 2023 and is the only WASH actor in Geneina.

In the East of the country, especially Gedaref, Al Jazirah and Madani states, security situation is tense but much calmer than in Darfur. SI is doing assessments to implement a WASH/shelter and NFIs response for IDPs, mainly coming from Khartoum.

In Khartoum, SI wants to develop a WASH emergency response as soon as possible, and when authorizations are provided.

SI is one of the pillars of the INGO forum coordination, especially for Darfur.

ABOUT THE JOB

General objective:

The Partnership and Grant Coordinator plays a key role in developing and monitoring the partnership and financial strategies for the country office. He or she guarantees a high level of interdepartmental coordination in the management of grants and provides strategic support to the country office in terms of donor relations, funding strategy, external representation, implementing partners management, external compliance, and donor accountability.

The main challenges:

• Due to the ongoing conflict, SI Sudan mission increases a lot its activties and fundings (from 400 000 USD end of March 2023 to an expected 26M in 2024)
• As it is complicated to get Sudanese visa, the work will be done remotely at the begining and the coordination is spread in a lot of countries
• Flexibility of the funds due to the ongoing conflict

Priorities for the 2/3 first months:

• Compliance and Accountability
• Ensure the continuity on the flow of information and reporting in the country office;
• Work with CD and Prog Co to structure the Grant Unit and Roles and Responsabilities
• Support the Prog Co to formalize proposal and reporting writing processes within the CO;
• Develop the partnership strategy and its implementation

YOUR PROFILE

Education / academic background:

Master degree in international relations, programs management

Specific skills and experience:

• 3-4 years experience in the humanitarian sector
• 3-4 years on a similar position
• Experience with BHA, ECHO, UN, and big consortiums
• Ability to work independently and meet deadlines with minimal
• Excellent organizational skills: the ability to multi-task, learn quickly, and work independently and productively in a fast-paced and detail-oriented environment.
• Work under a lot of pressure
• Adaptability
• Strong initiatives and improvisation capacities
• English fluently
• Arabic would be a strong asset

SI WILL OFFER YOU

A salaried position:

According to experience, starting from EUR 2640 gross per month (2400 base salary + 10% annual leave allowance paid monthly) and a monthly Per Diem of USD 750.

SI also covers accommodation costs and travel expenses between the expatriate's country of origin and the place of assignment.

Breaks: During the assignment, a system of alternation between work and time off is implemented at the rate of 7 working days every three months (with a USD 850 break allowance, allocated by Sl). To these breaks periods, SI grants one (1) additional rest day per month worked.

Insurance package: Expatriates benefit from an insurance package which refunds all healthcare expenses (including medical and surgical expenses, dental care and ophthalmological expenses, repatriation) and a welfare system including war risks. Essential vaccination and antimalarial treatment costs are refunded.

LIVING CONDITIONS:

If Sudanese visa, a lot of security contraints will be there. Access is still in negociation, some areas are still closed, open an ongoing conflict. Movement in the East of Sudan submitted to a lot of administrative impediment. In Darfur, highly volatile context, cross bording operation to go to Geneina.

Depening on visa, and on the coordination set-up place, but security measures will be on place, with curfew. Internet in country is very challenging, with days without connexion. A lot of NGOs are in Sudan (East Sudan), but socialization will depend on the evolution of the context. It has to be understand that rooms could be shared as SI is currently working in a highly emergency context.

APPLICATION PROCESS

Do you recognize yourself in this description? If yes, please send us your CV and cover letter!

Please note that CV-only applications will not be considered, and that the vacancy may close before the deadline.

Thank you for your understanding.

To learn more about Sl: www.solidarites.org

Solidarités International (SI) est déterminé à prévenir et à combattre tout type d’abus – tout acte d’exploitation, d’abus et/ou de harcèlement sexuels (SEAH) à l’encontre des membres des communautés bénéficiaires ou de ses collaborateurs et collaboratrices, atteinte aux personnes et/ou aux biens, fraude, corruption, conflit d’intérêt non déclaré, financement d’activités portant atteinte aux droits de l’homme - qui pourrait être perpétré dans le cadre de ses interventions. SI applique une tolérance zéro à l’égard de tout type d’abus, particulièrement des actes de SEAH.

Solidarités International est un employeur équitable qui combat toute forme de discrimination. SI ne demandera jamais une rétribution quelconque en vue de participer à un processus de recrutement.

How to apply

https://www.aplitrak.com/?adid=YXNzaXN0LnJlY3J1dC4yMDg4NC4zODMwQHNvbGlkYXJpdGVzaW50ZXJuYXRpb25hbC5hcGxpdHJhay5jb20

Related Content

La espiral de violencia en sudán tiene un impacto aterrador.

Sudan + 7 more

Sudan Situation: UNHCR External Update #61, 9-15 May 2024

Sudan idp movement intentions assessment - rabak, may 2024, sudan: the rsf sets its eyes on north darfur - situation update | april 2024.

The Federal Register

The daily journal of the united states government, request access.

Due to aggressive automated scraping of FederalRegister.gov and eCFR.gov, programmatic access to these sites is limited to access to our extensive developer APIs.

If you are human user receiving this message, we can add your IP address to a set of IPs that can access FederalRegister.gov & eCFR.gov; complete the CAPTCHA (bot test) below and click "Request Access". This process will be necessary for each IP address you wish to access the site from, requests are valid for approximately one quarter (three months) after which the process may need to be repeated.

An official website of the United States government.

If you want to request a wider IP range, first request access for your current IP, and then use the "Site Feedback" button found in the lower left-hand side to make the request.

• Global (EN)
• Albania (en)
• Algeria (fr)
• Argentina (es)
• Armenia (en)
• Australia (en)
• Austria (de)
• Austria (en)
• Azerbaijan (en)
• Bahamas (en)
• Bahrain (en)
• Bangladesh (en)
• Barbados (en)
• Belgium (en)
• Belgium (nl)
• Bermuda (en)
• Bosnia and Herzegovina (en)
• Brasil (pt)
• Brazil (en)
• British Virgin Islands (en)
• Bulgaria (en)
• Cambodia (en)
• Cameroon (fr)
• Canada (en)
• Canada (fr)
• Cayman Islands (en)
• Channel Islands (en)
• Colombia (es)
• Costa Rica (es)
• Croatia (en)
• Cyprus (en)
• Czech Republic (cs)
• Czech Republic (en)
• DR Congo (fr)
• Denmark (da)
• Denmark (en)
• Ecuador (es)
• Estonia (en)
• Estonia (et)
• Finland (fi)
• France (fr)
• Georgia (en)
• Germany (de)
• Germany (en)
• Gibraltar (en)
• Greece (el)
• Greece (en)
• Hong Kong SAR (en)
• Hungary (en)
• Hungary (hu)
• Iceland (is)
• Indonesia (en)
• Ireland (en)
• Isle of Man (en)
• Israel (en)
• Ivory Coast (fr)
• Jamaica (en)
• Jordan (en)
• Kazakhstan (en)
• Kazakhstan (kk)
• Kazakhstan (ru)
• Kuwait (en)
• Latvia (en)
• Latvia (lv)
• Lebanon (en)
• Lithuania (en)
• Lithuania (lt)
• Luxembourg (en)
• Macau SAR (en)
• Malaysia (en)
• Mauritius (en)
• Mexico (es)
• Moldova (en)
• Monaco (en)
• Monaco (fr)
• Mongolia (en)
• Montenegro (en)
• Mozambique (en)
• Myanmar (en)
• Namibia (en)
• Netherlands (en)
• Netherlands (nl)
• New Zealand (en)
• Nigeria (en)
• North Macedonia (en)
• Norway (nb)
• Pakistan (en)
• Panama (es)
• Philippines (en)
• Poland (en)
• Poland (pl)
• Portugal (en)
• Portugal (pt)
• Romania (en)
• Romania (ro)
• Saudi Arabia (en)
• Serbia (en)
• Singapore (en)
• Slovakia (en)
• Slovakia (sk)
• Slovenia (en)
• South Africa (en)
• Sri Lanka (en)
• Sweden (sv)
• Switzerland (de)
• Switzerland (en)
• Switzerland (fr)
• Taiwan (en)
• Taiwan (zh)
• Thailand (en)
• Trinidad and Tobago (en)
• Tunisia (en)
• Tunisia (fr)
• Turkey (en)
• Turkey (tr)
• Ukraine (en)
• Ukraine (ru)
• Ukraine (uk)
• United Arab Emirates (en)
• United Kingdom (en)
• United States (en)
• Uruguay (es)
• Uzbekistan (en)
• Uzbekistan (ru)
• Venezuela (es)
• Vietnam (en)
• Vietnam (vi)
• Zambia (en)
• Zimbabwe (en)
• Financial Reporting View
• Women's Leadership
• Corporate Finance
• Board Leadership
• Executive Education

Fresh thinking and actionable insights that address critical issues your organization faces.

• Insights by Industry
• Insights by Topic

KPMG's multi-disciplinary approach and deep, practical industry knowledge help clients meet challenges and respond to opportunities.

• Advisory Services
• Audit Services
• Tax Services

Services to meet your business goals

Technology Alliances

KPMG has market-leading alliances with many of the world's leading software and services vendors.

Helping clients meet their business challenges begins with an in-depth understanding of the industries in which they work. That’s why KPMG LLP established its industry-driven structure. In fact, KPMG LLP was the first of the Big Four firms to organize itself along the same industry lines as clients.

• Our Industries

How We Work

We bring together passionate problem-solvers, innovative technologies, and full-service capabilities to create opportunity with every insight.

• What sets us apart

Careers & Culture

What is culture? Culture is how we do things around here. It is the combination of a predominant mindset, actions (both big and small) that we all commit to every day, and the underlying processes, programs and systems supporting how work gets done.

Relevant Results

Sorry, there are no results matching your search., mobility matters.

U.S. & Canada Cross-Border Commuter Impact: From Compliance to Change Management. 

May 2024 | by John Denworth and Kyle Christensen, KPMG LLP (U.S.), Detroit (KPMG LLP in the United States is a KPMG International member firm)

With over 20,000 daily commuters between Michigan and Ontario, the post COVID-19 landscape has radically transformed the rules of remote work and payroll management. In this article, we focus on the technical rules on both sides of the border, how remote and hybrid work policies have spotlighted the risks of compliance, and how change management is critical to a creating a positive experience for all stakeholders involved. We take a  detailed look at varying tax rates, the implementation of dual payroll systems, and the intricacies involved in social security agreements.

Learn how effective change management can not only ensure compliance and minimize risk but also optimize business processes for both employers and employees.

Dive into our thinking:

Mobility Matters: U.S. & Canada Cross-Border Commuter Impact: From Compliance to Change Management

GMS Flash Alerts and Mobility Matters

Meet our team.

Subscribe to GMS Flash Alerts and Mobility Matters.

Provide the information below to begin receiving publications of interest., check the publication(s) you would like to receive:.

By submitting, you agree that KPMG LLP may process any personal information you provide pursuant to KPMG LLP's Privacy Statement .

Thank you for contacting KPMG. We will respond to you as soon as possible.

Contact KPMG

Job seekers

Visit our careers section or search our jobs database.

Use the RFP submission form to detail the services KPMG can help assist you with.

Office locations

International hotline

You can confidentially report concerns to the KPMG International hotline

Press contacts

Do you need to speak with our Press Office? Here's how to get in touch.