A clearer view across your institution.
Bring your facilities, reporting teams and review decisions into focus. AfriMed™ helps authorised teams coordinate aggregate information and see where attention is needed.
The workflows below have been evaluated with synthetic data. Institutional workspaces are not yet open for general use; request a review to discuss evaluation and deployment. Technical overview: scope and requirements
Shared information. Clearer follow-through.
When reports, corrections and questions sit in separate conversations, it is difficult to see what has arrived, what still needs review and who should respond. The Institution workspace gives teams a shared place to organise facilities and responsibilities, while Regional Health brings aggregate reports and their review history together.
Know where reporting stands
See which facilities are ready to report and which records are drafts, submitted or awaiting review. Facility and programme context helps teams direct attention to the right part of their organisation.
Keep questions with the report
Review data-quality flags, request clarification and record the reason. Reviewers can reconcile and close records, with a history of actions and timing that makes the decision easier to follow.
Put the regional view in context
Explore authorised aggregate reports by facility, programme, reporting period and review status. The map adds approximate geography, helping teams relate the reports they can access to the facilities involved.
Built around the people responsible
Institution owners and authorised administrators organise facilities and membership. Reporting teams contribute the information; reviewers examine it and resolve questions. Teams with the appropriate Regional Health authority can review the wider picture within their assigned scope.
Each team can understand its part in the reporting process. People remain responsible for checking information, deciding what it means and taking the appropriate next action.
Access, interpretation and availability
Access and service availability are agreed with your organisation, its facilities and its reporting needs. Membership does not by itself grant clinical, research or wider Regional Health access. The illustration shows a workspace using synthetic aggregate information, not live population coverage.
Aggregate reports describe groups, not individual patient histories. Totals depend on the reporting period and completeness; a missing report does not mean zero events. Approximate map locations are not exact case locations, and a reported signal is not an outbreak declaration.
Clinical care and external public-health reporting retain their own professional responsibilities, permissions and authorised channels. External system connections and automatic reporting are not established capabilities of this workspace; any proposed integration needs a separate agreement and verification.
Make information useful across systems
Start with the decision your team needs to make. You may need approved facility totals for programme reporting, or information from another authorised service. Agree what should be shared, who may receive it and why before choosing a connection.
A controlled demonstration has exchanged synthetic data with a DHIS2 public-demo DataStore. This is not a live partner connection or national reporting service. A FHIR connection, or an exchange with a named hospital, laboratory or ministry, still requires its own implementation and validation.
Technical overview: scope and requirements
Purpose and access
The implemented Institution and Regional Health workflows organise facilities, aggregate reports, review decisions and audit history. They have been evaluated in a test environment with synthetic data. Owners and authorised administrators manage membership; reporting and review rights remain scoped. Membership alone grants no clinical, research or wider regional authority.
Information and data flow
For a proposed exchange, identify the source owner, recipient, dataset and operational purpose. The demonstrated external flow used synthetic aggregates sent from a server-side adapter to a shared DHIS2 demo DataStore, with acknowledgement, readback and retry checks. It does not establish patient-record exchange, a mapped reporting interface or a production partner service.
What an integration needs
Agree identifiers, terminology and versioned mappings; permissions and consent where applicable; data-quality checks and reconciliation; audit records; and failure, retry and duplicate-handling rules. The organisation and receiving system must approve the scope, local governance and acceptance tests before activation.
Deployment boundaries
Hosting, data residency, transfers, retention and deletion arrangements must be confirmed for the proposed deployment. A request opens a discussion; the response deadline does not promise a completed integration.
Standards in context
Africa CDC’s AU health-information-exchange guidance provides regional context. HL7 FHIR describes an exchange framework that needs local agreements. DHIS2 supports aggregate and individual-level integration use cases. These references do not certify or endorse AfriMed™.
Let’s discuss your institution
Tell us which facilities and teams you coordinate, what you need to report, and where review or follow-up becomes difficult. We can discuss the relevant access, reporting scope, languages and support before agreeing the next step.
Request accessPlease describe the organisational need without including patient-identifying information.