To implement a search filter that will exclude certain providers from being available to members for messaging:

1. Create a new class that extends   HSPortal.Messaging.Settings.FilterInterface .

2. Implement the   ShouldExcludeRecipientFromResults()   method. This method loops through all available providers and must return   1   for each recipient you want to exclude and   0   for each recipient you want to include.

   The filtering criteria include:

   • AcceptsAttachments   - Boolean flag.

   • ClinicalGroupAddress   - Address object of type   HSPortal.API.Datagram.Providers.Address .

   • ClinicalGroupRecipientID   - ID of the   Recipient   object for the clinical group.

   • ClinicalGroupID   - ID of the   ClinicalGroup   object.

   • ClinicalGroupName   - Name of the clinical group.

   • RecipientID   - ID of the   Recipient   object for the provider at the clinical group.

   • ProviderID   - ID of the   Provider   object.

   • ProviderTitle   - Title of the provider.

   • ProviderSuffix   - Suffix for the provider.

   • FirstName   - First name of the provider.

   • LastName   - Last name of the provider.

   • Specialties   - List of specialty names.

   • Favorite   - Boolean flag to indicate if the provider is a favorite of the member doing the search.

   For example, if you wanted to exclude from a messaging search all providers from the “Physicians Group, Inc.” clinical group, the filtering code in your implementation of the method might look like this:

   Set pStatus = $$$OK
   Set tExclude = 0
       
   If (pRecipient.ClinicalGroupName = "Physicians Group, Inc.") {
           Set tExclude = 1
           }
           
   Quit tExclude
   

   IMPORTANT

   If you need to perform an expensive call to retrieve member-specific information, such as retrieving the providers in the member’s care team, you can use the   InitializeRecipientFilter()   method once in the initialization method. Then, you can add the relevant set of recipients to a local property so that each call to   ShouldExcludeRecipientFromResults()   can simply look up the provider locally. If you use the method, your code must call   ##super() ; see the class documentation for   InitializeRecipientFilter() .

3. Compile your class.

After creating your search filter, you must change a configuration setting in the Workbench to enable it.

To enable provider search filtering:

1. Log in to the Workbench as a user with the   Configuration Manager   role.

2. Go to the   Site Configuration Settings   page ( Setup   >   Site Configuration ).

3. Change the value of the   Provider search filter class   setting to the name of your custom class.

4. Select   Apply .

For each external system, answer the following questions:

1. Regarding messages sent   from   Personal Community   to   the external system:

   1. What APIs (if any) already exist?

   2. Is a new interface needed on the external system to support this?

   3. What message structures does the external system support as part of its existing workflows?

   4. Are those structures extensible?

   5. Are the message contents limited to plain text?

   6. What structures does the system’s message format support?

2. Regarding messages sent   from   the external systems   to   Personal Community:

   1. Can the system make calls to the Personal Community Secure Message API?

   2. What are the Workbench object IDs and assigning authority codes of the clinical group and provider? This information is required for meaningful use reporting within the Workbench.

   3. Is there a need to send messages with pre-written content?

   4. Are there events that should automatically trigger messages?

3. Regarding message flow:

   1. Can providers initiate communication with members?

   2. Can members respond to messages from providers?

4. Regarding recipient identification:

   1. How does the external system identify members (that is, members of Personal Community)?

   2. How does the external system identify its recipients such as providers or other staff?

   3. If the external system requires identifying recipients individually, how do messages differentiate one individual from another? (Personal Community has a group-oriented model, and processes all messages to each provider group uniformly; this requires each message to include content that identifies the particular member of that group, if necessary.)

   4. What is required so that the correct identifiers are available to ensure delivery to the correct recipient? (Note that Personal Community allows for site-specific properties to be defined for message flows, so identifiers may be stored this way.)

5. Regarding message tracking:

   1. Is it possible to allow for responses from members to be tied to the original message? (This generally requires a field to store the original message ID that was sent to the external system.)

6. Regarding varied implementations:

   1. If a particular system is in use for multiple activities, does it have different constraints for each activity?

   2. Does a particular system support different configurations, such as for different provider groups, which may require different behaviors for each group?

When a member sends a message, Personal Community determines how to route the message based on the message type (medical question, billing question, etc.) and the recipient (clinical group). Specifically, the following sequence of events occur:

1. Personal Community creates a message wrapper object that includes the underlying message as well as some information about the intended recipient (the care provider at a particular location).

2. Personal Community looks up the appropriate delivery interface based on the message type and clinical group (which comprise the message flow). This delivery interface allows Personal Community to communicate with the external system.

3. If the delivery interface class is a subclass of   HSPortal.Delivery.ExternalSystem , then Personal Community sends the message wrapper object to the   HSPortal_MessageHandler_ExternalSystem   business process.

4. The   HSPortal_MessageHandler_ExternalSystem   business process then calls the delivery interface’s   SendMessage   method (which is a user-overridden method) to control transmission of the message to the external system.   SendMessage   takes two arguments: the message wrapper object and the business process object.

5. The delivery interface’s   SendMessage   method   should not   contain code that communicates with the external system. Instead, it should send a message to a business operation that is responsible for delivering messages to the external system. The message should be sent using code such as:

   set status = pContext.SendRequestAsync("YourBusinessOperationName", pMessageWrapper)
   

   Note

   The code may also use the   SendRequestSync   method, but this method is not recommended, as it may delay feedback to the member.

6. The business operation that handles communication with the external system then performs most, if not all, of the following steps (also using user-implemented code):

   1. Examines the following pieces of information:

      • Member information associated with the incoming message.

      • Additional information about the member, such as the member’s identifiers for the external system.

      • Additional information about the recipient, which may be stored in the options for the delivery interface or may be tied to the provider involved.

   2. Formats the outgoing message according to the capabilities and requirements of the external system. (This also depends on the specific type of message being handled.)

   3. Sends the message to the external system using a protocol and transmission channel that the external system supports.

The delivery interface gathers any interface-specific configuration information and directs the message to the correct business operation. The delivery interface’s name also appears in the drop-down list when Workbench administrators configure a message flow.

To create a delivery interface for your external interface, and make it available in the Workbench, the steps are:

1. Extend the   HSPortal.Delivery.ExternalSystem   class.

2. Override the following methods in order to implement the required workflow behavior for your site:

   • %GetInterfaceName   – Displays the name of the messaging interface in the Delivery Interface list on the page for creating or modifying the message flow associated with a clinical group. (This is the   Create Flow   or   Modify Flow   page, available through   Setup   >   Clinical Groups   > the group name >   Create Message Flow   or the   Modify   link for an existing message flow for the clinical group.)

   • %MapOptionKeyToInternalValue   – If your interface has selectable options, allows an option key to be mapped to a value internal to Personal Community. See   HSPortal.Delivery.Workflow   for an example implementation.

   • SendMessage   – Uses the information in the message wrapper to assemble a message for the external system; uses either   SendRequestAsync   or   SendRequestSync   to send that message to the business operation that delivers messages to the external system.

     IMPORTANT

     Your subclass(es) of   HSPortal.Delivery.ExternalSystem   need to handle every message type supported by your external system. You must override the   SendMessage   method in each subclass, and must provide all the available information about the sender, recipient, and message to the external system.

3. Override the   Active   parameter and set its value to 1. This parameter controls whether or not the interface is available to be selected in the Workbench.

4. Compile the class.

Additional Configuration of the Delivery Interface

Each delivery interface can specify that some options should be specified on a per-flow basis using the   %GetConfigurationLayout   method, and then using the   %OnCreateRecipientMap   and   %OnUpdateRecipientMap   callbacks. The key feature here is that you can include information that identifies which inbox or pool messages for the flow should be sent to in the external system. In general, this information is specific to each message flow (that is, to each clinical group and message type), so that the information is stored and configured along with each flow. The value that you pass to   %GetConfigurationLayout   should ensure that any values entered by the user are stored under   Options.[SettingName] . For an example, see the   %GetConfigurationData   and   %GetConfigurationLayout   methods in the   HSPortal.Delivery.Workflow   class.

To be able to select a delivery interface when configuring a workflow group, you must first associate the delivery interface with the Personal Community production. To do this:

1. Logon to the Management Portal for the production as a user with the   %EnsRole_Administrator   role or one with greater privileges.

2. Set up the business operation associated with the delivery interface:

   1. In the Personal Community namespace, go to the   Production Configuration   page (from the Management Portal Home page,   Interoperability   >   Configure   >   Production ).

   2. On the   Production Configuration   page, under   Operations , select the   +   icon, to add a new business operation. This displays information the   Business Operation Wizard .

   3. Complete the fields on the wizard, specifying the required information about the code that communicates with the external system.

   4. Select   OK to save the business operation.

3. Set up the business process associated with the delivery interface:

   1. Also on the   Production Configuration   page, under   Processes , select the   +   icon, to add a new business process. This displays information the   Business Process Wizard .

   2. Complete the fields on the wizard, specifying the required information about the delivery interface.

   3. Select  OK to save the business process.

The delivery interface is now available for selection when setting up a message flow for a clinical group.

To associate a message delivery workflow with a clinical group, you must:

1. Log into the Workbench as a user with the   Provider Manager   role.

2. Go to the   Setup   tab.

3. In the activity pane, choose   Clinical Groups .

4. On the   Clinical Groups   page, select the group that is using the flow. This displays the   Clinical Group Details   page for the group.

5. On the   Group Details   page, near the bottom of the page, select the   Create message flow   button.

6. Enter the following values for the fields:

   1. Message Type   - Select the type of message that the flow uses (or   All   for all of them).

   2. Delivery Interface   - S elect your external system delivery interface   to use the external workflow or   Workbench Task   to use the Workbench workflow.

   3. Workflow Group   - This will appear if  Workbench Task   has been selected. Select the workflow group that will be processing the message tasks.
   4. Other Settings  - If your external system delivery interface defined additional settings, they will be displayed on this page.
   5. Active   - Select the   check box.
7. Select  Save.  

1. Lo g into the Workbench as a user with the  Configuration Manager  role.

2. Go to the  Configuration Application   page ( Setup  >  Configuration Application ) and select the  Feature Control  tab.  In the activity pane, select   Configure Messaging .  

3. Select  Edit Mode   to make edits to the fields described in the following steps.

4. To the right of the   Messaging box, ensure that the   Enable   checkbox is selected.

5. Once the   Configure Messaging section is expanded, select from the current settings:

1. • Allow patient to send messages -  allows messaging functionality for members. Once selected, you must choose at least one of the following message types:
     • Medical Question - allows members to send a message specifically labeled as a "medical question".
     • General Question - allows members to send a message specifically labeled as a "general question".
     • Billing Question - allows members to send a message specifically labeled as a "billing question".
   • Allow patient to send replies - allows members to reply back to a message sent by a provider.
2. After you have finished, select   Submit   at the bottom of the page to save your changes. 

The following content files relate to messaging, which you may wish to update:

Content Files for the Public Application

Help Files for the Workbench

Tasks

Messages

To modify page content:

1. In the Workbench, enable the setting that displays the source file for each page’s content in the public application:

   1. Log into the Workbench as a user with the Configuration Manager role.

   2. Go to the Site Configuration Settings page ( Setup > Site Configuration ).

   3. In the Content Settings section, select Highlight Personal Community content .

   4. Select Apply .

   This is also known as enabling content highlighting or enabling the debug flag .

2. If there is not already a custom copy of the content file, copy the existing file from

   <hspc-home>/base/content/en/

   to

   <hspc-home>/custom/content/en/

   Note

   If such a file already exists, do not create a new copy, as this may overwrite any customizations your organization has already made in it.

3. Edit the custom copy of the file as required for your organization.

   Note

   1. If this is a right to left language, the files should contain:

   <html dir= "rtl" ></html>

   The customer would then put their content within the tags.

4. Refresh the content for your organization's site.

To refresh content:

1. Log into the Workbench as a user who has the Configuration Manager role.

2. Go to the Content tab.

3. On the activity pane, select Content Updates . This displays the Content Updates page.

4. On the Content Updates page, choose Refresh Content .

This updates every aspect of each application to display the custom content, including text, images, and so on.