Plateau PHC EMR
Product Management
Built for Plateau State, Nigeria, this product is a digital platform designed to strengthen primary healthcare delivery, patient information management, and care coordination across the state's healthcare system. Primary healthcare is the foundation of Nigeria's healthcare system, but much of the information that moves through it is still fragmented across manual processes, disconnected records, and facility-level workflows. We set out to build a digital platform that could strengthen how primary healthcare facilities capture patient information, coordinate care, manage referrals, and generate health-system intelligence. What began as a product focused on improving referrals evolved into a broader Primary Healthcare Electronic Medical Record and Care Coordination System. The platform brings together patient records, clinical encounters, maternal and child health workflows, laboratory, pharmacy and inventory, referrals, ambulance coordination, reporting, alerts, and administrative visibility. I joined the project as the Product Manager, working with a seven-member cross-functional team of engineers, product designers, and a cybersecurity engineer. My responsibility was to take the product from early-stage discovery through product definition and delivery, translating complex public-health workflows into something the team could actually design, build, test, and present to government stakeholders. Although initially developed for Plateau State, the product architecture and workflows are being positioned for adaptation to other state-level implementations, including ongoing conversations in Lagos and Ogun States.
Built for Plateau State, Nigeria, this product is a digital platform designed to strengthen primary healthcare delivery, patient information management, and care coordination across the state's healthcare system. Primary healthcare is the foundation of Nigeria's healthcare system, but much of the information that moves through it is still fragmented across manual processes, disconnected records, and facility-level workflows. We set out to build a digital platform that could strengthen how primary healthcare facilities capture patient information, coordinate care, manage referrals, and generate health-system intelligence. What began as a product focused on improving referrals evolved into a broader Primary Healthcare Electronic Medical Record and Care Coordination System. The platform brings together patient records, clinical encounters, maternal and child health workflows, laboratory, pharmacy and inventory, referrals, ambulance coordination, reporting, alerts, and administrative visibility. I joined the project as the Product Manager, working with a seven-member cross-functional team of engineers, product designers, and a cybersecurity engineer. My responsibility was to take the product from early-stage discovery through product definition and delivery, translating complex public-health workflows into something the team could actually design, build, test, and present to government stakeholders. Although initially developed for Plateau State, the product architecture and workflows are being positioned for adaptation to other state-level implementations, including ongoing conversations in Lagos and Ogun States.
Client:
Plateau State Government
Role:
Product Manager
Year:
2026
Explore the full story –
Challenge
The challenge wasn't simply digitizing healthcare records. It was connecting the system around the people who use it. Healthcare workers, facility managers, and government administrators interact with the health system differently. At the same time, the system needed to support the underlying public-health reporting requirements and workflows expected from primary healthcare facilities. This created several product challenges: • Complex, interconnected workflows: clinical care, referrals, laboratory, pharmacy, maternal health, inventory, reporting, and administration could not be treated as isolated features. • Different user needs: each role required different information, actions, dashboards, and reports. • Referral coordination: referrals needed to carry the relevant clinical context forward rather than becoming a disconnected handoff. • Reporting: data captured during daily patient care needed to become useful for facility and state-level reporting. • Operational visibility: important, critical, and outstanding activities needed to surface differently for different users. • Ambiguity: the team needed a simple product structure despite the complexity of the healthcare environment. The key product question became: How do we turn a complex public-health system into a product that is simple enough for each user to understand, while still powerful enough to support the wider healthcare system?
The challenge wasn't simply digitizing healthcare records. It was connecting the system around the people who use it. Healthcare workers, facility managers, and government administrators interact with the health system differently. At the same time, the system needed to support the underlying public-health reporting requirements and workflows expected from primary healthcare facilities. This created several product challenges: • Complex, interconnected workflows: clinical care, referrals, laboratory, pharmacy, maternal health, inventory, reporting, and administration could not be treated as isolated features. • Different user needs: each role required different information, actions, dashboards, and reports. • Referral coordination: referrals needed to carry the relevant clinical context forward rather than becoming a disconnected handoff. • Reporting: data captured during daily patient care needed to become useful for facility and state-level reporting. • Operational visibility: important, critical, and outstanding activities needed to surface differently for different users. • Ambiguity: the team needed a simple product structure despite the complexity of the healthcare environment. The key product question became: How do we turn a complex public-health system into a product that is simple enough for each user to understand, while still powerful enough to support the wider healthcare system?
My Approach
1. I shifted the product from feature-based thinking to user-based thinking. Rather than structuring the product around a list of features—EHR, referrals, laboratory, inventory, reporting—I organized the product around who uses the system and what they need to accomplish. I mapped the workflows and requirements for roles including: IT Administrator, State Administrator, Officer In Charge, Doctor, Nurse, Pharmacist, Lab Technician. This became the foundation for designing dashboards, workflows, permissions, reports, and alerts. The principle was simple: Every capability should exist because a specific user needs it to accomplish something. 2. I translated healthcare workflows into product requirements. I worked through the actual workflows behind the system rather than treating individual features as isolated requirements. For example, a referral wasn't defined simply as “allow a doctor to refer a patient.” I mapped the information and actions required across the journey: Patient → Encounter → Clinical information → Referral decision → Receiving facility → Referral status → Follow-up The same approach was applied to maternal care, laboratory, inventory, immunization, reporting, and other workflows. I authored the PRD, user stories, acceptance criteria, and product requirements needed to turn these workflows into buildable work. 3. I connected point-of-care data to health-system reporting. A major part of the product was ensuring that information captured during routine healthcare delivery could also support reporting and oversight. Instead of treating reporting as a separate administrative activity, I worked through how data generated during patient interactions could feed into role-specific reports and higher-level health indicators. This included reporting requirements across: • Maternal and newborn health • Child health and immunization • Disease surveillance • Clinical activity • Laboratory • Pharmacy and inventory • Stock-outs • Referrals • Facility operations This created a core product principle: Capture data once at the point of care; make it useful across the health system. 4. I designed workflows around action, not information overload. Because each user interacts with a different part of the system, I worked with design and engineering to make information role-specific. The system surfaces information based on what is: Due → Important → Critical → Actionable This informed the design of role-specific dashboards, alerts, and reporting. For example, clinical, maternal, vitals, referral, laboratory, inventory, low-stock, and reporting alerts are surfaced according to the user's responsibilities. The product uses defined system rules and thresholds rather than presenting these as AI-powered predictions. 5. I coordinated design and engineering through delivery. I acted as the connective layer between the healthcare problem, product requirements, design, engineering, and validation. My work included: Product discovery → Requirements → Backlog → Design coordination → Engineering clarification → QA/validation → Delivery Working with a 7-member cross-functional team required continuous prioritization and clarification as the product evolved. I also worked through the product's implementation details with engineers to resolve ambiguity and ensure that the intended workflows were reflected in the actual product. 6. I helped turn the finished product into a stakeholder story. Once the product reached the delivery stage, the challenge shifted from “What are we building?” to “Why should a state government adopt this?” I authored the stakeholder-facing pitch deck and reframed the product around the larger healthcare infrastructure problem. This positioned the product as a potential digital infrastructure layer for primary healthcare, rather than simply an EMR.
1. I shifted the product from feature-based thinking to user-based thinking. Rather than structuring the product around a list of features—EHR, referrals, laboratory, inventory, reporting—I organized the product around who uses the system and what they need to accomplish. I mapped the workflows and requirements for roles including: IT Administrator, State Administrator, Officer In Charge, Doctor, Nurse, Pharmacist, Lab Technician. This became the foundation for designing dashboards, workflows, permissions, reports, and alerts. The principle was simple: Every capability should exist because a specific user needs it to accomplish something. 2. I translated healthcare workflows into product requirements. I worked through the actual workflows behind the system rather than treating individual features as isolated requirements. For example, a referral wasn't defined simply as “allow a doctor to refer a patient.” I mapped the information and actions required across the journey: Patient → Encounter → Clinical information → Referral decision → Receiving facility → Referral status → Follow-up The same approach was applied to maternal care, laboratory, inventory, immunization, reporting, and other workflows. I authored the PRD, user stories, acceptance criteria, and product requirements needed to turn these workflows into buildable work. 3. I connected point-of-care data to health-system reporting. A major part of the product was ensuring that information captured during routine healthcare delivery could also support reporting and oversight. Instead of treating reporting as a separate administrative activity, I worked through how data generated during patient interactions could feed into role-specific reports and higher-level health indicators. This included reporting requirements across: • Maternal and newborn health • Child health and immunization • Disease surveillance • Clinical activity • Laboratory • Pharmacy and inventory • Stock-outs • Referrals • Facility operations This created a core product principle: Capture data once at the point of care; make it useful across the health system. 4. I designed workflows around action, not information overload. Because each user interacts with a different part of the system, I worked with design and engineering to make information role-specific. The system surfaces information based on what is: Due → Important → Critical → Actionable This informed the design of role-specific dashboards, alerts, and reporting. For example, clinical, maternal, vitals, referral, laboratory, inventory, low-stock, and reporting alerts are surfaced according to the user's responsibilities. The product uses defined system rules and thresholds rather than presenting these as AI-powered predictions. 5. I coordinated design and engineering through delivery. I acted as the connective layer between the healthcare problem, product requirements, design, engineering, and validation. My work included: Product discovery → Requirements → Backlog → Design coordination → Engineering clarification → QA/validation → Delivery Working with a 7-member cross-functional team required continuous prioritization and clarification as the product evolved. I also worked through the product's implementation details with engineers to resolve ambiguity and ensure that the intended workflows were reflected in the actual product. 6. I helped turn the finished product into a stakeholder story. Once the product reached the delivery stage, the challenge shifted from “What are we building?” to “Why should a state government adopt this?” I authored the stakeholder-facing pitch deck and reframed the product around the larger healthcare infrastructure problem. This positioned the product as a potential digital infrastructure layer for primary healthcare, rather than simply an EMR.
Results
• The product has moved beyond the build phase and is now being showcased to government stakeholders as the team works toward deployment and institutional adoption. • The product is also being positioned for conversations beyond the initial Plateau State context, with the underlying product structure designed to be adaptable to other state-level implementations. What this project demonstrates This project strengthened my ability to: • Turn ambiguity into product strategy: I transformed a broad healthcare problem into a structured product with defined users, workflows, requirements, and priorities. • Manage complex cross-functional delivery: I coordinated product, design, engineering, and cybersecurity around a shared product definition. • Translate domain complexity into usable products: I converted public-health and clinical workflows into interfaces, requirements, reports, and system rules. • Think beyond features: I connected individual user workflows to the larger goal of improving information flow, coordination, reporting, and visibility across the healthcare system. • Take a product from idea to delivery: I was involved from early discovery through the point where the product became a working system ready to be taken to real-world stakeholders.
• The product has moved beyond the build phase and is now being showcased to government stakeholders as the team works toward deployment and institutional adoption. • The product is also being positioned for conversations beyond the initial Plateau State context, with the underlying product structure designed to be adaptable to other state-level implementations. What this project demonstrates This project strengthened my ability to: • Turn ambiguity into product strategy: I transformed a broad healthcare problem into a structured product with defined users, workflows, requirements, and priorities. • Manage complex cross-functional delivery: I coordinated product, design, engineering, and cybersecurity around a shared product definition. • Translate domain complexity into usable products: I converted public-health and clinical workflows into interfaces, requirements, reports, and system rules. • Think beyond features: I connected individual user workflows to the larger goal of improving information flow, coordination, reporting, and visibility across the healthcare system. • Take a product from idea to delivery: I was involved from early discovery through the point where the product became a working system ready to be taken to real-world stakeholders.
