Reading a document is easy. Understanding its meaning is the real challenge.

While building AI-powered medical document intelligence systems, I’ve been learning that extracting words is only one part of the problem.

Consider this sentence:

“Patient denies chest pain.”

A system might recognize the words correctly but still extract the wrong information if it ignores the word “denies.”

The same challenge appears in phrases like:

“No history of asthma”

“Mother had breast cancer”

“Rule out pneumonia”

“Aspirin discontinued”

Each sentence requires more than text recognition. It requires understanding context, negation, uncertainty, relationships, and whether information is current.

This is one of the challenges I’m exploring while building MDIS (Medical Document Intelligence System) at Cognate AI.

My focus is on developing systems that go beyond extracting information—toward structured outputs, validation, evidence traceability, and human review.

Because in healthcare AI, extracting the right words is not enough. The system must preserve what those words actually mean.

I’m continuing to learn, build, test, and improve this system one step at a time.

What do you think is the biggest challenge in making AI understand clinical language accurately?

#AIEngineering #HealthcareAI #MedicalAI #DocumentIntelligence #BuildingInPublic

negation like that is exactly where naive extraction falls apart, great example

The Webhook Arrived Twice. The Sale Happened Once.

A conversion notification arrives twice. Should your report show two sales?

Imagine an integration saves the first notification, but its acknowledgement never reaches the sender. The sender retries. Both deliveries describe the same event.

Counting every arrival as a new conversion would inflate the report. In another workflow, the same mistake could create a second task or send the customer another confirmation.

I built duplicate checks into my Internal Campaign Tracker, a private working proof of concept for a business partner. Incoming conversions are matched to the original visit. Outgoing callbacks have a persistent queue, retry history and a way to inspect and replay failed deliveries.

That separates two questions: did the business event happen, and did its notification reach the next system?

Before accepting an integration, agree what identifies a repeat. An email address is usually too broad: the same customer can make two legitimate purchases. The identity needs to match the action you are protecting.

Then test three cases:

• Deliver the same event twice, including two attempts arriving close together. • Retry after a timeout where the receiving system may already have saved the first attempt. • Send a genuinely new event for the same customer and confirm it is still processed.

The expected result should be written down for each case. A repeated notification should not repeat the protected action; a new purchase should not disappear because its customer is already known.

The operator also needs to see what happened: completed, waiting to retry, or needing attention. For outgoing callbacks, retries and manual replay should keep the same event identity, and the receiving system must handle repeat deliveries safely.

Project details and screenshots on NikoCodes: https://nikocodes.com/software/internal-campaign-tracker/

Great breakdown. A pattern that holds up even when two deliveries race each other: save the event ID under a unique constraint in the same transaction as the side effect. Then the database decides which one wins, instead of a check-then-insert in app code.