The questions a skeptical judge would ask

Real. The number comes from grep -c "@Tool\b" on the actual repository, audited per file:

• 24 in AllergiesAgentTools.kt
• 18 in JemmaTools.kt
• 17 in PatientAgentTools.kt
• 4 in IdentifyDrugTools.kt
• 3 in MedScanTools.kt
• 2 in ExplainTools.kt

Total: 68 distinct @Tool-annotated functions, each typed, each callable synchronously from LiteRT-LM's native thread. Run the grep yourself on the GitHub repo to verify.

Three compression stages, no magic:

1. Schema compaction. The _j 1.2 schema uses 2-character field names (gn, fn, al, md) instead of FHIR's verbose names (given, family, allergyIntolerance, medicationStatement). FHIR is for interoperability via reconstruction, not wire transport.
2. Pruner. Empty arrays, default values, redundant _display fields stripped. JemmaPayloadPruner.kt drops everything reconstructible at decode time.
3. deflate-raw RFC 1951. A 777-byte pruned JSON compresses to ~500 bytes because clinical codes (SNOMED, ATC) have high mutual information.

The full FHIR R4 Bundle is reconstructible from _j 1.2 via JemmaFhirBundleBuilder.kt — we don't lose semantic data, we just don't ship serialization padding across the wire.

Because clinical safety decisions must be deterministic and auditable. A vector search returns the "most similar" allergen — a SQL JOIN returns the exact code match or nothing. For "is this patient allergic to penicillin?", we want the second behavior. Hallucination-prone fuzzy match is the wrong tradeoff when anaphylaxis is on the line.

We do use SQLite FTS5 for free-text lookup (drug brand names, allergen synonyms), but only as a candidate-generation stage feeding into a deterministic code lookup. The LLM orchestrates; the safety logic is deterministic SQL.

It actually runs on-device. Two ways to verify:

1. Network monitor. Run the app in airplane mode. Run the full demo. Use adb shell cmd netstats get --uid <UID> to confirm zero bytes transferred.
2. Process inspector. adb shell top -m 1 -p <PID> shows ~3.8 GB RSS attributed to the JemmaPass process — that's the mmap'd Gemma 4 E4B model.

The only network calls in the codebase are (a) the first-boot model download (gated on Wi-Fi presence), and (b) opt-in crash reports (off by default in v1.0.14). Search the source for OkHttp or HttpURLConnection to verify.

Because the AI never invents clinical facts. When Gemma 4 needs to know "is Augmentin a penicillin?", it doesn't introspect its training weights — it calls the resolveDrug @Tool, which queries the SQLite KB for the ATC code J01CR02 and its ancestors. The LLM only handles orchestration (multi-turn conversation, intent recognition, vulgarisation) — every fact comes from a deterministic database lookup.

This is the architectural inversion of GPT-4-as-doctor: instead of trusting a 70B parameter model to remember clinical facts, we use a small AI to interface a curated database. The result is hallucination-resistant by construction.

Yes, but with a caveat. DDInter 2.0 added drug-disease interactions (DDSI) in 2024 — these are in the KB. However, the v1.0.14 hackathon demo only surfaces DDI and allergy cross-checks in the UI. The DDSI data is queryable via @Tool but not yet rendered as red alerts.

This is a roadmap item: surface drug-disease conflicts in the red alert UI for v1.1. The infrastructure (KB + @Tool) is in place; only the UI binding remains.

Through code-to-display translation, not LLM translation. Every clinical concept in the KB has a SNOMED CT or ICD-10 code. The ips_valuesets_translations table maps each code to its display text in 25+ languages, sourced from:

• SNOMED International IPS Free Set language refsets (July 2024)
• WHOCC ATC Index 2026 multilingual labels
• Regulatory authority files (EMA for EU languages, PMDA for Japanese, NHS dm+d for British English)

So when Kamekichi (Japanese rescuer) scans Kurodo's (Belgian) profile, "Allergy to penicillin" → SNOMED 91936005 → ja-JP refset display "ペニシリンアレルギー". Sub-millisecond lookup, zero hallucination risk.

License compatibility. DrugBank and Lexicomp are commercial — embedding their data in a Apache-2.0-licensed open-source app is not legally possible without paying per-user fees. DDInter 2.0 is the most comprehensive open DDI database currently published (302,516 interactions, peer-reviewed in NAR 2024). It's the right choice for a hackathon project that may become an open-source good.

If JemmaPass ever ships commercially, we'd revisit this with a DrugBank Plus license — but that's a deployment concern, not a hackathon concern.

No, and intentionally so. JemmaPass is positioned as a decision-support tool for emergency resilience and patient empowerment. Specifically:

• Not classified as Software as a Medical Device (SaMD) under FDA criteria
• Not Class IIa under EU MDR (2017/745)
• Not in scope of the EU AI Act's high-risk healthcare AI provisions because it does not make autonomous clinical decisions

It supplies information (drug class, allergy match, interaction warning) — it does not prescribe, diagnose, or treat. A human rescuer interprets the information and decides. This is the same regulatory position as MedicAlert bracelets, EMS field guides, and the AMPLE mnemonic checklist.

If a future version intends to provide autonomous treatment recommendations, EU MDR Class IIa classification would be required (CE marking, post-market surveillance, etc.) — that's a deliberate architectural divergence we'd plan for.

It can't, by architecture. Gemma 4 never generates SNOMED codes — it requests them via @Tool. The KB returns either the canonical code or "not found". If Gemma misinterprets a user input ("I'm allergic to penilcin" with typo), the worst case is:

1. FTS5 fuzzy matcher returns 5 candidates (probably penicillin is #1)
2. The chat agent asks "Did you mean penicillin?" → user confirms
3. Code 91936005 is stored

The hallucination risk is in the orchestration (asking the right follow-up question), not in the clinical data layer. Even if Gemma misroutes a conversation, the underlying code stored in the profile is always a real SNOMED code that came from the KB.

In the device's app-private storage:

• /data/data/be.heyman.android.jemmapassdemo/databases/

This is OS-enforced isolation — no other app can read it without root. Backups are disabled in AndroidManifest.xml (android:allowBackup="false") to prevent accidental cloud sync via Google Backup.

The profile leaves the device only when the user explicitly:

• Generates a QR for sharing
• Activates SOS Mode (Nearby broadcast)
• Exports a Pocket Pass PDF for printing

Zero telemetry, zero analytics, zero cloud sync. By design, not by promise.

The codebase is currently MIT-licensed during the hackathon. Per Section 2.5(a) of the Competition Rules, winning submissions are relicensed under CC-BY 4.0 to maximize public benefit. We agree with this and have designed JemmaPass to be a long-term open-source good for the global health resilience community.

The clinical knowledge base inherits its source licenses (DDInter CC BY-NC-SA, SNOMED CT IPS CC BY 4.0, etc.) — see the licensing section of the DDInter page for details.

MedicAlert bracelets are excellent for static information (allergies, conditions) but have three structural limitations:

1. Capacity. A bracelet engraves ~3 lines. JemmaPass carries the full IPS R4.
2. Updates. Re-engraving costs $30+ and takes weeks. JemmaPass updates instantly.
3. Decision support. A bracelet says "Penicillin allergy". JemmaPass actively warns when you scan a beta-lactam.

MedicAlert is a passive identifier. JemmaPass is a portable clinical decision support system. They're complementary — wear the bracelet, scan the badge.

These ecosystems excel at longitudinal health tracking for the device owner. They're optimized for the user's quantified-self journey. JemmaPass is optimized for a different use case: emergency hand-off between strangers across language barriers.

Their architectures depend on the cloud (Apple Health Records pulls from FHIR endpoints; Google Fit syncs to Google's cloud). JemmaPass works in a Faraday cage. They store everything for the user; JemmaPass stores the IPS subset for handoff.

A patient can have an Apple Watch and a JemmaPass profile — they don't compete, they serve different stages of the care continuum.

To our knowledge, no one has fused all three ingredients required:

1. Gemma 4 native function calling (April 2026 release)
2. HL7 IPS R4 stable standard (v2.0.0 STU 2)
3. Google Nearby P2P_CLUSTER mesh + ML Kit barcode + the right Android NDK 16 KB tooling (all 2025-2026)

Each ingredient existed before, but the combination only became feasible in the past 12 months. Several adjacent projects exist (Google Open Health Stack for FHIR + Android, the e-Patient Dave SHL POC for QR-based IPS, various Gemma-based health chatbots), but nobody else combines all three into a single offline-native artifact.

We hedge with "to our knowledge" because the field is moving fast — but we've searched, and we believe this is genuinely a first.

Honest list of limitations in the hackathon submission:

• 3 of 18 IPS pillars actively used. Patient demographics, allergies, medications. The remaining 15 (conditions, immunizations, procedures, devices, advance directives, results, etc.) have schema stubs but no UI surfaces in v1.0.14.
• DDSI surfaces partially. Drug-disease interactions are in the KB but only DDI is rendered as red alerts.
• iOS support: none. Android-only. iOS would require a complete rewrite — LiteRT-LM is Android-first.
• Tablet UI: not optimized. Compose layouts target phone form factors. Tablets work but are not visually polished.
• Accessibility audit incomplete. Screen reader support is partial; high-contrast mode not fully tested.
• Voice STT is English/French/Japanese only in v1.0.14 (UI supports 15 languages but onboarding by voice has only 3 STT models bundled).
• No clinical validation study. The cross-reactivity logic is based on published medical references but hasn't been validated against a clinical trial cohort.

These are deliberate scope choices for a solo-developer hackathon submission. The architecture supports all of them — the implementation just hasn't shipped.

FTS5 fuzzy match returns the closest candidates. The conversational allergy intake then asks the user to confirm:

User: "I'm allergic to penilcin"
Jemma: "Did you mean penicillin? I want to make sure your safety information is correct."
User: "Yes"
→ Stored as SNOMED 91936005

If the user types something completely unintelligible (e.g., "asdjklasd"), Jemma asks for clarification rather than guessing.

This is exactly why JemmaPass ships a Pocket Pass PDF export. It's a printable A4 sheet with:

• The _j2: QR code (machine-readable by JemmaPass)
• The multilingual text channel QR (machine-readable by ANY phone camera)
• Plain-text human-readable summary in 2 languages
• An emergency contact phone number + ICE info

Print it once, fold it into your wallet, and the data survives even if your phone, the network, and the cloud all fail simultaneously. Paper is the ultimate fallback.

JemmaPass is intended to remain an open-source good for the global health resilience community. The author is exploring partnerships with:

• Pilgrim associations on the Shikoku Henro and Camino de Santiago routes
• Disaster preparedness NGOs (Red Cross, Médecins Sans Frontières)
• EU health-tech consortia in Belgium and Japan

If a commercial spin-off ever happens, it would likely be a hosting/support service for hospitals and clinics, not a per-user license. The patient-facing app stays free and open-source. JemmaPass is built for humans, not systems.