EWA Release 40.8.0
Version 40.8.0 stable: Component Versions
Version 40.8.0 stable of EWA was released to customers on 1st October 2026.
| Component | Version |
|---|---|
| Chat Server | 26.8.274.0 |
| Chat Service (Chat v2) | 0.14.0 |
| Client Application | 26.9.46.0 |
| Client Hub | 26.9.241.0 |
| Data Warehouse Export Service | 26.9.222.0 |
| EOC Integration | 26.9.222.0 |
| Export Service | 26.9.231.0 |
| Insights API | 26.9.223.0 |
| Form Module API | 26.8.4 |
| HP Link Patient Identity API | 26.9.231.0 |
| Insights Web | 26.9.231.0 |
| LiveView API | 26.9.222.0 |
| Medical Unit Broker | 26.5.13.0 |
| Migration and Seeding Tool | 26.9.222.0 |
| Personnel Registration API | 26.8.1.0 |
| Version Manager API | 26.9.72.0 |
| Version Manager Client Installer | 26.9.78.0 |
| EWA Multiplatform Client | 0.0.5385 |
| EWA Multiplatform IIS | 0.0.5385 |
Version 40.8.0 stable: New Features
- Image tags for gallery attachments
- Multiple RETTS triages per record
- EWA Multiplatform is registered by the migration tool
- Consultation chat v2 in Insight
- Chat v1 and chat v2 coexist, with v2 taking precedence
- Archived chat v1 messages are visible on the record
- EWA Multiplatform: manual export over REST
- EWA Multiplatform: invite catalog on the device
Image tags for gallery attachments
Photos taken in the EWA gallery can be tagged, and the tags travel with the attachment into Insight and LiveView.
The predefined tag list is an Insight JSON dataset (ImageTags) rather than a list hardcoded in
the app, so a customer-specific list can be introduced without a client release, and the labels stay
translated per device locale.
- Administrators edit the list in the dataset editor, gated by the
Dataset v2feature like the other JSON datasets. A fresh installation is pre-filled with six default tags labelled in German, English, French, Luxembourgish, Dutch and Norwegian. - Each tag carries an id, per-locale labels, a severity and an icon. The editor validates the document against the schema and rejects duplicate ids, missing English labels, blank labels and icon names outside the supported set.
- The tags the crew saw at tagging time are stored on the attachment, so a later edit of the dataset does not rewrite history.
- The Insight journal view and LiveView return the tags per gallery image, and the photo viewer shows them as severity badges with the label as text. Icons are stored but not rendered in Insight yet, which needs the icon font.
Database change: a nullable Tags column is added to dbo.JournalAttachments by migration
202609031107390_AddJournalAttachmentTags, which also re-creates the attachment insert and update
procedures.
Affected components: Insight Web, Client Hub, Migration and Seeding Tool, EWA Multiplatform
Multiple RETTS triages per record
Until now a record could show at most two RETTS triages, because a triage was identified by the
triage_1 / triage_2 update field and only those two fields exist. A record could already hold
more, and the extra ones were invisible.
- New feature flag:
MultipleTriagesis added to Insight → Administration → Features at Release Candidate state, activatable per resource, with labels and descriptions in all five shipped languages. It is visible only to administrators holding theManageReleaseCandidateFeaturespermission. - Record page: with the flag on, the Triage 1 and Triage 2 tiles are replaced by a single Triages tile listing every triage on the record in a read-only accordion. Each row header shows the triage number, time and risk badge, and the most recent triage opens expanded. The tile appears under exactly the conditions the Triage 1 tile does today, and a mission type that marks triage mandatory still validates it on completion. With the flag off, nothing changes.
- Client Hub: triage updates are now keyed by the triage type in the update payload rather than by the field suffix, so a client can send any number of triages and all of them are stored. Existing clients, which only ever send types 1 and 2, keep storing at most two, with no version switch involved.
Affected components: Insight Web, Client Hub
EWA Multiplatform is registered by the migration tool
This change supports the new EWA Multiplatform application and its use of the Version Manager feature.
The product row ships as a migration inside the Version Manager persistence package, and the migration tool takes that package by pin, so until the pin moved a customer running the tool got no Multiplatform row at all.
Verified against a real database: running the migration tool applies the pending migrations and creates exactly one Multiplatform product row, and a second run changes nothing.
Installation: to deploy EWA Multiplatform to Windows devices through Version Manager, follow the Multiplatform Version Management Guide.
Affected components: Migration and Seeding Tool, Version Manager, EWA Multiplatform
Consultation chat v2 in Insight
Where it appears:
- LiveView journal panel: the chat island mounts writable, resolved to the mission thread by journal id. Records that are not linked to a thread show localized "not available" copy.
- Record page, Consultation History tab: the same island mounts read only (no composer, no read receipts) on both Journal → View and Journal → Edit. Chat is only ever written from a LiveView.
The new chat service is hosted by Insight behind an authenticated /chat-api reverse proxy. The chat service has no ingress
of its own, so its API key never leaves the cluster.
The server determines who a user is by reading and verifying secure credentials, rather than trusting a user ID sent by the client. The proxy rewrites the sender, the read receipts and the inviting user from the authenticated session, so a browser cannot post, acknowledge or invite in someone else's name, and no e-mail identifiers reach chat event payloads.
Behaviour included in this version:
- Invite catalog in the island's picker: every consultation group plus every location covered by at least one active LiveView, so a location is invitable before any destination is selected.
- Board discoverability: consultation locations are always included on the LiveView overview board. Previously a pure chat v2 installation granted journal access without the journal ever appearing on the board, so an invited team could open the journal but never find it.
- Message order: threads are sorted by sent time with a stable tie break, so Insight, the record page and the device app all agree. Previously the islands rendered database key order.
- 2000 character message cap, enforced server side and surfaced in the composer with a near-limit counter placed below the input. Existing messages are unaffected.
- Projection self healing: events the projector skips are recorded and replayed at startup, so a later code change can heal a gap instead of it being permanent.
Feature flag: enable Consultation in EWA Client [Release Candidate] for the resource in use in
Insight → Administration → Features for the chat v2 service to work. The flag gates the island on
both pages and the tab header. Enabling it requires the ManageReleaseCandidateFeatures permission.
Installation: on-premise customers install the chat service as described in the
Chat v2 service - Installation Guide.
When updating Insight Web to 40.8.0, set its two new install parameters in
Bliksund.EWA.Insights.Web.SetParameters.xml:
ChatV2 Endpoint: the URL of the chat service, for examplehttp://localhost/ChatV2.ChatV2 Api Key: the same value asChat Api Keyin the chat service installation.
Both default to empty. An installation without chat v2 leaves them empty, and the chat v2 route then stays off. See the Insight Web - Installation Guide.
Affected components: Insight Web, Chat Service, Client Hub, EWA Multiplatform
Chat v1 and chat v2 coexist, with v2 taking precedence
Both chat generations run side by side, decided per journal:
- LiveView: the chat v2 island renders when Consultation in EWA Client [Release Candidate] is on and chat v2 is configured;
otherwise the v1 consultation panel renders as before, gated by
LiveViewConsultationplus an existing chat session. - Record View/Edit: the Chat History tab shows when the record carries either generation.
LiveViewConsultationandVideoStreamForConsultationare back at Release state, so they can still be enabled on new resources. An earlier change had marked them deprecated, which blocked that.
Affected components: Insight Web, Client Hub
Archived chat v1 messages are visible on the record
Chat v1 messages are not migrated into chat v2. Instead the record page renders them directly in a clearly labelled archived consultation section below the chat v2 island, with sender, timestamp and text, and with join events shown as muted system lines. Access control is the record page's own, not chat v1's session model, and no chat service or chat auth cookie is involved.
New localized strings are provided in English, Danish, German, Norwegian and Swedish. Installations that never deployed chat v1 are unaffected: the read is guarded, so a database without the chat v1 tables keeps working.
Affected components: Insight Web
EWA Multiplatform: manual export over REST
Client Hub now exposes manual export to the Multiplatform client over REST, in addition to the existing SignalR hub that the UWP client uses:
POST api/journal/{journalId}/manual-exportstarts a manual export and returns the accepted targets with their initial status.GET api/journal/manual-export/status?journalIds=[...]returns the per-target statuses of several journals in one database query.
The Multiplatform client has no SignalR client, and a second long-lived connection was rejected on
architectural grounds. The hub and its emitter are untouched, so the UWP client is unaffected and
both paths coexist. Authorization is the same EWAClientAccess policy the hub uses.
The status endpoint deliberately returns 200 with an empty array rather than 404 when nothing
matches, because the Multiplatform client polls it roughly every ten seconds while a share is
outstanding.
Affected components: Client Hub, EWA Multiplatform
EWA Multiplatform: invite catalog on the device
A new Client Hub endpoint, api/v1/chatParticipantCatalog, serves the chat v2 invite catalog to
devices in the same shape Insight's picker uses: every consultation group plus every distinct
non-deleted location covered by an active Patient Reception LiveView configuration.
The Multiplatform invite picker works offline from a locally synced candidate list, and the device
cannot work out which locations an active LiveView covers. Until now the device could therefore only
offer consultation groups while Insight offered locations as well. Older Client Hubs degrade
gracefully: the device falls back to the consultation recipients endpoint on 404.
Affected components: Client Hub, EWA Multiplatform
Version 40.8.0 stable: Fixes
- Hidden mandatory fields blocked journal completion after the mission type was changed
- Saving a personnel change threw the user back to journal search
- Could not switch resource after completing a record with extended offline mode
- Missing kilometre header in the EMCC update popup
- An EMCC update crashed the client
- Live View kept showing a record that could no longer be opened
- Audit log paging timed out on month-wide date ranges
- Drug administrations still stored the performer type as "Acctive"
- A PDF exported to DIPS could contain another mission's content
Hidden mandatory fields blocked journal completion after the mission type was changed
- Ticket: 427702495427 | DevOps: 41285 | Reported by: Sykehuspartner / Helse Sør-Øst, on 40.2.11 and 40.2.12 in production
- HubSpot Title: EWA 40.2.11 - Endring av oppdragstyper - Felter/skjema forblir obligatoriske selv om de ikke lenger er synlige i journal
- Issue: A form triggered under one mission type, for example the cardiac arrest form triggered by "Hjertestans med ROSC", kept blocking journal completion after the mission type was changed to one that hides the tile, such as "Ingen pasient/avbrutt". The crew got a mandatory-field warning for a field that is nowhere on screen, and had to switch the mission type back and forth to get out of it.
- Root cause: Completion validation and tile visibility used two different rules. Visibility asked whether the mission type enables the field; validation combined a sticky "form is required" flag on the journal with the mission type's required rule, and never asked whether the field was enabled at all. Nothing releases the sticky flag when the mission type changes, so it survived into a mission type that hides the tile.
- Solution: Completion validation now only requires the cardiac arrest form when the current mission type enables the field, matching the rule already used for the chart. The only outcome that changes is the reported case, a field the mission type disables. A mission type that genuinely requires the form still blocks completion when it is unfilled.
Affected components: Client Application (Windows / UWP)
Saving a personnel change threw the user back to journal search
- Ticket: 430495664362 | DevOps: 41361 | Reported by: Helse Vest
- HubSpot Title: Får ikke endret personell fra Insight
- Internal Reference: PT-182
- Issue: In Insight, with New personnel registration [Release Candidate] switched off, saving a change on the Personnel tile discarded the change and returned the user to Journal → Search.
- Root cause: The dialog's script looked the form up under the wrong identifier, so no save handler was ever bound. The save fell through to a plain browser form submission, which rewrote the page's query string and made the journal controller redirect to Search.
- Solution: The script now uses the identifier the view actually renders, a missing driver no longer breaks the save, and a stale mandatory-driver rule was removed so a change to the attending clinician alone can be saved on a journal with no driver. A test pins the contract between the view and the script.
Affected components: Insight Web
Could not switch resource after completing a record with extended offline mode
- Ticket: 367245007052 | DevOps: 29955 | Reported by: Helse Sør-Øst
- HubSpot Title: Får ikke byttet ressurs
- Internal Reference: PT-166
- Issue: With Extended offline mode enabled, completing a record and waiting for it to reach the Completed column left the user unable to switch resource. The client kept showing "not allowed to switch resources with ongoing records" even though no record was ongoing. The known workarounds were to restart the app, lock and unlock the device, or start and delete a manual mission.
- Root cause: The overview page cached the blocking message on the resource button when the page was opened. Under extended offline mode, completing a record only signs it, so the record still counted as ongoing at that moment and the message was cached. The record turned completed later, from a sync, and nothing refreshed the cached state.
- Solution: The guard is no longer cached. It is evaluated when the button is tapped, against the live record state. A record that is still genuinely ongoing still blocks switching resource.
Affected components: Client Application (Windows / UWP)
Missing kilometre header in the EMCC update popup
- Ticket: 410351321335 | DevOps: 38576 | Reported by: Helse Nord
- HubSpot Title: Bliksund EWA, oppdatering av KM flis
- Issue: The EMCC/AMK update popup showed
{Not Found}as the label of the kilometre row. The value itself was correct. - Root cause: That one row resolved its label through a view-bound lookup while every sibling row used the view-independent one. Update items are built on the background polling thread, where there is no current view, so the lookup failed and the placeholder was shown. The translation itself was never missing.
- Solution: The kilometre header is resolved the same way as every other header in the popup.
Affected components: Client Application (Windows / UWP)
An EMCC update crashed the client
- Ticket: 432680066288 | DevOps: 43473 | Reported by: Helse Sør-Øst
- HubSpot Title: App-krasj hjertestansregistrering
- Internal Reference: PT-184
- Issue: Receiving an EMCC/AMK update on an open mission could crash the UWP client, and the update was lost.
- Root cause: After fetching the update, the client applied it to the mission from a background thread. The mission's latest update is bound to the Sign and Export button, and touching it off the UI thread throws. The failure was unhandled, so it terminated the process.
- Solution: The update is applied on the UI thread, and a future failure in this path is observable instead of ending the process.
Affected components: Client Application (Windows / UWP)
Live View kept showing a record that could no longer be opened
- Ticket: 417426323682 | DevOps: 39231 | Reported by: Helse Nord
- HubSpot Title: Sanntidsskjerm, oppdragsheng etter bytte av oppdragstype
- Internal Reference: 308
- Issue: Changing a record's mission type to one without a delivery place tile, for example from Ordinary to Patient without transportation, left the card on the Live View board. Opening it returned 403.
- Root cause: Clearing the delivery place removes the record's destination, which correctly revokes the Live View's access. The board, however, only re-evaluated records that still had at least one location, so a record left with none was never pruned and stayed until the 24 hour idle sweep.
- Solution: Every updated record is re-evaluated, including one with no locations left, so the card disappears on the next board refresh (about 20 seconds).
Affected components: LiveView API
Audit log paging timed out on month-wide date ranges
- Ticket: 430177669317 | DevOps: 41517, 41627
- HubSpot Title: EWA 40.2.X - heng og feilmeldinger ved søk i brukeraktivitetslogg
- Issue: Paging through Insight → Audit log over a wide date range, such as a whole month, failed with a gateway timeout.
- Root cause: Each page request counted the total by loading every matching audit log id into memory.
- Solution: The total is counted in the database. The returned total is unchanged.
Affected components: Insights API
Drug administrations still stored the performer type as "Acctive"
- Ticket: 431221829860 | DevOps: 43476 | Reported by: Helse Nord
- HubSpot Title: Analytics - records_drugs
- Issue:
records_drugs.given_by_typein the data warehouse still held the misspelled valueAcctiveinstead ofActivefor drug administrations. - Root cause: A data correction written in 2020 to fix the stored value in journals was never registered with the migration pipeline, so it never ran on any installation.
- Solution: The correction is registered and triggered by a new migration,
202609141020000_RerunFixTypoInPreformedByOnDrugs. It edits the stored journal content in place, only on journals that carry the typo, and changes only the corrected value. - Note: analytics rows derived from these journals are refreshed on their normal schedule, not immediately, because the correction does not change a journal's last updated time.
Affected components: Migration and Seeding Tool
A PDF exported to DIPS could contain another mission's content
- Ticket: 423763912939 | DevOps: 40639 | Reported by: Helse Nord
- HubSpot Title: Eksport av journal til DIPS
- Issue: A PDF exported to DIPS contained content from a different mission.
- Root cause: The native PDF engine is created once per process and reused for the life of that process, and it can carry residue from one conversion into the next. Disposing and recreating the converter inside the same process corrupts output deterministically and then crashes, and a second instance hangs the first conversion. Only process exit resets the engine.
- Solution: Every PDF is now rendered by a process created for that one document, which then exits. In addition, each render injects begin and end markers carrying a per-render identifier as the first and last body elements, and the result is rejected unless each marker appears exactly once, the begin marker is on the first page and the end marker is on the last page. Engine residue pushes the end marker off the last page, which is exactly the observed failure shape.
- Also fixed: a broken pipe to the render process now reports its exit code and standard error
instead of surfacing as a bare
IOException. Every real journal is large enough that production always took the path where all diagnostics were lost. - Scope: Export Service only. Client Hub, Insight Web and the SATS to DIPS re-exporter keep the in-process converter and follow in a later release, Insight Web first.
Affected components: Export Service
EWA Multiplatform status
40.7.0 delivered the first Multiplatform client to a health trust for testing, on Windows 11 only. That prerequisite is unchanged in 40.8.0.
Upgrading an existing Multiplatform installation
A customer that has already installed the Multiplatform application must uninstall it and install the new version for this release, rather than upgrading in place.
40.8.0 changes the SQLite engine the application stores its local data with, to prepare the local database for encryption.
On every device running the Multiplatform application, in this order:
- Complete all ongoing missions on the device.
- Confirm the data has been transferred to the server, so that every completed mission is visible in Insight.
- Uninstall the Multiplatform application.
- Install the 40.8.0 version of the Multiplatform application.
Uninstalling removes the local data on the device, so a mission that has not reached the server before step 3 is lost.
Two of the parity gaps listed in 40.7.0 have moved:
- Chat consultation is now served by chat v2 on both Insight and the Multiplatform client, including invites to consultation groups and to locations covered by an active LiveView. Chat v1 continues to work as before in the UWP client.
- Image tagging is delivered, with the tag list driven by the
ImageTagsInsight dataset and the tags stored on the attachment. The part of the original design where a tag switched on Billable mission was dropped by decision on both the device and the dataset, so that coupling does not exist in any client. Confirm with the Multiplatform team before publishing whether this closes the "Paid mission with image tagging" gap or narrows it.
Cardiac arrest in the Multiplatform application
The Multiplatform application has no dedicated cardiac arrest form. Cardiac arrest is captured through Forms instead, so a health trust that needs one builds it as a form and it behaves like any other form: it is configured, versioned and reported on through Forms.
What follows from that, for the Multiplatform application only:
- Cardiac arrest trigger configuration does not apply. There is no dedicated form for a mission type or an assessed condition to trigger.
- The cardiac arrest report page does not apply. Cardiac arrest data captured in a form is reported on through Forms.
- The dedicated cardiac arrest section in the record view and edit pages will be removed in a future release for records created in the Multiplatform application, since those records never carry the dedicated form.
None of this affects the UWP client application. Records created there keep the dedicated cardiac arrest form, its trigger configuration, its report page and its section on the record pages, exactly as before.
Remaining known parity gaps:
- Tile helper texts
- The billable mission report page does not list completed missions created in the Multiplatform application. Missions created in the UWP client are listed as before.
- The billable mission checkbox on the patient tile is not triggered by the ID type. Making that trigger configurable is planned for a future release.
- EtCO2 is displayed in mmHg rather than kPa. Displaying it in kPa is planned as a feature update in a future release.
- The Via, Trauma, Transferred from and Transferred to tiles are not displayed in the Multiplatform application. They will be added in a future release.
✅ Testing Focus Areas for 40.8.0
🏷️ Image tags
- Confirm the
ImageTagsdataset appears in the dataset editor on an installation with Dataset v2 enabled, pre-filled with the six default tags on a fresh installation - Edit the list, save, and confirm the device offers the edited tags without a client release
- Confirm the editor rejects a duplicate tag id, a missing English label and a blank label
- Open an existing dataset that still carries the old billable field and confirm it validates and saves unchanged
- Tag a photo on the device, then confirm the tags appear on that image in the Insight journal view and in LiveView, as severity badges with the label as text
- Change the dataset after tagging and confirm the already-tagged attachment still shows what the crew saw at the time
- Confirm tagging an image does not change the billable state of the mission
- Confirm the attachment migration applies cleanly and that uploading and editing attachments still works afterwards
🚑 Multiple triages
-
Confirm
MultipleTriagesappears in Insight → Administration → Features for an administrator holding the manage-release-candidate permission. -
With the flag on, open a record holding three or more triages and confirm the single Triages tile lists all of them, read only, with number, time and risk badge, and the most recent expanded
-
With the flag off, confirm the Triage 1 and Triage 2 tiles are shown exactly as in 40.7.0
-
On a mission type that marks triage mandatory, confirm completion is still blocked when no triage is present
-
From the UWP client, update triage 2 on a record with no triage 1 and confirm the update is stored
-
Confirm the UWP client still stores and shows at most two triages
⚡ EMCC update crash
- Send a full AMK simulation from Insight, open the mission in the UWP client, send a new update, and confirm the client keeps running and the update is applied
🗺️ Live View pruning
- Set a Live View location as the delivery place on a record and confirm the card appears on the board
- Change the mission type to one without a delivery place tile and confirm the card disappears within about 20 seconds, and that no 403 is returned
📜 Audit log and Client Hub logging
- Page through Insight → Audit log with a month-wide date range and confirm pages load and the total is correct
- Confirm Client Hub log files rotate and stay bounded, and that a resend of already stored audit entries writes one summary line per request
💊 Drug performer type correction
- On a database with journals carrying
Acctive, run the migration and confirm the value becomesActive, and that no other journal content (vital signs, administration times) changes - Confirm journals without the typo are untouched
🏢 Chat v2 on-premise
- Install Insight Web through WebDeploy with ChatV2 Endpoint and ChatV2 Api Key set and
confirm the chat panel works through
/chat-api - Install with both left empty and confirm Insight Web starts and behaves as without chat v2
- Confirm chat pods pass their health probes without restarting, and that the chat island bundle is served from browser cache on a second journal open
🩺 Journal completion after a mission type change
- Trigger the cardiac arrest form under a mission type that requires it, then change the mission type to one that hides the tile, and confirm the journal completes with no warning about unfilled fields
- On a mission type whose mask requires the cardiac arrest field, confirm an unfilled form still blocks completion
🧑🚒 Personnel save in Insight
- With New personnel registration [Release Candidate] switched off, change an attending clinician on the Personnel tile and save; confirm the dialog closes, the journal stays open and the change persists
- On a journal with no driver, change only the treater and confirm it saves with no validation block
- Confirm the same flow with the feature on is unaffected
🔁 Switching resource with extended offline mode
- With Extended offline mode enabled, complete a record, wait for it to reach the Completed column, then tap the resource button and confirm the resource list opens with no error
- With a record still ongoing, confirm the error still appears and the list does not open
- Start a record, delete it from Insight, close the message in the client, then switch resource, and confirm the list opens
- Repeat the first check without the feature flag
📏 EMCC update popup
- Send an update containing kilometre data to a resource in use and confirm the kilometre row shows
its localized label rather than
{Not Found}, with the value unchanged
💬 Consultation chat v2
- With Consultation in EWA Client [Release Candidate] enabled on a resource, open a LiveView journal panel and confirm the chat island renders and a message can be sent
- Confirm the sent message flips from pending to sent without a page refresh, and within about a second
- Send a message from the Multiplatform client and confirm it appears live in the Insight island
- Open the same record in Journal → View and Journal → Edit and confirm the Consultation History tab shows the island read only, with no composer
- Confirm messages are displayed in sent order on Insight, on the record page and on the device, and that all three agree
- Type past 2000 characters in the composer and confirm typing is blocked and the counter warns before the limit
- Open an unlinked record and confirm the localized "not available" copy is shown rather than an error
👥 Invite catalog and board discoverability
- In Insight, open the invite picker and confirm it lists consultation groups and locations covered by an active LiveView, before any destination is selected
- Repeat on the Multiplatform client and confirm both kinds are offered there as well
- Invite a location and confirm the journal appears on that location's LiveView board, and that an invited team can find it, not only open it
- Against an older Client Hub with no catalog endpoint, confirm the device falls back to consultation recipients rather than failing
🔀 Chat v1 and v2 coexistence
- With Consultation in EWA Client [Release Candidate] off and
LiveViewConsultationon, confirm the v1 consultation panel renders on LiveView exactly as in 40.7.0 - With both on, confirm v2 takes precedence on LiveView and on the record page
- Confirm
LiveViewConsultationandVideoStreamForConsultationcan still be enabled on a new resource in Insight → Administration → Features - Open a record that has chat v1 history and confirm the archived consultation section renders the old messages with sender, timestamp and text, labelled as archived
- Confirm join events render as muted system lines
- Confirm a record with both an island and archived v1 messages shows the island first and the archive below
- Confirm the archived section renders in each localized language (en, da, de, nb, sv)
- On an installation that never had chat v1, confirm the record page still opens normally
📤 PDF export
- Export several journals to DIPS in quick succession and confirm each PDF contains only its own mission's content
- Confirm a legitimate PDF containing synthesised bold text, ordered lists and CSS generated content is not withheld
- Confirm a failed render is reported with a useful error rather than a bare I/O failure
- Confirm export throughput and memory use are acceptable under a realistic export load, since each document now starts its own render process
- Confirm Insight Web printing and the SATS to DIPS re-exporter are unchanged, as they still use the in-process converter
📱 EWA Multiplatform manual export
- Start a manual export from the Multiplatform client and confirm the accepted targets and their initial status are returned
- Confirm the status is polled and updates without a hub connection, and that a journal with no export returns an empty result, not an error
- Confirm manual export from the UWP client is unchanged, since it still uses the hub
- Ask for the status of several journals at once and confirm the answer is correct
Tested Medical Devices
All versions of this release have been tested on the listed medical devices and corresponding software versions, ensuring compatibility and performance in the specified environments.
Corpuls
- Software versions: 4.4.4
- SDK version: 4.4.0.0
Zoll
- Software version: 02.36.21.00
- SDK version: 6.44.315