List messages

The ID of the patient linked to this message.

The MessageTemplate name. There are only 2 templates available through the RESTful API. The secure template means that the patient only gets a generic message with a link to open the patient web app and then read the real message. In that case, there are 2 messages, one with that generic message, and one with the real message. This parameter is set automatically on the message, depending on the secure parameter which was chosen when the message was created.

the phone number or e-mail address from whom this message was received. It depends on the value of the parameter channel.

the phone number or e-mail address to whom this message was sent. It depends on the value of the parameter channel.

Indicates if a message was sent from Luma to an external person, or the other way around.

voiceAnsweredBy

Indicates what this message is about. Depending on this value, you also know what the parameter refId refers to.<br/>

• reminder (refId will be the ID of a Reminder)<br/>
• referral-reminder (refId will be the ID of a Reminder)<br/>
• feedback-reminder (refId will be the ID of a Reminder)<br/>
• followup (refId will be the ID of a Reminder)<br/>
• outbound-referral-reminder (refId will be the ID of a Reminder)<br/>
• form-reminder (refId will be the ID of a Reminder)<br/>
• reschedule (refId will be the ID of a Reminder)<br/>
• waitlist (refId will be the ID of a Waitlist)<br/>
• appointment-offer (refId will be the ID of a Offer)<br/>
• chat-notification (refId will be the ID of a Message)<br/>
• pin-verification (refId will be the ID of a Message)<br/>
• chat (refId will be the ID of a Message)<br/>
• chat-audit (refId will be the ID of a ChatActivity)<br/>
• chat-audit-tz (refId will be the ID of a ChatActivity)<br/>
• feedback (refId will be the ID of a Feedback request)<br/>
• waitlist-offer (refId will be the ID of an Appointment)<br/>
• referral-followup (refId will be the ID of a Referral)<br/>
• outbound-referral-outreach (refId will be the ID of a Referral)<br/>
• referral-redirect (refId will be the ID of a Referral)<br/>
• broadcast (refId will be the ID of a Broadcast)<br/>
• generic (refId will refer to the same object of the previous message to this same patient)<br/>
• stop (refId will refer to the same object of the previous message to this same patient)<br/>
• bot:followup (refId will be the ID of a Patient)<br/>
• telehealth (refId will be the ID of a Telehealth object)<br/>
• waiting-room-patient (refId will be the ID of a WaitingRoomPatient object)<br/>

The ID of the object referenced by the ref parameter.

The ID of a Hub Message Template (or PatientMessageTemplate). These are custom messages, created by users, to make their typing experience easier.

This field is only present on a patient's reply (aka messages whose type are inbound) so as to link it to the original outbound message that was sent to them.

The deliverability status, provided by Luma's external vendors.<br/> Messages are initially created as sent, and later updated to some other status.<br/>

• Sent = vendor has acknowledged receipt of request<br/>
• Pending = vendor has sent non-terminating status update<br/>
• Delivered = vendor has confirmed a delivered message<br/>
• Undelivered = vendor has confirmed an undelivered message<br/>
• Opened = vendor has confirmed an opened message<br/>
• Skipped = system skipped sending the message<br/>

Delivery status codes and messages provided by external vendors. <br/> code : Status code provided by vendor <br/> reason : Status message provided by vendor

This field is only present on messages whose status is skipped. It contains the reason why Luma decided to skip sending the message out.

The channel used to send this message.<br/> On our RESTful API, you may search for multiple channels, but only POST chat messages.<br/> Two of them deserve an explanation:<br/>

• chat will check the recipient's contact and pick the channel automatically.<br/>
• inapp are meant for internal messages, when a staff user @mentions another staff user on Hub. The mentioned person only gets a notification on their browser window, by fetching from the notifications API.

The content of the message. If the channel was chat, then the text was manually provided when the message was created. For all other channels, the key was used to fetch a messageTemplate and determine the text based on that template.

The classification of patient replies (inbound messages) interpreted by our NLP (Natural Language Processing) service.<br/>

• positive indicates a yes-type answer (e.g. "sounds good", "yes", or "ok")<br/>
• negative indicates a no-type answer (e.g. "no way", "negative", "no good")<br/>
• irregular indicates classification attempt was not able to classify the text as positive or negative<br/>
• recognized-keywords indicates that an expected keyword was identified (e.g. "waitlist")<br/>
• unclassified indicates no classification attempted - yet<br/>

Indicates how a message with channel chat will be delivered.<br/> Secure messages are created on the database but not really sent to patients. Instead, we create another unsecure message whose content is the messageTemplate chatRequestInsecure, which basically instructs the patient to click on a link to open patient-web-app to log in and then read the secure message. Insecure messages are sent directly to patients. Their text should not contain any PHI or sensitive information.

Indicates if a message was created by users (chat) or by the system (reminders, recalls, etc).

Helps determine where a certain message should be displayed.

• public = manual and automated messages sent to patients, visible to patients logged into our patient web app;<br/>
• private = automated messages sent to staff, only visible to one recipient staff user;<br/>
• internal = manual messages sent from staff to staff, visible to both staff users involved in a conversation, whenever one @mentined the other, both logged into our internal web app, and usually on Hub rather than any notification areas.<br/>

The ID of a FileUpload, in case this message has any attachment, sent via the FileUpload RESTful API.

The ID of the User receiving the message. Usually, for messages type outbound, the recipient is the ID of a patient.

The type of the user in the field recipient

When the patient has the patient web app open, we detect that and only send messages through the web interface. This is to avoid having the patient receive the same message both on the web and also by SMS. But if this flag is set to TRUE, then we will send to the contact specified in the notifyTo field, regardless of the patient's online presence.

ID of Appointment

ID of Provider

ID of AppointmentType

ID of Followup, or Custom Action.

ID of Recall

ID of Referral

ID of MessageFailure

An _id or array of _ids separated by comma. Filters by message.facility within the facilities from the specified groups

Language code.

The ID of the user who created this object.

The ID of the user who updated this object.

The date/time when this object was created.

The date/time when this object was updated.

How many items to fetch per page

Response properties which will be replaced by the referenced objects, separated by commas.

Response properties that should be returned, separated by commas.