Lets document the process of deploying care to DO app platform.

• Add the docs to the deploy docs
• Get it reviewed by @vigneshhari
• Publish

Context:
Currently, in Care, consultations take care of an entire visit and there is no separation between multiple doctor appointments.

Idea:
Have an encounter that encompasses the entire visit of a patient (something similar to existing consultations) and within them a way to group one or more doctor consultations.

Checkout encounters and appointments in FHIR for initial reference:

• https://build.fhir.org/encounter.html
• https://build.fhir.org/appointment.html

TODO:

• Rename existing consultation to encounter
• Design actual consultation

Needs further discussions before getting started

Context:
Currently, in Care, we have a file upload functionality where the user can upload a file to a consultation of a patient (and a few other variants of this like HCX and ABDM).

Idea:
Improve the existing file upload functionality so that it is easy to manage files,

• User being able to create folders to group files
• User being able to label files which can be used for searching and filtering
• Support for viewing Dicom files.

Needs further discussions before getting started

This issue serves as a comprehensive placeholder for the ideas/features for implementation in our long-term roadmap. Before being taken up for active development, each item needs to be detailed in a separate issue within this docs repository. Following this, a RFC (Request for Change) will be drafted and submitted as a Pull Request (PR) to the docs repository for review and collaboration, outline the changes required on models and APIs for building this feature. Upon approval, an issue will be created in the respective application's repository, marking the beginning of the development phase.

Billing Pre-requisites

• Procedures - Scheduling - Team - Master List | Planned/Execution | Requires Generic Scheduling
• Asset/Bed Utilization (Ventilators) | consultation_bed_asset
• Investigations | Merge Sample flow & Investigations & Investigation Recommendations flow | maybe Rebuild? | Planned/Execution
• Medicine & Consumables | Planned/Execution
• Pharmacy/Inventory

Platform Features

• Citizen v2 with ABDM
• DICOM Viewer on care_fe | S3 based DICOM file management
• IM Wrapper for CARE/CARE bot (Ideally start with Whatsapp)
• Middleware Rewrite in Django | Active GSoC Project

Consultation/Encounter Related

• Refactor patient_consultation as patient_encounter
• Create Consultation/Appointments with Encounters | Requires Generic Scheduling
• Build out ABDM Scan & Share for Creating Appointments

Long Term

• Billing App
• Billing Export to Odoo or similar CRM/Accounting System
• RBAC
• Plugin Architecture
• Events Archival
• Scribe | Internal rewrite
• Generic Scheduling System | for Consultations, Doctors, Resources, Locations etc

The existing models for Sample Tests and Investigations needs to be reimagined, to create a unified flow for Managing Lab Orders and for storing the final results as Investigations

Context:
Care uses an additional service to control and communicate between hardware devices used in teleicu. These devices primarily include cameras and 5 para monitors.

checkout the service at https://github.com/coronasafe/teleicu_middleware

Todo:

• Rewrite the entire service code in python (preferred in Django)

Needs further discussions before getting started

Project Detail

CARE is a centralized capacity management and patient management system, central to the 10BedICU Project, integrating patients, doctors, hospitals, labs, specialized treatment centers, hospital administrators, and shifting control cells. Hospitals update crucial information about their assets, providing district administration with a comprehensive view of the healthcare system via smart dashboards. CARE digitizes patient records, streamlines workflows for pandemic management, and is deployed in remote areas, enabling TeleICU services for underserved citizens. It revolutionizes healthcare management, enhancing efficiency, accessibility, and patient outcomes.

Features To Be Implemented

This project outlines enhancements to the existing facility inventory management system. This feature will assist users in managing facility inventory and pharmacy. The features expected to be achieved are outlined below:

• Dynamic Inventory Management: Allow adding and removing items dynamically to support pharmacy and inventory management.
• Facility and Location Tracking: Implement a log to track stock and issuance locations within the facility, e.g.,Store room, pharmacy, ICU, ward etc
• Real-time Stock Levels: Ensure real-time visibility of stock levels for efficient management.
• Automated Reordering: Integrate automated reordering based on minimum stock levels and rate of consumption. (Low Stock items on top of the list)
• Report Generation: Add export functionality to generate csv report (Inventory Name, Location, Current Stock, Minimum Stock Required, Last Updated Date)

Learning Path

Link to documentation for Product Set-Up

1. For setting up the frontend, please refer to the readme file available at: https://github.com/coronasafe/care_fe
2. For setting up the backend, please refer to the readme file available at: https://github.com/coronasafe/care

Acceptance Criteria

• All the CI/CD workflows should pass.
• Code is logically structured for long-term project sustainability.
• Proper descriptions should be included for review purposes.
• QA and Code Review

Milestone

• Get to know CARE as a product and understand the workflow.
• Understand the user-level requirements and come up with a design.
• Design and implement the updated UI
• Complete functionality of Enhanced Inventory Management System
• Implement a Basic Cypress automation test to test functionality
• Optimise and improve UX
• Review and QA

Todo:

• Clean up the usage or access of the abdm app inside the facility app
  • care/facility/models/patient.py

    abha_number = models.OneToOneField(
        AbhaNumber, on_delete=models.SET_NULL, null=True, blank=True
    )


    # TODO: move this relation inside Abha Number model
    
    patient = models.OneToOneField(
        Patient, on_delete=models.CASCADE, null=True, blank=True
    ) # VERIFY: abha number is deleted when patient is deleted and not vice versa
    
    # TODO: Add the necessary migration

  • care/facility/api/serializers/patient.py

    abha_number = ExternalIdSerializerField(
      queryset=AbhaNumber.objects.all(), required=False, allow_null=True
    )
    abha_number_object = AbhaNumberSerializer(source="abha_number", read_only=True)
    
    # TODO: create an extended serializer in abdm plug for internal use and in the frontend seperate out the api calls for patient and abha number

  • care/facility/api/serializers/patient_consultation.py

    if patient.abha_number:
        abha_number = patient.abha_number
        try:
            AbdmGateway().fetch_modes(
                {
                    "healthId": abha_number.abha_number,
                    "name": abha_number.name,
                    "gender": abha_number.gender,
                    "dateOfBirth": str(abha_number.date_of_birth),
                    "consultationId": abha_number.external_id,
                    "purpose": "LINK",
                }
            )
        except Exception:
            pass
    
# TODO: use signals to intercept post_save inside plug
    
    # in signals/consultation.py
    from django.db.models.signals import post_save
    from django.dispatch import receiver
    from facility.models import Consultation  # Import the Consultation model from the facility app
    
    @receiver(post_save, sender=Consultation)
    def create_care_context(sender, instance, created, **kwargs):
        patient = instance.patient
        abha_number = AbhaNumber.objects.filter(patient__external_id=patient.id)
        if created:
            try:
                AbdmGateway().fetch_modes(
                    {
                        "healthId": abha_number.abha_number,
                        "name": abha_number.name,
                        "gender": abha_number.gender,
                        "dateOfBirth": str(abha_number.date_of_birth),
                        "consultationId": abha_number.external_id,
                        "purpose": "LINK",
                    }
                )
            except Exception:
                pass 

• Move envs and routes to the plug

Extras:

• Clean up fetch_modes, init, confirm flow
• Refactor M1 & M2 into the structure used in M3
• Add standard suffixes for the routes of abdm callback apis

This EPIC issue serves as a placeholder to track the changes and features to be implemented under ABDM Integration.

• #22
• Write tests for ABDM data mapping
• Write tests for ABDM flows
• Show user-friendly error messages
• Implement new counterparts of the APIs and deprecate the older ones
• Fix the scan and share flow
• Implement the pending M1 flows
  • Creation and Verification using Aadhaar Demographics
  • Creation using Aadhaar Biometric
  • Creation using a Driving License
  • Profile Update
• Fix Download ABHA card flow
• Scope out integrating HFR (Health Facility Registry) and HPR (Health Professional Registry)
• Improve the UI UX of the incoming data displayed from ABDM
• Improve the FHIR mapping of the data sent out via ABDM

Overview

Implement a feature flipper system in CARE, starting with the requirement to control the availability of the Scribe for specific users or facilities OR Available Instance-wide. This feature flipper should be built as a general-purpose module that can be reused across different parts of CARE. The flipper should have an API(to be used by FE) and authorization blockers.

Requirements

1. Feature Flipper Implementation:
   • Develop a feature flipper mechanism that can toggle features on or off based on user or facility-specific configurations.
   • Management of the Feature Flipper can be done in the Django Admin Panel

Implementation Approach: Evaluate the feasibility of using an existing package for the feature flipper or consider creating a custom implementation if a suitable package is not available or does not meet the requirements.

2. API Integration:

   • Create an API endpoint to check if a specific feature (starting with Scribe) is enabled or not for a user or facility.
   • This API should be able to:
     • Accept current_user or facility request_param.
     • Return the status of the feature (enabled/disabled).

3. Authorization Blockers:

   • Implement authorization logic that prevents unauthorized access to the Scribe feature if it is disabled for a user or facility.
   • Ensure that any attempt to access the Scribe feature via API will be blocked and return an appropriate error message if the feature is not enabled.

4. Care Scribe Add-On Integration:

   • Update the Care Scribe add-on to utilize the new feature flipper API.
   • Modify the add-on to check the feature status before allowing access to its functionalities.

5. Documentation:

   • Document the feature flipper's implementation details, including:
     • API endpoints and their usage.
     • How to add new features to the flipper system.
     • How to configure the feature flipper for specific users or facilities.

6. Deployment:

   • Ensure the feature flipper is deployed in a manner that does not disrupt existing functionality.
   • Perform testing to verify that the feature flipper works as expected and that unauthorized access to disabled features is properly blocked.

Additional Considerations

• Consider implementing logging for feature flip decisions to help with debugging and auditing.
• Make sure the feature flipper is performant and does not introduce significant overhead to API requests.

Checklist

• Feature flipper system is implemented and can toggle features for specific users and facilities via Django Admin.
• API endpoint for checking feature status is live and functioning correctly.
• Authorization blockers prevent unauthorized access to the Scribe feature based on the flipper status.
• Care Scribe add-on is updated to use the feature flipper.
• Documentation for developers and administrators.

Requirements

Develop a scheduling system within CARE that supports managing outpatient (OP) tickets or slots. Each doctor should be able to configure their availability, specifying the days they will be available and either the number of slots or the duration they will be available for. Appointments can then be booked within these availability windows. The system should offer both an appointment-based and a token-based model, ensuring that the number of tokens matches the available slots. Additionally, the scheduling table should be flexible enough to handle bookings for different locations, such as operation theatres, cath labs, etc., which will be represented as location entities in CARE.

Appointments may include multiple participants or be linked to other objects. For example, a procedure could be an object with a team associated with it, and the team would consist of the participants involved in the appointment.

Moreover, a receptionist flow needs to be created for managing both the booking of appointments and the assignment of tokens, specifically for OP consultations. The receptionist flow should streamline the booking process for outpatient services.

Roadmap

• Create a Care Enhancement Proposal (CEP) outlining the APIs & Models for enabling Scheduling
• Get the CEP reviewed from the Core Team
• Expand the CEP with planned Mockups
• Design and Implement the models, APIs & UI

Context:
Different entities (let's call them "billable entities") in Care are utilized/consumed by a patient which the patient could be billed for.

A list of examples that a patient could be billed for:

• Procedures
• Asset utilization (ventilator, etc.)
• Bed utilization
• Investigations
• Consumables
• Medicines (administrations)
• Pharmacy / Inventory
• Consultations

Additional Features:

• Export Billing to Accounting softwares (eg: Odoo)

References:

• https://openmrs.atlassian.net/wiki/spaces/docs/pages/25521139/Billable+Objects+Developer+Documentation
• https://github.com/ArchiveOrg/openmrs-module-openhmis.billableobjects/tree/master/api/src/main/java/org/openmrs/module/openhmis/billableobjects/api/type

Needs further discussions before getting started

Context:
Currently, Care is only used by nurses, doctors, or generally hospital staff where the patient has no direct access to the application.

Idea:
Build an app where the patient can access their records in care.

Consider using ABDM for this.

Ref: ohcnetwork/citizen#43

Idea:
Create a whatsapp bot for Care where users can access non-sensitive info like

• patients being able to access their records, medication and so on
• doctors and nurses being able to access their schedules and so on

consent and privacy details should be reviewed

Develop bots for other IM based on future needs

Needs further discussions before getting started