EHR Support Matrix
Which events, fields and API operations each EHR supports
Vim normalizes EHR differences, but it cannot invent capabilities an EHR doesn't expose. Coverage varies: an event or field available in one EHR may be absent in another.
This page is the authoritative view of what each supported EHR can do. It is generated from Vim's live adapter configuration, so it reflects current production behaviour rather than a hand-maintained table.
Read this before finalizing your manifest
The most common avoidable integration failure is declaring an EHR scope your target EHRs don't support. Confirm coverage here first — a missing field passes review and then fails silently in production.
How to read the matrix
Capabilities are grouped by workflow event, then by entity, then by field. Each EHR gets a column, and a marked cell means that EHR supports that capability.
Cells are colour-coded by state, and hovering one names its state:
- Readable — the field is extracted and available to your app.
- API implemented — the API operation is available for this EHR.
- Partially implemented — the operation exists but covers only a subset of its fields.
- Readable & Writable — also writable via Writeback.
An empty cell means unsupported. Treat every field as potentially absent and handle null
defensively — see Error Handling.
Write support is not yet reflected here
The matrix currently reports read support only; no cell resolves to Readable & Writable yet. Confirm write capability with your Vim contact before depending on it, and see Writeback for what is supported today.
What determines support
Support is derived from Vim's adapter configuration, not declared by hand:
- Event detection — the EHR's adapter maps a UI component to that workflow event.
- Field readability — a component firing that event has an extractor for the field.
- API operations — the EHR has an implemented automation for that catalog entry. Partial means only some of the operation's fields are covered.
This is why the matrix is per-event rather than a flat field list: the same field may be
available on encounter_open but not on chart_open, because different EHR screens expose
different data.
Interactive matrix coming soon
The interactive support matrix renders here once it's available. Until then, confirm current per-EHR coverage with your Vim contact rather than relying on a table on this page.
Using it in practice
Choose your baseline. Decide which EHRs you must support at launch, then filter to just those columns. A capability supported by only one EHR is a differentiator, not a foundation.
Design for the intersection. Build your core flow on capabilities all your target EHRs support; treat the rest as progressive enhancement, enabled at runtime when the data is present.
Re-check before each submission. Coverage expands as adapters improve. A field unsupported when you built may be available now.
Related
- EHR Connectivity — how to read the data listed here
- Workflow Events — the events used to group this matrix
- Writeback — writing to the fields marked writable
- Managing Your Developer Account — declaring these scopes in your manifest