Nextech

Access

• Register through Nextech’s developer portal. There is no sandbox.
• SMART Backend Services with a JWT (RS384).
• Multi-tenant by client id: one shared base URL and token endpoint, with a separate client id for each practice. The token carries a practice-id claim — decode it and confirm it is the practice you expect, because credentials have been issued for the wrong practice.

Extraction approach

Paginated search of each resource type, not bulk.

• $export is accepted but crawls (1% after 34 minutes), its status URL drops into multi-minute 5xx windows, and older status URLs stop working.
• Paginated search, by contrast: _count up to 200, about 1.2 seconds per page, a whole tenant in under half an hour. Use _lastUpdated=ge<date> for incremental pulls and stream each page to NDJSON.
• Types pulled: Patient, Practitioner, Encounter, Condition, Observation, Procedure, MedicationRequest, DiagnosticReport.
• A type that returns 400 “patient or _id must be supplied” (for example Condition) needs a per-patient cascade. Comma-separated patient lists are rejected, so it is one call per patient — limit it to patients with an encounter in the measurement year.

Known behaviour

• _count is capped at 200.
• MedicationRequest is slow (about 20 seconds per page); Condition about 4.6 seconds per patient.
• DiagnosticReport returns 500 on tenant-wide search.
• Procedure.code was always empty in the tenants we saw.
• References have no type; inject it.
• No provider participants, NPI or TIN in the data — attribution must come from your own configuration.
• Encounter coding is good: the measures’ qualifying-encounter value sets match.
• Retry transient pages (0, 429, 5xx) with backoff; several consecutive failures can occur.