@awell-health/awell-extensions 2.1.185 → 2.1.187

package/dist/extensions/markdown.json

@@ -160,8 +160,8 @@
     "changelog": "# MessageBird changelog"
   },
   "metriport": {
-    "readme": "---\ntitle: Metriport\ndescription: Metriport is Plaid for healthcare data.\n---\n# Metriport\n\nMetriport is Plaid for healthcare data. We help digital health companies access and manage patient health and medical data, through an open-source and universal API.\n\nThrough a single integration, our API enables modern health companies to get the comprehensive patient data they need from both HIEs and EHRs, as well as popular wearable devices.\n\nAs a developer-first interoperability solution, Metriport is powering the next wave of innovative companies, accelerating a revolution in digital health.\n\nTo learn more visit [https://www.metriport.com/](https://www.metriport.com/)\n# Extension settings\n\nIn order to set up this extension, **you will need to provide a Metriport API key**. You can obtain an API key via the Metriport dashboard by selecting the `Developers tab`. To learn more on how to get started with Metriport visit our [quick start docs](https://docs.metriport.com/medical-api/getting-started/quickstart) for our Medical API. Also, to better understand how our API keys work check out the [API Keys section](https://docs.metriport.com/home/api-info/api-keys) of our docs as well.\n\n# Ingestion\n\n## Metriport ADT notifications (`metriportAdt`)\n\nAn ingestion endpoint for Metriport's [real-time patient notifications](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications). Point the webhook URL in the Metriport dashboard at it. Request verification (Metriport's HMAC-SHA256 `x-metriport-signature`, with the verification ping answered by `pong`) is implemented but switched off for the pre-release; it will be enabled, and the **Webhook Key** setting required, before general availability.\n\nHandled notification types are `patient.admit`, `patient.transfer`, `patient.discharge` and `medical.discharge-summary`. For each, the FHIR bundle behind the pre-signed `payload.url` is downloaded and the patient is resolved on `payload.externalId` (the id you gave Metriport when creating the patient, i.e. your own MRN). The endpoint saves one encounter keyed on the visit number (the patient itself is created by that resolution; demographics are not written yet), so all four notifications about one visit update the same encounter (`in-progress` until the discharge, `finished` after it, with the last transfer destination as its location). Any other notification type is acknowledged and produces nothing.\n\nEvents published, for care flows to trigger on: `patient.admitted`, `patient.transferred`, `patient.discharged` and `discharge.summary-received` (on a discharge summary). Every handled notification also publishes `fhir.bundle-received`, which FHIR data movement listens for; it carries no clinical data, the bundle is looked up by ingestion id.\n\n# Custom Actions\n\n**GENERAL NOTE: Make sure to create Organizations and Facilities in Metriport before using this extension. A Patient must be associated with a Facility by providing the facilityId when stated in the actions.**\n\n## Create Patient\n\nCreates a Patient in Metriport for the specified Facility where the Patient is receiving care. The Patient is not enrolled in real-time monitoring; use **Enroll in Monitoring** for that.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/create-patient) for more info.\n\n## Enroll in Monitoring\n\nCreates a Patient in Metriport and enrolls them in real-time monitoring in one step. It takes the same Patient details as **Create Patient**, but instead of a Facility ID it takes a **Cohort Name**. By convention a Cohort and the Facility its Patients receive care at share the same name, so the action looks both up by that name: the Patient is created in the matching Facility and added to the matching Cohort.\n\nNames are matched case-insensitively, ignoring surrounding whitespace, and must identify exactly one Cohort and exactly one Facility. Both lists are cached in memory for 24 hours; a name that is not in the cached list triggers an early refresh (at most once a minute) before the action fails, so a Cohort or Facility created recently is still found.\n\nNote that enrolling a Patient in real-time monitoring has downstream consequences: once you start receiving updates about the Patient, you are expected to contribute data back to Metriport.\n\nVisit the endpoint docs for [create patient](https://docs.metriport.com/medical-api/api-reference/patient/create-patient), [list facilities](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) and [list cohorts](https://docs.metriport.com/medical-api/api-reference/cohort/list-cohorts) for more info.\n\n## Update Patient\n\nUpdates the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/update-patient) for more info.\n\n## Get Patient\n\nRetrieves the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/get-patient) for more info.\n\n## Remove Patient\n\nRemoves a Patient at Metriport and at HIEs the Patient is linked to.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/delete-patient) for more info.\n\n## List Documents\n\nLists all Documents that can be retrieved for a Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/list-documents) for more info.\n\n**NOTE: It also returns the status of querying Document references across HIEs, indicating whether there is an asynchronous query in progress (status processing) or not (status completed). If the query is in progress, you will also receive the total number of Documents to be queried as well as the ones that have already been completed.**\n\n## Query Documents\n\nTriggers a Document query for the specified Patient across HIEs.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/start-document-query) for more info.\n\n**NOTE: When executed, this endpoint triggers an asynchronous Document query with HIEs and immediately returns the status of Document query, processing .**\n\n## Get Document Url\n\nGets a presigned URL for downloading the specified Document.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/get-document) for more info.\n\n**NOTE: This endpoint returns a URL which you can use to download the specified Document using the file name provided from the List Documents endpoint.**\n\n## Get Facility by Name\n\nGets the Facility with the given name, so a care flow can resolve a human-readable Facility name into the `facilityId` that the Patient and Document actions require.\n\nMetriport has no endpoint to filter Facilities by name, so this action lists all Facilities in your Organization and matches in memory. The name is matched case-insensitively and ignoring surrounding whitespace, and must match **exactly one** Facility: the action errors if no Facility matches, and also if several do, rather than guessing which one was meant.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) for more info.\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `facilityName` | string | The name of the Facility to look up. Matched case-insensitively, ignoring surrounding whitespace, and must match exactly one Facility in your Organization. |\n\nThe data points mirror the Facility object Metriport returns from [Get Facility](https://docs.metriport.com/medical-api/api-reference/facility/get-facility), one data point per response field:\n\n| Data point | Type | Metriport field | Description |\n| --- | --- | --- | --- |\n| `facilityId` | string | `id` | Metriport's UUID for the Facility. This is the `facilityId` the Patient and Document actions take. |\n| `facilityName` | string | `name` | The Facility name, as stored at Metriport — the canonical casing and spacing, not the name that was searched for. |\n| `npi` | string | `npi` | The Facility's National Provider Identifier. |\n| `tin` | string | `tin` | The Facility's Taxpayer Identification Number. Optional at Metriport; left unset when absent. |\n| `active` | boolean | `active` | Whether the Facility is active. Optional at Metriport; left unset when absent. |\n| `addressLine1` | string | `address.addressLine1` | Street address line 1. |\n| `addressLine2` | string | `address.addressLine2` | Street address line 2. Optional; left unset when absent. |\n| `city` | string | `address.city` | Address city. |\n| `state` | string | `address.state` | Two-letter US state or territory code. |\n| `zip` | string | `address.zip` | Address ZIP code. |\n| `country` | string | `address.country` | Address country — always `USA` at Metriport today. Left unset when absent. |\n\n## Remove Patient from Cohort\n\nRemoves the specified Patient from a cohort.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/cohort/remove-patients-from-cohort) for more info.\n\n## Get Webhook Bundle\n\nFetches the FHIR bundle from a Metriport webhook payload URL — e.g. the [Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle) from an ADT notification, or a discharge summary. Pass the `bundleUrl` data point emitted by the **Realtime Update** webhook; the action downloads the bundle and returns it on the `bundle` data point.\n\nWhen the payload is a Patient Encounter Bundle, the action also rewrites it into an executable FHIR transaction and returns that on the `transactionBundle` data point, ready to hand to the Medplum **Find or create resource** action.\n\nThe Encounter's Metriport id is returned separately on the `encounterId` data point, so a later step can address the imported Encounter without re-parsing the bundle.\n\n**NOTE: Metriport pre-signed URLs are only valid for 10 minutes, so this action should run early in the care flow, shortly after the realtime update webhook fires.**\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `url` | string | The pre-signed payload URL to fetch (the webhook's `bundleUrl` data point). |\n| `eventType` | string (optional) | The Metriport notification type — wire this from the realtime update webhook's `eventType` data point. Recorded on the import Provenance so admit, transfer and discharge can be told apart. |\n| `provenanceReason` | text (optional) | Free-text reason recorded on the import Provenance, describing why the data was imported. |\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `bundle` | json | The FHIR bundle fetched from the URL, exactly as Metriport sent it. |\n| `transactionBundle` | json | The same data rewritten as an executable FHIR transaction. Omitted when the payload is not a Patient Encounter Bundle. |\n| `encounterId` | string | Metriport's UUID for the Encounter in the bundle. Resolve the imported Encounter in Medplum with `Encounter?identifier=https://metriport.com/fhir/encounter\\|<encounterId>`. Omitted when the bundle carries no Encounter. |\n\n### Building the transaction bundle\n\nMetriport delivers a bundle of `type: 'collection'`, which is **not executable**. Handing it straight to Medplum does nothing useful: no entry carries `request` metadata saying what to do with it, and every internal reference points at a Metriport UUID that means nothing in Medplum. The action therefore builds a second, executable bundle rather than passing the original through.\n\nThe transformation is a pure function with no Medplum access of its own — this extension holds Metriport credentials only. That rules out reading Medplum to reconcile against what is already there, so every lookup is expressed declaratively and resolved by the server when the transaction executes.\n\n**The Patient is never written.** Awell/Medplum is the source of truth for patient demographics, so the Patient entry is dropped entirely and every reference to it becomes a conditional reference:\n\n```\nPatient?identifier=https://awellhealth.com/patients|<awell patient id>\n```\n\nOmitting the entry guarantees structurally that a Metriport ADT feed can never overwrite the patient record.\n\n**Everything else is written idempotently.** Each Metriport resource is stamped with an identifier derived from its Metriport id and written with a conditional update:\n\n```\nidentifier: { system: 'https://metriport.com/fhir/encounter', value: '<metriport id>' }\nrequest:    PUT Encounter?identifier=https://metriport.com/fhir/encounter|<metriport id>\n```\n\nA conditional update creates on zero matches and updates on one, so a redelivered notification updates in place instead of duplicating Conditions, Observations, Practitioners and Locations — and the admit and discharge notifications for one visit converge on a single Encounter. Existing identifiers are kept, so the Encounter keeps its HL7 `VN` visit number alongside ours.\n\n**References are rewritten to Metriport's own `fullUrl`s.** Metriport resolves its relationships correctly, but emits them in a form FHIR cannot match: entries carry `urn:uuid:` fullUrls while references to them are relative.\n\n```\nfullUrl:    urn:uuid:3ca5e8d2-7c84-45ab-91e7-834f8becde12\nreference:  Location/3ca5e8d2-7c84-45ab-91e7-834f8becde12\n```\n\nA transaction resolves an internal reference by matching it against `fullUrl` verbatim, and a relative reference does not match a `urn:uuid:` one — Medplum would read it as a reference to a *Medplum* Location with that id, which does not exist. Rewriting the reference to the entry's `fullUrl` closes the gap while keeping Metriport's identity. This is also why the result is a `transaction` and not a `batch`: `urn:uuid` resolution is a transaction feature.\n\n**`meta` is stripped from every resource.** Medplum's `meta.accounts` is inherited from the compartment of the Patient a resource references, but specifying `meta` at all on a create or update replaces those inherited accounts instead of adding to them. Metriport's Encounter arrives with a `meta`, so it is removed. `resource.id` is dropped too, for a separate reason: Medplum assigns identity, and the entry's `fullUrl` already carries the local identity the transaction needs.\n\n**Two entries are synthesised.** An `Organization` named *Metriport Realtime Monitoring*, created with `ifNoneExist` so an existing one is reused rather than overwritten; and a `Provenance` recording the import — what it created, when, which Metriport bundle it came from, and which ADT event triggered it (`patient.admit` → `A01`, `patient.transfer` → `A02`, `patient.discharge` → `A03`).\n\n`extensions/metriport/actions/webhookBundle/bundle/transform.test.ts` asserts the complete output for a real `patient.admit` bundle, if you want to see the whole before/after in one place.\n\n### Wiring it into a care flow\n\n1. **Realtime Update** webhook fires and emits `bundleUrl` and `eventType`.\n2. **Get Webhook Bundle** — pass `bundleUrl` to `url` and `eventType` to `eventType`. Run this early; the URL expires after 10 minutes.\n3. Medplum **Find or create resource** — pass the `transactionBundle` data point to its `resourceJson` field. No changes to that action are needed; it detects a Bundle and executes it.\n\n**PREREQUISITE: for imported resources to be tagged with the Metriport organization, the Medplum Patient must already carry it in `meta.accounts` before the notification arrives.** Resources created without a `meta` inherit their accounts from the compartment of the Patient they reference, so tagging the Patient once causes every subsequent import to inherit it automatically. Note that this only covers resources *in* the patient compartment — `Location` and `Practitioner` are shared directory resources and are intentionally created untagged, since scoping a hospital or a physician to one patient's tenant would be wrong.\n\n**NOTE: the conditional Patient reference only resolves if your Medplum Patients carry an identifier under the `https://awellhealth.com/patients` system with the Awell patient id as its value. A conditional reference that matches no Patient fails the whole transaction.**\n\n### When the transaction bundle is omitted\n\n`Get Webhook Bundle` serves several Metriport webhook types and only ADT notifications carry encounter bundles. For any payload that is not a `collection` bundle, `transactionBundle` is simply omitted and `bundle` is emitted on its own — the action still succeeds.\n\nA `collection` bundle that is missing its Patient or Encounter entry is treated differently: that is an encounter bundle which does not describe an encounter, so the action **fails** rather than silently emitting a partial result.\n\n# Webhooks\n\n## Realtime Update\n\nAn enrollment trigger that starts a care flow when Metriport sends a [real-time patient notification](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications).\n\nMetriport POSTs every notification type to the same endpoint. Four of them share one payload shape — a `meta` envelope plus a `payload` pointing at a pre-signed bundle URL — and this webhook enrolls a patient on all four:\n\n- `patient.admit` (HL7 ADT^A01)\n- `patient.discharge` (HL7 ADT^A03)\n- `patient.transfer` (HL7 ADT^A02)\n- `medical.discharge-summary`\n\nThe `eventType` data point carries the raw Metriport webhook type, so a care flow can branch on it. The payload's `url` is a pre-signed link to the [FHIR Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle).\n\nThe webhook validates the request, emits the data points (including the pre-signed bundle URL on `bundleUrl`), and replies immediately — it does **not** download the bundle. Fetch the bundle later in the care flow with the **Get Webhook Bundle** action, using the `bundleUrl` data point. Because the URL expires after 10 minutes, run that action early.\n\nAny other notification type Metriport sends — `medical.document-download`, `medical.consolidated-data`, and anything added in future — is acknowledged with a `200` and does not enroll a patient. A notification whose type *is* handled but whose payload is malformed fails loudly instead, so a genuine integration problem is not mistaken for an event we chose to ignore. Metriport [verification `ping` messages](https://docs.metriport.com/medical-api/getting-started/webhooks#the-ping-message) are answered with a `200` that echoes the ping value back as `pong: <value>`.\n\n### Data points\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `eventType` | string | The Metriport webhook type: `patient.admit`, `patient.discharge`, `patient.transfer` or `medical.discharge-summary` |\n| `metriportPatientId` | string | The Metriport patient ID (also used as the patient identifier for enrollment) |\n| `externalId` | string | Your external patient ID, if provided to Metriport |\n| `when` | date | When the event occurred — the admit time on an admit event, the discharge time on a discharge event |\n| `messageId` | string | The Metriport message ID for the notification |\n| `bundleUrl` | string | Pre-signed URL to the FHIR bundle; fetch it with the **Get Webhook Bundle** action (valid for 10 minutes) |\n\n### Verifying incoming requests\n\nOptionally set the **Webhook Key** setting to the webhook key from the Metriport dashboard (Settings/Developers tab). Metriport [authenticates each webhook](https://docs.metriport.com/medical-api/getting-started/webhooks#authentication) with an HMAC-SHA256 signature of the raw request body, keyed with your webhook key and sent in the `x-metriport-signature` header. When the setting is populated, the webhook recomputes the HMAC over the raw body and rejects any request whose signature is missing or does not match (`401`). When left empty, requests are not verified.\n\n## More Info\n\nFor more information on how to integrate with Metriport please visit our [Medical API docs](https://docs.metriport.com/medical-api/getting-started/quickstart)\n",
-    "changelog": "# Metriport changelog\n\n## September 2026\n\n- Add the `metriportAdt` ingestion endpoint (`source: 'webhook'`): receives Metriport real-time notifications, handles `patient.admit`, `patient.transfer`, `patient.discharge` and `medical.discharge-summary`, downloads the FHIR bundle each points at, and saves one encounter per visit (the patient is created by identifier resolution; demographics are not written yet), so admit, transfer, discharge and the summary converge on the same encounter. Publishes `patient.admitted` / `patient.transferred` / `patient.discharged` / `discharge.summary-received` for care flows and `fhir.bundle-received` for FHIR data movement. Any other notification type is acknowledged without producing a record; HMAC-SHA256 signature verification (with the ping answered by `pong`) is implemented but switched off for the pre-release. The extension now declares `identifier.system` (`https://metriport.com`).\n- Add `Enroll in Monitoring` action: creates a Patient and enrolls them in real-time monitoring in one step. It takes the same Patient details as `Create Patient` but a **Cohort Name** instead of a Facility ID; by convention a Cohort and its Facility share a name, so both are resolved from that one input. Facility and Cohort lists are cached in memory for 24 hours per API credential, refreshing early (at most once a minute) when a name is not found.\n- **Breaking: remove the `Cohort` field from `Create Patient` and `Update Patient`.** Real-time monitoring enrollment now lives on `Enroll in Monitoring`; care flows that passed a cohort ID to `Create Patient` should switch to the new action.\n\n## August 2026\n\n- Rename the `enrollment` webhook to `realtimeUpdate`. The old name described what Awell does with the notification rather than what Metriport sends, which read confusingly next to the genuine enrolment concepts (the `Cohort` field, enrolling a patient into a care flow). Behaviour is unchanged. **Breaking: the webhook endpoint URL changes, so any webhook already configured in the Metriport dashboard must be repointed.**\n- `Date of Birth` on the `Create Patient` and `Update Patient` actions is now a date field rather than a free-text string, so care flows can map a date onto it directly instead of hand-formatting `YYYY-MM-DD`. The value is normalised to the date-only string Metriport expects, so care flows already passing `YYYY-MM-DD` are unaffected.\n\n## July 2026\n\n- Add `enrollment` webhook: an enrollment trigger for Metriport real-time patient notifications. The `eventType` data point carries the Metriport webhook type (`patient.admit` or `medical.discharge-summary`) so care flows can distinguish on it. The webhook validates and replies immediately, emitting the pre-signed FHIR bundle URL on the `bundleUrl` data point rather than downloading the bundle inline.\n- Add `Get Webhook Bundle` action: fetches the FHIR bundle from a Metriport webhook payload URL (the webhook's `bundleUrl`), for use later in the care flow.\n- Add optional `Webhook Key` setting used to verify incoming webhook requests via Metriport's HMAC-SHA256 signature (`x-metriport-signature` header), computed over the raw request body.\n"
+    "readme": "---\ntitle: Metriport\ndescription: Metriport is Plaid for healthcare data.\n---\n# Metriport\n\nMetriport is Plaid for healthcare data. We help digital health companies access and manage patient health and medical data, through an open-source and universal API.\n\nThrough a single integration, our API enables modern health companies to get the comprehensive patient data they need from both HIEs and EHRs, as well as popular wearable devices.\n\nAs a developer-first interoperability solution, Metriport is powering the next wave of innovative companies, accelerating a revolution in digital health.\n\nTo learn more visit [https://www.metriport.com/](https://www.metriport.com/)\n# Extension settings\n\nIn order to set up this extension, **you will need to provide a Metriport API key**. You can obtain an API key via the Metriport dashboard by selecting the `Developers tab`. To learn more on how to get started with Metriport visit our [quick start docs](https://docs.metriport.com/medical-api/getting-started/quickstart) for our Medical API. Also, to better understand how our API keys work check out the [API Keys section](https://docs.metriport.com/home/api-info/api-keys) of our docs as well.\n\n# Ingestion\n\n## Metriport ADT notifications (`metriportAdt`)\n\nAn ingestion endpoint for Metriport's [real-time patient notifications](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications). Point the webhook URL in the Metriport dashboard at it. Request verification (Metriport's HMAC-SHA256 `x-metriport-signature`, with the verification ping answered by `pong`) is implemented but switched off for the pre-release; it will be enabled, and the **Webhook Key** setting required, before general availability.\n\nHandled notification types are `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`. For each, the FHIR bundle behind the pre-signed `payload.url` is downloaded and the patient is resolved on `payload.externalId` (the id you gave Metriport when creating the patient, i.e. your own MRN). The endpoint saves one encounter keyed on the visit number (the patient itself is created by that resolution; demographics are not written yet), so all four notifications about one visit update the same encounter (`in-progress` until the discharge, `finished` after it, with the last transfer destination as its location). Any other notification type is acknowledged and produces nothing.\n\nEvents published, for care flows to trigger on: `patient.admitted`, `patient.transferred`, `patient.discharged` and `discharge.summary-received` (on a discharge summary). Every handled notification also publishes `fhir.bundle-received`, which FHIR data movement listens for; it carries no clinical data, the bundle is looked up by ingestion id.\n\n# Custom Actions\n\n**GENERAL NOTE: Make sure to create Organizations and Facilities in Metriport before using this extension. A Patient must be associated with a Facility by providing the facilityId when stated in the actions.**\n\n## Create Patient\n\nCreates a Patient in Metriport for the specified Facility where the Patient is receiving care. The Patient is not enrolled in real-time monitoring; use **Enroll in Monitoring** for that.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/create-patient) for more info.\n\n## Enroll in Monitoring\n\nCreates a Patient in Metriport and enrolls them in real-time monitoring in one step. It takes the same Patient details as **Create Patient**, but instead of a Facility ID it takes a **Cohort Name**. By convention a Cohort and the Facility its Patients receive care at share the same name, so the action looks both up by that name: the Patient is created in the matching Facility and added to the matching Cohort.\n\nNames are matched case-insensitively, ignoring surrounding whitespace, and must identify exactly one Cohort and exactly one Facility. Both lists are cached in memory for 24 hours; a name that is not in the cached list triggers an early refresh (at most once a minute) before the action fails, so a Cohort or Facility created recently is still found.\n\nNote that enrolling a Patient in real-time monitoring has downstream consequences: once you start receiving updates about the Patient, you are expected to contribute data back to Metriport.\n\nVisit the endpoint docs for [create patient](https://docs.metriport.com/medical-api/api-reference/patient/create-patient), [list facilities](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) and [list cohorts](https://docs.metriport.com/medical-api/api-reference/cohort/list-cohorts) for more info.\n\n## Update Patient\n\nUpdates the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/update-patient) for more info.\n\n## Get Patient\n\nRetrieves the specified Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/get-patient) for more info.\n\n## Remove Patient\n\nRemoves a Patient at Metriport and at HIEs the Patient is linked to.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/patient/delete-patient) for more info.\n\n## List Documents\n\nLists all Documents that can be retrieved for a Patient.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/list-documents) for more info.\n\n**NOTE: It also returns the status of querying Document references across HIEs, indicating whether there is an asynchronous query in progress (status processing) or not (status completed). If the query is in progress, you will also receive the total number of Documents to be queried as well as the ones that have already been completed.**\n\n## Query Documents\n\nTriggers a Document query for the specified Patient across HIEs.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/start-document-query) for more info.\n\n**NOTE: When executed, this endpoint triggers an asynchronous Document query with HIEs and immediately returns the status of Document query, processing .**\n\n## Get Document Url\n\nGets a presigned URL for downloading the specified Document.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/document/get-document) for more info.\n\n**NOTE: This endpoint returns a URL which you can use to download the specified Document using the file name provided from the List Documents endpoint.**\n\n## Get Facility by Name\n\nGets the Facility with the given name, so a care flow can resolve a human-readable Facility name into the `facilityId` that the Patient and Document actions require.\n\nMetriport has no endpoint to filter Facilities by name, so this action lists all Facilities in your Organization and matches in memory. The name is matched case-insensitively and ignoring surrounding whitespace, and must match **exactly one** Facility: the action errors if no Facility matches, and also if several do, rather than guessing which one was meant.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/facility/list-facilities) for more info.\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `facilityName` | string | The name of the Facility to look up. Matched case-insensitively, ignoring surrounding whitespace, and must match exactly one Facility in your Organization. |\n\nThe data points mirror the Facility object Metriport returns from [Get Facility](https://docs.metriport.com/medical-api/api-reference/facility/get-facility), one data point per response field:\n\n| Data point | Type | Metriport field | Description |\n| --- | --- | --- | --- |\n| `facilityId` | string | `id` | Metriport's UUID for the Facility. This is the `facilityId` the Patient and Document actions take. |\n| `facilityName` | string | `name` | The Facility name, as stored at Metriport — the canonical casing and spacing, not the name that was searched for. |\n| `npi` | string | `npi` | The Facility's National Provider Identifier. |\n| `tin` | string | `tin` | The Facility's Taxpayer Identification Number. Optional at Metriport; left unset when absent. |\n| `active` | boolean | `active` | Whether the Facility is active. Optional at Metriport; left unset when absent. |\n| `addressLine1` | string | `address.addressLine1` | Street address line 1. |\n| `addressLine2` | string | `address.addressLine2` | Street address line 2. Optional; left unset when absent. |\n| `city` | string | `address.city` | Address city. |\n| `state` | string | `address.state` | Two-letter US state or territory code. |\n| `zip` | string | `address.zip` | Address ZIP code. |\n| `country` | string | `address.country` | Address country — always `USA` at Metriport today. Left unset when absent. |\n\n## Remove Patient from Cohort\n\nRemoves the specified Patient from a cohort.\n\nVisit [endpoint docs](https://docs.metriport.com/medical-api/api-reference/cohort/remove-patients-from-cohort) for more info.\n\n## Get Webhook Bundle\n\nFetches the FHIR bundle from a Metriport webhook payload URL — e.g. the [Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle) from an ADT notification, or a discharge summary. Pass the `bundleUrl` data point emitted by the **Realtime Update** webhook; the action downloads the bundle and returns it on the `bundle` data point.\n\nWhen the payload is a Patient Encounter Bundle, the action also rewrites it into an executable FHIR transaction and returns that on the `transactionBundle` data point, ready to hand to the Medplum **Find or create resource** action.\n\nThe Encounter's Metriport id is returned separately on the `encounterId` data point, so a later step can address the imported Encounter without re-parsing the bundle.\n\n**NOTE: Metriport pre-signed URLs are only valid for 10 minutes, so this action should run early in the care flow, shortly after the realtime update webhook fires.**\n\n| Field | Type | Description |\n| --- | --- | --- |\n| `url` | string | The pre-signed payload URL to fetch (the webhook's `bundleUrl` data point). |\n| `eventType` | string (optional) | The Metriport notification type — wire this from the realtime update webhook's `eventType` data point. Recorded on the import Provenance so admit, transfer and discharge can be told apart. |\n| `provenanceReason` | text (optional) | Free-text reason recorded on the import Provenance, describing why the data was imported. |\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `bundle` | json | The FHIR bundle fetched from the URL, exactly as Metriport sent it. |\n| `transactionBundle` | json | The same data rewritten as an executable FHIR transaction. Omitted when the payload is not a Patient Encounter Bundle. |\n| `encounterId` | string | Metriport's UUID for the Encounter in the bundle. Resolve the imported Encounter in Medplum with `Encounter?identifier=https://metriport.com/fhir/encounter\\|<encounterId>`. Omitted when the bundle carries no Encounter. |\n\n### Building the transaction bundle\n\nMetriport delivers a bundle of `type: 'collection'`, which is **not executable**. Handing it straight to Medplum does nothing useful: no entry carries `request` metadata saying what to do with it, and every internal reference points at a Metriport UUID that means nothing in Medplum. The action therefore builds a second, executable bundle rather than passing the original through.\n\nThe transformation is a pure function with no Medplum access of its own — this extension holds Metriport credentials only. That rules out reading Medplum to reconcile against what is already there, so every lookup is expressed declaratively and resolved by the server when the transaction executes.\n\n**The Patient is never written.** Awell/Medplum is the source of truth for patient demographics, so the Patient entry is dropped entirely and every reference to it becomes a conditional reference:\n\n```\nPatient?identifier=https://awellhealth.com/patients|<awell patient id>\n```\n\nOmitting the entry guarantees structurally that a Metriport ADT feed can never overwrite the patient record.\n\n**Everything else is written idempotently.** Each Metriport resource is stamped with an identifier derived from its Metriport id and written with a conditional update:\n\n```\nidentifier: { system: 'https://metriport.com/fhir/encounter', value: '<metriport id>' }\nrequest:    PUT Encounter?identifier=https://metriport.com/fhir/encounter|<metriport id>\n```\n\nA conditional update creates on zero matches and updates on one, so a redelivered notification updates in place instead of duplicating Conditions, Observations, Practitioners and Locations — and the admit and discharge notifications for one visit converge on a single Encounter. Existing identifiers are kept, so the Encounter keeps its HL7 `VN` visit number alongside ours.\n\n**References are rewritten to Metriport's own `fullUrl`s.** Metriport resolves its relationships correctly, but emits them in a form FHIR cannot match: entries carry `urn:uuid:` fullUrls while references to them are relative.\n\n```\nfullUrl:    urn:uuid:3ca5e8d2-7c84-45ab-91e7-834f8becde12\nreference:  Location/3ca5e8d2-7c84-45ab-91e7-834f8becde12\n```\n\nA transaction resolves an internal reference by matching it against `fullUrl` verbatim, and a relative reference does not match a `urn:uuid:` one — Medplum would read it as a reference to a *Medplum* Location with that id, which does not exist. Rewriting the reference to the entry's `fullUrl` closes the gap while keeping Metriport's identity. This is also why the result is a `transaction` and not a `batch`: `urn:uuid` resolution is a transaction feature.\n\n**`meta` is stripped from every resource.** Medplum's `meta.accounts` is inherited from the compartment of the Patient a resource references, but specifying `meta` at all on a create or update replaces those inherited accounts instead of adding to them. Metriport's Encounter arrives with a `meta`, so it is removed. `resource.id` is dropped too, for a separate reason: Medplum assigns identity, and the entry's `fullUrl` already carries the local identity the transaction needs.\n\n**Two entries are synthesised.** An `Organization` named *Metriport Realtime Monitoring*, created with `ifNoneExist` so an existing one is reused rather than overwritten; and a `Provenance` recording the import — what it created, when, which Metriport bundle it came from, and which ADT event triggered it (`patient.admit` → `A01`, `patient.transfer` → `A02`, `patient.discharge` → `A03`).\n\n`extensions/metriport/actions/webhookBundle/bundle/transform.test.ts` asserts the complete output for a real `patient.admit` bundle, if you want to see the whole before/after in one place.\n\n### Wiring it into a care flow\n\n1. **Realtime Update** webhook fires and emits `bundleUrl` and `eventType`.\n2. **Get Webhook Bundle** — pass `bundleUrl` to `url` and `eventType` to `eventType`. Run this early; the URL expires after 10 minutes.\n3. Medplum **Find or create resource** — pass the `transactionBundle` data point to its `resourceJson` field. No changes to that action are needed; it detects a Bundle and executes it.\n\n**PREREQUISITE: for imported resources to be tagged with the Metriport organization, the Medplum Patient must already carry it in `meta.accounts` before the notification arrives.** Resources created without a `meta` inherit their accounts from the compartment of the Patient they reference, so tagging the Patient once causes every subsequent import to inherit it automatically. Note that this only covers resources *in* the patient compartment — `Location` and `Practitioner` are shared directory resources and are intentionally created untagged, since scoping a hospital or a physician to one patient's tenant would be wrong.\n\n**NOTE: the conditional Patient reference only resolves if your Medplum Patients carry an identifier under the `https://awellhealth.com/patients` system with the Awell patient id as its value. A conditional reference that matches no Patient fails the whole transaction.**\n\n### When the transaction bundle is omitted\n\n`Get Webhook Bundle` serves several Metriport webhook types and only ADT notifications carry encounter bundles. For any payload that is not a `collection` bundle, `transactionBundle` is simply omitted and `bundle` is emitted on its own — the action still succeeds.\n\nA `collection` bundle that is missing its Patient or Encounter entry is treated differently: that is an encounter bundle which does not describe an encounter, so the action **fails** rather than silently emitting a partial result.\n\n# Webhooks\n\n## Realtime Update\n\nAn enrollment trigger that starts a care flow when Metriport sends a [real-time patient notification](https://docs.metriport.com/medical-api/handling-data/realtime-patient-notifications).\n\nMetriport POSTs every notification type to the same endpoint. Four of them share one payload shape — a `meta` envelope plus a `payload` pointing at a pre-signed bundle URL — and this webhook enrolls a patient on all four:\n\n- `patient.admit` (HL7 ADT^A01)\n- `patient.discharge` (HL7 ADT^A03)\n- `patient.transfer` (HL7 ADT^A02)\n- `patient.discharge-summary`\n\nThe `eventType` data point carries the raw Metriport webhook type, so a care flow can branch on it. The payload's `url` is a pre-signed link to the [FHIR Encounter Bundle](https://docs.metriport.com/medical-api/handling-data/patient-encounter-bundle).\n\nThe webhook validates the request, emits the data points (including the pre-signed bundle URL on `bundleUrl`), and replies immediately — it does **not** download the bundle. Fetch the bundle later in the care flow with the **Get Webhook Bundle** action, using the `bundleUrl` data point. Because the URL expires after 10 minutes, run that action early.\n\nAny other notification type Metriport sends — `medical.document-download`, `medical.consolidated-data`, and anything added in future — is acknowledged with a `200` and does not enroll a patient. A notification whose type *is* handled but whose payload is malformed fails loudly instead, so a genuine integration problem is not mistaken for an event we chose to ignore. Metriport [verification `ping` messages](https://docs.metriport.com/medical-api/getting-started/webhooks#the-ping-message) are answered with a `200` that echoes the ping value back as `pong: <value>`.\n\n### Data points\n\n| Data point | Type | Description |\n| --- | --- | --- |\n| `eventType` | string | The Metriport webhook type: `patient.admit`, `patient.discharge`, `patient.transfer` or `patient.discharge-summary` |\n| `metriportPatientId` | string | The Metriport patient ID (also used as the patient identifier for enrollment) |\n| `externalId` | string | Your external patient ID, if provided to Metriport |\n| `when` | date | When the event occurred — the admit time on an admit event, the discharge time on a discharge event |\n| `messageId` | string | The Metriport message ID for the notification |\n| `bundleUrl` | string | Pre-signed URL to the FHIR bundle; fetch it with the **Get Webhook Bundle** action (valid for 10 minutes) |\n\n### Verifying incoming requests\n\nOptionally set the **Webhook Key** setting to the webhook key from the Metriport dashboard (Settings/Developers tab). Metriport [authenticates each webhook](https://docs.metriport.com/medical-api/getting-started/webhooks#authentication) with an HMAC-SHA256 signature of the raw request body, keyed with your webhook key and sent in the `x-metriport-signature` header. When the setting is populated, the webhook recomputes the HMAC over the raw body and rejects any request whose signature is missing or does not match (`401`). When left empty, requests are not verified.\n\n## More Info\n\nFor more information on how to integrate with Metriport please visit our [Medical API docs](https://docs.metriport.com/medical-api/getting-started/quickstart)\n",
+    "changelog": "# Metriport changelog\n\n## September 2026\n\n- Add the `metriportAdt` ingestion endpoint (`source: 'webhook'`): receives Metriport real-time notifications, handles `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`, downloads the FHIR bundle each points at, and saves one encounter per visit (the patient is created by identifier resolution; demographics are not written yet), so admit, transfer, discharge and the summary converge on the same encounter. Publishes `patient.admitted` / `patient.transferred` / `patient.discharged` / `discharge.summary-received` for care flows and `fhir.bundle-received` for FHIR data movement. Any other notification type is acknowledged without producing a record; HMAC-SHA256 signature verification (with the ping answered by `pong`) is implemented but switched off for the pre-release. The extension now declares `identifier.system` (`https://metriport.com`).\n- Add `Enroll in Monitoring` action: creates a Patient and enrolls them in real-time monitoring in one step. It takes the same Patient details as `Create Patient` but a **Cohort Name** instead of a Facility ID; by convention a Cohort and its Facility share a name, so both are resolved from that one input. Facility and Cohort lists are cached in memory for 24 hours per API credential, refreshing early (at most once a minute) when a name is not found.\n- **Breaking: remove the `Cohort` field from `Create Patient` and `Update Patient`.** Real-time monitoring enrollment now lives on `Enroll in Monitoring`; care flows that passed a cohort ID to `Create Patient` should switch to the new action.\n\n## August 2026\n\n- Rename the `enrollment` webhook to `realtimeUpdate`. The old name described what Awell does with the notification rather than what Metriport sends, which read confusingly next to the genuine enrolment concepts (the `Cohort` field, enrolling a patient into a care flow). Behaviour is unchanged. **Breaking: the webhook endpoint URL changes, so any webhook already configured in the Metriport dashboard must be repointed.**\n- `Date of Birth` on the `Create Patient` and `Update Patient` actions is now a date field rather than a free-text string, so care flows can map a date onto it directly instead of hand-formatting `YYYY-MM-DD`. The value is normalised to the date-only string Metriport expects, so care flows already passing `YYYY-MM-DD` are unaffected.\n\n## July 2026\n\n- Add `enrollment` webhook: an enrollment trigger for Metriport real-time patient notifications. The `eventType` data point carries the Metriport webhook type (`patient.admit` or `patient.discharge-summary`) so care flows can distinguish on it. The webhook validates and replies immediately, emitting the pre-signed FHIR bundle URL on the `bundleUrl` data point rather than downloading the bundle inline.\n- Add `Get Webhook Bundle` action: fetches the FHIR bundle from a Metriport webhook payload URL (the webhook's `bundleUrl`), for use later in the care flow.\n- Add optional `Webhook Key` setting used to verify incoming webhook requests via Metriport's HMAC-SHA256 signature (`x-metriport-signature` header), computed over the raw request body.\n"
   },
   "nexuzhealth": {
     "readme": "---\ntitle: nexuzhealth\ndescription: Demo extension for nexuzhealth\n---\n\nThis is an extension that can only be used for demo purposes.",

package/dist/extensions/metriport/actions/patient/create.js

@@ -51,7 +51,7 @@ const convertToMetriportPatient = (patient) => {
             addressLine2: patient.addressLine2,
             city: patient.city,
             state: patient.state,
-            zip: patient.zip,
+            zip: patient.zip.slice(0, 5),
             country: patient.country,
         },
         personalIdentifiers: [],

package/dist/extensions/metriport/actions/patient/create.js.map

@@ -1 +1 @@
-{"version":3,"file":"create.js","sourceRoot":"","sources":["../../../../../extensions/metriport/actions/patient/create.ts"],"names":[],"mappings":";;;AAAA,gDAG2B;AAC3B,uEAAkD;AAElD,mEAAwD;AAExD,yCAAiD;AACjD,4DAA8D;AAC9D,qCAAuC;AACvC,8DAAuD;AACvD,6CAAsE;AACtE,6CAAiD;AAEpC,QAAA,aAAa,GAItB;IACF,GAAG,EAAE,eAAe;IACpB,QAAQ,EAAE,0BAAQ,CAAC,gBAAgB;IACnC,KAAK,EAAE,gBAAgB;IACvB,WAAW,EACT,4LAA4L;IAC9L,MAAM,EAAE,qBAAY;IACpB,WAAW,EAAE,IAAI;IACjB,0BAA0B,EAAE,IAAI;IAChC,UAAU,EAAE,+BAAkB;IAC9B,OAAO,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,UAAU,EAAE,OAAO,EAAE,OAAO,EAAE,EAAiB,EAAE;QAC1E,OAAO,CAAC,GAAG,CAAC,EAAE,MAAM,EAAE,OAAO,CAAC,MAAM,EAAE,EAAE,0BAA0B,CAAC,CAAA;QAEnE,IAAI,CAAC;YACH,MAAM,OAAO,GAAG,gCAAmB,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,CAAA;YAEzD,MAAM,UAAU,GAAG,sBAAQ,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,UAAU,CAAC,CAAA;YAE5D,MAAM,gBAAgB,GAAG,IAAA,iCAAyB,EAAC,OAAO,CAAC,CAAA;YAE3D,MAAM,GAAG,GAAG,IAAA,2BAAkB,EAAC,OAAO,CAAC,QAAQ,CAAC,CAAA;YAEhD,MAAM,EAAE,EAAE,EAAE,GAAG,MAAM,GAAG,CAAC,aAAa,CAAC,gBAAgB,EAAE,UAAU,CAAC,CAAA;YAEpE,MAAM,UAAU,CAAC;gBACf,WAAW,EAAE;oBACX,SAAS,EAAE,MAAM,CAAC,EAAE,CAAC;iBACtB;aACF,CAAC,CAAA;QACJ,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,GAAG,CAAC,EAAE,GAAG,EAAE,EAAE,OAAO,EAAE,GAAY,CAAC,CAAA;YAC3C,MAAM,IAAA,iCAAkB,EAAC,GAAG,EAAE,OAAO,CAAC,CAAA;QACxC,CAAC;IACH,CAAC;CACF,CAAA;AACM,MAAM,yBAAyB,GAAG,CACvC,OAAsB,EACE,EAAE;;IAC1B,MAAM,gBAAgB,GAA2B;QAC/C,SAAS,EAAE,OAAO,CAAC,SAAS;QAC5B,QAAQ,EAAE,OAAO,CAAC,QAAQ;QAC1B,GAAG,EAAE,OAAO,CAAC,GAAG;QAChB,aAAa,EAAE,OAAO,CAAC,aAAa;QACpC,OAAO,EAAE;YACP,YAAY,EAAE,OAAO,CAAC,YAAY;YAClC,YAAY,EAAE,OAAO,CAAC,YAAY;YAClC,IAAI,EAAE,OAAO,CAAC,IAAI;YAClB,KAAK,EAAE,OAAO,CAAC,KAAK;YACpB,GAAG,EAAE,OAAO,CAAC,GAAG;YAChB,OAAO,EAAE,OAAO,CAAC,OAAO;SACzB;QACD,mBAAmB,EAAE,EAAE;KACxB,CAAA;IAED,IAAI,OAAO,CAAC,KAAK,IAAI,OAAO,CAAC,KAAK,EAAE,CAAC;QACnC,gBAAgB,CAAC,OAAO,GAAG;YACzB,KAAK,EAAE,OAAO,CAAC,KAAK,IAAI,SAAS;YACjC,KAAK,EAAE,OAAO,CAAC,KAAK,IAAI,SAAS;SAClC,CAAA;IACH,CAAC;IAED,IACE,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,KAAK,SAAS,EACzC,CAAC;QACD,MAAM,IAAI,KAAK,CACb,0EAA0E,CAC3E,CAAA;IACH,CAAC;SAAM,IACL,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,KAAK,SAAS,EACzC,CAAC;QACD,MAAM,IAAI,KAAK,CACb,0EAA0E,CAC3E,CAAA;IACH,CAAC;IAED,IACE,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,CAAC,MAAM,GAAG,CAAC;QACtC,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,CAAC,MAAM,GAAG,CAAC,EACtC,CAAC;QACD,MAAM,KAAK,GAAG,IAAA,kCAAO,EAAC,OAAO,CAAC,mBAAmB,EAAE;YACjD,MAAM,EAAE,OAAO,CAAC,mBAAmB;SACpC,CAAC,CAAA;QAEF,IAAI,KAAK,EAAE,CAAC;YACV,CAAC;YAAA,CAAC,MAAA,gBAAgB,CAAC,mBAAmB,mCAAI,EAAE,CAAC,CAAC,IAAI,CAAC;gBACjD,IAAI,EAAE,gBAAgB;gBACtB,KAAK,EAAE,OAAO,CAAC,mBAAmB;gBAClC,KAAK,EAAE,uBAAa,CAAC,KAAK,CAAC,OAAO,CAAC,mBAAmB,CAAC;aACxD,CAAC,CAAA;QACJ,CAAC;IACH,CAAC;IAED,OAAO,gBAAgB,CAAA;AACzB,CAAC,CAAA;AA9DY,QAAA,yBAAyB,6BA8DrC"}
+{"version":3,"file":"create.js","sourceRoot":"","sources":["../../../../../extensions/metriport/actions/patient/create.ts"],"names":[],"mappings":";;;AAAA,gDAG2B;AAC3B,uEAAkD;AAElD,mEAAwD;AAExD,yCAAiD;AACjD,4DAA8D;AAC9D,qCAAuC;AACvC,8DAAuD;AACvD,6CAAsE;AACtE,6CAAiD;AAEpC,QAAA,aAAa,GAItB;IACF,GAAG,EAAE,eAAe;IACpB,QAAQ,EAAE,0BAAQ,CAAC,gBAAgB;IACnC,KAAK,EAAE,gBAAgB;IACvB,WAAW,EACT,4LAA4L;IAC9L,MAAM,EAAE,qBAAY;IACpB,WAAW,EAAE,IAAI;IACjB,0BAA0B,EAAE,IAAI;IAChC,UAAU,EAAE,+BAAkB;IAC9B,OAAO,EAAE,KAAK,EAAE,EAAE,OAAO,EAAE,UAAU,EAAE,OAAO,EAAE,OAAO,EAAE,EAAiB,EAAE;QAC1E,OAAO,CAAC,GAAG,CAAC,EAAE,MAAM,EAAE,OAAO,CAAC,MAAM,EAAE,EAAE,0BAA0B,CAAC,CAAA;QAEnE,IAAI,CAAC;YACH,MAAM,OAAO,GAAG,gCAAmB,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,CAAA;YAEzD,MAAM,UAAU,GAAG,sBAAQ,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,UAAU,CAAC,CAAA;YAE5D,MAAM,gBAAgB,GAAG,IAAA,iCAAyB,EAAC,OAAO,CAAC,CAAA;YAE3D,MAAM,GAAG,GAAG,IAAA,2BAAkB,EAAC,OAAO,CAAC,QAAQ,CAAC,CAAA;YAEhD,MAAM,EAAE,EAAE,EAAE,GAAG,MAAM,GAAG,CAAC,aAAa,CAAC,gBAAgB,EAAE,UAAU,CAAC,CAAA;YAEpE,MAAM,UAAU,CAAC;gBACf,WAAW,EAAE;oBACX,SAAS,EAAE,MAAM,CAAC,EAAE,CAAC;iBACtB;aACF,CAAC,CAAA;QACJ,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,GAAG,CAAC,EAAE,GAAG,EAAE,EAAE,OAAO,EAAE,GAAY,CAAC,CAAA;YAC3C,MAAM,IAAA,iCAAkB,EAAC,GAAG,EAAE,OAAO,CAAC,CAAA;QACxC,CAAC;IACH,CAAC;CACF,CAAA;AACM,MAAM,yBAAyB,GAAG,CACvC,OAAsB,EACE,EAAE;;IAC1B,MAAM,gBAAgB,GAA2B;QAC/C,SAAS,EAAE,OAAO,CAAC,SAAS;QAC5B,QAAQ,EAAE,OAAO,CAAC,QAAQ;QAC1B,GAAG,EAAE,OAAO,CAAC,GAAG;QAChB,aAAa,EAAE,OAAO,CAAC,aAAa;QACpC,OAAO,EAAE;YACP,YAAY,EAAE,OAAO,CAAC,YAAY;YAClC,YAAY,EAAE,OAAO,CAAC,YAAY;YAClC,IAAI,EAAE,OAAO,CAAC,IAAI;YAClB,KAAK,EAAE,OAAO,CAAC,KAAK;YACpB,GAAG,EAAE,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC;YAC5B,OAAO,EAAE,OAAO,CAAC,OAAO;SACzB;QACD,mBAAmB,EAAE,EAAE;KACxB,CAAA;IAED,IAAI,OAAO,CAAC,KAAK,IAAI,OAAO,CAAC,KAAK,EAAE,CAAC;QACnC,gBAAgB,CAAC,OAAO,GAAG;YACzB,KAAK,EAAE,OAAO,CAAC,KAAK,IAAI,SAAS;YACjC,KAAK,EAAE,OAAO,CAAC,KAAK,IAAI,SAAS;SAClC,CAAA;IACH,CAAC;IAED,IACE,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,KAAK,SAAS,EACzC,CAAC;QACD,MAAM,IAAI,KAAK,CACb,0EAA0E,CAC3E,CAAA;IACH,CAAC;SAAM,IACL,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,KAAK,SAAS,EACzC,CAAC;QACD,MAAM,IAAI,KAAK,CACb,0EAA0E,CAC3E,CAAA;IACH,CAAC;IAED,IACE,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,CAAC,MAAM,GAAG,CAAC;QACtC,OAAO,CAAC,mBAAmB,KAAK,SAAS;QACzC,OAAO,CAAC,mBAAmB,CAAC,MAAM,GAAG,CAAC,EACtC,CAAC;QACD,MAAM,KAAK,GAAG,IAAA,kCAAO,EAAC,OAAO,CAAC,mBAAmB,EAAE;YACjD,MAAM,EAAE,OAAO,CAAC,mBAAmB;SACpC,CAAC,CAAA;QAEF,IAAI,KAAK,EAAE,CAAC;YACV,CAAC;YAAA,CAAC,MAAA,gBAAgB,CAAC,mBAAmB,mCAAI,EAAE,CAAC,CAAC,IAAI,CAAC;gBACjD,IAAI,EAAE,gBAAgB;gBACtB,KAAK,EAAE,OAAO,CAAC,mBAAmB;gBAClC,KAAK,EAAE,uBAAa,CAAC,KAAK,CAAC,OAAO,CAAC,mBAAmB,CAAC;aACxD,CAAC,CAAA;QACJ,CAAC;IACH,CAAC;IAED,OAAO,gBAAgB,CAAA;AACzB,CAAC,CAAA;AA9DY,QAAA,yBAAyB,6BA8DrC"}

package/dist/extensions/metriport/ingestion/adt/__testdata__/dischargeSummaryBundle.d.ts

@@ -1,6 +1,6 @@
 import { type Bundle } from '@medplum/fhirtypes';
 /**
- * A `medical.discharge-summary` bundle: the FHIR conversion of the matching
+ * A `patient.discharge-summary` bundle: the FHIR conversion of the matching
  * source document, not the ADT Patient Encounter Bundle. It still carries the
  * Encounter for the same visit (visit number `987654321`, the one in
  * `patientAdmitBundle`) so the summary converges on the encounter the ADT

package/dist/extensions/metriport/ingestion/adt/__testdata__/dischargeSummaryBundle.js

@@ -2,7 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.dischargeSummaryBundle = void 0;
 /**
- * A `medical.discharge-summary` bundle: the FHIR conversion of the matching
+ * A `patient.discharge-summary` bundle: the FHIR conversion of the matching
  * source document, not the ADT Patient Encounter Bundle. It still carries the
  * Encounter for the same visit (visit number `987654321`, the one in
  * `patientAdmitBundle`) so the summary converges on the encounter the ADT

package/dist/extensions/metriport/ingestion/adt/metriportAdt.js

@@ -35,7 +35,7 @@ const displayOf = (concept) => { var _a, _b, _c; return (_c = (_b = (_a = concep
 exports.metriportAdt = (0, extensions_core_1.withSettings)().endpoint({
     key: 'metriportAdt',
     title: 'Metriport ADT notifications',
-    description: 'Receives Metriport real-time patient notifications. Handles `patient.admit`, `patient.transfer`, `patient.discharge` and `medical.discharge-summary`, downloading the FHIR bundle each points at; any other notification type is acknowledged without producing a record.',
+    description: 'Receives Metriport real-time patient notifications. Handles `patient.admit`, `patient.transfer`, `patient.discharge` and `patient.discharge-summary`, downloading the FHIR bundle each points at; any other notification type is acknowledged without producing a record.',
     source: 'webhook',
     // TODO: enable verification after the pre-release: `import { verify } from './verify'`
     // and set `verify` here. The verifier and its tests are kept in verify.ts.

package/dist/extensions/metriport/ingestion/adt/schemas.d.ts

@@ -44,7 +44,7 @@ export declare const adtRecordSchema: z.ZodObject<{
         "patient.admit": import("../../webhooks/types").MetriportWebhookType.PatientAdmit;
         "patient.discharge": import("../../webhooks/types").MetriportWebhookType.PatientDischarge;
         "patient.transfer": import("../../webhooks/types").MetriportWebhookType.PatientTransfer;
-        "medical.discharge-summary": import("../../webhooks/types").MetriportWebhookType.DischargeSummary;
+        "patient.discharge-summary": import("../../webhooks/types").MetriportWebhookType.DischargeSummary;
     }>;
     messageId: z.ZodString;
     externalId: z.ZodString;

package/dist/extensions/metriport/webhooks/realtimeUpdate.js

@@ -47,7 +47,7 @@ const dataPoints = {
 };
 exports.realtimeUpdate = {
     key: 'realtimeUpdate',
-    description: 'Starts a care flow when Metriport sends a real-time patient notification. Enrolls on `patient.admit`, `patient.discharge`, `patient.transfer` and `medical.discharge-summary`, which share one payload shape; the `eventType` data point carries the Metriport webhook type so it can be distinguished on. Any other notification type is acknowledged with a 200 without enrolling. The FHIR bundle is not fetched here — the pre-signed URL is passed on the `bundleUrl` data point and can be retrieved later with the "Get Webhook Bundle" action.',
+    description: 'Starts a care flow when Metriport sends a real-time patient notification. Enrolls on `patient.admit`, `patient.discharge`, `patient.transfer` and `patient.discharge-summary`, which share one payload shape; the `eventType` data point carries the Metriport webhook type so it can be distinguished on. Any other notification type is acknowledged with a 200 without enrolling. The FHIR bundle is not fetched here — the pre-signed URL is passed on the `bundleUrl` data point and can be retrieved later with the "Get Webhook Bundle" action.',
     dataPoints,
     onEvent: async ({ payload: { payload, rawBody, headers, settings, endpoint }, onSuccess, onError, helpers: { rateLimiter }, }) => {
         var _a, _b, _c;

package/dist/extensions/metriport/webhooks/types.d.ts

@@ -18,7 +18,7 @@ export declare enum MetriportWebhookType {
      * Discharge summary notification. Undocumented by Metriport, but delivered
      * with the same envelope and payload as the `patient.*` family.
      */
-    DischargeSummary = "medical.discharge-summary"
+    DischargeSummary = "patient.discharge-summary"
 }
 /**
  * Metadata present on every Metriport webhook request.

package/dist/extensions/metriport/webhooks/types.js

@@ -21,6 +21,6 @@ var MetriportWebhookType;
      * Discharge summary notification. Undocumented by Metriport, but delivered
      * with the same envelope and payload as the `patient.*` family.
      */
-    MetriportWebhookType["DischargeSummary"] = "medical.discharge-summary";
+    MetriportWebhookType["DischargeSummary"] = "patient.discharge-summary";
 })(MetriportWebhookType || (exports.MetriportWebhookType = MetriportWebhookType = {}));
 //# sourceMappingURL=types.js.map

package/dist/extensions/metriport/webhooks/validation.zod.d.ts

@@ -47,7 +47,7 @@ export declare const realtimeNotificationSchema: z.ZodObject<{
             "patient.admit": MetriportWebhookType.PatientAdmit;
             "patient.discharge": MetriportWebhookType.PatientDischarge;
             "patient.transfer": MetriportWebhookType.PatientTransfer;
-            "medical.discharge-summary": MetriportWebhookType.DischargeSummary;
+            "patient.discharge-summary": MetriportWebhookType.DischargeSummary;
         }>;
     }, z.core.$strip>;
     payload: z.ZodObject<{

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awell-health/awell-extensions",
-  "version": "2.1.185",
+  "version": "2.1.187",
   "packageManager": "yarn@4.5.3",
   "main": "dist/src/index.js",
   "repository": {