This is a great program. I am a healthcare provider. The fact is that law HIPPA actually requires that healthcare providers have a client portal with private secure messaging. It is a requirement that providers have been slow to jump on and it is the law. This application comes close to meeting the needs but it is not quite there yet. So far I see four things missing:
Purge posts: Posts should be able to be completely purged from the database once all participants have deleted the post. This is important because we do not want too much patient information accessible on a public website even if it is password encrypted. It increases confidentiality and decreases risk of exposure. I am just going to write a custom function to search and purge but why not just make it part of the program. I am storing messages off site behind a VPN.
Two way only communication: We can almost do this by unselecting “Can users send message to other users” and selecting “Can users send message to admin” in the pro version (well worth the $29). Problem 1: If “Can admin send new message to other users” is selected admin can add more than one client/patient to the post. Legally this should only happen if both parties have signed a consent for release of information. That is hard to track. Also, even if no protected healthcare information is being shared in this way and you want to take the risk, the email addresses or client id’s are visible to all users and that is a breach of confidentiality. So, clinicians are taking a risk if they add more than one participant to the post and in a clinic it would be best to restrict this to just two way communication. Problem 2: If “Can admin send new message to other users” is unselected then admin can select to send a message to a patient by using the directory. In this case one patient/client only can be selected, which is good. However in the send page only the subject field is visible in this case. It would be best to have a non editable To: field with the name of the individual we are sending to if this were to be the solution. So, some way to force two way communication only that adds either of these features would be best.
Options for name: I understand the architecture of the program and the use of display_name as the standard. I know that there are workarounds to allow for other variations such as using the first-last plugin. But why not just build it in. Perhaps replace display_name with a custom field in settings with options for what to display. In healthcare we would need first last and email or other id. I can see some conflicts would be possible in other programs if display_name is messed with too much. It would help to guard against such by using a custom field instead. Just a thought. There are many other ways.
Revive string if one side has not deleted: We have already discussed this.
These four things would make FEP much more marketable to healthcare. And I think it would be a good market. So for what it is worth, these are my observations.
- The topic ‘Four things to make this more useful for healthcare providers in US’ is closed to new replies.