NeurOptics
NPi pupillometer

What this driver does

The NeurOptics NPi pupillometer (NPi-200/NPi-300 family) produces quantitative, repeatable pupillometry measurements at the bedside. Every exam generates a set of discrete numerical values: the NPi (Neurological Pupil index), pupil size (mm), constriction velocity, dilation velocity, and latency. These readings are clinically significant in neuro-critical care settings, including TBI monitoring, post-operative neuro status tracking, and neurological ICU surveillance, but they have historically lived on the handheld device or in a proprietary portal, disconnected from the patient’s EHR record.

This OpenShare driver bridges that gap. It solves pupillometry EHR integration, accepting readings from the NeurOptics device or its middleware (via TCP/IP or file drop, depending on your site’s workflow) and routing them into your OIE instance, which then writes structured observations to the destination system using one of the three supported protocols: HL7v2, Epic FHIR R4, or Generic FHIR R4.

Key capabilities:

• Converts raw NPi readings into structured HL7v2 ORU^R01 messages, one OBX segment per measurement
• Writes FHIR R4 Observation resources (Epic-targeted or vendor-neutral) for each exam
• Attaches patient and encounter context from the OIE’s ADT feed or a configurable lookup
• Bundles a ready-to-import OIE channel definition, so integration engineers do not need to build message transformations by hand

The driver does not perform clinical interpretation. It routes and formats data; the clinical significance of any reading is determined by the receiving EHR workflow and the clinician reviewing the chart.

---

HL7v2, ORU^R01 mapping

NeurOptics HL7 integration uses the standard ORU^R01 observation result message to carry pupillometry results. The driver constructs a multi-segment ORU with one OBX segment per measurement value. The mapping table below describes the representative structure; specific OBX-3 coding (LOINC or local) is finalized per site during the channel configuration step, as sites vary in whether they use LOINC codes, NeurOptics-assigned codes, or locally defined identifiers.

Measurement-to-OBX mapping (representative)

Measurement	OBX-3 Identifier (illustrative)	OBX-5 Value	OBX-6 Units	OBX-7 Reference
NPi (right)	<LOINC-or-local-code>^NPi-Right^L	0.0–5.0		>= 3.0 (site policy)
NPi (left)	<LOINC-or-local-code>^NPi-Left^L	0.0–5.0		>= 3.0 (site policy)
Pupil size, right (mm)	<LOINC-or-local-code>^Size-Right^L	e.g. 3.5	mm	site-defined
Pupil size, left (mm)	<LOINC-or-local-code>^Size-Left^L	e.g. 3.4	mm	site-defined
Constriction velocity, right	<LOINC-or-local-code>^CV-Right^L	e.g. 2.1	mm/s	site-defined
Constriction velocity, left	<LOINC-or-local-code>^CV-Left^L	e.g. 2.0	mm/s	site-defined
Dilation velocity, right	<LOINC-or-local-code>^DV-Right^L	e.g. 0.8	mm/s	site-defined
Latency, right	<LOINC-or-local-code>^Lat-Right^L	e.g. 0.23	s	site-defined

Note on coding: OBX-3 identifier values shown as <LOINC-or-local-code> are placeholders. The driver ships with a configurable code map; your integration engineer will substitute the appropriate LOINC codes or locally assigned identifiers during site configuration. Do not treat the illustrative labels above as an authoritative LOINC binding.

Example ORU^R01 message

The following is a representative example of the HL7v2 message the driver emits. Segment values (MRN, accession, timestamps) are illustrative:

MSH|^~\&|NEUROPTICS|PUPILLOMETRY|EHR_SYSTEM|MAIN|20260627143000||ORU^R01|PUPIL-20260627-001|P|2.5.1
PID|1||MRN-123456^^^HOSP^MR||DOE^JANE^A||19700415|F|||100 MAIN ST^^ANYTOWN^NY^10001
PV1|1|I|NICU^201^A||||ATTEND^DOC^MD|||MED||||||||VN-987654^^^HOSP^VN
OBR|1||PUPIL-001^NEUROPTICS|PUPILLOMETRY^Pupillometry Exam^L|||20260627143000|||||||||||||||F
OBX|1|NM|<LOINC-or-local>^NPi Right^L||4.2||>=3.0|N|||F|||20260627143000
OBX|2|NM|<LOINC-or-local>^NPi Left^L||3.9||>=3.0|N|||F|||20260627143000
OBX|3|NM|<LOINC-or-local>^Size Right^L||3.5|mm||N|||F|||20260627143000
OBX|4|NM|<LOINC-or-local>^Size Left^L||3.4|mm||N|||F|||20260627143000
OBX|5|NM|<LOINC-or-local>^CV Right^L||2.1|mm/s||N|||F|||20260627143000
OBX|6|NM|<LOINC-or-local>^CV Left^L||2.0|mm/s||N|||F|||20260627143000
OBX|7|NM|<LOINC-or-local>^DV Right^L||0.8|mm/s||N|||F|||20260627143000
OBX|8|NM|<LOINC-or-local>^Lat Right^L||0.23|s||N|||F|||20260627143000

The MLLP transport wraps this message with the standard start-block (0x0B) and end-block (0x1C 0x0D) characters. The OIE channel handles framing automatically.

---

Epic FHIR R4, Observation write-back

NeurOptics Epic FHIR integration uses Epic’s FHIR R4 API to write Observation resources for each pupillometry exam. The driver constructs individual Observation resources (one per measurement value) or a panel Observation with component elements, depending on the Epic environment’s preference. Patient context is resolved via Epic’s SMART on FHIR patient context or a pre-configured patient identifier lookup.

The Observation write endpoint follows Epic’s standard FHIR R4 pattern: POST /api/FHIR/R4/Observation. The driver is configured with the Epic base URL and an OAuth 2.0 client credential obtained through Epic’s App Orchard or your organization’s Epic on FHIR integration process.

Epic API endpoint note: The exact Epic FHIR endpoint URL is environment-specific (sandbox vs. production, MyChart vs. clinical backend). The driver package includes a configuration template; your Epic integration team must supply the registered application client ID, client secret, and the correct FHIR base URL for your Epic instance.

Example Epic FHIR R4 Observation payload

The following is a representative example of an Observation resource the driver POSTs to Epic for the NPi-right measurement. Coding (LOINC system URI and code) should be confirmed with your Epic integration team and validated against Epic’s accepted value sets.

{
  "resourceType": "Observation",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs",
          "display": "Vital Signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "<LOINC-or-local-code>",
        "display": "Neurological Pupil index - Right"
      }
    ],
    "text": "NPi Right"
  },
  "subject": {
    "reference": "Patient/<epic-patient-fhir-id>"
  },
  "encounter": {
    "reference": "Encounter/<epic-encounter-fhir-id>"
  },
  "effectiveDateTime": "2026-06-27T14:30:00Z",
  "valueQuantity": {
    "value": 4.2,
    "system": "http://unitsofmeasure.org",
    "code": "{score}"
  },
  "device": {
    "display": "NeurOptics NPi Pupillometer"
  }
}

A full pupillometry exam produces multiple Observation POSTs (one per measurement), or optionally a single Observation with component elements grouping all values under one resource. The driver supports both patterns; the active pattern is selected in the channel configuration.

---

Generic FHIR R4, vendor-neutral Observation

Generic FHIR R4 mode targets any FHIR R4-conformant server, including open-source FHIR servers (HAPI FHIR, Azure FHIR Service, AWS HealthLake, Google Cloud Healthcare API) and non-Epic EHRs with FHIR write capability.

The payload structure is identical to the Epic variant above, with two differences:

1. No Epic-specific extensions. The Epic variant may include Epic OID-based identifiers or Epic-specific profile URLs (meta.profile). The Generic variant omits these, producing a clean R4 Observation with standard terminology only.
2. Auth is configurable. Generic mode supports Bearer token, Basic auth, or client certificate, depending on what the target FHIR server requires. The Epic variant specifically uses Epic’s OAuth 2.0 SMART backend service flow.

{
  "resourceType": "Observation",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "<LOINC-or-local-code>",
        "display": "NPi Right"
      }
    ]
  },
  "subject": { "reference": "Patient/<patient-fhir-id>" },
  "encounter": { "reference": "Encounter/<encounter-fhir-id>" },
  "effectiveDateTime": "2026-06-27T14:30:00Z",
  "valueQuantity": {
    "value": 4.2,
    "system": "http://unitsofmeasure.org",
    "code": "{score}"
  }
}

The Generic FHIR channel is a useful baseline for proof-of-concept integrations before committing to an Epic-specific deployment, or for sites running non-Epic EHRs that expose a standard FHIR R4 write endpoint.

---

What’s in the driver package

The NeurOptics pupillometry driver package is a single .zip file containing:

• OIE channel bundle, the complete channel definition importable via OpenShare Console (or the OIE admin API). Includes source connector (TCP/MLLP listener or file poller), message transformer (NeurOptics payload → HL7v2 or FHIR), and destination connector (MLLP sender or HTTPS POST).
• Protocol specification, the exact OBX mapping table and FHIR Observation schema this driver implements, with configuration slots for site-specific coding.
• Firewall manifest, the outbound rule list (TCP 6661 for MLLP, TCP 443 for FHIR) in a format ready to hand to your network team.
• Configuration guide, step-by-step instructions for setting the NeurOptics middleware IP, the MLLP or FHIR endpoint, and the patient-context lookup strategy.
• Test harness, sample NeurOptics output and expected HL7v2/FHIR payloads for validation after import.

The package is free, and will be available from the driver catalog, coming soon.

Free-tier on-ramp

The driver runs on any OIE instance, including the free, self-hosted OIE (open-source). You do not need a paid OpenShare subscription to use the driver channel. OpenShare Console (free tier) gives you the browser-based channel editor and message browser that make configuring and debugging the NeurOptics integration faster than working in the OIE’s default Java desktop client.