Healthcare standards
Clinical and administrative data moves through whatever interface the source system offers. Lynx Labs works with that standard, and keeps the mapping inside the access and the operations the engagement agrees.
FHIR R4
When a source system exposes current clinical and administrative data as FHIR R4, Lynx Labs reads and writes resources such as appointments, patient demographics, encounters, and documents. The profiles follow what that system supports.
SMART on FHIR
Lynx Labs builds SMART on FHIR for EHR launch and standalone launch when the source system supports that mode. The app requests the scopes the engagement needs. Lynx Labs obtains non-production access through the source system’s developer program, and the client organization turns on production access.
Bulk FHIR
When an engagement needs to move a set of records and the source system offers Bulk FHIR, Lynx Labs uses that export instead of reading one resource at a time.
CDS Hooks
Lynx Labs implements a CDS Hook when an EHR calls out at a defined point in a workflow, such as when an order is selected, and returns the response that hook defines.
HL7 v2
Admissions, orders, and results still arrive as HL7 v2 on many systems. Lynx Labs maps the message types agreed for the engagement.
C-CDA
When an engagement exchanges a clinical summary, Lynx Labs reads and produces C-CDA documents, such as a continuity-of-care document, in the types the client’s systems accept.
USCDI
USCDI names a set of health data classes and elements. When an engagement follows a profile that uses it, Lynx Labs maps to the elements that profile requires, at the version the client’s systems support.
X12 EDI
Lynx Labs maps X12 EDI for administrative exchanges such as eligibility and claims. Which transactions are in scope is agreed before the mapping starts.
Identity and security
Authorization and encryption are part of the integration. Lynx Labs uses the authorization the source system offers, and encrypts client data on the connections and the storage it controls.
OAuth 2.0
Lynx Labs uses OAuth 2.0 when a source system supports it, including the authorization-code flow used by SMART on FHIR, and requests only the scopes that engagement needs.
OpenID Connect
OpenID Connect identifies the user who authorized access, when the authorization server provides it and the engagement needs that identity.
TLS 1.3
Lynx Labs encrypts client data in transit on the connections it controls. Where Lynx Labs configures the endpoint, the connection negotiates TLS 1.3.
AES-256
Client data is encrypted at rest. Where Lynx Labs chooses the cipher, it uses AES-256.
Engineering
The interface has to keep running after the mapping is agreed. Lynx Labs builds it in the language and runtime that fit the work, and ships the same build into the environment the engagement uses.
TypeScript
Lynx Labs writes application and integration code in TypeScript, on a JavaScript runtime.
Python
Lynx Labs writes integration jobs, data mapping, and automation in Python when the work fits a script or a service.
Elixir
Lynx Labs writes services that stay running, and handle concurrent work, in Elixir on the Erlang virtual machine.
PostgreSQL
When an engagement needs to store operational data outside the source system, Lynx Labs uses PostgreSQL. What is stored, and for how long, is agreed for that engagement, and client data in that database is encrypted at rest.
Cloudflare Workers
Lynx Labs uses Cloudflare Workers for a short-lived HTTP handler when an engagement needs one. This website is a separate static site.
AWS
When an engagement needs hosted infrastructure, Lynx Labs runs the client software on AWS, with client data encrypted in transit and at rest.
Docker
Lynx Labs packages a service with Docker so the same build runs in development and in the environment agreed for the engagement.
Voice
A voice assistant is a narrow path into work the office already does. Lynx Labs connects it by phone or in the browser, and limits it to scheduling, reminders, and intake. It does not provide medical advice.
SIP
When a voice assistant connects to a phone system the client already operates, Lynx Labs uses SIP to place and receive the calls.
WebRTC
When a voice workflow runs in the browser, Lynx Labs carries the audio with WebRTC.
speech-to-text
Speech-to-text turns the caller’s words into text the workflow can use, for scheduling, reminders, and intake.
text-to-speech
Text-to-speech speaks the prompts and confirmations for those same tasks, from the script agreed for the engagement.
Working with a specific EHR
The standards above are how the integration is built. For a specific EHR, Lynx Labs requests non-production access through that vendor’s published developer program and builds against those APIs. The client organization enables production access. What is available in production depends on the vendor and the client’s configuration.