Implementation Projects

• 1: Community Training Centres
• 2: Digital Learning Infrastructure
• 3: Training and Assessment Network
• 4: Livelihood and Market Linkages
• 5: HealthCareNet
• 6: DharmaNet
• 7: Assisted Living Network
• 8: Diagnostic Lab Network
• 9: Pharmacy Network
• 10: AYUSH Network
• 11: Emergency Coordination
• 12: Surgical Facility Network
• 13: Technical and Service Provider Network

1 - Community Training Centres

The implementation idea

A community training centre is a local facility where people can develop practical capabilities through structured learning, guided practice and assessment. It may serve school students, young people preparing for work, adults seeking new skills and community members who need access to digital learning.

The objective is not simply to open a room containing computers or training equipment. A useful centre combines an appropriate physical environment with a defined learning programme, capable trainers, practical activities, learner support, equipment maintenance and a way to assess what participants can actually do.

The centre may be established in an existing school, community institution, suitable training facility or another location where the necessary permissions and resources can be secured. Its configuration should reflect the intended learners, selected courses, local demand and available facilities.

The proposed model is modular. A centre can begin with a defined learning purpose and add other capabilities only when the relevant demand, people, equipment and operating arrangements are in place.

Why community-based facilities matter

Access to education and skills development is affected by more than the availability of course material. Learners may lack a computer, a reliable place to practise, specialist guidance, suitable tools or access to someone who can help them overcome practical difficulties.

A local centre can help address these barriers by bringing together resources that would be difficult or expensive for every learner to maintain independently.

It can provide:

• A place for structured learning and supervised practical work.
• Shared access to computers, tools and other learning equipment.
• Trainers and facilitators who can guide practice and assess progress.
• Prepared learning materials that can be reused and improved.
• Opportunities to practise skills in a setting suited to the intended task.
• A local point of coordination for schools, training providers, institutions and community organisations.
• A possible progression from introductory learning to more specialised training.

These benefits depend on how the centre is operated. Equipment without useful activities may remain idle, while a course without sufficient practice resources may not develop the intended capability. The operating model must therefore be designed alongside the physical facility.

What a centre may provide

The centre’s activities should be selected according to local needs and the resources available. The following are possible components of the proposed model, not a claim that every centre will offer all of them.

Digital learning

A digital learning area may support computer fundamentals, digital literacy, productivity applications, safe use of online services, programming and other selected digital skills.

Computers may also support learning in mathematics, science, languages, geography and other subjects. This helps make the facility useful beyond a single computer course.

Where appropriate, a centre may use standardised open-source software and refurbished computers to reduce acquisition and recurring software costs. The actual hardware and software specification should be determined by the learning requirements, reliability and support capability.

Vocational and practical learning

Selected vocational pathways may require tools, machines, consumables, demonstration equipment, protective equipment or a dedicated practical workspace.

The centre should introduce these facilities only when the course requirements are defined. A tailoring pathway, for example, requires a different arrangement from a networking or digital-services pathway.

Each practical course must specify the tasks learners will perform, the supervision required, the equipment they will use, the safety procedures they must follow and the evidence needed to demonstrate competence.

School-linked learning

A centre may support schools that cannot independently provide all the equipment, specialist instruction or practical facilities required by a particular course.

Under a school-linked arrangement, foundational learning can take place at school while selected specialist activities, practical work or further assessment take place at the centre. The arrangement must define how the curriculum, learner records and assessment evidence are shared.

The centre should complement the school rather than create a disconnected parallel curriculum.

Continuing and community learning

Depending on its purpose, a centre may also support adult digital literacy, refresher learning, community education and other approved learning activities.

A centre should not be assumed to provide every service simply because it has the physical capacity to do so. Each activity needs an identified purpose, suitable staff, an agreed schedule and the resources to operate it safely.

A modular facility model

A proposed centre can be planned around four connected elements.

The modules should be sized according to actual demand and the chosen courses. A digital learning centre may need a computer classroom and reliable connectivity. A practical vocational centre may need additional specialist equipment, secure storage and safety controls.

Some resources may be shared with the host institution. Others may need to be dedicated to the centre. The arrangement should identify who owns each asset, who can use it, who maintains it and who pays for repairs or replacement.

An example: the Haflong school IT classroom

The project materials include a specific operating design for a school IT classroom in Haflong. It demonstrates how a learning environment can be designed around available resources instead of assuming that every learner must have an individual computer.

The proposed baseline is:

• 40 students organised into 10 learning pods.
• One computer per four-student pod.
• Two pairs of students within each pod, rotating between computer work and a related activity.
• A specialist IT teacher responsible for introducing concepts, demonstrations, practical instruction and assessment.
• A school-based lab assistant or supervisor who supports routine practice and reports technical problems.
• A standardised software and network configuration to simplify installation and maintenance.

In this example, a computer room remains a classroom rather than becoming a collection of isolated workstations. Students who are not using the computer have a defined activity related to the same lesson. The rotation is designed to reduce waiting and ensure that computer access forms part of a complete learning task.

The specification also proposes Linux Mint Xfce, LibreOffice, Firefox, Python and classroom-management software, with wired Ethernet and a standardised system image. These are design choices for the Haflong example, not mandatory choices for every community centre.

The proposed specialist-teacher circuit across three schools is also specific to that school model. It should not be treated as a staffing ratio for every centre.

Before adapting the example, the implementation team must check the intended classes, curriculum, timetable, available staff, equipment condition, room layout, electricity, connectivity and maintenance arrangements.

How the centre would operate

A centre needs a predictable operating routine. The precise schedule will depend on its users and activities, but the following cycle provides a starting point for planning.

1. Identify demand and define the scope

Establish which learners the centre will serve, what capabilities they need to develop and what local facilities are already available.

The initial scope should be narrow enough to implement properly. It should specify the proposed courses or activities, expected learner groups, available time and intended outcomes.

2. Prepare the facility

Inspect the proposed premises and identify the work required before use. This may include electrical safety, furniture, equipment installation, connectivity, accessibility, ventilation, secure storage and arrangements for equipment maintenance.

For a practical course, preparation must also address task-specific safety requirements and the competence needed to supervise learners.

3. Prepare the learning programme

Each course should have defined learning outcomes, competencies, lesson materials, practical tasks, assessment requirements and learner-support arrangements.

The learning framework should connect explanation with practice and observable evidence of achievement. Attendance alone is not proof that a learner can perform a task.

Where possible, a common course design should support trainer guides, learner materials, practical activities and assessment resources without creating separate, inconsistent versions of the curriculum.

4. Schedule trainers and learning activities

Allocate the available teaching and practice time according to the number of learners, equipment capacity, trainer availability and course requirements.

If the centre supports multiple courses, the timetable must prevent incompatible activities from competing for the same room, equipment or staff.

Routine practice may be supported by an appropriately prepared local assistant, but specialist instruction, assessment and regulated activities must remain with people qualified and authorised for those responsibilities.

5. Record progress and maintain the facility

The centre should maintain appropriate records of enrolment, attendance, learning progress, assessment, equipment condition, incidents and resource use.

Learner records should distinguish between a competency being studied, demonstrated and formally verified where verification applies. Access to personal information must be controlled and limited to legitimate purposes.

Equipment faults, safety concerns and gaps in learning resources should be recorded and addressed through an agreed process.

6. Review performance

Review whether the centre is delivering the agreed activities, whether learners can access the facility, whether practical resources are being used effectively and whether the intended competencies are being achieved.

The findings should inform changes to the timetable, course materials, equipment, staffing or delivery model. Expansion should follow evidence of readiness and need rather than the mere availability of another room.

Partner roles and responsibilities

A community training centre can involve several organisations. The actual allocation of responsibilities must be agreed for each location rather than assumed from the project concept.

One organisation may fulfil more than one role. A host school, for example, may provide the premises and an existing staff member to supervise routine practice, provided the person is appropriately prepared and the responsibilities are manageable.

Wara Systems may provide agreed technology or operational services where appropriate. Its commercial work should remain distinct from the Trust’s charitable and educational activities.

Local Community Organisation may be considered as a potential institutional collaborator for a specific centre where there is mutual interest and a suitable agreement. No premises, staff, funding or other resource commitment should be assumed without formal approval.

The project should identify a responsible coordinator and document who makes operational decisions, approves expenditure, supervises staff, maintains assets and handles complaints or incidents.

Resources and financial sustainability

A centre’s financial plan should cover both establishment and continued operation. The cost of opening a facility is only part of the requirement.

Initial resources

Depending on the selected model, establishment costs may include:

• Preparing or adapting the premises.
• Furniture, computers, tools and specialist equipment.
• Electrical work, networking and internet installation.
• Initial software configuration and approved learning materials.
• Safety equipment, storage and other task-specific requirements.
• Trainer preparation, installation support and initial testing.

Recurring resources

Ongoing costs may include:

• Trainers, assistants and centre coordination.
• Electricity, connectivity and routine consumables.
• Equipment maintenance, repairs and eventual replacement.
• Course-material updates and assessment.
• Cleaning, security and other premises-related costs.
• Learner support and other agreed programme expenses.

The project budget should identify which resources are contributed in kind, which require cash expenditure and which organisation is responsible for each item.

Possible funding sources include grants, donations, CSR support, institutional contributions, sponsorship and other permitted sources. Any participant contribution or service revenue must be defined for the specific centre and programme rather than assumed.

The operating model should explain how the centre can continue after initial funding ends. Options may include shared use of existing facilities, support from multiple programmes, institutional operating contributions or separately agreed paid training and services where appropriate.

Local Partner does not automatically assume financial responsibility for the project or for Wara’s general activities. Any financial contribution or resource commitment is subject to separate approval.

Where applicable, Wara may receive an agreed payment for actual programme, system, technology, curriculum or implementation services provided to the project, as defined in the project-specific financial arrangement.

Governance, safeguards and risk

The centre must operate within the authority and responsibilities of its participating organisations. A written project arrangement should cover the issues relevant to the particular location and activities.

Important requirements include:

• Premises and asset ownership: confirm permission to use the location, ownership of equipment, access rights, maintenance duties and arrangements if the project ends.
• Participant safety: provide appropriate supervision, safe equipment and premises, incident reporting and relevant safeguarding arrangements.
• Privacy and records: define what learner information is collected, who can access it, how it is protected and how long it is retained.
• Course and assessment integrity: use defined learning outcomes and assessment criteria; make clear whether a completion record, internal certificate or externally authorised qualification is being offered.
• Financial accountability: maintain agreed budgets, expenditure records, asset registers and reporting.
• Institutional separation: each organisation retains its own governance, personnel, assets and liabilities except where specific responsibilities are agreed in writing.

The project should not advertise a centre as operational until its essential requirements are in place. Nor should the presence of equipment be treated as proof that a course is ready to run.

Participation in a centre project does not by itself create a continuing obligation for any partner to finance, operate or expand the centre, nor does it transfer Wara’s commercial or organisational liabilities to another organisation.

Measuring whether the centre is working

The implementation plan should establish a baseline and a small set of meaningful indicators. Depending on the centre’s purpose, these may include:

Targets should be set only after the local model and baseline are understood. Results should be reviewed with the host institution and implementation partners, with corrective actions recorded where needed.

Readiness before implementation

Before a centre is approved to begin delivery, the participating organisations should confirm the following.

• The intended learners, local need and initial scope are defined.
• The host institution and premises have been identified, with the necessary permissions.
• The courses and practical activities have defined learning outcomes.
• Trainers, assistants and supervisors are identified for their respective responsibilities.
• Required equipment, software, connectivity and consumables are available or have an agreed procurement plan.
• Safety, safeguarding, privacy and incident-handling arrangements are documented as applicable.
• The timetable, enrolment process, learning records and assessment arrangements are prepared.
• The establishment budget and recurring operating model are agreed.
• Partner responsibilities, asset ownership, reporting and review arrangements are documented.
• A named coordinator is accountable for implementation and follow-up.

If important requirements remain unresolved, the project should stay in development while those gaps are addressed.

How to explore a centre project

An organisation interested in hosting, establishing, equipping or operating a community training centre can begin by describing its proposed contribution and the local need it wants to address.

Useful information for an initial discussion includes:

• Location and type of host institution.
• Intended learners and the learning or service gap.
• Existing rooms, equipment, connectivity and staff.
• Proposed courses or practical activities.
• Resources the organisation can contribute.
• Support or funding still required.
• Relevant permissions, constraints and potential implementation partners.

The next step is to assess feasibility and agree a project-specific scope, responsibilities, resources, safeguards and measures of success.

A centre should be developed as a functioning learning system, not simply as an equipment installation. Its long-term value depends on whether learners can use the resources consistently, receive appropriate guidance, demonstrate meaningful capability and continue learning when their needs change.

2 - Digital Learning Infrastructure

The implementation idea

Digital learning infrastructure is the shared technical foundation on which computer-based education, digital literacy and selected vocational courses can operate.

The project aims to provide institutions with a consistent, maintainable arrangement for computers, software, connectivity, classroom management and technical support. Rather than designing every installation independently, participating locations could use common specifications and deployment procedures wherever their requirements are similar.

The emphasis is on reliable infrastructure that supports a defined learning purpose. A computer should be selected for the applications and activities it must support. Network equipment should be selected for the teaching and operational functions it needs to enable. Software should be installed because it serves a curriculum or administrative purpose, not simply because it is available.

The proposed approach favours appropriate, reliable equipment, open-source software where suitable, standardised configurations and repeatable maintenance procedures. These choices can reduce avoidable costs and simplify support, but they do not eliminate the need for funding, competent technical staff or replacement planning.

This project is a proposed implementation model. It does not imply that a standard infrastructure package has already been procured, deployed or made available to partner institutions.

Why standardisation matters

When every institution chooses its own hardware, operating system, software and installation method, the resulting environment becomes difficult to support consistently.

A technical problem at one location may require a different solution from the same problem elsewhere. Staff must learn different configurations, software updates become harder to coordinate, and replacing a failed machine may involve repeating much of the original installation work.

A standardised approach can reduce this complexity by establishing:

• A small set of approved hardware configurations.
• A defined operating system and software baseline for each intended use.
• Repeatable installation and configuration procedures.
• Consistent network and classroom-management arrangements.
• Documented troubleshooting and maintenance practices.
• A process for updating the approved configuration without disrupting learning.
• Clear responsibility for technical support, repairs and equipment replacement.

Standardisation should not mean forcing every type of facility to use identical equipment. A school computer classroom, a vocational electronics workshop and a digital-services training centre may have different requirements. The aim is to standardise within appropriate equipment profiles and use cases.

Infrastructure components

The implementation plan should cover the full technical environment rather than treating computers as an isolated procurement item.

1. Computing devices

The hardware specification should reflect the intended learning activities, software requirements, expected usage and available support capability.

For general digital learning, suitable refurbished x86-64 computers may be more economical than purchasing new equipment, provided that the devices are reliable, supportable and adequate for the intended workload.

The Haflong school IT classroom specification proposes the following characteristics for its computer pods:

• SSD storage.
• At least 4 GB RAM, with 8 GB preferred.
• Gigabit Ethernet.
• Reliable keyboard and mouse.
• A monitor of 19 inches or larger where affordable.

These are proposed baseline characteristics for that particular classroom model, not universal minimum specifications for all courses. More demanding software or specialist vocational activities may require a different configuration.

Equipment should be evaluated for condition, compatibility, power requirements, repairability, availability of replacement parts and expected service life. Very old or unsupported equipment should not be selected merely because it is free.

2. Operating system and standard software

For the Haflong school classroom example, the proposed standard operating system is Linux Mint Xfce. The purpose is to provide a consistent, lightweight environment suitable for the selected hardware and educational applications.

The proposed classroom software includes:

The final software list should be controlled and documented. Every application should have a clear learning or operational purpose.

Students do not need to study operating-system administration merely because Linux is used to run the classroom. The operating system is part of the infrastructure; the curriculum should focus on the digital and technical capabilities learners are expected to develop.

Other centre types may need different software. A vocational course involving specialist equipment or applications should define those requirements separately and confirm compatibility before procurement.

3. Wired network and connectivity

A wired local area network can provide a stable foundation for a computer classroom. In the Haflong example, wired Ethernet is proposed for classroom computers, with Wi-Fi available where useful for other devices.

The local network can support:

• Internet access where connectivity is available.
• Distribution of the teacher’s screen to learner computers.
• Classroom-management functions.
• Distribution of learning materials.
• Collection of student work.
• Local administration and technical support.
• Future local learning services where they are separately designed and implemented.

The infrastructure specification should include network switches, structured cabling, router requirements, cable management and suitable power distribution. Cables should not create hazards in student movement areas, and computers should not be placed where they are vulnerable to damage.

Internet availability and local network availability are different requirements. A centre should determine which activities depend on an external connection and which can continue using locally available materials when connectivity is interrupted.

4. Power, furniture and physical arrangement

Computers and network equipment need a safe, practical physical installation. Power distribution, cable routing, ventilation, equipment placement and access for maintenance should be considered before installation.

The Haflong design deliberately avoids requiring expensive specialist computer-lab furniture. It proposes using ordinary school benches where practical and positioning computers and monitors so that equipment remains accessible without occupying student foot space.

The layout must also allow a trainer to supervise the class, enable learners to use the equipment correctly and provide space for related non-computer activities.

Other facilities may need different furniture or environmental controls, particularly where practical tools, specialist equipment or other safety-sensitive activities are involved.

The standard system image

One of the central proposals in the Haflong specification is to maintain a standard, versioned classroom system image.

A system image is a prepared installation containing the approved operating system, software, configuration and standard learning environment. It can be used to restore or deploy compatible computers without manually configuring each device from the beginning.

A standard image may contain:

• The approved operating system.
• Required productivity, browser and programming software.
• Approved educational applications.
• Desktop settings and shortcuts.
• Classroom-management configuration.
• Security settings.
• Required fonts and printer support.
• The standard student environment.

Machine-specific settings, such as hostname, machine identity, network configuration and classroom-management identity, must be applied separately where required.

The project proposes using Clonezilla as a starting point for disk imaging. Larger deployments may later use network-based imaging where the scale and operational requirements justify it.

A controlled image process should include version identification, testing, backup, deployment instructions and a record of changes. For example, an image might progress through versions such as Haflong-IT-Image-v1.0 and Haflong-IT-Image-v1.1.

An updated image should be tested before widespread deployment. The objective is to make installations repeatable without introducing the same fault or unsuitable configuration across every computer.

Classroom management and shared computer use

The infrastructure should support the teaching model rather than dictate it.

In the Haflong classroom design, 40 students are organised into 10 pods, with one computer per four students. Each pod contains two pairs of students who rotate between computer work and a related activity.

This arrangement depends on the room layout, prepared learning activities, teacher instructions and classroom-management capability. The computer is shared, but every learner should have a defined task throughout the lesson.

The proposed use of Veyon and a wired network supports teacher demonstrations and classroom supervision. The teacher’s screen can be displayed on learner monitors during instruction, while each pod can use its own computer during practical work.

The infrastructure must be tested against the intended classroom routine. Screen sharing, computer identities, user access, file distribution and recovery from common problems should be checked before learners begin using the facility.

The equipment design should also consider what happens when one computer fails. The operating plan should explain how the class continues, how the fault is reported and who is responsible for repair.

Installation and deployment process

A repeatable deployment process helps avoid inconsistent configurations and reduces the technical work required at each location.

The proposed process is:

1. Assess the site. Confirm the intended learning activities, equipment count, power, network, room layout and available technical support.
2. Approve the configuration. Select compatible hardware and define the software, network and security baseline.
3. Prepare the master system. Install and configure the approved operating system and applications on a representative computer.
4. Test the master image. Verify required applications, network functions, classroom-management behaviour, security settings and learning tasks.
5. Deploy to compatible devices. Use the approved imaging procedure, then apply machine-specific identities and settings.
6. Validate each installation. Confirm that every device boots, connects, runs the required applications and performs its intended role.
7. Document and hand over. Record device identities, configuration versions, known limitations, maintenance procedures and responsible contacts.

The deployment process should include acceptance criteria. A computer should not be considered ready simply because the operating system starts. It must perform the activities for which it was procured and configured.

Maintenance and technical support

Infrastructure remains useful only when it can be maintained. The implementation plan should establish responsibility for routine checks, fault reporting, repairs, updates and replacement.

Routine support

Depending on the installation, routine work may include:

• Checking computers, monitors, keyboards and mice.
• Inspecting cables and power connections.
• Confirming network connectivity and classroom-management functions.
• Applying approved updates.
• Checking storage and system health.
• Restoring the standard image when necessary.
• Maintaining backups of required configuration and learning resources.
• Recording faults, repairs and equipment changes.

A school-based lab assistant may handle routine startup, shutdown, basic user assistance and fault reporting when appropriately prepared. More complex technical work should be assigned to a person with the necessary competence.

Fault management

The operating model should define how a fault is reported, who assesses it, what work can be done locally and when specialist support is needed.

A useful record identifies the affected device, the reported problem, the action taken, any parts required and whether the equipment has returned to service. This creates a basis for identifying recurring problems and planning replacement.

Updates and configuration control

Operating-system and application updates should be managed in a way that maintains security without unexpectedly disrupting teaching.

The approved configuration should be documented and versioned. Significant changes should be tested on a representative device before being applied across a wider deployment.

Where devices operate with limited internet access, the support plan should specify how updates, software packages and learning resources will be obtained and transferred safely.

Offline-tolerant learning

Some participating locations may have unreliable or expensive connectivity. The infrastructure design should distinguish between functions that require the internet and those that can be delivered locally.

Depending on the course, possible measures include:

• Locally stored learning materials.
• Printed practice activities where appropriate.
• Local copies of approved software installers and system images.
• Local storage and collection of learner work.
• A documented process for synchronising records when connectivity returns.

The wider learning framework envisages online-first delivery that tolerates offline conditions, with local caching or synchronisation where appropriate. The exact approach must be designed and tested for the selected learning platform and environment.

Offline operation should not be assumed to work automatically. The project must identify which content, records and activities remain available, what happens when data must be synchronised and how conflicting or incomplete updates are handled.

Partner roles and responsibilities

Several organisations may contribute to digital learning infrastructure. Their roles should be agreed according to the installation and the capabilities they can provide.

A single organisation may fulfil several roles if it has the appropriate capability. The project should nevertheless name who is accountable for each responsibility.

Wara KarmaYoga Foundation may contribute to the educational purpose, community coordination or programme development within an agreed charitable scope. Wara Systems may provide separately agreed commercial technology or implementation services. Neither role should be assumed without a project-specific arrangement.

Local Partner may be considered as a potential collaborator where there is mutual interest and formal agreement. Its premises, personnel, funding or technical resources must not be treated as committed in advance.

The project should also define ownership of equipment, software and documentation, the rights to use the standard system image, access to administrative credentials, data protection responsibilities and the process for handover if a partner changes.

Procurement and cost planning

The project budget should cover the complete installation and its expected operating needs rather than only the purchase price of computers.

Relevant cost categories may include:

• Computers, monitors and peripherals.
• Network switches, routers, cabling and installation.
• Power distribution and any necessary electrical work.
• Furniture, mounting and cable-management materials.
• Software configuration and deployment.
• Site testing, documentation and staff orientation.
• Connectivity and recurring utilities.
• Maintenance, repairs, spare parts and replacement equipment.
• Technical support and approved updates.

Refurbished equipment may lower initial costs, but its condition and expected service life must be assessed. A lower purchase price may not be economical if the equipment fails frequently, cannot run the required software or is difficult to repair.

The budget should state which items are donated, contributed in kind, purchased or maintained by a partner. It should also identify who will pay recurring costs after the initial installation funding is exhausted.

A project should not proceed to procurement until the intended use, technical specification, site readiness, budget and maintenance responsibility have been agreed.

Security, privacy and responsible use

The infrastructure must be configured to support safe use and protect institutional and learner information.

The implementation plan should address:

• Appropriate user accounts and access permissions.
• Administrative credential control.
• Approved software installation and update procedures.
• Safe browsing and responsible use of online services.
• Protection of learner records and submitted work.
• Backup and recovery arrangements for information that must be retained.
• Physical security and safe handling of equipment.
• Procedures for reporting suspected misuse, data exposure or technical incidents.

Classroom-management tools should be configured for legitimate teaching and administration. Access to learner devices or records should be limited to authorised purposes and handled in accordance with the host institution’s policies and applicable requirements.

A standard image is not a substitute for ongoing security management. Installed software, configurations and access arrangements must be reviewed as the environment changes.

Measures of implementation success

The project should evaluate both installation quality and continued usefulness.

Possible measures include:

Targets should be established after the project scope and baseline are known. Reporting should distinguish a completed installation from a facility that remains usable over time.

Readiness before deployment

Before infrastructure is installed for a participating institution, the implementation team should confirm the following.

• The learning purpose and intended applications are defined.
• The site, power, room layout and connectivity have been assessed.
• The hardware and software configuration has been approved.
• Equipment is compatible, supportable and suitable for the intended workload.
• Network, security and classroom-management requirements are documented.
• A tested master configuration and deployment procedure are available where imaging is used.
• Technical support, maintenance and repair responsibilities are assigned.
• Equipment ownership, administrative access and documentation handover are agreed.
• The installation and recurring operating budget is approved.
• Acceptance tests and post-installation review arrangements are defined.

If these requirements are not met, the project should remain in preparation until the gaps have been addressed.

Discuss an infrastructure project

A school, community institution, training provider, technology company or funding organisation can begin by identifying the learning environment it wants to establish or improve.

The initial discussion should cover the location, intended users, existing equipment, required learning activities, current technical limitations, resources available and support still needed.

The next step is a site and requirements assessment, followed by an agreed technical specification, cost plan, division of responsibilities and implementation schedule.

The objective is not to deploy the largest possible quantity of equipment. It is to create a technical environment that supports the intended learning activities reliably, can be maintained by identifiable people and remains useful after the initial installation is complete.

3 - Training and Assessment Network

Why a training and assessment network is needed

A training programme requires more than a syllabus, a classroom and an instructor. Learners need opportunities to practise, demonstrate their capabilities and receive fair assessments against clearly defined standards.

When training is delivered across different schools, community centres and vocational facilities, maintaining consistent standards becomes even more important. A learner should not be considered competent merely because they attended classes or completed the prescribed number of sessions.

The proposed Training and Assessment Network will help connect the people and processes required to deliver learning responsibly. It is intended to support the broader KarmaYoga learning framework across academic subjects, digital literacy and vocational occupations.

The network is a development concept, not a claim that a complete network of trainers or authorised assessment providers is already operational.

What the network is intended to connect

The network brings together five related capabilities:

• Training delivery: People and institutions that can teach the defined competencies and guide learners through appropriate practice.
• Practical learning: Facilities, equipment, materials and activities that allow learners to develop and demonstrate real capabilities.
• Assessment: Controlled activities that establish whether the required competencies have been demonstrated.
• Verification and records: Processes for reviewing evidence, recording verified competencies and tracking progress.
• Qualification and progression: Clear requirements for course completion, internal credentials and any external qualification route that has been established.

These capabilities may be provided by one institution or distributed across several partners. Their responsibilities must be defined before a programme begins.

One learning architecture across different settings

KarmaYoga uses a common learning and competency architecture for school education, vocational training and continued learning.

The underlying principle is:

Learn → Practise → Demonstrate → Verify → Qualify → Work

Each course should begin with a clear definition of what the learner is expected to know or do. The course is then organised around competencies, meaningful tasks, lesson units, practice activities, assessment requirements and evidence.

The same competency definitions and assessment standards should be used wherever the same course is delivered. A school may develop a competency gradually, while a vocational centre may provide more intensive practice. The learning environment and pace can differ without changing what the competency means.

This approach is intended to make learning progress transferable across settings rather than forcing learners to start again whenever they move from school to vocational training or return to education later.

The roles within the network

The following roles describe the capabilities the proposed network may need. One person or institution may fulfil more than one role where appropriate, but assessment and verification responsibilities must remain clear.

Training providers

Training providers organise and deliver courses against the approved course design. They arrange learning sessions, guide practice, maintain attendance and progress records, and ensure that learners have access to the required learning resources.

A provider must be able to demonstrate that its trainers, facilities and equipment are suitable for the particular programme.

Trainers and instructors

Trainers help learners understand concepts, perform tasks safely and develop the required competencies. Their responsibilities may include:

• Preparing and delivering lessons using the approved learning materials.
• Demonstrating procedures and explaining common errors.
• Guiding practice at different levels of difficulty.
• Identifying learning gaps and arranging remedial practice.
• Preparing learners for assessment without misrepresenting practice results as verified achievement.
• Maintaining appropriate learner progress records.

Subject knowledge alone may not be sufficient for a practical trade. Relevant occupational experience, instructional capability and any applicable trainer requirements must also be considered.

Practical supervisors and workplace mentors

Some competencies require equipment, realistic working conditions or supervised field experience. Practical supervisors and workplace mentors can help learners apply what they have learned in appropriate settings.

Their responsibilities should include maintaining safety, defining the permitted scope of learner activity, observing performance and providing feedback. Workplace exposure must not be treated as permission for a learner to undertake tasks beyond their competence or legal authority.

Assessors and verifiers

Assessors determine whether a learner has demonstrated the required capability against defined assessment criteria. Verifiers review whether the assessment process and its evidence meet the applicable standard.

Depending on the course and qualification route, these functions may be performed by different people or by an authorised external organisation. Where independence is required, the person who teaches a learner should not automatically be treated as the sole authority for confirming that learner’s competence.

Any mandatory assessor qualifications, authorisations or independence requirements must be established for the specific programme.

Qualification and certification partners

Some programmes may lead to an internal course credential or qualification. Others may be designed to support an external qualification through an eligible awarding body, Sector Skill Council or other authorised route.

A partner’s role and authority must be confirmed before the programme is advertised as leading to an externally recognised qualification. The existence of a potential mapping to a national occupational standard does not itself establish approval to train, assess or certify against it.

The assessment process

Assessment should establish what a learner can actually do, rather than simply what content the learner has encountered.

The proposed process follows a consistent sequence:

1. Define the competency. Specify the capability, the conditions under which it must be demonstrated and the required performance standard.
2. Define the task and evidence. Establish what the learner must perform, solve, produce or explain to demonstrate the competency.
3. Prepare the learner. Provide suitable instruction, demonstration, guided practice and independent practice.
4. Conduct the assessment. Use an appropriate, controlled activity that measures the required capability.
5. Review the evidence. Compare the observed performance or submitted work with the assessment criteria.
6. Record the result. Distinguish between a competency that is being learned, one that has been demonstrated and one that has been verified by an appropriately authorised person.
7. Determine the next step. Record successful achievement or identify the additional practice and reassessment required.

Evidence may include a practical demonstration, completed physical work, a correctly solved task set, a digital artefact, a written response or a verified project output. The evidence must be appropriate to the competency being assessed.

For example, a learner studying network installation may need to terminate and test a cable, explain relevant safety precautions and produce evidence that the connection meets the required criteria. Attendance at a networking class would not, by itself, demonstrate that capability.

Competency records and learner progression

A learner’s progress should be recorded at the level of the competencies that have actually been demonstrated and verified.

The intended competency states are:

Not Started → Learning → Demonstrated → Verified

These states distinguish participation in learning from successful performance and authorised verification. They should not be treated as interchangeable.

A reliable competency record can help a subsequent trainer understand what the learner has already achieved, what remains incomplete and what the next learning step should be. Properly verified competencies should be carried forward where the same competency and standard remain applicable.

This supports the principle that learners should not needlessly repeat learning they have already mastered. It does not remove the need to check prerequisites, the relevance of previous evidence, changes in occupational standards or any requirements imposed by an external qualification.

The network should also make a clear distinction between:

• Completion of a lesson or training session.
• Completion of a course.
• Verification of individual competencies.
• Completion of an internal qualification.
• Achievement of an externally recognised qualification or licence, where applicable.

These are different achievements and must be recorded and communicated accurately.

Connection with the Course Master

The Course Master is the academic source of truth for each course. It defines the competencies, tasks, lesson units, learning elements, practice and assessment requirements.

The same controlled course design should support the materials used by trainers and learners, including:

• Student learning materials.
• Teacher and trainer guides.
• Demonstrations and practice activities.
• Assessment tasks and criteria.
• Printable resources and digital learning content.
• Records of course and competency completion.

When a course is updated, its materials and assessment requirements should be reviewed together. The network should avoid situations in which a trainer teaches one version of a course while the assessment measures a different set of competencies.

Course versions and competency identifiers should be maintained consistently so that records remain interpretable as learning materials evolve.

Quality assurance and continuous improvement

Consistent assessment requires more than a common examination paper. The network should establish appropriate procedures for maintaining standards across trainers, providers and locations.

Proposed quality measures include:

• Trainer suitability: Verify relevant knowledge, practical capability and applicable trainer requirements.
• Assessment consistency: Use documented criteria, suitable evidence and clear decision rules.
• Assessment review: Sample assessment records and results where appropriate to identify inconsistent decisions.
• Learner feedback: Collect feedback on instruction, practice opportunities, facilities and assessment clarity.
• Appeals and reassessment: Establish a transparent way for learners to question results and demonstrate competence again.
• Record integrity: Restrict access to learner records and maintain appropriate correction and review procedures.
• Course review: Update learning and assessment materials when evidence shows that they are unclear, ineffective or no longer appropriate.
• Safety and scope: Review whether training and assessment activities are safe and remain within the permitted scope of the programme.

The exact quality assurance procedure should reflect the nature of the course, the risks associated with the occupation and any external requirements that apply.

Relationship with national skill standards

Where a suitable national occupational qualification exists, a course may be reviewed against the relevant Qualification Pack, National Occupational Standards and assessment requirements.

The mapping process should establish:

• The exact qualification and its current status.
• The extent to which its competencies match the proposed course.
• Any additional prerequisites, practical requirements or assessment conditions.
• The eligibility and authorisation requirements for training and assessment.
• The route through which an eligible learner could receive the external qualification.
• The funding or scheme conditions, if a programme is intended to use a supported training route.

If no suitable external qualification exists, a competency-based programme may still be developed where it is appropriate and responsibly designed. The gap and the status of the programme should be documented.

KarmaYoga’s internal Foundation, Certificate and Diploma stages describe progressive capability and responsibility. They must not automatically be represented as equivalent to NSQF levels or national qualifications. A course credential must not be advertised as nationally recognised unless the relevant recognition and authorisation have been established.

How the network may be organised

The network could operate through a combination of local providers and specialist partners rather than requiring every training centre to maintain every capability.

A community training centre, for example, might provide the venue, local learner support and basic practical facilities. A specialist trainer could deliver a particular course, while a separate eligible assessor or assessment organisation handles formal assessment where required.

The proposed operating sequence is:

Demand identified → Course approved for delivery → Trainer and facility prepared → Learners trained → Competencies assessed → Evidence verified → Results recorded → Next steps identified

The sequence is a planning model. Its adoption requires defined responsibilities, suitable resources and agreed operating procedures.

Potential partner contributions

Different organisations may contribute to the network according to their capabilities and the needs of a particular programme.

The Wara KarmaYoga Foundation may coordinate charitable education and skill-development activities, seek resources and support access for underserved learners, subject to its arrangements and capacity.

Wara Systems may separately provide agreed commercial technology or operational services. Those services should be documented independently from charitable funding and programme responsibilities.

Local Partner may participate in a specific programme only where collaboration is mutually agreed and formally established. No institutional participation or approval should be assumed.

Resources required

The resources needed will depend on the occupations, number of learners, location and assessment route. A programme-specific plan should identify:

• Trainer and practical supervisor requirements.
• Trainer preparation and continuing development.
• Learning materials and controlled course versions.
• Classroom, workshop or field-learning facilities.
• Equipment, consumables and maintenance.
• Assessment instruments and evidence-recording methods.
• Assessor or verifier costs, where applicable.
• Learner support, accessibility and safety arrangements.
• Record management, quality review and reassessment.
• Travel and coordination across distributed locations.

Costs should be estimated only after the intended course portfolio, delivery volume, partner responsibilities and applicable external requirements are understood. No fixed network capacity or standard operating cost is assumed at this stage.

Safeguards and learner protection

The network must protect the integrity of learning records and the interests of learners.

Programmes should provide clear information about the course, prerequisites, assessment requirements, fees where applicable, the credential offered and any limitations on external recognition. Learners should not be led to believe that training guarantees employment, income or a nationally recognised qualification.

Assessment evidence and personal information should be collected only for defined purposes, accessed by authorised people and retained under appropriate procedures. Photographs, videos or workplace evidence should be handled with suitable consent and privacy safeguards.

Practical activities must be supervised according to their risks. Healthcare, electrical, emergency-response and other safety-sensitive pathways require particular care to ensure that training does not authorise learners to perform regulated or hazardous work beyond their permitted competence.

Measuring progress and quality

The network should be evaluated on the quality of learning and verification, not merely on the number of sessions held or certificates issued.

Possible indicators include:

• Number of courses with documented competencies and assessment criteria.
• Number of trainers whose suitability has been reviewed.
• Availability of required practical facilities and equipment.
• Learner participation, retention and course completion.
• Competencies demonstrated and verified against defined standards.
• Assessment consistency and results of quality reviews.
• Reassessment outcomes and time taken to address identified gaps.
• Learner feedback and completion of corrective actions.
• Number of courses with a documented and verified external qualification route, where applicable.
• Evidence that learners can progress to further learning or suitable work, where such follow-up is feasible.

Targets should be set only after the initial delivery model, baseline and available resources are established. Employment and income outcomes should be reported separately from training outputs and should not be attributed to the network without adequate evidence.

Readiness before implementation

Before launching a course through the proposed network, the responsible partners should confirm:

• The course has a defined scope and intended learner outcomes.
• Competencies, tasks, practice and assessment criteria are documented.
• Trainers and practical supervisors are suitable for their assigned roles.
• Facilities, equipment and consumables meet the course requirements.
• Assessment, verification and reassessment responsibilities are agreed.
• The internal credential and any external qualification route are accurately described.
• Learner records, evidence handling and privacy arrangements are in place.
• Safety, complaints and learner-protection procedures are defined.
• Funding and operating responsibilities are understood.
• Quality indicators and review arrangements have been established.

A course should be described as ready for implementation only when the requirements relevant to that course have been addressed.

Explore related opportunities

The Training and Assessment Network is one component of a wider learning and livelihood system.

• Community Training Centres — the local facilities in which learners may study and practise.
• Digital Learning Infrastructure — the equipment, software and technical support that enable digital learning.
• Vocational Skills Programme — the proposed occupational pathways that require suitable training and assessment.
• Livelihood Development Programme — the wider goal of connecting demonstrated capability with realistic pathways towards work and enterprise.

Discuss a training or assessment partnership

We welcome discussions with educational institutions, training organisations, subject specialists, employers, assessment providers, community organisations and potential funders interested in strengthening competency-based learning.

A useful initial discussion should identify the proposed occupation or subject, the learners to be served, the competencies to be developed, the available facilities, the intended assessment route and the responsibilities each partner may be able to undertake.

The next step is to establish the scope, resources, standards and readiness requirements of a specific programme. Participation in a discussion does not constitute approval, accreditation or a commitment to deliver a course.

4 - Livelihood and Market Linkages

1. Project Overview

Training becomes more valuable when learners can apply what they have learned to real tasks. However, completing a course does not automatically lead to employment, customers or income. Workers may lack access to employers, reliable customer demand, work equipment, professional networks or the ability to organise and price their services.

At the same time, businesses and households need people who can perform defined tasks reliably. Small organisations may struggle to find suitable service providers, while individual workers and small producers may find it difficult to reach customers beyond their immediate communities.

The proposed Livelihood and Market Linkages initiative aims to address this gap by connecting demonstrable capability with real demand.

It brings together four related activities:

• Demand identification: Understand what employers, customers and organisations actually need.
• Capability development: Help people acquire the practical skills required for defined work.
• Work linkage: Create appropriate routes for capable people to reach employers, customers, service providers and production networks.
• Enterprise development: Help experienced workers explore independent service provision, coordination, production or small-business opportunities.

The initiative is intended to support people at different stages, from first-time workers to experienced individuals seeking more independent work.

It may support local employment, remote or digitally delivered work, distributed production, independent services and small enterprises. Relocation may be relevant for some occupations, but it should be considered only where the opportunity, requirements and worker’s circumstances justify it.

Intended progression

Learning → Demonstrated Skill → Work Opportunity → Income → Enterprise

This is a pathway of possibilities, not a guaranteed outcome. Progress depends on capability, actual demand, working conditions, fair commercial terms and the opportunities available to each person.

The project is proposed. It does not imply that a functioning marketplace, established employer network, guaranteed assignments or a continuing income stream is already available.

2. Project Model

The project should be organised around the relationship between a person’s capabilities and the work that needs to be done. It should not begin by training large numbers of people for occupations without a credible understanding of demand.

A. Identify demand before expanding training

Potential sources of demand include:

• Employers seeking workers with defined capabilities.
• Businesses requiring recurring technical, administrative or operational services.
• Households needing suitable local services.
• Healthcare, education, hospitality and tourism organisations requiring qualified or appropriately trained support personnel.
• Customers requiring repair, installation, maintenance or other technical services.
• Producers and buyers who can support distributed production and supply arrangements.
• Organisations seeking remote or digitally delivered services.

Demand assessment should establish the actual task, expected quality, required competence, location, volume, frequency, working conditions and likely payment terms.

An expression of interest is not the same as a confirmed order or job vacancy. The project should record the difference between potential demand, verified demand and a formally agreed assignment.

B. Prepare people for defined work

Training and preparation should be connected to the requirements of the selected occupation or service.

The common learning pathway is:

Learn → Practise → Demonstrate → Verify → Qualify → Work

Depending on the occupation, preparation may include practical training, supervised experience, work samples, competency assessment, communication, digital literacy, customer handling, safety procedures and workplace expectations.

KarmaYoga’s intended vocational progression distinguishes increasing levels of responsibility:

These are internal pathway descriptions. They must not be treated automatically as nationally recognised qualifications, professional licences or permission to perform regulated work.

Where an external occupational qualification is relevant, its current status, competency coverage and authorised assessment and certification route must be verified separately.

C. Connect capability with suitable opportunities

Once a person’s relevant capability has been demonstrated, the project may help connect that person with suitable work opportunities.

Possible routes include:

• Employment: Introduction to employers with relevant vacancies and selection requirements.
• Contract or assignment work: Matching capable workers with clearly defined tasks and agreed deliverables.
• Local service provision: Connecting independent workers with households, businesses or institutions that need their services.
• Distributed production: Coordinating orders, materials, production, quality checks and delivery across multiple workers or locations.
• Remote services: Connecting suitable workers with organisations that can use digitally delivered work.
• Enterprise development: Helping experienced workers assess demand, pricing, costs, customer relationships and the practical requirements of running a service.

Each route requires a different arrangement. Employment must be distinguished from independent contracting, and a training provider must not imply that a worker is self-employed simply because an assignment is available.

D. Organise the work process

Where a marketplace or other coordination mechanism is established, a defined work lifecycle can help protect both the worker and the customer:

Demand → Scope → Assignment → Work → Quality Check → Acceptance → Payment → Work History

The process should establish:

1. Who is requesting the work and who is responsible for payment.
2. What task or deliverable is required and what is outside its scope.
3. Which skills, licences, equipment or other prerequisites are necessary.
4. The agreed price or compensation, expenses, deadlines and payment conditions.
5. How work quality will be checked and how disagreements will be handled.
6. When payment becomes due and how completion is recorded.
7. What feedback or evidence may be retained to support future opportunities.

Not every type of work requires the same workflow. Healthcare, care, construction, electrical work and other safety-sensitive activities need additional requirements appropriate to their professional and legal boundaries.

E. Support progression towards enterprise

Some workers may eventually be ready to organise a service rather than perform every task themselves.

Enterprise preparation may cover customer discovery, costing, pricing, procurement, quality control, scheduling, recordkeeping, payment management, applicable registrations and the responsibilities of employing or supervising others.

The project should help participants assess whether an enterprise is viable before encouraging them to incur expenses or borrow money. Enterprise development is a possible progression, not a required outcome for every learner.

Roles in the proposed model

The marketplace is intended to be open to suitable external organisations and service providers. Participation must be based on relevant capability, eligibility, service quality and agreed terms, rather than exclusive access to WARA.

3. Resources and Financial Model

The project requires a combination of people, demand information, practical preparation, reliable work arrangements and suitable coordination systems. The exact requirements depend on the occupations and locations selected for implementation.

People and capabilities

Potential resources include:

• A coordinator who can engage employers and customers and validate demand.
• Trainers and assessors appropriate to the selected occupations.
• Employer, customer and industry contacts.
• Staff able to support work matching, documentation, communication and issue resolution.
• Mentors or business-support professionals for participants exploring independent services.
• Qualified specialists and authorised service providers for regulated occupations.

The project should not treat a large contact list as proof of an effective market. Useful partnerships require defined needs, accountable contacts and practical arrangements for offering or delivering work.

Technology and operational resources

Depending on the model, the initiative may require:

• A structured record of worker capabilities and verified evidence.
• A catalogue of services, occupations and work requirements.
• An employer and customer relationship process.
• Assignment, scheduling and communication workflows.
• Agreed quality, acceptance and payment records.
• Appropriate privacy, security, grievance and dispute-handling procedures.
• Reporting to distinguish enquiries, confirmed opportunities, completed work and actual payments.

These are possible project requirements, not claims that a complete marketplace or all these systems are currently operational.

Potential funding and revenue

Different parts of the initiative may require different financial arrangements.

Charitable and programme funding may support eligible activities such as:

• Vocational training and practical assessment.
• Access to learning equipment and facilities.
• Career and livelihood guidance.
• Support for participants who cannot afford training.
• Employer engagement and demand assessment.
• Enterprise preparation for eligible beneficiaries.

Potential sources include CSR sponsorship, philanthropic donations, grants and other permitted programme funding. Any funding arrangement must specify its intended use, eligibility conditions, reporting requirements and accountable recipient.

Commercial market activities may generate revenue through arrangements such as:

• Payment by customers for completed services or products.
• Employment compensation paid by employers to workers.
• Agreed commercial fees for marketplace or coordination services.
• Separately contracted technology, implementation or operational services.
• Revenue earned by independent service providers or enterprises from their customers.

The party receiving revenue and the party bearing costs must be clearly identified. Any marketplace fee, service charge or commission must be transparent, commercially justified and legally appropriate for the relevant activity.

The Trust’s charitable programmes must remain distinct from the commercial activities of Wara Systems . Any shared resources or related-party services should be documented and handled under appropriate governance and financial arrangements.

Ramakrishna Mission remains an independent institution. Any participation would require mutual agreement and relevant institutional approvals. RKM does not automatically assume financial responsibility for the project or for Wara’s general activities. Any RKM financial contribution or resource commitment is subject to separate approval.

Where applicable, Wara may receive an agreed payment for actual programme, system, technology, curriculum or implementation services provided to a project, as defined in the project-specific financial arrangement.

Sustainability

A sustainable model should distinguish the cost of developing capability from the cost of connecting people to work and the cost of delivering the work itself.

Training may require subsidy even when the resulting service is commercially viable. Conversely, a marketplace may need a viable transaction model before it can support ongoing coordination. Neither should be assumed to finance the other automatically.

The project should assess costs, funding sources, participant affordability, employer willingness to pay, transaction economics and the responsibilities of each party before expanding.

4. Governance, Legal Boundaries and Risk

Market linkage can affect people’s time, income, safety and financial decisions. Clear expectations and fair treatment are therefore essential.

Fair work and transparent terms

Before a worker accepts an assignment, the relevant parties should understand the scope of work, expected quality, compensation, payment timing, expenses, deadlines, cancellation conditions and the process for resolving disagreements.

The project should not advertise speculative work as confirmed employment or require participants to pay recruitment or placement charges without a clearly documented, lawful and appropriate basis.

No participant should be promised a job, minimum assignment volume, income level or guaranteed business success. Training completion does not itself establish that a customer will purchase the participant’s services.

Competence and professional boundaries

Work opportunities should match demonstrated competence and any applicable eligibility, registration, licence or supervision requirements.

Where the work is regulated or safety-sensitive, the project must verify the relevant requirements before matching a participant to the opportunity. A general vocational certificate must not be presented as authorisation to perform work that legally requires additional qualifications or registration.

Participant protection and information

The project should establish appropriate safeguards for:

• Worker and customer identity and eligibility checks.
• Consent for sharing personal information and work records.
• Confidentiality and protection of customer or employer information.
• Fair selection and transparent assignment decisions.
• Complaints, non-payment, unsafe conditions and disputes.
• Misrepresentation, fraud and inappropriate recruitment practices.
• Financial records, conflicts of interest and accountability.
• Feedback and work-history records that are accurate and proportionate.

Workers should have a clear route to raise concerns. Customers should have a clear route to report quality or delivery issues. Serious safety, exploitation or legal concerns require appropriate escalation.

Institutional responsibilities

Wara KarmaYoga Foundation , Wara Systems , training providers, employers and customers retain their respective responsibilities. Participation by an organisation does not automatically make it responsible for another party’s staff, debts, contracts or commercial liabilities.

Principal risks and controls

5. Mission Value and Expected Outcomes

Livelihood and Market Linkages is intended to make practical capability more useful by improving the connection between learning, work and the people or organisations that need services.

For participants, the value may include clearer work pathways, access to relevant employers or customers, better understanding of work expectations and opportunities to build a record of demonstrated capability.

For employers and customers, the value may include a more structured way to identify suitable people, communicate task requirements and assess completed work.

For communities, the model may support local services, distributed production, independent work and small enterprises where genuine demand exists. It may also help identify where training programmes need to change because the market does not require the skills being taught.

Measures of progress

A pilot should establish baseline information and track measures appropriate to its scope, such as:

• Number of employers, customers and organisations engaged.
• Number of work opportunities verified, rather than merely collected.
• Number of participants who demonstrate the required capabilities.
• Number of participants referred, selected or assigned to work.
• Number of assignments completed and accepted.
• Payment completion and timeliness, where records are available.
• Repeat orders, recurring employment or continued customer relationships.
• Participant and customer feedback.
• Participant progression towards more independent work or enterprise.
• Cost of training and linkage activities relative to the outcomes achieved.

Training enrolment and course completion are useful activity measures, but they are not sufficient evidence of livelihood impact. The project should separately record whether participants actually obtain work, complete it, receive payment and choose to continue.

A staged implementation approach

The initiative can be developed in manageable stages:

1. Select a market: Choose a locality, occupational domain or service category where a real need can be investigated.
2. Validate demand: Engage potential employers and customers, define the tasks and establish realistic commercial terms.
3. Prepare participants: Identify the required competencies, suitable training, assessment and any professional prerequisites.
4. Establish work arrangements: Agree on matching, assignment, quality, payment, accountability and participant safeguards.
5. Run a limited pilot: Work with a manageable group of participants and verified opportunities.
6. Evaluate and improve: Review actual work, payment, participant experience, customer satisfaction and operating costs before considering expansion.

The first pilot should be narrow enough to evaluate properly. A local technical-service network, a digital business-services pathway and a distributed production model may all support livelihoods, but each needs a different demand assessment, operating process and commercial arrangement.

Explore related initiatives

• Vocational Skills: Develop practical capability for defined occupations.
• Livelihood Development: Understand the broader programme connecting learning, work and enterprise.
• Training and Assessment Network: Support consistent training, assessment and evidence of competency.
• Technical and Service Provider Network: Explore the organisation of technical and local service work.
• How to Apply or Collaborate: Discuss a potential partnership or implementation proposal.

The project is intended to create measurable value within its own scope. If successful, its experience and learning may be reused or adapted for future programmes, subject to separate consideration and approval.

5 - HealthCareNet

From an individual entrepreneur to a connected care network

Healthcare needs are rarely limited to a single visit to a doctor. Patients and families may need help finding the appropriate service, arranging appointments, understanding where to obtain prescribed investigations, coordinating transport or care, and keeping track of follow-up requirements.

These activities require coordination, but they must also respect the boundaries between clinical care, trained support work and administrative assistance.

HealthCareNet is a proposed network concept within the broader WARA livelihood and community-development framework. It explores how trained individuals, care-service providers, healthcare institutions and community organisations could work together to improve access to appropriate services.

The objective is not to create a substitute for a hospital, clinic, diagnostic laboratory or licensed healthcare professional. It is to develop the people, processes and relationships that can help patients navigate existing services and receive appropriate support.

HealthCareNet is a concept under development. It should not be interpreted as an announcement of an operating healthcare network, an established provider directory, a live referral system or a guaranteed source of work.

What HealthCareNet could connect

The proposed network may bring together several distinct service areas. Each would require its own defined scope, suitable personnel, operating arrangements and safeguards.

Care at home and in the community

Trained care workers may support people who need assistance with everyday activities, including older adults, people recovering from illness and others requiring appropriate non-clinical support.

Depending on the training and agreed service scope, this may include personal-care assistance, support with daily routines, observation and communication of concerns, and assistance to families and caregivers.

Care workers must understand their limits and know when to contact a family member, supervisor or qualified healthcare professional. Training for a support role does not automatically authorise clinical procedures or independent medical decisions.

Patient navigation and service coordination

Some patients and families need help navigating a complex service environment. A trained coordinator could help with administrative activities such as:

• Finding appropriate healthcare providers from a verified directory.
• Arranging appointments and communicating scheduling information.
• Helping patients understand the administrative steps involved in accessing a service.
• Coordinating appointments and referrals requested or directed by qualified providers.
• Tracking whether reports or follow-up appointments have been received or arranged.
• Helping patients identify the appropriate provider when their needs fall outside the coordinator’s role.

The coordinator would not diagnose conditions, decide which treatment a patient needs or independently interpret clinical findings.

Digital healthcare and telehealth support

Digital tools can help patients and providers coordinate appointments, records and communications. A suitably trained digital healthcare assistant may support administrative workflows, such as appointment scheduling, record handling, teleconsultation preparation and patient communication.

Such work requires appropriate privacy controls and clear responsibility for patient information. A digital assistant must not present administrative support as medical advice or make clinical decisions on behalf of a provider.

Remote consultation, where offered, must be delivered by an appropriately qualified professional through suitable arrangements. HealthCareNet does not itself establish the availability of doctors or a telemedicine service.

Diagnostics and specialist support

Diagnostics-related activities require particular care because they may involve clinical procedures, biological samples, patient identification, laboratory processes and regulated responsibilities.

A future network could explore coordination between patients, eligible diagnostic providers and appropriately trained personnel. Activities such as sample collection would require the relevant training, authorisation, facilities, procedures and provider arrangements.

Phlebotomy and basic emergency medical response are separate specialist training pathways. Neither should be treated as a routine extension of general caregiving or patient-coordination training.

Community care and service access

Community organisations may help people understand what services exist and how to approach them. With appropriate partnerships, programmes could also support caregiver awareness, community education and referral to suitable services.

These activities may be particularly useful for people who face difficulties with digital services, travel, communication or navigating institutions. Community outreach must not become an unqualified medical screening or treatment service.

A network of defined roles

HealthCareNet should not depend on every participant performing every healthcare-related task. Its proposed model separates roles according to capability, responsibility and the requirements of the service.

These are potential roles, not a list of currently appointed participants. A person may undertake a role only when the necessary competence, authorisation and arrangements are in place.

Training pathways that support the network

HealthCareNet should draw on the broader KarmaYoga competency-based learning architecture rather than treating a single short course as preparation for all healthcare-related work.

The proposed learning progression is:

Learn → Practise → Demonstrate → Verify → Qualify → Work

The relevant competencies, practice requirements and assessments must be defined for each occupational pathway.

Potentially relevant course families include the following.

Home, Patient and Elderly Care Assistant

This pathway focuses on appropriate non-clinical care and support for people who need assistance at home or in other suitable care settings.

The course would need to define the permitted activities, safety requirements, communication responsibilities, practical assessment and escalation procedures.

Digital Healthcare and Telehealth Assistant

This pathway focuses on administrative and digital support for healthcare services, including appropriate record handling, appointment coordination and telehealth workflows.

It must distinguish administrative tasks from clinical judgement and protect sensitive health information.

Clinical and Emergency Support Assistant

This catalogue family contains two separate specialist tracks:

• Phlebotomy: Requires a dedicated curriculum, practical training, suitable facilities and the relevant assessment and authorisation arrangements.
• Basic emergency medical response: Requires a separate curriculum, appropriate practical preparation and compliance with applicable occupational and service requirements.

These tracks are not interchangeable, and neither is automatically included in general care-assistant training.

The courses are proposed pathways. Their presence in the course framework does not mean that each is currently available for enrolment or that external qualification arrangements have been secured.

From training to suitable work

HealthCareNet could eventually provide a practical connection between verified competencies and appropriate service opportunities.

The intended sequence would be:

Local need → Defined service → Suitable training → Demonstrated competency → Appropriate assignment → Service delivery → Quality review

For example, a community may need help coordinating appointments for older adults. The first step would be to establish the actual need, identify the organisations or professionals involved, define what the coordinator may and may not do, and determine how the work will be funded.

Training could then prepare people for the defined role. Where assessment confirms the required competencies, a suitable provider or programme might consider them for relevant work.

An assignment would still depend on service demand, eligibility, provider requirements, available funding and appropriate supervision. Completing a course would not guarantee an assignment, employment or income.

Where a role involves regulated work, the relevant professional qualifications, registration, authorisation and service arrangements must be verified independently of the KarmaYoga learning pathway.

Possible operating models

The network could take different forms depending on the needs of a community and the partners willing to participate.

Provider-linked coordination

A community organisation or service coordinator could help patients navigate existing healthcare providers. Each provider would retain responsibility for its own professional services, appointments, records and clinical decisions.

Home and community care services

An eligible care-service provider could organise trained care workers, scheduling, supervision, service records and communication with families. The provider would need clear service boundaries, safeguarding procedures and arrangements for handling concerns or emergencies.

Healthcare institution support

A hospital, clinic or other healthcare institution could engage suitable personnel for defined administrative, digital or non-clinical support activities under its own operating and compliance arrangements.

Community access programmes

A charitable or community programme could help people understand available services, navigate access barriers or obtain appropriate assistance. Its scope, funding, staffing and referral arrangements would need to be agreed before delivery.

These models are alternatives to explore, not services that HealthCareNet currently promises to provide.

Technology and information management

Technology may help coordinate a network, but it cannot substitute for appropriate clinical responsibility, capable staff or dependable service providers.

Depending on the model eventually adopted, technology requirements may include:

• A verified directory of participating providers and their service scope.
• Appointment and referral coordination.
• Assignment and scheduling records for eligible support workers.
• Secure administrative communication.
• Appropriate records of service delivery and follow-up.
• Role-based access to information.
• Audit trails and procedures for correcting inaccurate records.
• Reporting on service availability, quality and unresolved issues.

Any patient-record or care-coordination system would require a defined purpose, suitable access controls, privacy safeguards, retention rules and responsibility for the information it contains.

Health information should not be collected simply because a system makes it possible. Only information necessary for an authorised purpose should be handled, with appropriate consent or other lawful grounds.

No specific HealthCareNet platform, patient-management system, doctor network or diagnostic integration is assumed to be operational at this stage.

Safety, professional boundaries and accountability

Healthcare-related coordination can affect people’s safety and access to treatment. The network must therefore be designed around clear boundaries and accountable service delivery.

Clinical decisions remain with qualified professionals

A coordinator or care worker must not independently diagnose a condition, prescribe medication, alter treatment or interpret clinical reports as a substitute for a qualified professional.

Any task involving clinical assessment, sample collection, procedures or emergency response must be assigned only to people who meet the applicable competence and authorisation requirements.

Escalation must be defined

Care workers and coordinators should know how to communicate a concern, contact the responsible provider and follow an established escalation procedure. They must not delay urgent professional assistance while attempting to resolve a clinical issue themselves.

Patient dignity and consent must be protected

People receiving care should be treated respectfully and should understand the nature and limits of the service. Personal information, home visits, photographs and communications require appropriate safeguards and consent arrangements.

Providers must be verified

Before a provider is included in a working network, its identity, relevant credentials, service scope and required authorisations should be checked. The process should also establish who is accountable for complaints, incidents and service quality.

Financial relationships must be transparent

Any fees, referral arrangements or payments must be disclosed and structured appropriately. Patient choice and clinical judgement must not be compromised by commercial incentives. A proposed network must not assume that referral commissions or consultation-coordination fees are lawful, appropriate or available without specific review.

Roles of the Foundation, service providers and Wara Systems

The proposed network may involve charitable programmes, independent service providers and commercial technology or coordination services. These responsibilities must remain distinct.

Wara KarmaYoga Foundation

The Trust may support charitable activities relating to education, care awareness, skills development, community capacity and access for underserved groups, subject to its approved objectives, resources and operating arrangements.

It may seek philanthropic or CSR support for eligible programmes. Any healthcare-related activity must have a defined scope, appropriate partners and suitable safeguards.

Healthcare and care-service providers

Participating providers would remain responsible for the professional or care services they undertake, including the personnel, qualifications, authorisations, supervision and service standards applicable to those activities.

Participation in a future network would not transfer a provider’s professional responsibilities to the Trust or to a technology supplier.

Wara Systems

Wara Systems may provide separately agreed commercial technology, software, administrative or operational services where appropriate. Any such engagement would require a clear scope, responsibilities, data-handling arrangements and financial terms.

A commercial technology arrangement does not make Wara Systems a healthcare provider, confer clinical authority on its personnel or establish that a particular healthcare service is available.

Resources and sustainability

The resources required depend on the operating model. A coordination service, a home-care provider and a clinical diagnostics service have very different staffing, infrastructure and compliance requirements.

A programme-specific assessment should identify:

• The actual community need and intended beneficiaries.
• The participating providers and their responsibilities.
• Required training, qualifications and supervision.
• Facilities, equipment and technology.
• Safeguarding, privacy and incident-management arrangements.
• Staffing, transport, communication and coordination costs.
• Funding sources or the basis on which a service provider may charge for services.
• Quality measures and arrangements for continuing or closing the activity.

Potential funding may include eligible grants, donations, CSR support, institutional contributions or agreed service revenue. The appropriate model must be established for each activity rather than assuming that every component can be funded in the same way.

No standard investment amount, income level, entrepreneur earnings or financial return is established by this concept.

Measuring whether the network creates value

If a pilot is developed, its evaluation should focus on whether the defined service improves access and coordination safely and responsibly.

Possible measures include:

• Number of participating providers whose credentials and service scopes have been verified.
• Number of people trained and assessed for defined roles.
• Number of eligible service requests coordinated.
• Appointment or referral coordination completed within the agreed process.
• Completion of required follow-up and administrative tasks.
• Patient or caregiver feedback.
• Timeliness of escalation and resolution of reported issues.
• Privacy, safeguarding and service-quality incidents.
• Cost per participant or completed service, where relevant.
• Evidence of suitable work opportunities for trained participants, where follow-up is feasible.

Targets should be established only after a specific service, operating baseline and delivery arrangements have been agreed. The number of consultations or referrals alone would not demonstrate improved health outcomes.

A practical path towards implementation

HealthCareNet should be developed in stages rather than by attempting to establish every possible healthcare-related service at once.

1. Identify a specific need. Establish the people to be served, the service gap and the existing providers or institutions involved.
2. Choose a limited service scope. Begin with clearly defined activities and avoid combining non-clinical coordination with specialist clinical work.
3. Identify accountable partners. Confirm which organisation provides the service, who supervises personnel and who handles complaints, incidents and records.
4. Define the required competencies. Establish the training, practical experience, assessment and authorisation requirements for each role.
5. Prepare the operating model. Document workflows, referral boundaries, data handling, safety procedures, resources and funding.
6. Review readiness. Confirm that the proposed activity meets the requirements relevant to its scope before accepting participants or patients.
7. Evaluate the pilot. Review service quality, safety, access, cost and participant experience before considering expansion.

A network should expand only when its service arrangements, provider capacity and safeguards can support the additional responsibilities.

Discuss a HealthCareNet project

HealthCareNet is open for concept-level discussion with healthcare institutions, care-service providers, training organisations, community organisations, potential implementation partners and eligible funders.

A useful starting point is a specific question: which people need help, what access or coordination problem are they experiencing, what service is missing, and which organisation could responsibly provide it?

From there, the proposed scope, training requirements, partner responsibilities, technology needs, safeguards and financial model can be assessed.

The aim is to explore a practical network that connects capable people with appropriate services while protecting patients, respecting professional boundaries and creating realistic opportunities for community service and livelihoods.

6 - DharmaNet

1. Project Overview: Community Care Close to Home

The purpose

Care needs are not limited to medical treatment. Older adults, people recovering from illness, people who need assistance with daily activities, and family caregivers may also need reliable practical support, information and help navigating local services.

DharmaNet is a proposed framework for organising these forms of community support. It aims to make responsibilities clearer, help people identify appropriate assistance, and create structured ways for trained workers and local organisations to contribute.

The project is intended to develop a network, not require every community to establish a fully equipped centre. Depending on local needs and available partners, support could be coordinated through an existing institution, a community organisation, a participating service provider or a dedicated local facility.

Who it may serve

• Older adults who need practical assistance or social support.
• People recovering from illness or injury who need appropriate non-clinical help.
• Individuals and households that need assistance navigating available services.
• Family members and informal caregivers who need information, preparation or support.
• Community organisations and service providers seeking a more organised way to coordinate appropriate care-related assistance.

What the project may develop

Subject to local needs, resources and approvals, a DharmaNet initiative could establish:

• A defined process for understanding a household’s support needs and obtaining consent.
• A directory or network of suitable local services and support organisations.
• Trained workers for clearly defined non-clinical support tasks.
• Caregiver awareness and practical preparation activities.
• Referral and follow-up procedures for situations requiring qualified or specialised assistance.
• A documented method for monitoring service quality, safety and participant feedback.

No operating DharmaNet network, centre, provider directory or service capacity is implied by this description.

2. Project Model: From Need to Appropriate Support

The proposed service journey is:

Identify need → Understand and obtain consent → Match appropriate support → Deliver or refer → Follow up → Review

Possible areas of support

These are potential service areas, not a claim that every activity is available or appropriate at every location.

How a local node could operate

A local DharmaNet node could be based in an existing community institution or another suitable facility. A dedicated centre could be considered where local demand and the operating model justify it, but a rented centre is not a mandatory starting point.

The local team would need to establish:

1. Defined services: What assistance is offered, what is excluded, and who is qualified to perform each task.
2. Intake and consent: How requests are received, support needs are understood, and personal information is handled.
3. Worker preparation: How workers or volunteers are selected, trained, assessed where applicable, and supervised.
4. Service coordination: How suitable workers or providers are identified, responsibilities are agreed, and referrals are made.
5. Follow-up and accountability: How completion, concerns, complaints, incidents and participant feedback are recorded and reviewed.

A request must not automatically result in service deployment. The proposed activity must be within the available team’s competence, capacity and authorised scope.

Relationship with the wider KarmaYoga system

DharmaNet could draw on the wider learning and livelihood framework to prepare people for suitable care-support roles. Training, practical assessment, service delivery and external qualification are separate steps, and each requires its own arrangements.

The network may also complement HealthCareNet, but the two concepts have different emphases:

• DharmaNet: community support, caregiving, household needs, caregiver support and access to appropriate services.
• HealthCareNet: healthcare-related service coordination, patient navigation and healthcare-support roles.

The exact division of responsibilities would need to be defined before implementation.

Related frameworks include the Care and Community Support Programme and the Training and Assessment Network.

3. Resources and Financial Model

People and capabilities

A local implementation may require some combination of:

• A project or local service coordinator.
• Appropriately prepared care-support workers.
• Volunteers for clearly defined community activities.
• Qualified healthcare or other specialist professionals when the service requires them.
• Training, supervision, safeguarding and quality-review support.
• Administrative and technical support appropriate to the operating model.

The actual staffing arrangement depends on the services selected. A community-awareness initiative, a home-support service and a staffed care facility have different requirements and should not be treated as interchangeable models.

Infrastructure and technology

Requirements would be determined by the agreed scope. A small coordination initiative might need only suitable meeting space, communication facilities and secure records. A more involved service may require staff facilities, equipment, transport arrangements, specialist partners or other infrastructure.

Any technology used for coordination or record-keeping must support appropriate access controls, privacy and accountability. Technology cannot replace professional judgement, direct supervision or the responsibility to respond appropriately to safety concerns.

Funding and sustainability

Potential funding sources, subject to eligibility and approval, include:

• Charitable donations and grants.
• Corporate social responsibility support.
• Sponsorship of defined community programmes.
• Contributions from participating institutions or permitted programme sources.
• Payments for separately agreed services where a lawful commercial model is appropriate.

The funding model must be determined for the specific project. Free charitable support and paid services should have clear eligibility, payment, accountability and service arrangements. No particular revenue stream, referral margin, participant fee or guaranteed income is assumed.

The intended institutional separation is:

• Wara KarmaYoga Foundation: may develop or support charitable care-awareness, training and community-development activities within its approved objectives and resources.
• Wara Systems: may provide separately contracted technology, coordination or commercial service capabilities where appropriate.
• Participating institutions and providers: may contribute premises, personnel, specialist services or other resources under an agreed arrangement.

Wara may receive an agreed payment for actual programme, system, technology, curriculum or implementation services provided to the project, as defined in the project-specific financial arrangement.

4. Governance, Safeguards and Risk

Care-related services involve personal vulnerability, trust and potentially sensitive information. Safety and clear accountability must therefore be part of the operating model from the beginning.

Scope of service and professional boundaries

DharmaNet must not be presented as a substitute for a hospital, clinic, licensed care institution or emergency service.

Workers may perform only tasks permitted by their training, demonstrated competence, role and applicable requirements. Diagnosis, prescribing, clinical decisions and other restricted activities must remain with appropriately qualified and authorised professionals. Clinical procedures require the relevant training, facilities and authorisation.

Urgent or potentially serious situations require an appropriate escalation process and contact with qualified professionals or emergency services. A local coordination node must not be represented as an emergency-response provider unless that function is separately established and authorised.

Safeguarding and privacy

An implementation plan should define:

• Informed consent and respect for the preferences and dignity of the person receiving support.
• Appropriate worker selection, identity checks and references where required.
• Boundaries for home visits, personal care, handling money and access to private spaces.
• Confidential handling of personal and health-related information.
• Incident reporting, complaints, escalation and review.
• Appropriate supervision and referral arrangements.
• Applicable legal, regulatory, insurance and professional requirements.

Additional safeguards may be necessary for people who have difficulty communicating their preferences or making decisions independently.

Responsibilities and institutional boundaries

Principal risks and controls

5. Mission Value and Expected Outcomes

DharmaNet aims to make community support more organised and accountable while helping people receive appropriate assistance closer to home.

Expected value

For individuals and households, a well-designed initiative may make it easier to understand available support, identify suitable providers and obtain agreed non-clinical assistance.

For caregivers, it may provide access to practical guidance, clearer service boundaries and better information about where to seek help.

For workers and volunteers, it may create a structured way to develop relevant capabilities and contribute responsibly. Where suitable paid work becomes available, it may also provide a pathway towards livelihood opportunities, without guaranteeing employment or income.

For participating institutions, the project may provide a defined and reviewable way to support community care. Any wider replication would depend on demonstrated results, local demand, suitable personnel, funding and separate approval.

Measures of progress

A pilot should select indicators that match its actual scope. Suitable measures may include:

• Number of individuals or households reached.
• Number and type of support requests received.
• Proportion of requests resolved, referred or left pending, with reasons recorded.
• Number of workers or volunteers prepared for their defined roles.
• Completion of required training and competency checks.
• Participant and caregiver feedback.
• Safeguarding incidents, complaints and corrective actions.
• Cost per participant or completed support activity, where the data can be collected meaningfully.

Measures should distinguish activities completed from outcomes achieved. A referral recorded, for example, does not by itself establish that a person received the required service or experienced a better outcome.

A practical path to implementation

A responsible first step is to select one local need and define a limited pilot around it. Before delivery begins, the project should establish the target group, service boundaries, delivery partner, staffing, safeguarding arrangements, funding, referral process and review method.

The project is intended to create measurable value within its own scope. If successful, its experience and learning may be reused or adapted for future programmes, subject to separate consideration and approval.

7 - Assisted Living Network

1. Project Overview: Strengthening Residential Care

The purpose

Some older adults and people who need continuing assistance cannot receive all the support they require at home. Residential care can provide accommodation, daily assistance and an organised environment, while also placing significant responsibility on the institution, its staff and the people who entrust a family member to its care.

The Assisted Living Network is a proposed initiative to help suitable residential-care providers strengthen their operating practices and coordinate appropriate support. Rather than assuming that every community needs a new facility, the network would explore how existing institutions can participate in a more structured and accountable service framework.

The project does not assume that all residential facilities provide the same services. An independent old-age home, a supported-living residence and a facility providing higher-dependency care may have substantially different staffing, infrastructure, clinical support and regulatory requirements.

Who the project may serve

• Older adults living in residential-care facilities.
• Families and authorised representatives who need reliable information about a resident’s wellbeing and services.
• Existing old-age homes and residential eldercare providers seeking to strengthen their practices.
• Care workers, supervisors and coordinators who need defined responsibilities and suitable preparation.
• Community organisations and qualified service providers that can contribute appropriate support.

Proposed outputs

Depending on the selected facility and agreed project scope, the initiative could develop:

• A facility-readiness and suitability assessment.
• Defined service standards and responsibility boundaries.
• Resident intake, consent and individual support-planning procedures.
• Care documentation, family communication and concern-resolution processes.
• Staff preparation and supervision arrangements.
• Coordination procedures for healthcare, specialist support and emergencies.
• A periodic review process for service quality and resident experience.

Status: Proposed concept. No participating facility, verified provider network, occupancy pipeline, monitoring platform or residential-care service is represented as currently operational.

2. Project Model: Facility Partnership and Service Quality

How a participating facility could work

The proposed partnership would begin with the facility and its existing capabilities, rather than with a promise to supply residents or impose a universal operating model.

Assess → Agree scope → Prepare → Operate → Review

1. Assess suitability: Understand the facility’s services, staffing, premises, care capabilities, operating practices and applicable approvals.
2. Agree the scope: Define the resident groups served, services included, responsibilities, reporting arrangements, costs and limitations.
3. Prepare the facility: Establish the agreed documentation, communication, safeguarding, staff-orientation and escalation procedures.
4. Deliver services: The facility continues to provide the residential services for which it is responsible, with participating providers undertaking only their separately agreed roles.
5. Review performance: Examine resident and family feedback, service records, complaints, incidents and corrective actions.

A facility should join only when the required arrangements for its proposed scope are in place. Inclusion in a network must not be treated as a guarantee of suitability for every resident or care need.

Resident admission and support planning

Where a resident is considering a participating facility, the process should help the resident and their authorised representatives understand the available services and relevant limitations.

The proposed process would include:

• Explaining the facility’s actual services, charges, admission criteria and limitations.
• Understanding the prospective resident’s needs, preferences and support requirements.
• Confirming whether the facility can appropriately meet those needs.
• Obtaining informed consent and the required authorisations.
• Documenting agreed responsibilities, emergency arrangements and communication preferences.
• Reviewing the support arrangement when needs change.

Residents should not be moved between facilities merely because a network coordinator considers another location more convenient. Any transfer requires appropriate consent or legal authority, clinical or care-related assessment where needed, receiving-facility acceptance, and a safe transition plan.

What a facility remains responsible for

A participating facility would remain responsible for the accommodation, staffing, daily care and other services it agrees to provide, subject to applicable requirements and its formal agreement.

Depending on the facility and project, these responsibilities may include:

• Safe and suitable premises.
• Adequate staffing and supervision.
• Respectful assistance with daily living within the facility’s scope.
• Resident records and authorised access to information.
• Nutrition, hygiene and other agreed residential services.
• Safeguarding, incident management and complaint handling.
• Access to appropriate healthcare and specialist services when required.

The network concept does not replace the facility’s own management, professional responsibilities or legal obligations.

Roles within the proposed network

3. Resources and Financial Model

Facility and staffing requirements

The resources required depend on the facility’s existing capabilities and the services included in the agreement.

A readiness assessment may need to examine:

• Accommodation, sanitation, accessibility and resident safety.
• Staff numbers, competencies, supervision and training needs.
• Arrangements for meals, hygiene, daily assistance and other included services.
• Access to appropriate healthcare, transport and emergency support.
• Record-keeping, communication and incident-management processes.
• Applicable registrations, permissions, insurance and other compliance requirements.

The network should not prescribe a single equipment list or staffing ratio for every institution without considering its resident population, dependency levels, service scope and applicable standards.

Technology and documentation

Where useful, a participating project may adopt secure digital or paper-based processes for:

• Resident profiles and authorised contact details.
• Agreed support plans and service records.
• Family communication and scheduled updates.
• Requests, complaints, incidents and follow-up actions.
• Provider contacts and escalation procedures.
• Service reviews and reporting.

Any technology must be selected and implemented under a defined arrangement. The proposed network does not imply that a WARA care-record system, remote-monitoring service or family dashboard is already available.

Personal and health-related information must be collected only for defined purposes, accessed by authorised people and handled according to applicable privacy and data-protection requirements. Monitoring must be proportionate, transparent and consistent with resident rights and consent.

Funding and commercial arrangements

Possible financial arrangements depend on the project structure. They may include facility-funded improvements, grants or donations for eligible charitable activities, CSR support, sponsorship of defined programmes, or separately contracted services.

The facility’s residential fees remain governed by its own arrangements with residents and their representatives. Network participation does not guarantee higher occupancy, additional admissions, increased revenue or reduced operating costs.

Any payment for coordination, technology, training or other services must be defined in an appropriate agreement. The terms should identify the contracting parties, deliverables, costs, payment responsibilities and accountability.

Wara KarmaYoga Foundation may support eligible charitable activities within its approved objectives and resources. Wara Systems DharmaNet may provide separately contracted commercial services. These roles should remain distinguishable in project governance, records and financial arrangements.

Wara may receive an agreed payment for actual programme, system, technology, curriculum or implementation services provided to the project, as defined in the project-specific financial arrangement.

4. Governance, Resident Protection and Risk

Residential care involves people who may depend on others for daily assistance, communication or access to services. Trust must therefore be supported by documented responsibilities and effective safeguards.

Resident dignity, rights and safeguarding

A participating project should establish appropriate procedures for:

• Respecting resident preferences, privacy, dignity and independence.
• Obtaining consent and respecting decision-making rights.
• Protecting residents from abuse, neglect, exploitation and discrimination.
• Managing complaints and concerns without retaliation.
• Protecting personal belongings, money and confidential information.
• Ensuring appropriate access to visitors and authorised representatives.
• Recording and escalating incidents and concerns.
• Supporting residents whose communication or decision-making needs require additional safeguards.

A family update or digital record is not a substitute for direct care, responsible supervision or an effective response to a resident’s concern.

Healthcare and emergency boundaries

The network must distinguish residential support from clinical care. Care staff should perform only tasks within their training, competence and authorised role. Diagnosis, prescribing, clinical decisions and restricted procedures must remain with appropriately qualified and authorised professionals.

Each participating facility must have suitable arrangements for obtaining healthcare assistance and responding to emergencies. A coordination process does not itself provide an ambulance, emergency medical response or clinical service.

Where specialist or clinical services are required, the facility should establish appropriate arrangements with qualified providers and document responsibility for the relevant activity.

Quality and accountability

Quality assurance should be proportionate to the services actually delivered. Depending on the agreement, review may cover:

• Whether agreed services are delivered as described.
• Staff preparation, supervision and competency requirements.
• Resident and family feedback.
• Complaints, incidents, response times and corrective actions.
• Record accuracy and authorised access.
• Resource adequacy and service continuity.
• Compliance with relevant legal and regulatory obligations.

A network-level review must not be described as independent accreditation, statutory inspection or clinical certification unless the appropriate authority and process have been established.

Principal risks and controls

5. Mission Value and Expected Outcomes

Value for residents and families

A well-designed residential-care partnership may help residents and families understand what a facility provides, whom to contact, how concerns are handled and how support arrangements are reviewed.

The aim is not to promise that every facility will deliver identical services. It is to make the agreed scope clearer and establish more consistent ways to document responsibilities and respond to concerns.

Value for participating facilities

Facilities may benefit from structured operating procedures, staff-development opportunities, clearer communication processes and better-organised service reviews. The value will depend on whether the arrangements address genuine needs without imposing disproportionate administrative or financial burdens.

Participation should be considered on the basis of service quality, resident welfare, feasibility and mutual benefit, not simply network membership or anticipated admissions.

Measures of progress

A pilot should establish a baseline and select measures relevant to the participating facility. Potential indicators include:

• Number of facilities assessed and admitted to the pilot.
• Proportion of required readiness actions completed.
• Staff completing the agreed preparation or competency requirements.
• Completion and review of resident support plans where applicable.
• Resident and family feedback.
• Number and type of complaints or incidents, together with response and corrective-action records.
• Compliance with agreed service standards.
• Cost and resource use compared with the approved project plan.

Incident counts must be interpreted carefully. An increase in reported incidents may reflect improved reporting rather than deteriorating care. Measures should therefore consider severity, response quality, reporting practices and corrective actions, not just raw totals.

A practical path forward

The first implementation decision is to identify a suitable facility and a clearly bounded area for improvement. The facility, project coordinator and any participating service providers should then agree the baseline, service scope, resources, safeguarding procedures, funding and review method.

Expansion to other facilities should follow only if the initial work demonstrates practical value, the safeguards are effective and the necessary resources and approvals are available.

The project is intended to create measurable value within its own scope. If successful, its experience and learning may be reused or adapted for future programmes, subject to separate consideration and approval.

8 - Diagnostic Lab Network

1. Project Overview: Connecting Diagnostic Services

The purpose

Diagnostic testing is an important part of healthcare, but obtaining a test can involve several separate activities: understanding a valid test request, arranging collection, transporting the sample under suitable conditions, processing it, releasing the report and ensuring that the result reaches the appropriate recipient.

Where these activities are poorly coordinated, patients and healthcare providers may face avoidable delays, unclear responsibilities or difficulty tracking the status of a request.

The Diagnostic Lab Network is a proposed way to improve coordination between diagnostic laboratories, healthcare institutions, authorised sample-collection providers and service coordinators. It is intended to work with existing capabilities rather than assume that WARA must establish or operate laboratories itself.

Who may participate

• Diagnostic laboratories that meet applicable requirements for their services.
• Qualified and appropriately authorised sample-collection providers.
• Hospitals, clinics and other healthcare institutions.
• Healthcare professionals who request tests and review results within their professional scope.
• Service coordinators supporting appointment scheduling, communication and non-clinical follow-up.
• Technology or logistics providers engaged for a defined purpose.

Potential project outputs

A project may develop the following, depending on its scope and readiness:

• A register of participating providers and their verified service capabilities.
• Defined workflows for receiving and validating test requests.
• Appointment and sample-collection coordination procedures.
• Sample identification, handling, transport and handover records.
• Laboratory processing and report-release responsibilities.
• Procedures for communicating report availability and managing delays.
• Defined escalation routes for rejected samples, operational incidents and urgent concerns.
• Service-quality and performance-review measures.

No active laboratory network, guaranteed testing volume, route schedule, technology integration or provider agreement is implied.

2. Project Model: From Test Request to Report

The proposed workflow

Valid test request → Booking → Collection → Transport and handover → Laboratory processing → Report release → Appropriate communication

Each stage must have a clearly identified responsible party.

1. Test request: An appropriately authorised healthcare professional or other permitted requester initiates the test request under the applicable rules. The required test, patient identity and relevant instructions must be clear.
2. Booking and preparation: The responsible provider confirms availability, appointment details, preparation requirements and the appropriate collection arrangement.
3. Sample collection: A qualified and authorised person collects the sample where collection is required, following the relevant identification, consent, hygiene and handling procedures.
4. Transport and handover: The responsible parties preserve sample integrity and maintain the required identification, timing, handling and handover records.
5. Laboratory processing: The receiving laboratory checks sample acceptability and performs the requested testing within its authorised scope and quality procedures.
6. Report release: The laboratory validates and releases the report through its approved process. The network must not alter laboratory findings or substitute its own interpretation.
7. Communication and follow-up: Report availability is communicated to the appropriate authorised recipient. Clinical interpretation and decisions remain with the responsible healthcare professional.

Not every test follows an identical workflow. Some require collection at the laboratory, special preparation, time-sensitive transport or other specific conditions. The workflow must reflect the requirements of each test and provider.

Collection points and route-based logistics

A cluster-based collection model could be considered where sufficient demand, suitable geography and qualified staff make it practical. Scheduled routes may help coordinate multiple collection locations, but they should be designed around actual test requirements and transport conditions.

The old proposal suggested coverage zones of 10–15 centres and routine collection routes. These figures should not be treated as established operating assumptions. A viable route depends on local demand, travel time, sample stability, collection hours, laboratory capacity, staffing and cost.

Before a route is activated, the project should establish:

• Participating locations and expected demand.
• Which tests and sample types can be handled through the route.
• Collection and handover schedules.
• Packaging, temperature and transport requirements where applicable.
• Contingency arrangements for delays, rejected samples and transport failure.
• The party accountable for each handover and any resulting incident.

A route should not be optimised for volume or travel efficiency at the expense of sample integrity or patient safety.

Responsibilities of a diagnostic laboratory

A participating laboratory would remain responsible for the testing services it agrees to provide, including the applicable requirements for:

• Authorised scope of testing and personnel.
• Sample acceptance and rejection criteria.
• Laboratory procedures, quality controls and equipment.
• Testing, validation and report release.
• Appropriate retention of records.
• Communication of laboratory-related delays, limitations and incidents.
• Compliance with applicable legal, professional and quality requirements.

Collection providers, transport providers and coordinators must likewise remain accountable for their own agreed responsibilities.

3. Resources and Financial Model

People and infrastructure

Depending on the project, resources may include:

• Laboratory personnel and technical supervision.
• Qualified sample-collection personnel.
• Collection and transport equipment appropriate to the sample types.
• Suitable packaging and handling arrangements.
• Scheduling and service-coordination personnel.
• Secure communication and record-keeping systems.
• Quality, compliance and incident-review support.

A laboratory’s existing capacity must be assessed before additional demand is introduced. Any new collection location, sample-handling arrangement or testing service must meet the requirements applicable to that activity.

Technology and information flow

Technology may support appointment scheduling, request status, collection records, sample handovers, report availability and operational reporting.

A proposed implementation could use existing laboratory systems and agreed interfaces where available. Manual or paper-based procedures may remain necessary where digital integration is unavailable, provided that traceability and security requirements are maintained.

The network must distinguish operational status information from clinical information. A coordinator may need to know whether a sample was collected or a report was released, but should not automatically receive unrestricted access to patient records or laboratory results.

Any system handling patient or health-related information must establish:

• A defined purpose for collecting and sharing each data item.
• Appropriate consent or other lawful authority.
• Role-based access and secure transmission.
• Rules for retention, correction and deletion.
• Audit records and incident-response procedures.
• Clear responsibility for the accuracy and release of information.

No particular WARA software, automated reporting integration or patient-facing dashboard is assumed to exist.

Funding and commercial arrangements

Potential arrangements depend on the specific project and applicable requirements. They may include:

• Direct payment by patients or institutional customers to the relevant provider.
• Contracted diagnostic services for healthcare institutions.
• Agreed fees for collection, transport or coordination services.
• Grants, donations or CSR support for eligible access-oriented programmes.
• Other permitted project-specific funding.

The laboratory’s testing charges, collection fees and any coordination charges should be transparent to the relevant parties. The agreement should define who bills whom, what each party provides, how cancellations and rejected samples are handled, and who is responsible for refunds or service failures.

The network must not assume that participation will produce regular demand, reduce customer-acquisition costs or improve profitability. These are hypotheses to evaluate through an actual pilot.

Wara KarmaYoga Foundation may support eligible charitable health-awareness or community-access activities within its approved objectives and resources. Wara Systems DharmaNet may provide separately contracted technology, workflow or commercial coordination services. These roles should remain distinct.

Wara may receive an agreed payment for actual programme, system, technology, curriculum or implementation services provided to the project, as defined in the project-specific financial arrangement.

4. Governance, Quality and Patient Safety

Diagnostic services require particular care because errors in identification, collection, handling, testing or communication may affect subsequent clinical decisions.

Clinical and professional boundaries

The network’s coordination role must not be confused with laboratory authority or clinical responsibility.

• Tests must be requested and performed under the applicable professional and regulatory requirements.
• Collection and other technical activities must be undertaken by appropriately qualified and authorised personnel.
• Laboratories remain responsible for their testing processes and released reports.
• Clinical interpretation, diagnosis and treatment decisions remain with the appropriate healthcare professional.
• Coordinators must not independently interpret results, advise treatment or change a test request outside their authority.
• Urgent or critical-result communication must follow the laboratory’s and responsible healthcare provider’s approved procedures.

A coordination platform cannot itself guarantee the accuracy of a test, determine a diagnosis or replace a clinician’s judgement.

Sample traceability and quality controls

The project should establish documented procedures for:

• Confirming patient identity and matching it to the request and sample.
• Obtaining required consent and following preparation instructions.
• Labelling samples and recording collection details.
• Maintaining required conditions during storage and transport.
• Recording custody and handovers.
• Identifying unsuitable, damaged, delayed or rejected samples.
• Reporting operational incidents and applying corrective actions.
• Protecting confidential information throughout the process.

Quality requirements should be based on the relevant test, laboratory procedures and applicable standards. A network-level review must not be represented as laboratory accreditation or statutory approval.

Accountability and institutional separation

Principal risks and controls

Institutional Partner and Wara remain independent organisations, each retaining its own governance, personnel, assets and responsibilities. Participation in this project does not by itself create a continuing obligation for Institutional Partner to finance, operate or expand the project, nor does it transfer Wara’s commercial or organisational liabilities to Institutional Partner.

5. Mission Value and Expected Outcomes

Potential value

For patients, better coordination may reduce avoidable confusion about appointments, collection arrangements, sample status and report availability.

For laboratories, clearly defined handovers and communication procedures may help organise participating workflows. Whether these changes improve utilisation, cost or turnaround time must be established from actual operating data.

For healthcare institutions and professionals, a defined process may make it easier to understand where a request stands and whom to contact when a problem occurs.

For communities, suitable partnerships may improve access to diagnostic services where geographic or coordination barriers exist. Any claim about improved access must be supported by evidence from the selected location and population.

Measures of progress

A pilot should select indicators appropriate to the tests and providers involved. Potential measures include:

• Number of providers assessed and formally participating.
• Number of valid test requests received and completed.
• Collection completion and cancellation rates.
• Sample rejection rates and documented reasons.
• Time from collection to laboratory receipt.
• Time from laboratory receipt to report release, measured against the applicable service expectations.
• Number of delayed, lost or misdirected samples and reports.
• Patient or institutional feedback and complaint resolution.
• Actual cost per completed workflow and resource utilisation.

Performance reporting should distinguish operational coordination from clinical outcomes. Faster reporting alone does not establish diagnostic accuracy or improved health outcomes.

A practical path to implementation

The first step should be a feasibility assessment with one suitable laboratory and a clearly defined set of tests or collection arrangements. The assessment should confirm provider authority, actual demand, sample-handling requirements, capacity, workflow ownership, pricing, data protection and escalation procedures.

A pilot should proceed only after the relevant agreements and operating safeguards are in place. Route expansion, additional collection points or system integration should follow only where results demonstrate feasibility and quality can be maintained.

The project is intended to create measurable value within its own scope. If successful, its experience and learning may be reused or adapted for future programmes, subject to separate consideration and approval.

9 - Pharmacy Network

1. Project Overview: Connecting Pharmacies with Care

Medicines are an essential part of many patients’ care journeys. However, obtaining the correct medicine at the right time can involve several separate activities: receiving a valid prescription, locating an appropriate pharmacy, checking availability, dispensing, arranging delivery where permitted, and communicating with the patient or caregiver.

The proposed Pharmacy Network aims to improve coordination across these activities by connecting eligible pharmacies with healthcare providers, patients and appropriate support services.

The network is intended to complement existing pharmacies, not replace them. Each participating pharmacy remains responsible for its own licensing, procurement, inventory, dispensing, professional supervision and compliance.

The central opportunity is better coordination, not a promise of guaranteed demand.

What the network could support

• Helping patients or authorised caregivers identify an appropriate participating pharmacy.
• Coordinating medicine availability and order status.
• Supporting lawful fulfillment of valid prescriptions.
• Arranging delivery where permitted and operationally feasible.
• Improving communication between pharmacies, patients and authorised care coordinators.
• Maintaining appropriate records of requests, fulfillment and service issues.
• Identifying recurring access difficulties that may require a wider community response.

The network is a proposed capability. No active pharmacy network, established prescription pipeline, guaranteed customer base or delivery operation is assumed.

2. Project Model: From Prescription to Fulfillment

The operating model should be designed around the responsibilities of the licensed pharmacy and the applicable rules for each medicine and transaction.

The proposed workflow

1. Medicine need identified

A patient, authorised caregiver or healthcare provider identifies a medicine requirement. Where a prescription is required, the process must use a valid prescription and the appropriate verification procedures.

2. Pharmacy identified

An eligible participating pharmacy is identified according to location, medicine availability, service capability and any relevant restrictions. Allocation should not be based on proximity alone if the pharmacy cannot lawfully or safely fulfill the request.

3. Availability and order confirmed

The pharmacy checks stock, prescription requirements, price and other applicable conditions. An order is confirmed only when the pharmacy can accept and fulfill it.

4. Dispensing and handover

The pharmacy performs the required professional checks, dispensing and documentation. Any delivery or handover follows applicable rules for the medicine, the recipient and the delivery method.

5. Status communicated

The patient or authorised caregiver receives appropriate updates about confirmation, availability, collection or delivery. The system should record the relevant status without exposing patient information to unauthorised parties.

6. Issue resolution and review

Shortages, substitutions, delays, cancellations and complaints are handled by the responsible pharmacy or healthcare professional, as applicable. Service records can support quality review and future operational improvement.

Roles and responsibilities

The network must not allow administrative coordination or software automation to replace professional judgment, required prescription checks or the pharmacy’s legal duties.

3. Resources and Financial Model

People and operating capability

Depending on the agreed scope, an implementation may require:

• Licensed pharmacy owners and qualified pharmacy personnel.
• Healthcare providers or authorised prescription sources.
• A coordinator for participating providers and service requests.
• Appropriate delivery personnel where delivery is permitted.
• Technical support for order status, communications and access controls.
• Defined procedures for complaints, medicine shortages, failed delivery and escalation.

The required staffing and operating arrangements must be determined after the service area, participating pharmacies and medicine categories are known.

Technology and infrastructure

A future implementation could use proportionate digital tools for:

• Pharmacy and service-area records.
• Medicine availability enquiries.
• Order and fulfillment status.
• Patient or caregiver communications.
• Authorised access to prescription-related information.
• Service records, complaints and operational reporting.

These are potential requirements, not claims that a Pharmacy Network platform or pharmacy integration is already operational. Any technology handling prescriptions or health information must be assessed for privacy, security, access control, record retention and applicable regulatory requirements.

How participating pharmacies may benefit

A pharmacy may benefit from better-organised enquiries, clearer order communication, reduced coordination friction and access to additional service channels. The actual benefit will depend on local demand, pharmacy capacity, customer choice and the agreed commercial arrangement.

The network does not guarantee regular orders, exclusive allocation, reduced marketing costs, increased sales or higher profit. Pharmacies should assess participation on the basis of a defined service scope and realistic operating assumptions.

Potential funding and revenue

The financial model will depend on the type of activity being delivered. Potential arrangements may include:

• Pharmacy revenue from lawful medicine sales.
• Separately agreed charges for permitted delivery or coordination services.
• Commercial fees for technology or operational services actually provided.
• Charitable or grant support for a clearly defined community-access programme, where eligible and properly governed.

Any fees, commissions, referral arrangements, data-sharing arrangements or revenue-sharing models require prior legal and regulatory review. No payment model should compromise prescribing independence, professional judgment, patient choice or medicine safety.

Wara KarmaYoga Foundation Trust may support eligible charitable education or community-access activities within its objects and approvals. Wara Systems may provide separately contracted commercial technology or operational services. The entities must maintain clear responsibilities, accounts and agreements.

Ramakrishna Mission is not assumed to be a participant or funder. Any involvement would require a specific, mutually agreed and appropriately approved arrangement.

4. Governance, Legal Boundaries and Risk

Medicine fulfillment is a regulated activity. The network must be designed around applicable pharmacy, prescription, medicine-sale, storage, transport, consumer-protection and data-protection requirements. The exact obligations depend on the medicines and services involved and must be verified before implementation.

Pharmacy eligibility and professional responsibility

A participating pharmacy must meet the applicable licensing and operational requirements for the services it provides. The pharmacy remains responsible for determining whether a prescription can be lawfully fulfilled, checking relevant restrictions, dispensing correctly and maintaining required records.

The network must not encourage dispensing without a required valid prescription, unauthorised substitution, inappropriate medicine promotion or the sale of restricted medicines outside permitted conditions.

Patient choice and clinical independence

• Patients should retain appropriate choice of pharmacy, subject to practical and legal constraints.
• Prescribing decisions must remain independent of commercial incentives.
• The network coordinator must not diagnose, prescribe, alter treatment or provide clinical advice outside an authorised professional scope.
• Urgent clinical concerns must be directed to an appropriate healthcare professional or emergency service rather than treated as a routine order-coordination issue.

Privacy and information security

Prescription and medicine-order information can reveal sensitive health details. Access should be limited to people who need the information for an authorised purpose. The implementation should define consent and other lawful grounds for processing, information sharing, secure communication, retention, correction and incident handling as applicable.

Key risks and controls

Institutional boundaries

The Trust’s charitable activities must remain distinct from commercial services provided by Wara Systems . Each organisation retains its own governance, personnel, assets and liabilities. Any use of another institution’s premises, staff, funding or identity requires the appropriate agreement and approval.

5. Mission Value and Expected Outcomes

A carefully scoped Pharmacy Network could help reduce avoidable coordination difficulties for patients and caregivers while allowing independent pharmacies to participate in a structured service model.

Potential value

For patients and caregivers: clearer information about availability, order status and permitted fulfillment options.

For pharmacies: a defined way to participate in coordinated service requests, with responsibilities and expectations agreed in advance.

For healthcare providers: a clearer administrative handover between prescription-related needs and pharmacy fulfillment, without transferring clinical responsibility to the network.

For the community: the possibility of identifying recurring access barriers and designing suitable support initiatives, subject to evidence and resources.

Measures of success

A pilot should establish a baseline and track measures appropriate to its scope, such as:

• Number of eligible pharmacies assessed and participating.
• Number of requests received and accepted.
• Proportion of accepted requests fulfilled successfully.
• Time from request to pharmacy confirmation.
• Availability-related cancellations and unresolved requests.
• Delivery or handover completion, where applicable.
• Complaints, dispensing-related incidents and privacy incidents.
• Patient or caregiver feedback, collected appropriately.
• Pharmacy participation and continued willingness to use the process.

These measures should be interpreted alongside safety, quality and compliance. Order volume alone is not evidence of better patient care.

A staged path to implementation

1. Define the scope: Select a locality, service model, medicine categories and intended users.
2. Validate requirements: Review pharmacy eligibility, legal obligations, data handling and permitted delivery arrangements.
3. Consult potential participants: Establish whether pharmacies and healthcare providers see a practical need and are willing to participate.
4. Agree the operating model: Define responsibilities, service standards, escalation, costs and commercial terms.
5. Run a limited pilot: Begin only after the necessary agreements, approvals, personnel and procedures are in place.
6. Review before expansion: Use measured results, safety review and participant feedback to decide whether to continue or adapt the model.

The project should proceed only if it demonstrates a legitimate need, a compliant operating model and a realistic path to sustainable service delivery.

Discuss a Pharmacy Network Project

Pharmacies, healthcare providers and community organisations interested in exploring a coordinated model can begin by describing their service area, current operating capacity, the access problem they want to address and the role they could contribute.

An initial discussion does not establish a partnership, guarantee business or commit any organisation to participate. The scope, responsibilities and terms would need to be agreed separately.

How to Apply or Collaborate

10 - AYUSH Network

1. Project Overview: Connecting Traditional Wellness and Community Services

People may seek support for wellbeing, physical activity, traditional systems of healthcare and ongoing lifestyle practices through practitioners working in different settings. Finding an appropriate provider, understanding the service being offered and arranging continued participation can be difficult when information and coordination are fragmented.

The proposed AYUSH Network would provide a framework through which eligible practitioners, wellness providers, community organisations and other appropriate service providers could participate in defined service arrangements.

The objective is not to create a single organisation that controls every practitioner or to promise a continuous flow of patients. It is to make legitimate services easier to discover and coordinate while preserving practitioner independence, patient choice and professional responsibility.

The network could eventually support local services, community programmes and appropriately coordinated wellness activities. Its actual scope would depend on demand, practitioner eligibility, available resources, applicable law and agreements between participants.

What the network could include

Subject to practitioner qualifications, registration requirements and the scope of each service, potential areas include:

• Ayurveda and other applicable AYUSH systems of practice.
• Yoga instruction and appropriate wellness programmes.
• Lifestyle education and health-awareness activities.
• Community-based wellness sessions.
• Services delivered by eligible practitioners through their own practices or suitable partner facilities.
• Administrative and digital support for appointments, enquiries and service coordination.
• Appropriate coordination with healthcare, care and community-support providers when a person’s needs extend beyond the network’s scope.

These are possible areas for development, not a declaration that every service is currently available through WARA.

Understanding the scope of AYUSH

AYUSH is an umbrella term for Ayurveda, Yoga and Naturopathy, Unani, Siddha, Sowa-Rigpa and Homoeopathy. The applicable qualifications, registration requirements and professional scope differ across systems and services.

Physiotherapy and rehabilitation are related areas of health and recovery support, but they should not automatically be presented as AYUSH services. They require their own appropriate professional qualifications and service arrangements.

The network should therefore distinguish each provider category rather than use a single broad label for every wellness, rehabilitation or healthcare activity.

2. Project Model: From Service Discovery to Appropriate Support

The network should begin with a clearly defined service, an eligible provider and an agreed way of serving the intended community.

The proposed service journey

1. Identify the need

An individual, family, community organisation or institution identifies a need for a particular service. The request should be understood within the limits of what the network is designed to coordinate.

2. Identify an appropriate provider

A suitable provider is identified based on the service requested, qualifications, applicable registration, location, availability and any relevant restrictions. Participation in the network does not itself establish professional eligibility.

3. Explain the service and obtain agreement

The provider explains the nature and scope of the service, relevant fees, practical arrangements and applicable limitations. The individual remains free to accept or decline the service and choose another provider where available.

4. Deliver the service

The practitioner or provider is responsible for delivering the agreed service within their professional scope, maintaining required records and following applicable standards. The network coordinator, if one is involved, handles only the administrative responsibilities assigned to that role.

5. Coordinate follow-up where appropriate

A provider may arrange further sessions or communicate practical information with the individual’s consent and in accordance with applicable requirements. Follow-up must not be represented as a clinical outcome guarantee.

6. Review the service

Appropriate feedback, attendance, service completion and complaints may be recorded to assess whether the arrangement is useful, safe and sustainable. Sensitive personal information should not be collected merely because a coordination system makes it technically possible.

Potential operating models

These models need not be introduced together. A first implementation should focus on one clearly defined service and a manageable local area.

Relationship with other networks

The AYUSH Network could complement other proposed WARA initiatives without taking over their responsibilities.

• HealthCareNet focuses on healthcare-related coordination, patient support and connections with appropriate healthcare providers.
• DharmaCareNet focuses on community care, practical assistance and support for individuals and families.
• Assisted Living Network concerns collaboration with residential eldercare and assisted-living facilities.
• Pharmacy Network concerns coordination with eligible pharmacies for lawful medicine fulfillment.

A person may interact with more than one service area, but that does not justify automatic sharing of health information or automatic referral. Each handover must have a legitimate purpose, appropriate consent or other lawful basis, and a clearly identified responsible provider.

3. Resources and Financial Model

People and operating capability

Depending on the chosen service model, implementation may require:

• Eligible AYUSH practitioners or other appropriately qualified service providers.
• Instructors with the qualifications and competence required for their specific activities.
• A programme or service coordinator, where coordination is needed.
• Suitable venues and equipment for the proposed activities.
• Administrative and technical support for enquiries, scheduling and records.
• Appropriate professional oversight, referral arrangements and procedures for complaints or concerns.

The staffing model must follow the actual service being offered. A group yoga programme, an independent clinical practice and an institution-linked wellness service have different requirements.

Technology and infrastructure

A future network could use proportionate digital tools for:

• Provider profiles and eligibility records.
• Service descriptions, locations and availability.
• Enquiries and appointment coordination.
• Agreed service records and administrative follow-up.
• Feedback, complaints and operational reporting.

These are potential capabilities, not claims that a provider directory, booking platform, patient-record system or referral network is already operational.

The technology should support the service rather than dictate professional decisions. It must not imply that a provider has been clinically endorsed merely because they appear in a directory or participate in a network.

How participating providers may benefit

A participating practitioner or organisation may gain a clearer way to describe its services, receive relevant enquiries, coordinate appointments or collaborate with other suitable providers.

Whether these arrangements generate additional work or income will depend on actual demand, service quality, location, pricing, provider capacity and the terms agreed with participants.

The network does not promise:

• A fixed number of patients or referrals.
• Guaranteed appointments, recurring revenue or income.
• Exclusive access to customers or institutions.
• Guaranteed clinical improvement or recovery.
• A nationally recognised status merely from network participation.

Practitioners should remain free to maintain their independent practices and participate only in arrangements that are suitable for them.

Potential funding and revenue

The financial model should reflect the purpose of each activity.

Possible arrangements include:

• Direct fees paid to practitioners for services they provide.
• Agreed charges for legitimate administrative or coordination services.
• Commercial fees for technology or operational services actually delivered.
• Sponsorship, grants or donations for eligible charitable community-wellness programmes.
• Institution-funded programmes under separately agreed terms.

Any commission, referral payment, revenue-sharing arrangement or other financial incentive must be reviewed for legal and professional compliance before use. Financial arrangements must not undermine patient choice, professional independence or appropriate clinical decision-making.

Wara KarmaYoga Foundation may support eligible educational, charitable or community activities within its objects and approvals. Wara Systems may provide separately contracted commercial technology, coordination or operational services. The respective responsibilities, accounts and agreements must remain clear.

4. Governance, Professional Boundaries and Risk

The network must distinguish traditional-medicine practice, general wellness instruction, regulated healthcare and non-clinical community support. A common coordination framework does not make their professional requirements interchangeable.

Provider eligibility and scope

Before a provider is included in a service arrangement, the responsible organisation should verify the credentials, registrations, permissions and other eligibility requirements applicable to that provider and service.

The network should:

• Describe qualifications and services accurately.
• Avoid implying that participation is a government endorsement or professional licence.
• Confirm that practitioners work within their authorised scope.
• Establish appropriate procedures for complaints and concerns about service quality.
• Avoid claims that a service can cure a condition or guarantee recovery unless the claim is lawful, appropriately supported and professionally justified.

Where a person’s needs require assessment or treatment outside the provider’s competence, the provider should direct them to an appropriate qualified healthcare professional or service.

Patient choice, consent and safety

Participation must be voluntary. Individuals should receive clear information about the service, the provider’s role, any fees and relevant limitations before making a decision.

Any sharing of personal or health information must be limited to what is necessary and permitted. Consent, privacy, safeguarding, secure recordkeeping and appropriate access controls should be addressed in the operating procedures.

Group activities and home or community visits may require additional precautions based on the participants, venue and type of service. The network should define how incidents, complaints and urgent concerns are escalated.

Key risks and controls

Institutional boundaries

The Trust’s charitable activities must remain distinct from commercial services provided by Wara Systems . Each organisation retains its own governance, personnel, assets and liabilities. Use of another institution’s premises, staff, funding or identity requires the relevant agreement and approval.

Participation in a specific project does not create a continuing obligation for Ramakrishna Mission to finance, operate or expand the network, nor does it transfer Wara’s commercial or organisational liabilities to Ramakrishna Mission.

5. Mission Value and Expected Outcomes

A responsibly designed AYUSH Network could help people discover suitable providers and could give practitioners a practical way to participate in community and institution-linked services. Its value should be assessed through accessibility, service quality, responsible practice and the usefulness of the coordination model, not simply the number of listed providers.

Potential value

For individuals and families: clearer information about available services, provider credentials and practical arrangements.

For practitioners: a defined opportunity to describe their services and participate in appropriate coordination or community programmes.

For institutions: a potential way to organise suitable wellness activities through eligible providers under agreed responsibilities.

For communities: the possibility of improving awareness and access to appropriate services, depending on local need and available resources.

For the wider WARA ecosystem: experience in coordinating independent service providers while respecting professional boundaries and institutional independence.

Measures of success

A pilot could track:

• Providers assessed and eligible to participate.
• Providers actively participating in the agreed service model.
• Enquiries received and appointments or activities completed.
• Time taken to respond to service enquiries.
• Participant attendance and feedback.
• Complaints and incidents, including how they were resolved.
• Actual operating costs and financial sustainability.
• Continued participation by providers and partner institutions.

Where outcomes depend on health or clinical measures, assessment should remain with appropriately qualified professionals using suitable methods. Participation counts or satisfaction surveys alone should not be treated as evidence of clinical effectiveness.

A staged path to implementation

1. Select the service: Define whether the first initiative concerns AYUSH practitioner discovery, group wellness activities, or an institution-linked programme.
2. Define the locality and users: Establish who the service is for and what local need it is intended to address.
3. Verify provider requirements: Confirm applicable credentials, registration, service scope and legal obligations.
4. Agree the operating model: Set responsibilities, fees, communication, consent, safety procedures and complaint handling.
5. Conduct a limited pilot: Begin only when appropriate providers, resources, agreements and procedures are in place.
6. Review the evidence: Decide whether to continue, revise or expand based on actual demand, participant feedback, safety and financial viability.

The project should expand only when its service model is clear, its responsibilities are manageable and the results justify further investment.

Discuss an AYUSH Network Project

Eligible practitioners, wellness providers, institutions and community organisations interested in exploring a collaboration can describe the service they provide, their qualifications, the community they intend to serve and the kind of coordination they need.

An initial discussion does not establish a partnership, guarantee referrals or commit any organisation to participate. Any implementation would require a separately agreed scope, appropriate verification and the necessary approvals.

How to Apply or Collaborate

11 - Emergency Coordination

1. Project Overview: Coordinating the Path to Emergency Care

When a person experiences a medical emergency, family members or caregivers may need to identify the appropriate emergency service, communicate the location, arrange transport and inform a suitable healthcare facility. Uncertainty about who is responsible for each step can create additional difficulty during an already stressful situation.

The proposed Emergency Coordination project explores how these activities can be better organised around existing emergency services and eligible local providers.

Its purpose is to establish a clear, locally appropriate process for raising concerns, contacting the right service, communicating essential information and recording the outcome where feasible. The project is a coordination initiative, not a substitute ambulance service, emergency medical service or hospital emergency department.

What the project could support

• Clear instructions for contacting official emergency services.
• A directory of verified ambulance and other relevant service providers.
• Defined procedures for communicating location, contact details and essential information.
• Coordination with an ambulance provider when that provider is available and accepts the request.
• Communication with an appropriate receiving healthcare facility, where arrangements permit.
• Updates for family members or authorised caregivers.
• Non-clinical assistance with navigation and communication.
• Review of coordination delays, failed handovers and other operational problems.

These capabilities are proposed. No operational command centre, live dispatch platform, guaranteed response network or established hospital arrangement is assumed.

2. Project Model: From Emergency Recognition to Appropriate Handover

The model should be designed around existing emergency arrangements in the selected locality. The first priority is to ensure that people know how to obtain emergency help without waiting for a new WARA system.

The proposed coordination workflow

1. Recognise the emergency and contact the appropriate service

The person present should contact the appropriate official emergency service immediately when urgent medical assistance is needed. A future coordination service must never delay that contact while collecting information, checking a directory or seeking internal approval.

2. Communicate essential information

Where appropriate and safe, the caller or authorised helper provides the location, callback details and relevant information requested by the emergency service. Any additional coordination should follow the instructions of the responsible emergency professionals.

3. Identify available transport support

If ambulance coordination is part of the agreed project, the coordinator may contact an eligible provider or follow an established dispatch procedure. Availability must be confirmed by the provider. The project must not imply that the nearest vehicle is necessarily available, suitable or authorised for the required response.

4. Support communication with the receiving facility

Where applicable, information may be communicated to a receiving healthcare facility through an authorised process. Hospital selection, admission and clinical decisions remain with the responsible healthcare professionals and institutions.

5. Keep authorised people informed

A coordinator may provide practical status updates to the family or authorised caregiver, subject to the situation, consent and applicable privacy requirements. Communication should not interfere with emergency treatment or transport.

6. Record and review the outcome

Where an agreed system exists, the responsible coordinator can record key operational events, such as the time a request was received, provider contact, confirmed dispatch and handover. These records can help identify coordination problems and improve the process.

The workflow is a framework for a future implementation, not a claim that these steps currently operate as one integrated system.

Who would do what?

A coordination role does not confer authority to dispatch official emergency resources, provide medical instructions or promise hospital acceptance.

Possible implementation models

The project could be developed through one of the following approaches, depending on local need and the participation of existing services.

• Emergency information and navigation: maintaining verified contact information and clear guidance for contacting appropriate services.
• Ambulance-provider coordination: helping connect a request to an eligible provider when the provider’s availability and service scope are confirmed.
• Institutional coordination: agreeing how a school, care facility, community organisation or other institution contacts emergency services and communicates with families.
• Caregiver preparedness: helping caregivers understand emergency contact procedures, essential information to keep available and the limits of non-clinical assistance.
• Operational reporting: reviewing coordination records to identify recurring problems and opportunities for improvement.

These models have different resource, legal and operational requirements. They should not be treated as one combined service until responsibilities and capacity have been established.

3. Resources and Financial Model

People and operating capability

A limited coordination project may require:

• A designated project coordinator.
• Verified contact information for relevant emergency services and participating providers.
• Written procedures for emergency escalation and communication.
• Trained personnel for any agreed non-clinical coordination duties.
• Appropriate supervision, recordkeeping and incident-review arrangements.
• Technical support if a digital directory, communication workflow or reporting tool is introduced.

If the project expands into dispatch or emergency transport operations, it will require a separate assessment of staffing, availability, authorisation, infrastructure, insurance, equipment and other applicable requirements. A simple coordination directory must not be presented as a functioning emergency response operation.

Technology and infrastructure

Depending on the selected model, technology could support:

• Verified service-provider contact records.
• A controlled directory of service areas and operating hours.
• Request and communication logs.
• Authorised status updates.
• Escalation instructions and operational checklists.
• Incident reporting and performance review.

These are potential capabilities, not features claimed to be operational. Technology must have appropriate availability, access controls, security, maintenance and fallback procedures. A digital tool must not become a single point of failure for obtaining emergency help.

Any location or health information should be collected and shared only when necessary and permitted. A coordinator should not assume that family, provider or hospital information can be circulated freely merely because an emergency is involved.

Potential funding and revenue

The financial arrangement should follow the chosen project scope.

Potential sources may include:

• CSR support, grants or donations for eligible community preparedness and coordination activities.
• Institutional funding for a defined programme.
• Agreed charges for legitimate commercial coordination or technology services.
• Separately contracted services provided to a participating institution or provider.

No ambulance trip volume, dispatch fee, referral payment or recurring commercial revenue should be assumed without a defined service and a reviewed financial arrangement.

The project should not create incentives that distort emergency prioritisation, encourage unnecessary transport or compromise the independence of clinical decisions.

Wara KarmaYoga Foundation may support eligible charitable education and community-preparedness activities within its objects and approvals. Wara Systems may provide separately agreed commercial technology or operational services. Their responsibilities, accounts and liabilities must remain distinct.

4. Governance, Safety and Risk

Emergency coordination has a higher duty of care than ordinary appointment or service scheduling. The project must have clear boundaries and must be reviewed by appropriately qualified emergency-service, healthcare and legal professionals before any operational launch.

Emergency escalation and service boundaries

• Official emergency services must remain the primary route for urgent assistance where applicable.
• A person must not be asked to wait for a WARA coordinator or platform before contacting emergency services.
• Non-clinical coordinators must not diagnose, prescribe treatment, perform unauthorised clinical tasks or override emergency-service instructions.
• Ambulance dispatch, clinical triage and treatment decisions remain with the authorised services and professionals responsible for them.
• No receiving hospital or healthcare facility should be represented as having accepted a patient unless that has been confirmed through the appropriate process.
• Any future service must define what happens when a provider is unavailable, a call cannot be completed or communication systems fail.

Accountability and records

Before a pilot begins, the project should identify who is responsible for each activity, how incidents are reported, who reviews complaints and how the project is suspended if it cannot operate safely.

Records should capture only information needed for the agreed purpose. Access to personal and health information must be restricted, and retention and sharing arrangements must comply with applicable requirements.

Key risks and controls

Institutional boundaries

Each participating organisation retains responsibility for its own personnel, assets, services and legal obligations. Any use of institutional premises, staff, funds, identity or resources requires the appropriate agreement and approval.

5. Mission Value and Expected Outcomes

A well-defined coordination process may help individuals and caregivers understand how to obtain emergency assistance, reduce avoidable communication difficulties and clarify the handover between existing services. These benefits must be demonstrated through an appropriately designed implementation.

Potential value

For individuals and families: clearer emergency contact information and a better understanding of whom to contact.

For ambulance providers: a defined communication process for requests that fall within their service scope, without a promise of guaranteed demand.

For healthcare facilities: clearer administrative communication where a participating institution agrees to such a process.

For community organisations: a structured way to support emergency preparedness without assuming the responsibilities of medical professionals or official emergency services.

For the wider community: an opportunity to identify recurring coordination barriers and develop practical improvements based on evidence.

Measures of success

A limited pilot could assess:

• Number of participating organisations and providers whose details have been verified.
• Proportion of test contacts successfully verified during scheduled reviews.
• Time taken to reach the appropriate contact in controlled exercises.
• Proportion of coordination requests for which a provider confirms availability.
• Completeness of agreed operational records.
• Number and type of communication failures or unresolved requests.
• Compliance with escalation and information-handling procedures.
• Feedback from participating organisations and caregivers.
• Documented corrective actions following incidents or exercises.

Any measurement of response time or emergency outcomes must use reliable records and a clearly defined method. A pilot must not expose real patients to avoidable risk merely to test the system.

A staged path to implementation

1. Define the problem: Select a locality and identify the specific coordination gap to address.
2. Map existing arrangements: Understand official emergency contacts, eligible ambulance providers and relevant healthcare facilities.
3. Agree responsibilities: Establish the scope, escalation procedures, availability checks, communication rules and accountability.
4. Review safety and compliance: Obtain the necessary professional, institutional and legal review before live operation.
5. Test the process: Use contact verification and controlled exercises before considering live coordination.
6. Evaluate the evidence: Decide whether to continue, revise or expand based on safety, actual need, provider participation and operational feasibility.

The project should progress only when the proposed service can complement existing emergency arrangements without creating confusion about who is responsible for the response.

Discuss an Emergency Coordination Project

Emergency-service providers, healthcare institutions and community organisations interested in improving a specific coordination process can describe the locality, existing arrangements, the problem they have identified and the role they could contribute.

An initial discussion does not establish an emergency-response partnership, guarantee service availability or commit any organisation to participate. Any implementation would require a defined scope, verified participants, appropriate approvals and documented responsibilities.

How to Apply or Collaborate

12 - Surgical Facility Network

1. Project Overview

Hospitals and surgical facilities may have periods when some of their infrastructure is not fully utilised. At the same time, patients in some communities face difficulties accessing planned procedures because of distance, affordability, specialist availability or fragmented coordination.

The Surgical Facility Network explores whether these gaps can be addressed through specific, facility-led partnerships, rather than by building a new surgical infrastructure network from the outset.

The proposed model brings together the parties required for a defined surgical programme:

• Hospitals and surgical facilities with suitable infrastructure and clinical governance.
• Registered and appropriately qualified surgeons, anaesthetists and other clinical professionals.
• Healthcare providers who can assess patients and determine whether a procedure is appropriate.
• Diagnostic and other support providers where required.
• Organisations that can support patient communication, administrative coordination and post-discharge arrangements.

The hospital or authorised healthcare provider retains responsibility for clinical decisions and surgical care. WARA’s potential contribution would be limited to the programme, coordination, technology or implementation services expressly agreed for a particular project.

What the project may create

Depending on the selected location and verified need, a project could establish:

• A documented partnership with one or more eligible surgical facilities.
• A defined process for evaluating requests for planned procedures.
• Agreed responsibilities for patient assessment, scheduling, admission, surgery and discharge.
• Administrative coordination between participating providers.
• A method for reviewing facility utilisation, patient access, safety and financial viability.

The initial task is to establish whether a workable partnership exists. The number of facilities, procedures, participating professionals and patients must be determined through project-specific assessment.

2. Project Model

The network should begin with a defined clinical and operational need, not with an assumption that unused operating theatre time automatically creates a viable programme.

Proposed project flow

Need identified → Feasibility assessed → Partners and responsibilities agreed → Patients assessed by qualified providers → Procedure scheduled → Hospital-led care → Follow-up and review

Step 1: Assess the need and feasibility

Identify the proposed procedure category, intended patient group and service area. Assess likely demand, affordability, travel requirements, availability of qualified professionals and the suitability of existing facilities.

The assessment must distinguish an expressed community need from verified demand for a particular procedure. No patient volume or utilisation improvement should be assumed before validation.

Step 2: Establish facility and clinical partnerships

A prospective facility would be assessed for its ability to support the proposed procedures. Relevant considerations include:

• Appropriate operating theatre and supporting infrastructure.
• Anaesthesia, recovery, sterilisation and infection-control arrangements.
• Qualified clinical staff and support personnel.
• Emergency response capability and arrangements for complications.
• Required licences, registrations, approvals and insurance.
• Patient admission, discharge, recordkeeping and grievance procedures.

The facility’s authorised management and clinical leadership must approve the proposed operating arrangement. Specialist participation must be separately established; the network does not automatically provide surgeons or clinical teams.

Step 3: Define the patient pathway

Participating healthcare providers would define how patients are assessed, informed and accepted for treatment.

Clinical assessment, investigations, consent, suitability decisions and prioritisation remain the responsibility of qualified professionals. Administrative coordination may support appointments, document collection and communication, but it cannot substitute for clinical judgement.

No procedure should be scheduled merely to fill available operating theatre time.

Step 4: Deliver the agreed programme

If a pilot is approved, the facility and clinical team would conduct procedures under the facility’s established clinical governance and applicable requirements.

The project agreement would specify who is responsible for staffing, consumables, equipment, admission, anaesthesia, recovery, complications, emergency escalation, discharge and clinical records.

Batch scheduling or designated surgical days may be considered only where the clinical team confirms that the arrangement is appropriate for the procedures and patients involved. Efficiency must not override individual clinical needs or safe staffing.

Step 5: Arrange continuity and review

Before discharge, the responsible healthcare provider should establish the appropriate follow-up plan and communicate it to the patient or authorised caregiver.

Where suitable arrangements exist, the project may coordinate with other participating providers for diagnostics, recovery support or follow-up appointments. Such support must be agreed in advance and must not be presented as an existing WARA service.

The pilot should then be reviewed against agreed measures, including patient experience, safety, facility use, operational costs and financial sustainability.

Responsibilities of participating parties

These roles are a proposed framework, not a statement that any organisation or professional has already joined the network.

3. Resources and Financial Model

The financial model must be developed for the specific procedure category, facility, geography and patient group. Surgical programmes have materially different requirements, so a single network-wide cost or revenue assumption would be unreliable.

Resources required

Clinical and operational personnel

• Facility management and programme coordinator.
• Qualified surgeons, anaesthetists and other required clinical professionals.
• Nursing, theatre, recovery and support staff.
• Administrative personnel for scheduling, patient communication and records.
• Appropriate diagnostic, transport or post-discharge support providers, where required.

Facilities and equipment

The participating facility must have the infrastructure, equipment, consumables, sterilisation, medicines, recovery arrangements and emergency capability appropriate to the agreed procedures. Any gaps must be assessed and addressed before implementation.

Coordination and technology

A project may need scheduling tools, secure document exchange, communication workflows, reporting and agreed methods of handling patient information. These are possible requirements, not claims that a surgical coordination platform is currently operational.

Potential funding and revenue

A project-specific financial arrangement may consider:

• Patient payments under transparent, agreed terms.
• Facility charges and professional fees.
• Philanthropic or CSR support for eligible patient-access programmes.
• Grants or other permitted funding.
• Separately agreed coordination, technology or implementation services.

The source and use of any subsidy must be explicit. If the project is intended to serve patients who cannot afford treatment, eligibility, the subsidy budget and responsibility for uncovered costs must be established before accepting patients.

No guaranteed patient volume, referral flow, facility utilisation, professional income or commercial return is implied.

Institutional and commercial separation

Wara KarmaYoga Foundation Trust may explore eligible charitable activities relating to healthcare access, community support and assistance to people who face barriers to services, subject to its mandate, resources and approvals.

Wara Systems may provide separately agreed commercial technology, coordination or implementation services where appropriate. Any such arrangement should define the service, payment, data responsibilities and accountability. The commercial role must not be confused with the Trust’s charitable activities.

Where applicable, Wara may receive an agreed payment for actual programme, system, technology or implementation services provided to the project, as defined in the project-specific financial arrangement.

4. Governance, Legal Boundaries and Risk

Surgical care is a high-responsibility clinical activity. The network’s purpose is to support appropriate collaboration, not to take over the authority of hospitals or qualified healthcare professionals.

Clinical authority and compliance

Every implemented programme must establish the applicable requirements for the facility, professionals, procedures, patient consent, clinical records, medicines, infection control, emergency arrangements and insurance.

The responsible facility and clinical professionals retain authority over clinical suitability, procedure selection, scheduling priorities, treatment, complications and discharge. Administrative or commercial partners must not direct clinical decisions.

The network must not:

• Arrange procedures without the required clinical assessment and patient consent.
• Represent a facility or professional as approved or available before verification.
• Promise a particular procedure, outcome, admission or recovery.
• Treat unused capacity as a reason to perform an unnecessary procedure.
• Make unsupported claims about reduced waiting times, lower costs or improved clinical outcomes.

Patient safety, privacy and accountability

A project-specific agreement should define:

• Clinical responsibility and escalation arrangements.
• Facility and professional eligibility checks.
• Patient communication, consent and grievance handling.
• Access to and protection of health information.
• Financial disclosures and responsibility for patient charges.
• Incident reporting, review and corrective action.
• Insurance, liability and termination arrangements.

Patient information should be shared only for an authorised purpose, with appropriate safeguards and access controls. Technology may support coordination, but it does not replace professional responsibility or clinical recordkeeping obligations.

Key risks and proposed controls

Wara, the facility and any other participating organisation would retain their respective governance, personnel, assets and liabilities. Participation by RKM, if separately approved, would not by itself create a continuing obligation for RKM to finance, operate or expand the project, nor transfer Wara’s commercial or organisational liabilities to RKM.

5. Mission Value and Expected Outcomes

The proposed network seeks to explore whether existing surgical facilities can support better-organised access to appropriate procedures through responsible partnerships. Its value must be demonstrated through a defined pilot rather than assumed from the existence of infrastructure.

Measures for a pilot

The participating parties should agree on a baseline and a small set of measures appropriate to the selected procedures, such as:

• Number of facilities assessed and formally participating.
• Availability of the agreed clinical team and required resources.
• Number of patients assessed by authorised providers.
• Procedures scheduled, completed, postponed or cancelled, with reasons recorded.
• Use of agreed facility capacity, where reliable baseline data exist.
• Patient-reported experience and clarity of information.
• Follow-up arrangements completed and unresolved issues escalated.
• Actual programme costs, funding sources and financial sustainability.
• Safety incidents and completion of required reviews.

Measures of surgical volume or utilisation must always be interpreted alongside clinical appropriateness, patient safety and quality of care. A higher procedure count alone is not evidence of success.

A staged approach

A responsible implementation pathway would be:

1. Explore: Identify a potential facility, a defined patient-access problem and a suitable procedure category.
2. Assess: Verify demand, clinical requirements, facility readiness, partner capability, costs and regulatory obligations.
3. Agree: Document responsibilities, patient pathway, funding, data handling, risk allocation and approval requirements.
4. Pilot: Proceed only after the necessary arrangements are approved and resources are confirmed.
5. Review: Evaluate results, safety, cost, patient experience and operational feasibility before considering any continuation or expansion.

The initial objective is to determine whether one well-defined surgical programme is feasible. Expansion to other procedures, facilities or regions would require separate evaluation and approval.

The project is intended to create measurable value within its own scope. If successful, its experience and learning may be reused or adapted for future programmes, subject to separate consideration and approval.

Discuss a Surgical Facility Partnership

Hospitals, eligible surgical facilities, healthcare organisations and potential funding partners may express interest in exploring a specific project. An initial discussion should identify the location, proposed procedure category, facility capability, intended patient group and the contribution each party may be able to make.

How to Apply or Collaborate

13 - Technical and Service Provider Network

1. Project Overview

Homes, businesses, schools and community institutions depend on technical infrastructure. Computers need maintenance, networks require installation and troubleshooting, broadband connections need support, and security equipment must be installed and maintained correctly.

Yet customers may find it difficult to identify a suitable technician, understand the scope and cost of a job, or obtain reliable follow-up service. Skilled workers may face the opposite problem: they can perform useful work but lack a dependable way to reach customers, build a service record or organise recurring assignments.

The proposed Technical and Service Provider Network seeks to address these challenges by connecting defined customer needs with appropriately skilled and eligible service providers.

The network may eventually support individual technicians, small service businesses, specialist providers and coordinated teams. It could serve households, schools, offices, healthcare facilities, hospitality businesses, community institutions and other organisations, depending on local demand and provider capability.

Initial areas of work

The broader technical and infrastructure domain may include:

• Computer and IT support: Computer setup, operating-system installation, peripheral configuration, routine maintenance and troubleshooting.
• Broadband and connectivity: Wi-Fi and local-area network installation, connectivity troubleshooting, and suitable broadband and fibre-related work.
• Networking and CCTV: Network equipment installation, IP camera configuration, testing, documentation and maintenance.
• Solar and essential technical services: Appropriate installation assistance, inspection and maintenance support, with regulated or hazardous tasks restricted to qualified and authorised personnel.
• Facility and equipment support: Defined installation, inspection, maintenance and technical support tasks where suitable competence and permissions can be established.

These are potential service categories, not a declaration that every service is currently offered. Each category requires a defined scope, suitable tools, competency requirements, customer demand and any necessary professional authorisations.

The initiative is proposed. It does not imply an active provider directory, established customer pipeline, guaranteed assignments or a functioning dispatch and payment system.

2. Project Model

The network should begin with a specific service category and a real customer need. It should not attempt to cover every technical occupation from the beginning.

A. Define the service and the customer need

For each selected category, establish:

• What problem or task the customer needs addressed.
• Whether the work is installation, maintenance, troubleshooting, repair or inspection.
• What information is needed before estimating the work.
• What tools, equipment, materials and technical capabilities are required.
• Whether the work requires a licence, registration, supervision or specialist authorisation.
• How the result will be tested and accepted.
• How pricing, expenses, warranties and follow-up responsibilities will be handled.

A request for a service is not a confirmed assignment. The scope and feasibility should be assessed before a provider commits to the work.

B. Prepare and verify service providers

Potential providers may include experienced technicians, people completing relevant vocational training, independent workers and existing local service businesses.

KarmaYoga’s proposed learning architecture supports a progression from learning to demonstrated competence and increasingly independent responsibility:

Learn → Practise → Demonstrate → Verify → Qualify → Work

For technical occupations, preparation may include practical installation, safe tool use, fault diagnosis, testing, documentation, customer communication, basic costing and maintenance procedures.

The intended progression is:

These pathway descriptions do not automatically confer a professional licence or national qualification. Any external qualification mapping, assessment route or authorisation must be verified for the specific occupation.

Experience and practical competence should also be assessed appropriately. A person who already has the required skills may need a suitable verification route rather than repeating all training, where such a route is available.

C. Match providers with suitable work

A proposed service workflow is:

Customer Request → Scope Assessment → Provider Selection → Estimate and Agreement → Service Delivery → Testing and Acceptance → Payment → Service Record

The process should make clear:

1. Request: Record the customer’s problem, location and relevant equipment or infrastructure details.
2. Assessment: Decide whether the task can be scoped remotely or requires a site visit.
3. Selection: Identify a provider whose demonstrated competence, availability and eligibility fit the work.
4. Agreement: Confirm the scope, price or estimation method, materials, schedule, payment terms and exclusions.
5. Delivery: Complete the work using appropriate safety and quality procedures.
6. Acceptance: Test or inspect the result against the agreed requirements.
7. Settlement: Record payment and handle any agreed warranty or follow-up obligations.
8. Work history: Maintain an appropriate record of the task, outcome and customer feedback.

The provider may be an independent professional, a small business or a team. The network should not assume that every assignment requires WARA to employ the worker or directly supervise the technical work.

D. Support different operating models

The network could explore several arrangements, depending on the service category.

• Customer-to-provider matching: Customers find suitable independent technicians or existing service businesses.
• Managed service delivery: A contracting organisation defines the service, coordinates delivery and remains accountable for the responsibilities it accepts.
• Local service teams: Several trained workers coordinate scheduling, tools, travel and quality checks under an agreed operating model.
• Institutional maintenance: Schools, offices, clinics, hospitality businesses or community facilities arrange defined maintenance and support services.
• Installation and project work: Customers engage suitable providers for scoped installation projects, testing and handover.

These arrangements are not interchangeable. Each requires clear responsibility for the customer contract, technical work, materials, payment, warranties, safety and complaint resolution.

E. Build a path from worker to service provider

An experienced technician may eventually move from individual assignments to organising a broader service.

For example:

Technical Assistant → Independent Technician → Service Provider → Local Service Team

Progression may involve learning to estimate jobs, schedule work, procure materials, maintain records, handle customer communication, manage quality and coordinate other workers.

A Diploma-level pathway may help prepare people for such responsibilities. It should not imply that every participant will become an entrepreneur or that sufficient customer demand already exists.

Roles in the proposed network

The proposed marketplace should be open to suitable external technicians, service businesses and organisations. It should not require every provider or customer to belong to WARA.

3. Resources and Financial Model

The resources required depend on the chosen service category, geographical coverage and operating model.

People and equipment

Potential requirements include:

• A coordinator to understand demand and define service requirements.
• Competent technicians and, where necessary, qualified specialists.
• Trainers, practical supervisors and assessors for relevant learning pathways.
• Tools, test equipment, protective equipment and consumables.
• Transport and communication arrangements where site visits are required.
• Technical documentation, testing procedures and maintenance records.
• Appropriate support for customer communication, estimates, payment and complaints.

Equipment should match the work. A computer-support service does not need the same tools or safety controls as fibre installation, CCTV work or solar maintenance.

Where specialist or regulated work is involved, the project must establish the applicable qualification, licensing, supervision and safety requirements before offering the service.

Potential funding and revenue

Charitable and programme funding may support eligible activities such as:

• Practical vocational training and assessment.
• Access to shared tools or training equipment.
• Safety preparation and supervised practice.
• Livelihood guidance and service-provider preparation.
• Community technical support programmes for eligible beneficiaries.

Potential sources include CSR support, grants, philanthropic donations and other permitted funding arrangements. Each contribution should have a defined purpose, accountable recipient and appropriate reporting.

Commercial service activity may be funded through:

• Customer payments for completed installation, maintenance or repair work.
• Service contracts with businesses or institutions.
• Agreed charges for materials, site visits or other defined deliverables.
• Commercial coordination or marketplace fees, where lawful and transparent.
• Separately contracted technology, implementation or operational services.

The provider’s earnings, customer charges and any coordination fees should be clearly distinguished. Pricing must account for labour, materials, transport, tools, rework risk, taxes where applicable and other legitimate costs.

No guaranteed job volume, customer demand, worker income or commercial return is implied.

Sustainability and institutional boundaries

A sustainable model must show who pays for training, who pays for the completed service, who owns or maintains equipment, and who remains responsible if work is delayed or fails acceptance.

Wara KarmaYoga Foundation Trust may support eligible charitable training and livelihood-development activities. Wara Systems may provide commercial technology or coordination services under a separately agreed arrangement. Any shared resources or related-party services should be properly documented and governed.

Where applicable, Wara may receive an agreed payment for actual programme, system, technology, curriculum or implementation services provided to the project, as defined in the project-specific financial arrangement.

The network should be evaluated on completed, accepted work and sustainable economics, not merely on the number of registered technicians or enquiries received.

4. Governance, Safety and Risk

Technical work can involve electrical hazards, working at height, customer premises, sensitive information and equipment that must operate reliably. Provider matching therefore requires more than availability.

Competence and scope

Providers should be selected according to demonstrated capability, relevant experience and any required licences, registrations or authorisations.

The network must distinguish between work a technician can perform independently, work requiring supervision and work that must be undertaken by a suitably qualified professional. For example, basic equipment support does not automatically authorise electrical installation or other regulated work.

Customer protection and quality

Each assignment should establish:

• The agreed scope, estimate and exclusions.
• Responsibility for materials, equipment and access.
• Testing and acceptance criteria.
• Documentation of changes or additional work.
• Payment terms and the process for handling disputes.
• Applicable warranty, maintenance or follow-up commitments.
• A way to report unsafe work, damage or unsatisfactory service.

Customer feedback can help improve service quality, but ratings alone should not replace appropriate verification or technical testing.

Safety, privacy and accountability

Depending on the service, safeguards may include:

• Safe tool use, electrical safety and work-at-height precautions.
• Site risk assessment and appropriate protective equipment.
• Secure handling of customer credentials, network configurations and CCTV footage.
• Permission to access customer premises and systems.
• Clear boundaries around confidential business or household information.
• Incident reporting, complaint handling and corrective action.
• Appropriate insurance and contractual allocation of liability.

Providers should not retain customer passwords, recordings or other sensitive information beyond the authorised purpose and agreed retention period. Access to customer systems should be limited to what is needed for the task.

Key risks and controls

Each organisation retains its own personnel, assets, governance and liabilities. Participation in a project does not automatically create a continuing obligation for RKM to finance, operate or expand it, nor does it transfer Wara’s commercial or organisational liabilities to RKM.

5. Mission Value and Expected Outcomes

The Technical and Service Provider Network is intended to help turn practical technical capability into reliable services and possible livelihood opportunities.

For customers, the potential value is a clearer route to finding a suitable provider, agreeing on the work and checking the result. For technicians, it may create opportunities to demonstrate competence, build a work history, reach more customers and develop independent service capability. For local communities, it may support access to technical maintenance and installation without requiring every service provider to operate as a large business.

The value must be established through actual service delivery, customer experience and viable operating arrangements.

Measures of progress

A pilot should establish a baseline and track suitable indicators, including:

• Number of customer and institutional requirements assessed.
• Number of providers whose competence and eligibility have been checked.
• Number of estimates and assignments accepted.
• Number of jobs completed and accepted.
• Timeliness of delivery and payment.
• Repeat customers and recurring maintenance requirements.
• Customer feedback, complaints and resolution.
• Safety incidents, rework and service failures.
• Provider earnings and operating costs where reliable records are available.
• Number of workers progressing towards independent service provision or organised team roles.

Registration and training completion are useful activity measures, but they do not prove that the network is generating sustainable work.

A staged implementation approach

1. Choose a service category: Start with a manageable scope such as computer support, broadband and Wi-Fi, or CCTV installation and maintenance.
2. Validate demand: Speak with potential customers and institutions, document common needs and determine whether they are willing to pay for the proposed service.
3. Define standards: Establish provider eligibility, practical competency requirements, equipment needs, safety controls and acceptance criteria.
4. Establish the operating model: Decide who contracts with customers, who assigns work, who collects payment and who handles complaints or warranty obligations.
5. Run a limited pilot: Work with a small group of eligible providers and verified assignments.
6. Review results: Assess completed work, repeat demand, customer experience, provider earnings, safety and costs before considering expansion.

The initial objective is to establish a service model that works reliably in a defined context. Expansion into additional technical categories or locations should follow only when the relevant demand, provider capability and operating arrangements have been established.

The project is intended to create measurable value within its own scope. If successful, its experience and learning may be reused or adapted for future programmes, subject to separate consideration and approval.

Discuss a Technical Service Partnership

Technicians, service businesses, training providers, equipment suppliers, employers, institutions and potential funding partners may express interest in exploring a specific service category or local pilot.

An initial discussion should identify the customer need, proposed work, provider capability, location, equipment requirements and the responsibilities each participant is prepared to accept.

How to Apply or Collaborate