Meridian Applied
PROJECT MERIDIAN · FIELD DATA CONTINUITY

The record travels with the patient.

OneResponse writes the treatment a patient has already received onto the phone in their pocket. No app on their device, no network, no lookup. The next clinician reads it before they touch them.

Architecture complete Integration path confirmed Not yet deployed
THE GAP

What happened at the point of injury usually doesn't arrive with the patient.

In a mass casualty incident, the most consequential clinical decisions are made in the first minutes, by the first person to reach the patient. A tourniquet goes on. A milligram of epinephrine goes in. An airway is placed.

Then the patient moves.

What happened at the point of injury usually arrives at the receiving facility as a marker on the skin, a strip of tape, a verbal handover from someone who is already leaving, or not at all. The clinician who takes over is making the next decision without the last one.

The failure mode is not abstract. A second dose of epinephrine given because nobody knew about the first. A tourniquet whose application time is unknown, so the limb is treated as either newly injured or already lost. Fluids given on top of fluids.

This is not a records problem to be solved later. It is a treatment problem happening now.

MECHANISM

How it works

01

Capture

The responder records what they did, in the flow their own service already trained them to use. The form is a local configuration, not a protocol.

02

Write

The record is encrypted and written to the NFC chip in the patient's own smartphone with a single tap. Their screen can stay locked, and nothing is installed on their device.

03

Read

At the receiving facility, an authorized device taps the same phone and the record opens. The tourniquet clock is still running. The drugs already given are on the screen before the next dose is drawn.

Under 100 bytes, encrypted, carried on hardware the patient already owns.
This is built as an addition to a field platform an organization already runs, not a replacement for it. Where OneResponse is integrated into an existing app, the responder keeps using the same app they already know, and gains this capability inside it. Nothing new to roll out, nothing old to retire.
ONE PROFILE, DEMONSTRATED

A working demonstration

What follows is a working demonstration of a single configuration, built to illustrate the interaction. It is not a clinical recommendation and it is not a proposed standard of care. The fields shown, their order, and the interventions considered worth recording are all properties of one profile. A different service would publish a different one and the system would work identically.
Synthetic data · no live NFC hardware · profile shown is illustrative only
WHOSE MEDICINE

Clinical neutrality is the design, not a caveat.

Emergency medicine is not practised the same way in two places. Protocols, scope of practice, drug formularies, and the training of the person who arrives first all vary by country, by service, and sometimes by shift. Any system that hardcodes one set of clinical assumptions is asking every service that does it differently to adopt someone else's medicine as the price of admission. Most will decline, and they will be right to.

OneResponse does not encode a protocol. It encodes a message format.

The universal layer is the envelope: who wrote the record, under what incident authority, at what time, with what integrity guarantees. Inside it, the clinical content is not stored at fixed byte positions tied to one clinical opinion. It is a list of coded entries, each carrying a SNOMED CT, LOINC, or RxNorm code, already the shared vocabulary of clinical informatics worldwide. Each deploying organization publishes its own profile defining which entries its responders capture and in what order, and the wire format doesn't change to accommodate it.

The consequence: readability does not depend on agreement. A record written under one service's profile remains fully legible to a facility running a different one, because both are reading the same codesets. Where a receiving system has no local label for a given entry, it falls back to the standard preferred term, legible to any clinician trained anywhere.

The design principle, stated plainly: the system sits underneath the place where clinicians disagree. It does not adjudicate it.

WHAT THIS IS NOT

Precisely, what this isn't

A triage system

It does not assign categories, calculate scores, or replace START, SALT, or any other triage methodology. It records what was done, not what should be done next.

A clinical decision support tool

It does not advise, recommend, or prompt. It surfaces what already happened and lets the clinician decide what that means.

A patient identity or tracking system

The record contains no name, date of birth, nationality, or biometric data. It carries an opaque tag issued by the field system already in use, so the clinical record can be associated with the casualty record that organization already maintains. It does not create an identity, and it does not follow anyone anywhere.

A surveillance mechanism

The record is encrypted with a key derived from a specific incident authorization and is readable only by devices holding that authorization. It is scoped to one incident, carries no location data, and compromise of one incident's key exposes nothing about any other.

A replacement for an existing field system

It extends the clinical capture window backwards to the moment of injury and hands the result to whatever record system the organization already runs. Where it is designed against a specific platform, the write is additive: if it fails for any reason, the underlying casualty record is already saved and unaffected.

A commercial product

There is no licensing fee and no commercial entity behind it. The codebase is intended to be owned by the organization implementing it. Its architect holds no financial interest of any kind in its adoption.

Deployed

It has not been fielded. There is no pilot, no live incident data, and no published clinical outcome evidence. See status below.

WHERE THIS ACTUALLY IS

Status

Complete

  • System architecture, v2.0
  • Encryption and key derivation design
  • Payload encoding specification
  • Technical integration review with a partner field platform's engineering lead
  • Android build, ready for pilot testing
  • Patient record linkage mechanism, resolved
  • White paper, drafted

Not yet done

  • Field validation of the Android build against physical NFC hardware
  • iOS write entitlement confirmation under managed device policy
  • Integration testing in a partner sandbox environment
  • Any field pilot or exercise deployment
  • Peer-reviewed publication
  • Profile authoring tooling for third-party deploying organizations
Current constraint: the Android build is complete and ready for pilot testing. It has not yet been validated against physical NFC hardware in the field, which is the next step before any exercise or live deployment.
WHO DECIDES

Governance and ownership

Activation authority belongs to the deploying organization, not to OneResponse. A record can only be written under an incident authorization issued by that organization, and only by a responder registered under it. When the incident closes, the authorization expires.

The system is designed to be handed over. The intended end state is that the implementing organization owns the codebase, publishes its own clinical profile, and operates it under its own medical governance. There is no vendor in this arrangement and no dependency on its architect.

INQUIRIES

Written and architected by Dr. Jonathan Trippett, MD, BCMAS.

Technical documentation, the integration specification, and the demonstration build are available to organizations evaluating the system for pilot or standardization. Inquiries from humanitarian health organizations, emergency medical services, and standards bodies are welcome.

info@meridian-applied.com
MERIDIAN APPLIED · PROJECT MERIDIAN