Initial commit of content from CHT overview deck

new/02-features/01-intro.md

@@ -0,0 +1,101 @@
+# Introduction
+
+*We’re building open source technology for a new model of healthcare that reaches everyone. We envision a world where primary health care is equitable, accessible, and delivered by people who are trusted in their communities.*
+
+The Community Health Toolkit (CHT) is a project by a group of leading organizations who have come together to support the development of digital health initiatives in the hardest-to-reach areas. 
+
+The CHT provides you with resources to design, build, deploy, and monitor digital tools for community health. It includes open source software frameworks and applications, guides to help design and use them, and a community forum for collaboration and support.  Together, we envision a world where healthcare is of the highest attainable quality, equitable, accessible, and delivered by the people who are trusted most in their communities.  
+
+With more than 24,000 health workers using these tools to support a million home visits every month, the CHT is the most full-featured, mature, and widely-used open source software toolkit designed specifically for advanced community health systems. 
+
+## CHT Core Framework
+
+The Core Framework makes it faster to build full-featured, scalable digital health apps by providing a foundation developers can build on. These apps can support most languages, are offline-first, and work on basic phones (via SMS), smartphones, tablets, and computers. 
+
+App developers are able to define health system roles, permissions and reporting hierarchies, and make use of five highly configurable areas of functionality: messaging, task and schedule management, decision support workflows, longitudinal person profiles, and analytics. 
+
+The Core Framework can be used to support the unique needs of a given health system and the work of community health workers, frontline supervisors, facility-based nurses, health system managers, and even patients and caregivers.
+
+## App Development
+
+From a technical perspective, developing a custom app begins with writing XForms, JSON, and JavaScript code that configures the Core Framework’s features to meet your organization’s needs. 
+
+The Core Framework allows you to define each element in your app in a modular way, and then specify when and how it should appear for different types of users, without having to modify the underlying Framework. Collectively, this customization is referred to as Configuration Code.
+
+Developing an app using the Core Framework requires an understanding of:
+- Javascript code and expressions
+- JSON format used to specify configuration
+- XLSForms to setup actions and contacts
+
+For more info about app development, visit [our website](). 
+
+### Reference Apps
+
+The Community Health Toolkit’s Reference Apps provide organizations with a template for structuring and organizing a community health workflow, its configuration code, and testing framework. They include a foundation for forms, data fields, and even analytics, and can be deployed as-is or easily customized by a developer for your unique context.
+
+This slide deck won’t describe any one Reference App in detail. Instead, we’ll use screenshots from the Medic Android Demo App and other Reference Apps to give you a general idea of how the Core Framework’s features can be deployed for different types of users in a wide range of health programs.
+
+## Responsive Web App Model
+
+A responsive web app is a hybrid of a website and a mobile application. On desktop and laptop computers, it runs in the web browser. On Android devices (such as cell phones or tablets), it is downloaded as an app. The same source code powers the experience, meaning that the app you see on your desktop is the same app you see on your mobile device. 
+
+Web apps built with the Core Framework are fully responsive, which means content will scale to fill the available space. Users accessing the app on a mobile device will see a single-panel mobile layout. Users accessing the app on a desktop or laptop device will see a two-panel layout.
+
+## Offline-First Technology
+
+Our technologies need to support health systems in a wide range of low infrastructure environments. Apps built with the Core Framework are designed to be offline-first and work with only an occasional internet connection.
+
+The app stores a user’s data locally on their device so that workflows can be completed without syncing to the server. When a connection becomes available, data will automatically sync to and from the server. Offline-first technology enables health workers to carry out important duties even when opportunities to sync may be weeks apart.
+
+As with any app, there is a limit to how much data can be stored locally, particularly on a mobile device. For users needing access to large amounts of data, online user roles are available. 
+
+## Made for Localization
+
+Apps can be customized for different deployments and types of workflows. We’re already using the framework in many countries around the world with localization settings.
+
+Users can currently interact with the app in English, French, Hindi, Nepali, Spanish, Swahili, or Indonesian and new languages can be added in the admin console. The app also supports Bikram Sambat or Gregorian calendars and localized date formatting.
+
+
+
+## User Personas
+
+We’ve used the Core Framework to build apps for a variety of users, including community health workers (CHWs), CHW supervisors, nurses, system administrators, and other people who deliver care and support.
+
+User personas give us a common understanding of who we are serving, particularly when working across diverse contexts. Our global personas are based on “typical” users, knowing that some variation is present in different settings.
+
+Being explicit about who are we designing with and for, and understanding what’s important to them helps us prioritize features, make better design decisions, and optimize impact.
+
+### Community Health Worker (CHW)
+
+CHWs are the central users of apps built with the Core Framework. They conduct household visits and are responsible for the health of their community. CHWs typically live in and are chosen by their community. Their degree of health training, responsibilities, and support depends upon their country and program. Many are unpaid volunteers, though a growing number receive wages or incentives. Most operate as a CHW on a part-time basis while engaging in farming or other income-generating activities. Most CHWs are responsible for:
+- Registering new people and families
+- Conducting guided health assessments
+- Screening for and tracking specific conditions
+- Providing basic medicines and health supplies
+- Reporting danger signs & referring to the clinic
+- Following up about clinic visits and care
+
+### CHW supervisor
+
+The CHW supervisor is the person who trains and supports CHWs and helps them meet their monthly goals. Supervisors usually split their time between administrative duties at the local health facility and accompanying CHWs on their community visits. Most CHW supervisors are responsible for:
+- Training CHWs and reinforcing health knowledge and protocols
+- Following up with CHWs on high-priority cases 
+- Liaising with the facility-based staff on the needs at the community level
+- Mobilizing CHWs to educate community on health promotion campaigns
+- Tracking progress towards key impact metrics and helping CHWs reach their targets
+- Aggregating CHW data and reporting on activities to health system officials
+
+### Nurse
+
+Nurses are stationed at the health facility and spend their days seeing patients. They are very busy and may see 50 or more patients a day. At the clinic, they sometimes deal with staff shortages, stock-outs, and poor internet connectivity. They help train and manage CHWs, particularly during monthly meetings at the facility. They are interested in seeing improvements in health metrics for the areas their facility serves.  Most nurses are responsible for:
+- Assessing patients and providing primary care 
+- Reporting service delivery statistics to health system officials
+- Coordinating care for high-priority patients through CHWs and supervisors
+- Initiating events to promote healthy practices in the community
+
+### Data Manager
+
+Data Managers are often based at a regional health facility and serve many local facilities. They are responsible for collating and reporting on community and health system data. Their work often involves following up with supervisors and nurses to verify data and retrieve missing information. Most data managers are responsible for:
+- Collecting health system data from the field
+- Verifying data for accuracy and completeness
+- Aggregating data and providing reports to nurses, supervisors, and health system officials with raw numbers and trends on key metrics

new/02-features/02-basics.md

@@ -0,0 +1,98 @@
+# Application Basics 
+
+## Care Guides
+
+We use forms to build “Care Guides” that take health workers through care protocols and provide decision support for their interactions with patients. App designers can use basic form building functionality in a variety of ways. 
+
+Care Guides also allow CHWs to register new families and people, assess a sick child, and enroll a new pregnancy into an antenatal care schedule. Care Guides can live in many parts of the app including the Tasks, People, and Reports tabs. 
+
+During app development, Care Guides can be written from scratch or based on those from a reference application. These variations are often necessary due to different local requirements, government protocols, etc.
+
+### Functionality
+
+Care Guides consists of questions grouped into pages. They are capable of presenting many different types of questions, skip logic, images, and videos. Validation rules can require certain questions to be answered or restrict answers to a specified type or range. 
+
+It’s possible to reference previous information that was submitted about the person or household from within the care guide. The interaction can also conclude with a summary that includes assessment results, treatment recommendations, and referral info. 
+
+Care Guides can include images for instructional purposes and can access a user’s camera to take a photo if needed.
+
+### Summary
+
+After all of the required questions have been answered, a summary page can be displayed. 
+
+Here, health workers can review the information they entered, receive instructions for treatment, care, and referrals, and relay detailed education to the patient.
+
+**Please Note:** The form is not submitted until the user scrolls to the very end of the summary and clicks the “Submit” button.
+
+### Examples
+
+- While a health worker is going through the form during the care visit, you can include a family planning question only if the person who the form is about is a woman and not pregnant.
+- You can include on-the-spot conversational prompts and advice for the CHW based on how they answer questions in the form. For instance, if a CHW answers “yes” to the question about a woman’s interest in family planning, text can automatically appear to provide information on her options.
+- An image showing how to read a rapid test can be displayed within a form, to help health workers to correctly interpret their test results.
+
+## Build Workflows
+
+Forms are the main building block of workflows, because they can be configured to initiate a schedule of tasks, such as follow-up visits for the CHW or a referral to be completed by a nurse. 
+
+Data submitted in one form can generate several tasks at once, e.g., multiple ANC visits following one pregnancy registration. Some workflows involve a series of sequential forms and tasks, e.g., a child health assessment form, a follow up task scheduled 48 hours later, a referral form (only if the child’s condition hasn’t improved), and then a referral follow up task. Tasks are accessible on the Tasks tab, as well as the Tasks section of profiles. 
+
+A form can also trigger an SMS to be sent to another user, such as CHW supervisor or nurse, where immediate notification is desired. 
+
+## Hierarchies
+
+The Core Framework requires a hierarchy to organize the app. It is often based on the hierarchy of a health system. These levels might have different titles depending on a particular health system’s configuration. 
+
+A user logging into their app will see a custom set of people, tasks, reports, and analytics based on the hierarchy level that they belong to. This allows appropriate data sharing based on the role of the user in the health system. 
+
+Note that each place in a hierarchy must have a primary contact person assigned to it. Other program staff working at the same level can be registered but there is only ever one primary contact. Supporting more flexible hierarchies is on the Core Framework development roadmap.  
+
+### Sample Hierarchy "A"
+
+This is an example of a hierarchy that includes district, health center, and CHW areas as the three levels which serve as “places,” or units of organizing people. User roles can be assigned to log in at any of these levels. For example, it would be customary for a CHW to log in at the CHW Area level and view the people, i.e. patients, who belong there.
+
+This is the typical setup for a project that prioritizes district-level overview and aggregation. In this hierarchy, patients are often created under the “CHW Area” level, and are not organized by household.
+
+### Sample Hierarchy "B"
+
+This is an example of a hierarchy that includes health center, CHW area, and families as the three levels which serve as “places” or units of organizing people. User roles can be assigned to log in at any of these levels. For example, it would be customary for a CHW to log in at the CHW Area level and view the families, and below that the people, i.e. patients or family members, who belong there.
+
+This is the typical setup for a project that requires family-level views.
+
+<!-- Visual page 23 -->
+
+The app hierarchy can be modeled after the health system, health program or the community.  All people are associated with a place and these places can be associated to each other. For instance, a Family Member is part of a Household. A Household and CHWs are part of a CHW Area. A CHW Area and nurses are part of a Health Facility. Additional levels may be added as needed. The Admin level operates outside of the hierarchy and gives access to all levels and people.
+
+<!-- Visual page 24 -->
+
+## User Roles
+
+The app uses roles and permissions to determine who has access to what data. User roles are general categories we use to assign a collection of broad permissions to users. There are two classes of roles: online and offline. Generally speaking, CHWs are usually offline users, while managers and nurses are usually online users. SMS users do not use the app, and thus do not have a user role.
+
+### Online Roles
+
+Online roles are for users who need access to a lot of data and need to maintain the system or update system settings. An internet connection is required.
+
+### Offline Roles
+
+Offline roles are for users who need to be able to access data on the go in the field, don’t need to maintain the system, and don’t have a reliable internet connection. All the data they have access to will be synced to their device.
+
+### Sample Hierarchy "B"
+
+Some people in the app will also be app users. Differing levels of access and permissions are assigned to each persona. A user role is created to provide them with access to the information they need. Offline and online access, storage limitations, and data privacy are taken into account.
+
+| Persona         | Hierarchy                                      | Device    | Permissions                                                                                                                                                                                                                                              |
+| :-------------- | :--------------------------------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Program Officer | Logs in as Admin                               | Computer  | Admin users, usually Program Officers, are online-only admin users not associated to a particular level. They have access to all people, places, and records in the app, but since they are online-only users, they cannot view any tasks or targets.    |
+| CHW Supervisors | Logs in at Health Facility level               | Tablet    | User at this level have offline access to view CHWs, fill out reports about them, and view tasks and targets related to them. Due to storage limitations, they aren’t able to view households or submit reports and review tasks and targets about them. |
+| CHWs            | Logs in at CHW Area level                      | Phone     | Users at this level have offline access to view households and family members, submit reports about them, and view tasks and targets about them.                                                                                                         |
+| Family members  | Registered at Household level, does not log in | Messaging | Family members might include fathers, mothers, children, and other adults. The program model determines which family members should be registered in the app. However, they are not users of the app, and do not log in themselves.                      |
+
+## User Permissions
+
+Roles are broad general collections of permissions. Permissions are fine grained settings that individually toggle on or off to allow a role to do a certain action or see a certain thing.
+
+Viewing permissions determine which page tabs a user sees in the app and which types of data they do and don’t have access to. User action permissions include who can create (e.g., create new users), who can delete (e.g., delete reports), who can edit (e.g., edit profiles), and who can export (e.g., export server logs).
+
+## Hardware & Software Requirements
+
+Hardware procurement, ownership, and management is the responsibility of each implementing organization. We strongly urge all organizations to procure hardware locally to ensure ease of replacement, repair, sustainability, and hardware support when needed.