Chat & video calls

When a conversation about a record happens somewhere else - a messaging app, a personal phone, a separate video product - two things follow. The organisation loses the conversation, and it loses control of what was disclosed in it.

The realtime communication module puts messaging, voice and video inside the system that already holds the record and already knows who each person is.

Messaging

One-to-one and group conversations, with history retained and searchable. Messages carry file attachments, and long messages are handled sensibly rather than dumped into a wall of text.

Because it runs inside the deployment, a conversation can be tied to the record it is about - a case, a patient, a requisition - so the discussion is visible to whoever picks the record up next, and invisible to everyone else.

Presence shows who is currently available, which is the difference between a message and a message somebody will actually see.

Voice and video

Peer-to-peer voice and video calling in the browser, for remote consultation, case review and support. It is the capability behind telemedicine use, where a clinician and a patient need to see each other and the clinician needs the record open at the same time.

Media flows directly between participants where the network allows it, which keeps quality reasonable on constrained connections and means call content is not accumulating on an intermediate server.

Why in-platform rather than a third-party product

The honest comparison, since a general-purpose video product is usually cheaper per seat:

• Identity is already established. Participants are authenticated users of the deployment, with the permissions they already hold. There is no second directory to keep in step and no invite link that works for whoever holds it.
• The conversation stays with the record. Nothing has to be copied back in afterwards, and nothing quietly stays outside.
• Disclosure stays inside the boundary. For deployments handling clinical or financial information, the organisation can say where conversation data went, and answer for it.
• Access ends when access ends. Someone who leaves loses conversation access along with everything else, in one action.

Deployment notes

Realtime features need a persistent connection between browser and server, which is a different requirement from ordinary page traffic. Two things to establish early in an evaluation:

• Whether the hosting arrangement permits persistent connections, and whether the network between participants allows direct media. Restrictive corporate networks sometimes do not, and relay provision has to be planned rather than discovered.
• What the retention rule is for conversation history and any recording. This is a policy decision the organisation owns; the module enforces what it is told.

Where it fits

Conversation is most useful attached to work: a case in workflow, a record under review, a query on a transaction. Notification of messages follows the same routing as the rest of the platform, so people are told once rather than by four different mechanisms.