Skip to content
Enes Demirezen

Healthcare systems

KOAH

A healthtech workflow system with patient, physician, reviewer and admin panels, medical document processing and clinical review logic.

Role
Software development
Status
Development work. Not one of my ventures.
What I owned
Patient, physician, reviewer and admin workflows · Medical document OCR · Pulmonary function test extraction · Laboratory result extraction · PDF, PNG, JPEG and structured file processing · DICOM processing · 3D lung visualization · Clinical review and approval workflows · Role-based permissions · Backend and frontend systems

Context and problem

Pulmonary care produces paperwork at a brutal rate. Pulmonary function test reports, laboratory results, imaging files and referral documents arrive as PDFs, phone photos and scans. Somebody has to read each one, type the values into a record, and route it to the physician who can act on it. Every manual step costs time and invites transcription errors, in a domain where a misread FEV1 value is not a typo, it is a clinical risk.

On top of the document problem sits a workflow problem: patients, physicians, reviewers and administrators all need different views of the same case, with different permissions, and every review step has to be traceable.

What the system does

KOAH is a healthtech workflow system I developed. It takes medical documents in the formats clinics actually produce (PDF, PNG, JPEG, DICOM and structured files) and turns them into structured, reviewable records.

Medical-document OCR extracts values from pulmonary function test reports (FVC, FEV1, FEV1/FVC ratio, PEF) and laboratory results. DICOM files are processed and feed 3D lung visualizations. Every extracted record enters a clinical review chain: uploaded, physician review, administrative check, approved. Patients, physicians, reviewers and administrators each work in their own panel, under role-based permissions.

The system supports clinical review. It does not diagnose, and no extracted value reaches a patient record without human review and approval.

My role

Software development. KOAH is development work, not one of my ventures. I built the backend and frontend systems: the document processing pipeline, the extraction flows, the multi-role panels, the review workflows and the permission model.

System architecture

  1. Intake

    • PDF, PNG, JPEG uploads
    • DICOM imaging files
    • Structured files
  2. Extraction

    • Medical document OCR
    • PFT values (FVC, FEV1, PEF)
    • Laboratory results
    • DICOM processing
  3. Clinical review

    • Physician review
    • Administrative check
    • Approval with audit trail
  4. Care records

    • Patient and physician panels
    • 3D lung visualization
    • Role-based permissions

A document enters the system in whatever format the clinic has. The extraction layer produces structured candidate data: test values from a PFT report, results from a lab sheet, volumetric data from DICOM series. Nothing extracted is trusted by default: each record moves through physician review and an administrative check before approval. Approved data becomes part of the case record, visible to each role exactly to the extent its permissions allow, and DICOM-derived data renders as 3D lung visualizations for the physician.

Engineering decisions

Extraction feeds review, never bypasses it

The tempting shortcut in medical OCR is to write extracted values straight into the record. KOAH refuses that shortcut structurally: extraction output is always a proposal, and the review chain (physician, then administrative check) is the only path to an approved record. The cost is extra clicks for clean documents; the gain is that a wrong OCR read is an annoyance instead of a clinical incident.

Meet the documents where they are

Clinics do not produce tidy inputs, so the intake accepts PDF, PNG, JPEG, DICOM and structured files rather than demanding one format. Supporting messy input made the pipeline harder to build and test, but it is the difference between a system that fits the clinic and a system the clinic must bend around.

Roles as a hard boundary

Patient, physician, reviewer and administrator are not display modes but permission boundaries enforced in the backend. Every view and action checks the role model. Healthcare data makes this non-negotiable: the UI hiding a button is not a security model.

Workflow states are explicit

A document is always in exactly one state: uploaded, physician review, administrative check or approved. Explicit states made the workflow hardening work tractable: edge cases become state transitions to handle, not surprises in production.

Results and evidence

The system is live at koah.tr. It covers patient, physician, reviewer and administrator workflows end to end, from document upload through OCR extraction and clinical review to approved records and 3D visualization. Screenshots and further technical detail will be added to this page as they are cleared for publication.

Contact

Let's talk.

Working on something close to Derbent, want to build together or just compare notes? Write to me. I read everything.