Email and SMS logging
This post is aimed at discussing the addition of a facility to have the system log emails and sms messages. We are currently using the trick of using gmail as as smtp server, but given our need (with multiple practice locations) to have various email 'from' addresses, the gmail trick is not ideal.
Hence, the following suggested enhancement:
- add the ability to log outgoing emails and sms messages - probably adding a new database file to do so (as I don't see that this log fits within the current database design)
- logging on/off for each of email and sms to be set at the practice location level (although in our case we would be happy with global switches at the practice level, but there may be some practices where the on/off setting needs to be done at the location level)
- log everything, ie location, from, to addresses, subject, body, and attachments
- reporting (ie examining of the log) to be done via an 'Email' addition to the Reports menu, with a suitable selection facility (ie location set by current location, type=all/email/sms), dates, subject, and to addressee), and clicking on one selected item displays the actual email/sms with links to any attachments
- access to log - I suspect that there needs to be some, but I am not sure what is best. The brute force approach would be to make Reporting|Email only available to users in the Administrator category. Archetype based access control will not work because we need everybody to be able to create entries in the log (so that emails they send are logged), but we want to control whether they can read the log - and the current archetype based system only controls create/save/delete and not read access.
I think that that covers everything. After a delay for comments I will ask Tim A to go ahead and spec and price this enhancement.
Regards, Tim G
Re: Email and SMS logging
I withdraw this post - I just found the multiple email address project - see http://www.openvpms.org/project/add-support-multiple-cc-and-bcc-addresse... - and the 'always BCC this address' facility in that provides a very good (and far cheaper) method of logging email and sms traffic. You will see that I have asked Tim A to cost this up so that we can get it done.
Regards, Tim G
Re: Email and SMS logging
Hey hey.. Hold on with the canceling there Sir!
Yes, the other project does provide a cheaper method of logging emails and SMS.
BUT
I think for us this goes to the wider issues of auditing generally and recording client communications within the medical history specifically. We would REALLY like emails and SMS sent to clients to be automatically recorded and logged within OVPMS as part of the medical history. Preferabbly we would like a "client communication" field that we can toggle on/off for display/printing purposes but is still a set part of the history.
For us this project while more costly and complex is the direction things should be heading in terms of ensuring we have a complete medical and communication record with the client within OVPMS.
Re: Email and SMS logging
Humm - Adrian - there were actually two things on the practice manager's wish-list - the 'log emails & sms msgs within OpenVPMS' and 'allow more that one To addressee'. The 'always BCC' facility in the latter, did address the first requirement, and hence my withdrawal.
However, I would agree that if one wants the client communications into the medical history, then this need is not met by the 'always BCC' facility.
I can see four areas needing clarification with saving the communications in the medical record:
a) I can see that one could add a note-like entry containing the addresses, subject, and body text, but what does one do with attachments. I suspect that the solution is to define a new document archtype for Emails and SMSs, with the Email one allowing multiple attachments.
b) whose medical record to use? The email is going to the customer, but needs to be put in the patient's record - and if the customer has multiple patients, which to use? I presume that this could be addressed by having an 'Attach to Patient' pull-down which allows one to select Fifi, Snuffles, or none.
c) as indicated above, I suspect that the 'add this to the medical records' should be an optional rather than mandatory facility - because one does not need an SMS 'Fifi resting comfortably after operation - you can pick her up at 10am' or an Email 'Remember you appointment next Tuesday at 3.15' in the medical record.
d) do things get more complicated if we move to supporting HTML format emails [a project which I think is fully funded].
Adrian - I will check with the Practice Manager, but I suspect that although she will fully support the 'multiple email addresses + always BCC', I am not sure about the 'add communications to the medical record side'.
Regards, Tim G
Re: Email and SMS logging
Hi,
How does OVPMS log the messages? How are these retrieved?
a) Not sure. Your solution seems reasonable.
b) I think the patient selection idea seems ok. Or and option to log in "customer notes and alerts?".
c) I disagree. "Fifi resting comfortably" is a clinical update and should be recorded in the history. SMS or emails about appointments are not, however wouldn't you prefer to have these in the record so someone can't come back at a later time and say "actually you told me my appointment was 8.15am"? Why not record these? What are the downsides?
d) Can't comment.
I guess I am not entirely clear how OVPMS logs messages under the proposed system and how a regular staff memeber can retrieve them/use them?
Just genreally as well we often write emails to clients. Sometimes giving them discharge instructions, sometimes instructions about patient care, billing, appointments, updates, consent forms (if they can't attend the practice). The more this information is recorded in OVPMS the better.
Re: Email and SMS logging
Adrian - the input from the Practice Manager is "I guess I was just thinking about the cheapest option - I suspect having all communications logged in the medical records would be quite a big exercise. The multiple addressess and always BCC would be a good stop-gap. I guess it depends how many people are ready to pony up and put in some cash." Regards, Tim G